A slow website affects customer happiness, increases abandonment, lowers brand experience, impacts SEO, frustrates site admins, and just kinda makes everything suck. We’ve been "under the hood" performance tuning websites for clients for over 15 years. In our Improving Website Performance Series, we'll help you establish a baseline for your site, review the key levers we look to for performance improvements, and point you in the right direction as you get started.

What’s the cache?

Caching is a big aspect of website performance, so it gets its own section in this series. A cache that is disabled, improperly bypassed, or misconfigured can be a huge penalty for performance. Caching is often disabled during the development process so changes are seen immediately, but it should always be in use once your website is live (your production site).
 
You don’t need to know the inner workings of caching, but we’ll walk through:

1. How caching improves performance.
2. The three main cache types, including browser, application, and server. Sometimes you need to “clear” one—or all—of them to see a change.
3. How caching is largely a “set it and forget it” one-time fix (those are nice, aren't they?).

Cache types

There are different caches typically at work — all with the same goal of improving speed for users while tapping into the efficiency of the internet and not wasting bandwidth. We’ve organized them into three buckets, and your website will utilize all three:

1. Browser-level caching
2. Application caching
3. Server caching 

Browser-level caching: First load vs subsequent loads

Somewhere along the way, browser companies (Chrome, Firefox, Safari, Microsoft) started to realize that many (most) elements on a web page don’t need to be served to a user with every single page request. Things like CSS, Javascript, images, videos, fonts, and so on — those hundreds of requests that make up a single page — can be downloaded the first time, but then really don’t need to be repeatedly downloaded the next time you visit a page. This means the first time a page loads, it will be slower than the second time.
 
For example, when a user visits our Bear Group website for the very first time, everything needs to be downloaded (as shown below on a Developer Tools > Network screenshot from our homepage). You can see images and a custom font are just a few of the 133 elements on this single homepage. It’s 2.6mb of assets that needed to be transferred from our server to your computer, and you can see the time each took to get there.

Then on a second visit to the page, you can now see that only 51Kb of assets need to be transferred. The page still needs 5.2mb of total assets, but things like images that make up the page are being served from my local computer browser cache (memory). Look at what happens to the time — it’s so fast they just label it as 0ms or instant. 
 
So all the biggest elements on the page are being served from your local computer. It’s a neat trick and the point is that the speed of your first-page load (pre-cache) versus your second load (post-cache) makes a big difference in the user experience of a page. 
 

Application-level caching

Inside your content management system (CMS) or eCommerce platform, there are usually configuration settings related to performance. For example in Drupal, there is a “Page Cache” which essentially pre-builds a page. This means that when your site gets a call for your homepage, the rendered version of it is already built and sitting in memory on your server. This is that very first item that gets returned when someone hits your site — it’s the concept of “latency” from our Server post in this series. 
 
You can reduce your application latency by having the page cache enabled. Then instead of having to build it, the application just retrieves the pre-built page.
 
For example, in the Drupal CMS performance admin screenshot below, you can see that we have Drupal’s page caching enabled and it’s set to auto-refresh every 15 minutes. We also have aggregated all CSS and Javascript together into singular, compressed files. This is a quick performance win if page caching was previously disabled (which it usually is on non-production environments).
 

Some aspects of your page shouldn’t be flattened and cached. These are dynamic elements that are changing and need to be loaded real time for the user. 

As seen in the warning above, most CAPTCHA methods need to be recreated at run-time to function properly. That can mean a portion of your page (or the whole page) is not able to be served from a cache. This can also come up on sites where customers have accounts, and log in to see something unique. A good way to think about it is if it’s something that is going to change for each user’s page load or needs to be updated less than every 15 minutes, it probably can’t be pre-built and cached in the application.

Server-caching and CDNs

Finally, your web server is made up of a stack of software. There are a few specific caching technologies like Memcache, Varnish, and Redis, which are server-side caching software that is available at any modern hosting company. These function in a similar way to a browser cache, where anything static is pre-processed and stored in the RAM on your server (the fastest way to return the pre-built page). 
 
You won’t need to install the server-side caching software, but your WebOps person or developer might need to tune them — which typically comes down to memory allocation.
 
Some providers like Magento Cloud Commerce provide reports on server performance and tuning suggestions as part of their support. This is a great resource to fine-tune the performance of the environment and they’re usually quite quick to adjust for a skilled WebOps person.
 
A Content Delivery Network (CDN) is another great technology to speed up the internet. Akamai was one of the first, but today there are many options that are often bundled with other services like Fastly and Cloudflare. 
 
The way CDNs work is by replicating your site’s static assets (like images, CSS, JS, etc) on “edge servers” that are just one hop away from the main internet backbone. So when a request for your web page comes, it will grab those static assets from the nearest edge server instead of your web server, giving you the shortest route possible for the delivery of assets on the page.

It’s largely set it and forget it

Caching improvements are measured in milliseconds, but across the thousands of requests per second needed to serve your website just to a single user, it can really improve your customer experience. And fortunately, once you get it tuned in, you can largely ignore it.

Bonus: Performance improvements are good for the planet

In case you need yet another reason to hone in on performance improvements for your website, consider this: Better performance is good for the planet. 
 
How so? You might have seen that all the massive data centers (like Amazon Web Services) are typically located in small towns next to hydroelectric dams. They require massive amounts of electricity to power and cool all of their machines. 
 
Performance improvements across trillions of requests per second on the internet mean more efficient use of resources with fewer dams and coal-powered electrical plants. This, in turn, helps to lower power consumption and counter global warming. 
 
So better performance is good for your customers, good for business, and good for the planet. Win-win-win.