Front-end optimisation for faster WordPress websites

Action Photography is a WordPress powered site we recently launched. I’m using is as a case study to document some of the performance optimisation techniques we use to make faster WordPress websites.

Some of the steps are WordPress specific, but most can be applied to any website.

Post-development Vitals

The following were the performance vitals after developing the site. Measured with the Chrome inspector network panel.

  • 64 HTTP requests
  • 1.3mb of data transferred on page load
  • 9.15 second average load time

Performance Improvement Steps

  • Create a custom build of Moderniser, with only the properties we are targeting. Resulted in a file size reduction from 12kb to 8kb, 33%.
  • Merge development stylesheets. We worked with three developer-specific stylesheets in development. Resulted in two less HTTP requests.
  • Minimise CSS. We use Compass and Sass, editing the Compass config.rb file to compress CSS and strip comments reduced the file size from 85kb to 55kb.
  • Losslessly optimise images using Image Optim (most are too large for the Smush.it WordPress plugin). Removed 6.7mb from a total of 56.9mb of images, over 10%.

WordPress Specific

  • Manually integrate Font Awesome instead of using a plugin. Removed 2 HTTP requests.
  • Deregister unnecessary plugin styles, for example, the contact form, and load conditionally where required. Removed 3 HTTP requests.
  • Deregister comment-reply.js, because we’re not using comments. Removed 1 HTTP request.
  • Page caching with W3 Total Cache. Enables Gzipping, saving 75% on files that can be zipped. Makes pages seem to load instantly after an initial page load.

W3 Total Cache can concatenate and minimise all JavaScript too, which would reduce HTTP quests further. However the site is on the client’s own hosting, which unfortunately is running a Zeus server. Zeus does not support WordPress’s default pretty URL re-writing, and requires some extra configuration. Also, the W3 Total Cache CSS and JS minimising relies on .htaccess (Apache only) to do the URL re-writing for it’s cache-busting URLs. So it can’t be used on the current server.

Spriting the home page animation images would also significantly reduce http requests. The question for spriting and finding a Zeus-friendly minimising solution is time vs benefit. Our goal with performance optimisation is to focus the cost effective ways to make improvements.

Production Ready Vitals

Results, after these steps and caching:

  • 1.5s average page load time (on my machine and connection)
  • 1.2mb of data transferred on page load
  • 54 http requests

Read the full Action Photography case study.

Paddy O’Hanlon is a web designer and one of the principals at Logo24. He is a lover of good semantics, well documented and architected CSS, and beautiful, content-driven design. (Really the design-guise is a cover-up so he can covertly feed his travel addiction and climb many rocks around the world). He tweets @Paddy.

Comments make us happy