Autoptimize speeds up your website and helps you save bandwidth by aggregating and minimizing JS, CSS and HTML.
It concatenates all scripts and styles, minifies and compresses them, adds expires headers, caches them, and moves styles to the page head, and scripts to the footer. It also minifies the HTML code itself, making your page really lightweight.
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.
If you have render-blocking JS: be sure not to tick the "force JS in head" if not absolutely needed.
If you have render-blocking CSS: consider to "inline" or "inline and defer" your CSS. There's more info on these topics below.
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 and esp. http://jonassebastianohlsson.com/criticalpathcssgenerator/ is an easy solution if you're not into node.js yourself.
The short answer: if you just want to improve your (mobile) pagespeed score; yes, otherwise maybe not.
Back in the days CSS optimization was easy; put all CSS in your head, aggregating everything in one CSS-file per media-type and you were good to go. But ever since Google included mobile in PageSpeed Insights and started complaining about redering blocking CSS, things got messy (see "deferring CSS" elsewhere in this FAQ). One of the solutions is inlining all your CSS, which as of Autoptimize 1.8.0 is supported.
Inlining all CSS has one clear advantage (better PageSpeed score) and one big disadvantage; your base HTML-page gets significantly bigger. The fact that the HTML gets heavier as such is not a huge issue; when looking at performance for a single page request/ response, performance will be better, as there's no overhead of one or more extra requests for CSS-files. But when looking at a test that includes multiple requests (let's say 5), performance will be worse, as the CSS-payload is sent over whereas normally the seperate CSS-files would not need to be sent any more as they would be in cache.
So the choice should be based on your answer to some site-specific questions; what is your site's bounce rate? How many pages per visit do your visitors request? If you have a high bounce rate and a low number of average pages per visit, inlining CSS looks like a good idea. But with a high number of pages/ visit, it's probably not a good idea. Except if all you care about is a stellar PageSpeed-score, off course.
You can find more information on this topic in this blog post.
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.
You can however keep the cache size at an acceptable level by either:
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 behing the aggregated on, to change the defer-attribute on the aggregated JS script-tag, ... There are examples for many filters in autoptimize_helper.php_example.
Copy it to /wp-content/plugins/autoptimize_helper.php and activate it in WordPress' plugin page. After that you can simple remove the one of the comment-sequences (double-slash) to activate one (or more) of the functions in there.
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!
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-seperated exclusion list. The exact identifier string to use can be determined this way:
If your blog doesn't function normally after having turned on Autoptimize, here are some pointers to identify & solve such issues using "advanced settings":
In some rare cases the CSS minification component currently used by Autoptimize crashes due to a lack of resources (see detailed technical explanation here). You can in that case either disable CSS optimization, try to exclude specific CSS from being aggregated or activate the legacy minifiers which don't have that problem. The latter can be accomplished by adding this to your wp-config.php:
The "legacy minifiers" will remain in Autoptimize "for ever" and changes to wp-config.php are not affected by core-, theme- or plugin-upgrades so you should be good to go.
Starting with version 1.6.6 Autoptimize excludes everything inside noptimize tags, e.g.:
<!--noptimize--><script>alert('this will not get autoptimized');</script><!--/noptimize-->
You can do this in your page/ post content, in widgets and in your theme files (consider creating a child theme to avoid your work being overwritten by theme updates).
Yes, if you want to serve files from e.g. /wp-content/resources/aggregated_12345.css instead of the default /wp-content/cache/autoptimize/autoptimize_12345.css, then add this to wp-config.php:
If you renamed your wp-content-folder, you can tell Autoptimize about that with;
define( 'AUTOPTIMIZE_WP_CONTENT_NAME','/content' );
Just fork Autoptimize on Github and code away!
Requires: 2.7 or higher
Compatible up to: 4.1.1
Last Updated: 2015-1-24
Active Installs: 50,000+
58 of 76 support threads in the last two months have been resolved.
Got something to say? Need help?