Whether you’re launching a new site or optimizing a current website, one thing is for certain, Cache is King. You’d be surprised how many websites aren’t caching properly. They subject themselves to DDoS attacks, site shutdown from seasonal traffic, hidden costs related to poor search engine optimization (SEO), and poor website experience for customers. In fact, we’ve had our fair share of caching issues, which was 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 pitfalls.

Server-Side Cache

Website content is always stored on a server. Without any caching, customers accessing your website would interact directly with your server. This puts a lot of strain on your server, potentially causing loading issues and can be 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 is configurable through your hosting provider or your development team. Keep in mind, a shorter cache time is ideal for content heavy sites such as news sites and galleries. On the other hand, a longer cache time is ideal for less content heavy websites. Note, 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.

Intermediary/CDN

Between your browser (Google, Safari, etc) and your server or server cache (if it’s implemented) can sit 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 through 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 with seasonal traffic. 

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 that 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 the wrong configurations, you may lose admin access to your site, be unable to update your site, and/or face URL redirects that prevent customers from viewing your website.

Browser Cache

The last caching that we’ll dive into is through your browser. Your website needs to declare instructions or policies for your browser to cache. This includes the file type, cache duration, and caching method. Once the browser caching is implemented, each subsequent visit interacts with the original loaded data. In other words, the browser cache will interact with the previously loaded data instead of with the CDN, server cache, or server. Note, you can clear server cache and CDN caches at their source but you cannot go onto someone’s computer to clear their browser cache. 

As a result, before implementing your final browser caching policy, ensure that you’ve fully tested it in a staging environment. You don’t want to release a dysfunctional site or content with grammatical errors that persist for months or even years. 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

You should have a profound appreciation for each of the three caching types. In our experience when all three types are implemented, we noticed a 20+ point bump to website performance for our website and for our partner websites. Caching can be tricky so when it’s enforced, clear your caches starting with the server-side and ending with the CDN. Remember, the browser cache cannot be cleared on the customer side so caution must be taken when implementing it.

Ultimately, the golden rule of thumb is the more work that’s offloaded from your server, the better your website performs. 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.