Plugin / Autoptimize

HTTP/2 is a great step forward for sure, reducing the impact of multiple requests from the same server significantly by using the same connection to perform several concurrent requests. That being said, concatenation of CSS/ JS can still make a lot of sense, as described in this css-tricks.com article and this blogpost from one of the Ebay engineers. The conclusion; configure, test, reconfigure, retest, tweak and look what works best in your context. Maybe it’s just HTTP/2, maybe it’s HTTP/2 + aggregation and minification, maybe it’s HTTP/2 + minification (which AO can do as well, simply untick the “aggregate JS-files” and/ or “aggregate CSS-files” options). And Autoptimize can do a lot more then “just” optimizing your JS & CSS off course 😉

Although Autoptimize comes without any warranties, it will in general work flawlessly if you configure it correctly. See “Troubleshooting” below for info on how to configure in case of problems.

Starting from AO 2.1 WordPress core’s jquery.js is not optimized for the simple reason a lot of popular plugins inject inline JS that is not aggregated either (due to possible cache size issues with unique code in inline JS) which relies on jquery being available, so excluding jquery.js ensures that most sites will work out of the box. If you want optimize jquery as well, you can remove it from the JS optimization exclusion-list (you might have to enable “also aggregate inline JS” as well or switch to “force JS in head”).

If not “forced in head”, Autoptimized JS is not render blocking as it has the “defer” flag added. It is however possible another plugin removes the “defer”-flag. Speed Booster Pack was reported doing this, but the behavior has not been confirmed yet.

With the default Autoptimize configuration the CSS is linked in the head, which is a safe default but has Google PageSpeed Insights complaining. You can look into “inline all CSS” (easy) or “inline and defer CSS” (better) which are explained in this FAQ as well.

CSS in general should go in the head of the document. Recently a.o. Google started promoting deferring non-essential CSS, while inlining those styles needed to build the page above the fold. This is especially important to render pages as quickly as possible on mobile devices. As from Autoptimize 1.9.0 this is easy; select “inline and defer CSS”, paste the block of “above the fold CSS” in the input field (text area) and you’re good to go!

There’s no easy solution for that as “above the fold” depends on where the fold is, which in turn depends on screensize. There are some tools available however, which try to identify just what is “above the fold”. This list of tools is a great starting point. The Sitelocity critical CSS generator and Jonas Ohlsson’s criticalpathcssgenerator are nice basic solutions and http://criticalcss.com/ is a premium solution by the same Jonas Ohlsson. Alternatively this bookmarklet (Chrome-only) can be helpful as well.

The short answer: probably not. Although inlining all CSS will make the CSS non-render blocking, it will result in your base HTML-page getting significantly bigger thus requiring more “roundtrip times”. Moreover when considering multiple pages being requested in a browsing session the inline CSS is sent over each time, whereas when not inlined it would be served from cache.

Autoptimize does not have its proper cache purging mechanism, as this could remove optimized CSS/JS which is still referred to in other caches, which would break your site. Moreover a fast growing cache is an indication of other problems you should avoid. Instead you can keep the cache size at an acceptable level by either: disactivating the “aggregate inline JS” and/ or “aggregate inline CSS” options excluding JS-variables (or sometimes CSS-selectors) that change on a per page (or per pageload) basis. You can read how you can do that in this blogpost. Despite above objections, there are 3rd party solutions to automatically purge the AO cache, e.g. using this code or this plugin, but for reasons above these are to be used only if you really know what you’re doing.

When clicking the “Delete Cache” link in the Autoptimize dropdown in the admin toolbar, you might to get a “Your cache might not have been purged successfully”. In that case go to Autoptimizes setting page and click the “Save changes & clear cache”-button. Moreover don’t worry if your cache never is down to 0 files/ 0KB, as Autoptimize (as from version 2.2) will automatically preload the cache immediately after it has been cleared to speed further minification significantly up.

When clearing AO’s cache, no page cache should contain pages (HTML) that refers to the removed optimized CSS/ JS. Although for that purpose there is integretion between Autoptimize and some page caches, this integration does not cover 100% of setups so you might need to purge your page cache manually.

Cloudflare Rocket Loader is a pretty advanced but invasive way to make JavaScript non-render-blocking, which Cloudflare still considers Beta. Sometimes Autoptimize & Rocket Loader work together, sometimes they don’t. The best approach is to disable Rocket Loader, configure Autoptimize and re-enable Rocket Loader (if you think it can help) after that and test if everything still works. At the moment (June 2017) it seems RocketLoader might break AO’s “inline & defer CSS”, which is based on Filamentgroup’s loadCSS, resulting in the deferred CSS not loading.

Autoptimize is not a simple “fix my Pagespeed-problems” plugin; it “only” aggregates & minifies (local) JS & CSS and images and allows for some nice extra’s as removing Google Fonts and deferring the loading of the CSS. As such Autoptimize will allow you to improve your performance (load time measured in seconds) and will probably also help you tackle some specific Pagespeed warnings. If you want to improve further, you will probably also have to look into e.g. page caching and your webserver configuration, which will improve real performance (again, load time as measured by e.g. https://webpagetest.org) and your “performance best practise” pagespeed ratings.

A whole lot; there are filters you can use to conditionally disable Autoptimize per request, to change the CSS- and JS-excludes, to change the limit for CSS background-images to be inlined in the CSS, to define what JS-files are moved behind the aggregated one, to change the defer-attribute on the aggregated JS script-tag, … There are examples for some filters in autoptimize_helper.php_example and in this FAQ.

Starting from version 1.7.0, CDN is activated upon entering the CDN blog root directory (e.g. http://cdn.example.net/wordpress/). If that URL is present, it will used for all Autoptimize-generated files (i.e. aggregated CSS and JS), including background-images in the CSS (when not using data-uri’s). If you want your uploaded images to be on the CDN as well, you can change the upload_url_path in your WordPress configuration (/wp-admin/options.php) to the target CDN upload directory (e.g. http://cdn.example.net/wordpress/wp-content/uploads/). Do take into consideration this only works for images uploaded from that point onwards, not for images that already were uploaded. Thanks to BeautyPirate for the tip!

Autoptimize supports this, but it is not enabled by default because non-local fonts might require some extra configuration. But if you have your cross-origin request policy in order, you can tell Autoptimize to put your fonts on the CDN by hooking into the API, setting autoptimize_filter_css_fonts_cdn to true this way; add_filter('autoptimize_filter_css_fonts_cdn',__return_true);

Nothing, when on Cloudflare your autoptimized CSS/ JS is on the Cloudflare’s CDN automatically.

If your webserver is properly configured to handle compression (gzip or deflate) and cache expiry (expires and cache-control with sufficient cacheability), you don’t need Autoptimize to handle that for you. In that case you can check the “Save aggregated script/css as static files?”-option, which will force Autoptimize to save the aggregated files as .css and .js-files (meaning no PHP is needed to serve these files). This setting is default as of Autoptimize 1.8.

Both CSS and JS optimization can skip code from being aggregated and minimized by adding “identifiers” to the comma-separated exclusion list. The exact identifier string to use can be determined this way: if you want to exclude a specific file, e.g. wp-content/plugins/funkyplugin/css/style.css, you could simply exclude “funkyplugin/css/style.css” if you want to exclude all files of a specific plugin, e.g. wp-content/plugins/funkyplugin/js/*, you can exclude for example “funkyplugin/js/” or “plugins/funkyplugin” if you want to exclude inline code, you’ll have to find a specific, unique string in that block of code and add that to the exclusion list. Example: to exclude , the identifier is “funky_data”.

After having installed and activated the plugin, you’ll have access to an admin page where you can to enable HTML, CSS and JavaScript optimization. According to your liking, you can start of just enabling all of them, or if you’re more cautious one at a time. If your blog doesn’t function normally after having turned on Autoptimize, here are some pointers to identify & solve such issues using “advanced settings”: If all works but you notice your blog is slower, ensure you have a page caching plugin installed (WP Super Cache or similar) and check the info on cache size (the soution for that problem also impacts performance for uncached pages) in this FAQ as well. In case your blog looks weird, i.e. when the layout gets messed up, there is problem with CSS optimization. Try excluding one or more CSS-files from being optimized. You can also force CSS not to be aggregated by wrapping it in noptimize-tags in your theme or widget or by adding filename (for external stylesheets) or string (for inline styles) to the exclude-list. In case some functionality on your site stops working (a carroussel, a menu, the search input, …) you’re likely hitting JavaScript optimization trouble. Change the “Aggregate inline JS” and/ or “Force JavaScript in head?” settings and try again. Excluding ‘js/jquery/jquery.js’ from optimization (see below) and optionally activating “Add try/catch wrapping“) can also help. Alternatively -for the technically savvy- you can exclude specific scripts from being treated (moved and/ or aggregated) by Autoptimize by adding a string that will match the offending Javascript or excluding it from within your template files or widgets by wrapping the code between noptimize-tags. Identifying the offending JavaScript and choosing the correct exclusion-string can be trial and error, but in the majority of cases JavaScript optimization issues can be solved this way. When debugging JavaScript issues, your browsers error console is the most important tool to help you understand what is going on. If your theme or plugin require jQuery, you can try either forcing all in head and/ or excluding jquery.js (and jQuery-plugins if needed). If you can’t get either CSS or JS optimization working, you can off course always continue using the other two optimization-techniques. If you tried the troubleshooting tips above and you still can’t get CSS and JS working at all, you can ask for support on the WordPress Autoptimize support forum. See below for a description of what information you should provide in your “trouble ticket”

AO minifies excluded JS/ CSS if the filename indicates the file is not minified yet. As of AO 2.5 you can disable this on the “JS, CSS & HTML”-tab under misc. options by unticking “minify excluded files”.

Make sure you’re not running other HTML, CSS or JS minification plugins (BWP minify, WP minify, …) simultaneously with Autoptimize or disable that functionality your page caching plugin (W3 Total Cache, WP Fastest Cache, …). Try enabling only CSS or only JS optimization to see which one causes the server error and follow the generic troubleshooting steps to find a workaround.

If you are running Apache, the htaccess file written by Autoptimize can in some cases conflict with the AllowOverrides settings of your Apache configuration (as is the case with the default configuration of some Ubuntu installations), which results in “internal server errors” on the autoptimize CSS- and JS-files. This can be solved by setting AllowOverrides to All.

Domain mapped multisites require Autoptimize to be initialized at a different WordPress action, add this line of code to your wp-config.php to make it so to hook into setup_theme for example: define( 'AUTOPTIMIZE_SETUP_INITHOOK', 'setup_theme' );

Autoptimize does a number of checks before actually optimizing. When one of the following is true, your pages won’t be optimized: when in the customizer if there is no opening