We’ve run many tests on LoadStorm’s website and shared the results in different blog posts. These are the first set of experiments for our Web Performance Lab, and we hope you read them because the details can be very helpful to anyone learning about WordPress performance, web scalability and page speed. The results below are focused on page speed measurements – not scalability.

We’ve tested several individual optimizations such as page caching and deferring JavaScript. What we haven’t looked at, though, is how well those optimizations work when they’re put together. As we’ve mentioned before, after testing these performance optimizations, we’d always reverse them to go back to a clean slate. Since our first project is rapidly coming to a close, we can finally see what happens when everything is turned on at once.

As a quick recap, here’s everything we’re turning on or off for this combined test:

No holding back this time, we’re running the full battery of benchmarking tests on this setup in order to compare before and after by both location and browser, in addition to comparisons between pages.

Results

The results are in! How much did the site improve overall?

By implementing all the optimizations we showed in previous articles, we managed to improve the average load time of our site by 30%! (Averaged over all tested locations, browsers, and pages.) Let’s break this down a bit. First, let’s look at which locations improved the most:

For the individual optimizations, we ran all our WebPageTest speed tests from Dulles since it was the default and was the most reliable of the available locations. Dulles saw a pretty impressive 20% drop overall. It was the locations further away from us, though, that saw the most improvement, with Sydney and Tokyo both seeing improvements upwards of 40%.

Chrome was our browser of choice for all the individual optimizations, but how much improvement did the other browsers get out of putting together all optimizations?

Overall, it was a pretty even spread between the three browsers we tested. Improvements ranged from 26-33%, with Firefox seeing the most improvement.

Lastly, let’s look at how we improved each page.

On average, each page now loads in under 2 seconds! Awesome! As with the browsers, the spread was about even, with improvements ranging from 24-34%. The homepage saw the best improvement overall, probably since it had a few extra JavaScript files on it for the carousel that were optimized by moving them to the footer. (We’ve since gotten rid of the carousel entirely in our site’s redesign, so it’s kind of a moot point now.)

So here’s the question on everyone’s mind: Which optimizations had the biggest impact?

Note: The numbers for “Benchmark” and “Final” are different here than their “Grand Total” counterparts because these values are averages of just the results from Dulles/Chrome, whereas the earlier Grand Total graph was averaged against all tested locations and all tested browsers.

It’s pretty obvious that enabling Page Caching gave the greatest improvement, as load time nearly doubled when it was turned off. Moving the JavaScript to the footer had the second best impact, dropping the load time by 23.7%.

Conclusions

So what does this all mean for you? What information can you, the reader, gain from these experiments?

This type of data can give you an idea of what you should focus on first to get the biggest bang for your buck when doing performance optimization. To that end, here’s the list of everything we did to improve the front end, ordered by effectiveness:

  1. Enable Page Cache: 45.7% reduction in average load time
    • Calculating backwards from the actual test, enabling Page Caching through W3TC nearly halved our load time.
  2. Move JS to Footer: 23.7% reduction in average load time
    • Due to the way JavaScript loads and executes, deferring the requests for JS files until the end of the page greatly improves speed.
  3. Disable Cache Preload: 13.7% reduction in average load time
    • I still think this one was a strange one, but these are the results we got. Maybe we just had cache preload configured improperly, but disabling it actually boosted speed for us. Go figure.
  4. Combine JS: 13.2% reduction in average load time
    • Turn several JS files into one JS file so fewer requests are made.
  5. Disable ETags: 9% reduction in average load time
    • ETags add a bit of data to each request, so if you’re not making full use of them, it’s better to just disable them.
  6. Install CDN: 4.7% reduction in average load time
    • While CDN is last on this list for page speed, hooking LoadStorm up to a CDN had the biggest impact on its scalability. So if scalability is your priority rather than front-end optimization, this is what you should be looking into.

We’ve certainly learned a lot on this journey, and I hope you are able to take what we’ve learned and put it to use with tuning your own websites. This does not mark the end of the Web Performance Lab, just the end of this first project working with www.loadstorm.com. Details to come soon, but we’ll be returning with new projects, a new setup, and more data that will help you meet your performance goals. Stay tuned!

Similar Posts