What they say about cash can be said about websites, cash or rather cache is king! Whether you’re launching a new site or optimizing a current website, one thing is for certain: a bad website cache policy will negatively impact your search engine optimization score (SEO). As a result, you’ll experience hidden costs that’ll bloat your paid media spend. So, if you haven’t already, it’s time to start addressing your website caching.

You’d be surprised how many websites aren’t caching properly. They subject themselves to DDoS attacks, site shutdown from seasonal traffic, and poor website experience for customers. In fact, we’ve had our fair share of poor site performance, which fortunately, was mostly addressed with good caching policies.

That’s right, policies. There’s usually more than one cache impacting your website! We’ll take a look at three ways to cache: server-side, intermediary/content delivery network (CDN), and browser. We’ll briefly discuss how each works and how to avoid some of their implementation pitfalls.

Server-Side Cache

With all websites, the content is always stored on a server. Without any caching, customers accessing your website would interact directly with your server. This interaction can put a lot of strain on your server and is prevented with server-side caching.

The server-side cache sits right in front of the server and acts as a buffer. With caching, the same customers now interact with the buffer/cached data, reducing the workload on your server. This frees up your server to process more pertinent tasks, such as updating your website content and storing contact form submissions.

Therefore, it’s a great idea to set up server-side caching and to configure it properly with your chosen tech stack. These configurations include the length of time for data to be cached and can be configured through your hosting provider or by your development team. Keep in mind, a shorter cache time is ideal for content heavy sites (news site). On the other hand, a longer cache time is ideal for less content heavy websites (like our website). Additionally, a poorly configured cache can break your content management system (CMS), disabling new content from being released. Check with an expert to confirm that your server-side cache is set up correctly and is optimal.


Between your browser (Google, Safari, etc) and your server or server cache (if it’s implemented) can be an intermediary cache called a CDN. Some popular CDNs include AWS CloudFront, CloudFlare, and Fastly, and serve as a distribution center for your website.

CDNs work by retrieving and storing your website data at physical locations across the world. These locations have infrastructure and hardware to store, protect, and safely house your website data. In doing so, customers interact with the CDN that’s closest in proximity to them and not with your server. Someone in Asia could spend 5+ seconds loading your site that’s hosted on your server in the US, or they could spend 1 second loading your site that’s hosted on a CDN in Asia or Australia. Remember, latency is a real thing and can really turn off customers.

By design, CDNs are built to handle high volumes of traffic with fallback systems. In other words, CDNs can prevent attacks on your server that could potentially crash your site indefinitely and can help your website scale/stay live with seasonal traffic. The last thing you want to happen is to pay for ads, only for customers to land on a dead page after clicking your ad.

Be diligent when leveraging a CDN and confirm that you’ve cleared your CDN cache before publishing new content. If you’ve got the server-side caching set up, clear the server cache before clearing your CDN cache. Otherwise, your CDN may retrieve your old server data. Like the server side, caution must be taken when configuring your CDN with your tech stack. With the wrong configurations, you may lose admin access to your site, be unable to update your site, and/or face URL redirects that prevent everyone from viewing your website.

Browser Cache

The last caching is through your browser. For browser caching to work, your website needs to set up instructions or policies for your browser to enforce. This includes the file type, cache duration, and caching method. Once the browser caching is implemented, each subsequent visit interacts with the originally loaded data. In other words, the browser cache will force customers to interact with their previously loaded data instead of with your CDN, server cache, or server.

Before implementing your final browser caching policy, make sure that you’ve fully tested it in a staging environment. You don’t want customers or even parts of the internet to be served permanent content that could damage your brand, such as a dysfunctional site or silly grammatical errors. In other words, that content would live and be seen indefinitely by those customers. That’s why it’s important to consult with a website developer who can set up your browser caching policy, or confirm that your browser caching is already working.

The Bottom Line

Without getting too technical, you should have a profound appreciation for each of the three caching types. When all three types were implemented, we noticed a 20+ point bump to website performance for our website and for our partner websites. Remember, when you’ve enforced a longer caching time, you’ll need to clear your caches, starting with the server-side cache and ending with the CDN, to serve new content to customers.

Ultimately, the golden rule of thumb for website performance: the more work that’s offloaded from your server, the better your website performance. So just having one cache type could dramatically improve your site performance.

Want to discuss your site with us? Connect with us today for help in developing and implementing a caching strategy that’s built for your organizational needs!

Share this post:

More Common Sense Blog Articles

Enjoyed the article? Check out some more topics from our blog on digital common sense.