Boost WordPress performance: Faster localization, (on the fly) dynamic image resizing and CDN support for images.
WPPP overrides WordPress' default implementation by using the override_load_textdomain hook. The fastest way for translations is using the native gettext implementation. This requires the PHP Gettext extension to be installed on the server. WPPPs Gettext implementation is based on Bernd Holzmuellers Translate_GetText_Native implementation. Gettext support is still a bit tricky and having the gettext extension installed doesn't mean it will work.
As second option WPPP features a complete rewrite of WordPress' MO imlementation: MO_dynamic (the alternative MO reader). The default WordPress implementaion loads the complete mo file right after a call to load_textdomain, whether any transaltions from this textdomain are needed or not. This needs quite some time and even more memory. Mo_dynamic features on demand loading. It doesn't load a mo file until the first translation call to that specific textdomain. And it doesn't load the entire mo file either, only the requested translation. Though the (highly optimized) search for an individual translation is slower, the vastly improved loading time and reduced memory foot print result in an overall performance gain.
Caching can further improve performance. When using MO_dynamic with activated caching, translations get cached using WordPress Object Cache API. Front end pages usually don't use many translations, so for all front end pages one cache is used per textdomain. Back end pages on the other hand use many translations. So back end pages get each their own individual translation cache with one base cache for each textdomain. This base cache consists of those translations that are used on all back end pages (i.e. they have been used up to admin_init hook). Later used translations are cached for each page. All this is to reduce cache size, which is very limited on many caching methods like APC. To even further reduce cache size, the transaltions get compressed before being saved to cache.
Images don't get resized on upload, instead only the meta data for the resized images is created and the actual images are created on demand. WPPP extends all registered image editors to prevent creation of intermediate image sizes by overriding the multi_resize function. As the classes get extended dynamically this should work with an image editor implementation. Serving the intermediate sizes is done using rewrite rules. Requests to none existent intermediate images are redirected to a special PHP file which uses SHORTINIT to only load a minimum of necessary PHP code to improve performance. Redirection is done via htaccess. If the requested file does exists it is served directly.
When a none existend image is requested WPPP first checks if the full size version of the requested image exists in the database. If it does, next is checked if the requested image size corresponds to a registered image size (either one of the default sizes "thumbnail", "medium" or "large" or any by themes or plugins registered sizes). This check also tells WPPP if to crop the image while resizing. Only if this check passes the intermediate image is created. This prevents unwanted creation of thumbnails.
Requires: 3.8.1 or higher
Compatible up to: 4.2.2
Last Updated: 2015-4-24
Active Installs: 1,000+
2 of 6 support threads in the last two months have been resolved.
Got something to say? Need help?