Tags: Shifter

Test Drive: Autoptimize for static WordPress sites

A deep dive into testing Autoptimize on Shifter demonstrating how it performs with static WordPress hosting and why you probably don’t need it.

If you just want the tl;dr of using Autoptimize on Shifter it’s this: don’t.

Nothing against Autoptimize, I personally think it’s a great plugin and offers a lot of benefits just not when using static WordPress on Shifter. To learn why, read on.

What is caching and optimization?

One of the most common questions about Shifter is: What about caching plugins? The answer we usually have for this question is simple. Caching plugins are not necessary when using Shifter. That answer is accurate but it’s also vague.

After some feedback and discussion with customers, community members at meetups and WordCamps, we realize there’s confusion around this topic. To try and clarify that, there are a few more things to consider.

We (the WordPress community) seem to use the words caching and optimization interchangeably. A lot of plugins offer both features so it makes perfect sense to use either term. After all, by adding caching you really are optimizing your site. Technically speaking, caching and optimization could mean very different things.

As an example, think of the differences between combining all of your CSS into a single file versus creating a static version of your about page. There are plugins that offer both features and others that specialize in one.

Why test Autoptimize

If you didn’t guess by the name, Autoptimize is an optimization plugin for WordPress. Autoptimize’s primary focus doesn’t seem to be caching which is why I wanted to test it on Shifter. Could Autoptimize improve performance? Let’s find out.

Shifter creates a completely static version of your WordPress site. All pages, posts, and assets are static and cached on our CDN once the site is generated. Adding a caching plugin to improve performance is redundant unless the plugin can also optimize what is rendered on the page. To use our example from before, that would mean combining all CSS into one file.

How we tested Autoptimize

We kept our process simple and used the same tools that our customers use and reference. Tools like Pingdom, WebPageTest, and GTMetrix. When using testing tools like these it is very important to note that these page testing tools are opinionated.

Opinionated in this case means that these tools measure things that a particular vendor believes to be good or bad. it’s also important to remember that these are page testing tools, not load testing tools. Getting an A or 100% on a page testing tool doesn’t mean you’re ready to serve 10,000 concurrent users. (All of our Shifter plans can handle this amount of traffic out of the box, but that’s a different topic.)

We tested with each of the three testing tools using the default twenty-twenty WordPress theme. The new theme offers everything you would want to test including images, CSS, JS, and a lot of demo content.


What we tested using Autoptimize

We started testing by creating a helper plugin. The helper plugin, called Shifter Cache Helper, ensured that, when the Shifter generator started, the cache of Autoptimize would be reset before Shifter generation began. Clearing out any old files when the Shifter generator starts is a crucial step because paths to CSS and JS files can break with each start and stop of the generator.

Establishing a Baseline

Now that we had a way to ensure Autoptimize would work as expected we established a baseline with the plugin disabled. No caching or optimization applied, just the twenty-twenty WordPress theme on Shifter.

Pingdom Results

Load time: 130ms
Requests: 7
Page size: 57kb

View the full results for each:


Our score to beat is 130 ms which seems hard to beat. It’s already low but let’s see if any of the settings offered by Autoptimize can improve our speed.

Minimum Settings

Screenshot of settings

Only checking the optimization of JS and CSS is the simplest way to get started, but this was stopped short because it broke the site. When testing with the above settings applied, the CSS and JS files resulted in a 404.

It appears that this was caused by missing PHP files. The CSS and JS files were saved as a PHP file on the static site which cannot be rendered on Shifter. Lucky for us Autoptimize offers an option to disable this.

Just a note: PHP files are not synced when the static site is created. This is a security feature.

Static Enabled

In the Autoptimize settings there is an option to enable static files. When enabled, it will render the sites’ assets as CSS and JS which no longer create PHP files. This seems to work. Just for good measure, we also enabled the option to optimize static assets for logged in users. This allowed us to view what would happen before we run the generator as a logged out user.

Pingdom Results

Load time: 138ms
Request: 7
Page size: 48.1kb

View the full results for each:


This test gave us the minimum requirements to get Autoptomize working on Shifter. With static WordPress, we need all of our assets to be static as well, and that checks out with Autoptomize. However, the load time increased. Not by much but it did go up. We could test this a few more times and the range could vary. Since it wasn’t a dramatic improvement we kept on testing.

Aggregate Enabled

Screenshot of settings

This test enabled CSS and JS concatenation. Concatenation is a fancy developer word for combining many things into one. For example, if you combined 3 small CSS files into one big file.

Combining static assets into a single file will only benefit you if your hosting provider does not support HTTP/2. The idea of combining files came about because servers at one time could only handle a few requests at a time. If you had 100 assets to download like images, your CSS file could be delayed and result in a long page load time.

That is no longer the case with HTTP/2 which allows us to download assets at the same time. Shifter supports HTTP/2 by default for all sites and all plans.

During this test, the JavaScript on our test site broke. I wasn’t sure why, but to move ahead I disabled this feature for JavaScript and tested again. This time I focused on CSS. It wasn’t long before I hit another snag. The CSS was also broken.

In the end, Aggregate did not work by itself. To use this feature I realized you need to enable another feature which inlines those Javascript and CSS files.

Aggregate Enabled, Inline CSS

Screenshot of settings

Since we weren’t getting any errors on our Javascript files, I decided to keep the same settings for Javascript. I also added the option to inline CSS since the CSS file was causing a 404 in the aggregate results.

And.. it works! Inlining and aggregating the CSS resolved the 404 error and the missing font. Since Shifter’s SSG does not modify CSS with our search and replace during Shifter site generation, the build the path in the CSS file remains unchanged. However, since we inline the CSS it’s available for search/replace because the CSS is not a part of the HTML.

Pingdom Results

Load time: 206ms
Requests: 4
Page size: 54.3kb

The important thing to note on this test is the time increased and the number of requested assets was reduced. Based on traditional optimization logic, fewer results resulting in a faster pagespeed doesn’t check out.

View the full results for each:



Screenshot of settings

There’s a few extras that you can apply, but they aren’t required and might not play well with your theme. The one setting I do like is the ability to remove the emojis JavaScript which now comes included with WordPress. If you don’t use emojis, or if you don’t support comments, then removing it is probably a good idea.

Pingdom Results

Load time: 124ms
Requests: 3
Page size: 37.8kb

This was the one exception where speed improved over no optimization plugins at all. Keep in mind it’s milliseconds which can vary from test to test and the number of assets requested is less than half.

View the full results for each:


Results Recap

The top performer was using all correct settings with Autoptimize and applying the extras which removed the WordPress Emoji JS file.

Is that really the winner though? I say no. I say this because the comparison between our test site with no optimization and our test with emojis removed is not a 1 to 1 comparison. By removing the emoji JavaScript completely, it’s not totally fair to call this a comparison since the site is now different.

Excluding the test with extras applied, the winner is the version of our test site without any optimizations applied. The default WordPress install using the default twenty-twenty theme loading at 130ms, outcompeted all of our optimized sites.

The next closest was our test that used Autoptimize with minimum settings and static settings enabled. The load time for that test was 137ms which is very close. But according to our tests, running a site with no optimization whatsoever is still faster, so why use optimization at all?

What benefits does Autoptimize offer?

In our case, not much. Shifter covers some of the functionality that Autoptimize offers as standard features. We create static assets without a plugin and the results are faster even when the number of assets is greater.

Should I use Autoptimize?

Sure, but not on Shifter. Adding a plugin with the goal of improving performance when the result gets you to the same place or less isn’t what we recommend. Keep your sites lean and focus on optimizing other areas of your site.

Let us know what you think. If you have a different experience or comment please let us know. If it’s helpful, we’ll add it!

Related Posts