Autoptimize power-up


This plugin extends Autoptimize to automatically create critical CSS rules. These rules inject the correct critical CSS in different types of pages to ensure these pages are rendered even before the full CSS is loaded, improving the “start to render time” and user experience. For this purpose the plugin integrates with, a 3rd party service, to have it generate the critical CSS.

Simply install and activate the plugin (you will need to have Autoptimize up and running), enter your API key and the plugin will automatically start work to create rules.

If you want to change settings or review the rules, you can find these by clicking the “critical css” tab on the Autoptimize plugin settings screen. There are “installation instructions” and more info in the FAQ.



  1. Install from your WordPress “Plugins > Add New” screen (search for Autoptimize)
  2. Activate the plugin.
  3. You will see a “Critical CSS”-tab in Autoptimize.
  4. Enter the API key from your
  5. (optional): create a default rule which can be used if no automated rule applies.
  6. (optional): create manual Path-based rules for specific pages to override automated rules. If you leave the critical CSS field of path-based rules empty, the plugin will automatically extract it.
  7. To get critical CSS going, make sure there are requests coming in that are not served by a page cache


Where do I get an API key from?

Please sign up at then go to API Keys. This is a premium service, so be sure to read the additional pricing information!

At the time of writing (4 May 2018) the price for using is:

£2/month for membership + £5/domain/month.

This means the total cost will be £7/month if you use this plugin for one site.

If you’re not sure yet; with the 30 day free trial, you have nothing to lose!

Will this work for inside paywalls or membership sites?

No; needs the pages for which it has to generate critical css to be publicaly visible to work.

What are the Terms of Service for usage


Why did nothing happen after I installed the plugin/ Why isn’t the critical CSS visible immediately?

Critical CSS generation is based on a job-queue. For jobs to be added to the queue, your site should have requests and those requests should not be served by a page cache (because in that case WordPress and Autoptimize are not triggered). If you want to speed things up, you can temporarily disable your page cache and click around on your website yourself.

Once a job is in the queue it can be executed and sent to and at one of the next queue runs the critical CSS is retrieved and turned into a rule and it will be used for the next matching request (again for a page not in page cache).

My hoster claims the plugin is time consuming, is this normal?

When just installed the plugin will be more active, generating new jobs and for most of those jobs making calls to As rules are automatically generated that way, the number of jobs and the number of requests to will go down significantly.

Most importantly; as the bulk of the work is done asynchronously (by the cronned queue processing job), there is no negative impact on the performance of your site, so your visitors will not notice any slowdown.

What if my hosts limits the time PHP processes can run?

Autoptimize power-up uses scheduled jobs to go over a queue with URL’s for which to fetch critical CSS. If there are many items in the queue, the process can take a couple of minutes to finish. If your hosts limits the time scheduled PHP processes can run, you can set the number of requests sent to (the “request limit”) under the Advanced Options.

I use a pagebuilder, so my pages are very different yet the same CCSS is applied?

As from AO CCSS 1.7 there is an (advanced) option you can activate to enforce PATH-based rules creation for pages so each page will end up with its own critical CSS.

Can I stop critical CSS being applied on some pages?

Yes; create a manual rule (can be both path- and conditional-tag based) and enter none for critical CSS. If the rule matches, no critical CSS will be added and the full CSS will be inlined instead.

I only see “N” jobs and no rules and I’m getting “WordPress cron”-warnings, what should I do?

If all jobs remain in “N” then wordpress “cron job” that does the queue processing is not getting triggered. To verify you can install the “wp crontrol”-plugin and then under Tools -> Cron Events look for “ao_ccss_queue” and check the “next run” time/ date.

If the “ao_ccss_queue” job is not there, you’ll have to de- and re-activate the “autoptimize critical css” plugin to have it re-register the queue-processing task.

If the “ao_ccss_queue” job is there, but has a “next run” date in the past, there is an issue with your site/ hosters WordPress cron and you will have to contact your hoster. Some hosters’ info on the topic: WP Engine, BlueHost, HostGator and SiteGround.


Excellent, and Then Some!

I have been using WordPress for 5 years. I recently switched to a popular masonry theme with a carousel gallery. Because it’s a popular theme and I have WP Rocket installed and my host (Siteground) uses Cloudflare, I had assumed the loading time would be okay with the new theme. I could not have been more mistaken. Even though I was using the same images as before, my site’s loading time was suddenly far slower than it had been with the older theme. Thank heavens for CriticalCSS. My site now loads in half the time than it did without CriticalCSS. Also, the developers of CriticalCSS have been incredibly helpful and responsive. I can’t recommend CriticalCSS highly enough.

I love this plugin!

My site has over 100 pages and the thought of using a manual critical css generator was daunting. This plug in does the job well and easily. The support was amazing as well when I had a little conflict with my theme. Thank you! You saved me a lot of work!

Read all 4 reviews

Contributors & Developers

“Autoptimize power-up” is open source software. The following people have contributed to this plugin.




  • remove a line of debug code


  • improvement: create path-based rules for pages by default for new installs (change the setting manually when upgrading from 1.9.0)
  • bugfix: recheck invalid API key during the daily maintenance to avoid it getting stuck
  • bugfix: don’t strip slashes in generated CCSS
  • update to latest version of the “persist admin notice dismissal” framework library


  • improvement: make some notices dismissable
  • improvement: job queue cleanup logic improved
  • improvement: there now is a different error-message for “bad API key” vs “could not check your API key”
  • improvement: logic added to be able to warn if would be down
  • bugfix for subfolder installations of WordPress resulting in wrong URL’s to be sent to
  • bugfix: some EDD conditionals were empty in the dropdown
  • bugfix for notice “Argument #2 is not an array /wp-content/plugins/autoptimize-criticalcss/inc/core.php: 243”


  • improvement (efficiency): don’t submit request to if the same one (same type and same hash) has been submitted already in the current queue processing run
  • improvement (UI): job queue panel is collapsable and only shown if no AUTO rule is available yet
  • improvement (debugging): add rule info in comment in Critical CSS if “debug” is on
  • improvement (conditional rules): added is_attachement as additional core conditional tag
  • new: handle (future) resultStatus (HTML_404) from


  • new: (advanced) option to allow PATH-based rules to be auto-created for pages allowing different CCSS for each page.
  • improvement: workaround a quirk in WordPress core’s is_front_page which also returns true for e.g. /page/12
  • improvement: ensure path-based rules with non-ascii characters can match the path


  • new: (advanced) option to disable CCSS injection for logged on users (as the CCSS is always extracted from an anonymous visitor context, the CCSS might not apply for logged in users).
  • improvement: warn when the job queue processing task is not getting triggered (due to WordPress cron issues).
  • improvement: also submit a request to if a rule exists but the file containing the CCSS does not exist or is empty.
  • added info about cron issues to the FAQ.


  • bugfix: when deactivating make sure lockfile is removed before removing cache directory.
  • bugfix: make sure Autoptimize’s “inline & defer above the fold CSS” is not removed when submitting criticalcss API key.
  • bugfix: ensure order of rules does not depend on when they were added, but is custom post types first, template 2nd, plugins (Woo, EDD, BuddyPress & BBPress) conditional tags and lastly the WordPress core conditionals.
  • bugfix: make sure non-core conditionals are checked against.


  • move cache to wp-content/uploads/ao_ccss/ (to prevent files from being deleted by a sometimes overzealous WP Super Cache purge)
  • warn if DISABLE_WP_CRON is true
  • update default viewport size in advanced settings


  • New: you can now create manual rules to make sure no Critical CSS is injected by entering none as critical CSS.
  • Improvement: make sure “advanced options” are visible when “activate inline & defer” warning is shown
  • Further copy changes in description (thanks for the great feedback Paul!)


  • New advanced option: “Fetch Original CSS”
  • Minor copy changes in Key settings panel and FAQ.


  • Changes to queue processing to cater for hosts with hard limits on PHP processes duration


  • Extra info on the API key entry page


  • Initial release