Performance: A Case Study

I’m going to start writing sister posts to talks that I give to make it easier to reference the information. This post is attached to a talk I gave last year at the Fort Collins WordPress Meetup. You can find the presentation slides here.

Why bother with performance?

Performance is a crucial piece of development and content marketing. Having a site that runs quickly and doesn’t frustrate your visitors will make you money and increase conversions significantly.

On average, each 1-second delay in loading time means:

  • 11% fewer page vies
  • 16% decrease in custom satisfaction
  • 7% loss in conversions

If you have a site that loads in 20 seconds, you’re losing a huge amount of your traffic and potentially advertising dollars simply because your site is inconveniently slow. This means a loss of ROI on your site. On the flip side, your ROI increases dramatically from speeding your site up.

  • Amazon increased revenues by 1% for every 100ms of improved loading time
  • Yahoo increased traffic by 9% for every 400ms of improvement
  • Mozilla dropped page load time by 2.2 second and saw an estimated 60 MILLION more downloads per year as a result

General speed concepts

There are few concepts that are crucial to understanding front-end performance.

Smaller sized objects

You have to load resources on a web page to display anything. Images, videos, CSS, JS all have to be externally loaded onto the page for a user to have a good experience. However, if we can decrease the size of each resource that we load, the user will have a much better experience.

Less HTTP Requests

On the same line, if we can reduce the number of requests, the user will see more faster. At the time of writing this, HTTP/1.1 is still the de-facto technology. HTTP/1.1 can only download so many objects at once, let’s say 5 at a time. So, if you have 60 resources to download on a page the browser will download 5, and then the next 5, and then the next 5 and on and on until we’re done. Each chunk takes a while and results in a slower site because it has to wait for the previous ones.

Optimized Rendering Path

Along the same lines as the other 2 points, there is a preferred rendering path in the browser. Javascript is a render-blocking resource. If you load your Javascript at the very top of the page, the browser will stop downloading the other resources, download the js, parse the js, and run the js before attempting any other resources. This slows down the entire page’s rendering time significantly.

The Site


The site we’re talking about today is Cheba Hut. This client came to us at Old Town Media wanting changes to their site but we quickly discovered that it needed a complete rebuild.


  • Static HTML site leveraging Cloudflare
  • Average of 23 seconds to load!
  • ~ 15 mb page weight
  • 170 resources loaded per page

This resulted in:

  • 2,549 hours a year of waiting
  • 4.837 TB a year in bandwidth
  • $368,640 a year in end-user bandwidth delivery costs

We rebuilt the site in WordPress and ended up with a significantly faster product.

  • .75 second average page load time
  • 2.4mb page weight
  • 61 resources per page load

Diagnosing the Problem

The Overview – Pingdom Tools

Pingdom Tools gives you a great 10,000-foot overview of the issues on a site. You can quickly work down the waterfall chart and see what’s taking the longest to load and get some basic stats on the the page you’re testing.

Practical Tips – Google Pagespeed Insights

Diving in a little deeper we have Google’s Pagespeed Insights tool. Pagespeed tests and instead of giving you data about load time, it gives solid recommendations on how to fix any identified problems and even optimizes your resources and packages them up for you.

In Depth Analytics – Webpage Speed Test

Webpage Speed Test is the powerhouse of all these tools. It takes quite a while to process, but gives more data and analysis than any of the others. You can run multiple tests at once from multiple locations and even run some powerful scripts such as a hosts re-direct.

The Build

The first step when optimizing a site is to get rid of every resource that you possibly can. Unneeded images, JS, and CSS are the the bane of an optimizer. By removing these unnecessary assets you can free up the waterfall for the important assets.

This case was no different, we were able to remove almost 2600 lines of HTML, 8 JavaScript files, and 5 CSS files.


The assets that we did have to keep, we re-wrote and refactored. The below JS snippet is a re-written version of almost 800 lines of code to control a single function. This brings down the load time and rendering time of the JS file significantly and kept the JS from blocking the rest of the assets.



Even more, you can defer or async the JavaScript that is loaded. Async loading allows the asset to load inline with the other resources – it essentially becomes the same as images and CSS in the waterfall. Defer defers the loading of the entire asset until the rest of the resources have been handled. This is a powerful tool when dealing with JS because you can completely delay the rendering delay.

Mobile-first CSS

There are several approaches to responsive CSS but the newest and most effective from a performance perspective is mobile-first. Mobile first involves taking the basic styles that apply to both mobile designs and desktop designs and and placing them in you base stylesheet and then adding features via min-width media queries. This is progressive enhancement.

The theory behind this is that tablets and desktops are usually on stable, Wifi Internet connections whereas your mobile views are most likely to be on 3G or 4G networks and would take longer to load. By placing smaller assets in your base stylesheet and only loading the larger versions on a desktop view, you save your user’s bandwidth and loading time.

SVGs vs. Images

SVGs are code that represents paths and basic shapes. They can be used to replace large and unwieldy images in a site and prevent the loading of a huge image. In this case, I replaced a large and highly styled map of the US and franchise locations with a SVG version of the US – this saved me from having to use a 300mB PNG representation of the states.


mages are the largest type of resource that you’ll likely be loading on your website. Therefore, paying attention to the size and type of images used is very important.


The first and most important thing to do when dealing with images is to compress them for web. Images coming straight out of Photoshop or God forbid Illustrator are very heavy and generally meant to retain their quality. Photoshop was built for photographers and is therefore unlikely to shed any quality unless you force it. Running all of your images through a compressor will remove unnecessary EXIF data, leftover layers, and leave a much smaller photo.

Popular Compressors:

Event Trigger Images

If you can avoid loafing images at page load entirely, that’s even better. There are multiple ways to trigger an image to load, but the most popular is through lazy loading. JS plugins will watch the bottom of your screen as you scroll down the page and load an image onto the page only when you get within X pixels of the top of the image. This prevents it from loading at render time and keeps a smooth experience for the user.

We took a slightly different route and handled our sandwich selector on the site carefully. Previously, all ~40 images were loaded at page load time – one for each sandwich that Cheba Hut makes. Instead, we hid the sandwich from the page load and only loaded it when the user clicked on the sandwich, thereby expressing intent to view it.

CSS Sprites

Making sprites is the act of combining several small images and loading them in using CSS – thereby reducing the total number of resources loaded on the page. We used this to cut down on the number of images by 6.

Choosing the Right File Type

Finally, choosing between a PNG and JPG image is vital to loading images wisely. PNGs and JPS each have their very specific purpose and choosing the right one can significantly reduce loading time:

PNGs should only be used when the image is extremely simple or has transparency in it. They should never be used for photographs or when there’s a large amount of complexity.

JPGs are best when there’s no transparency – background images, photographs, etc.

By using a JPG instead of a PNG for the map background on Cheba Hut, we dropped 50% of the file size on that single file – over 200kB!


Use a WordPress Host

WordPress hosts have the advantage f being able to optimize extremely well for a single application – WordPress and only WordPress. They’re more expensive, but it pays off because they can finely tune their server setup and caching to provide a huge speed boost.

Else, Use a Caching Plugin

If you can’t convince your client to go with an expensive WP host, use a caching plugin. This will compress and zip the files used on each page load and deliver them statically to each subsequent user.

Also, CDNs Are Awesome

Finally, CDNs are a life saver when it comes to performance. A CDN has servers all across the globe and the ability to distribute your cached site from whichever one is the closest to the user, shaving off microseconds or even whole seconds from the delivery of files to the browser.