Server-Side Caching vs. Client-Side Caching: The Differences (And Which Is Good For Your Website)
Have you ever noticed that the more times you visit a website, the faster it loads on your subsequent visits?
In some cases, the web page you requested is pre-loaded for you.
Your internet connection might be your obvious guess — and to some extent, you’re right.
However, this has little to no impact if the web page you’re requesting has poor load time.
Take yourself, for example, and think about the last website you exited without waiting for it to finish loading.
The top guess will be how slowly the website was loading—and when we say slowly, we’re talking about a matter of seconds.
But for you, the website visitor, it feels like forever.
The Google SOASTA Research confirms this—it puts a web page’s bounce rate at 32% once the page load time goes from 1 second to 3 seconds.
If it extends by an extra 7 seconds, the estimated bounce rate goes to 123%.
When you flip to the other end of the spectrum, businesses feel the impact of a poor load time in their bottom line.
Amazon, for example, would lose $1.6 billion in sales if its website were slow by one extra second. For every additional 100 milliseconds to Google’s website, it loses 20% of its traffic.
Bing is similar, as the company discovered that a 2-second delay in page load time led to a 1.8% drop-off in queries, a 3.75% reduction in clicks, and over a 4% reduction in revenue per visitor.
With all of this, how do websites, especially the major ones with massive traffic, such as Nike, Amazon, Facebook, Instagram, and many others, manage to stay up to speed and deliver the optimum user experience?
Simple, it’s all possible with Website Caching.
But before we can talk about website caching, let’s discuss what caching means.
What is Caching?
In plain terms, caching is the process or method of storing copies of files or data in a temporary storage location, or cache, to be accessed quickly.
What is a Cache?
A cache, by definition, is a memory reserved for storing temporary files or data from apps, servers, websites, or browsers to help load faster when requested.
Typically, it’s all about storing requested data for easier and faster access at a later time.
The concept of caching is based on storing commonly accessed or requested data without generating new content each time the data is continuously requested.
This cached data could include images, videos, animation, scripts, files, etc.—and it applies to every part of the present technology.
You can find cached data anywhere from the devices you use to the websites you visit.
For this article, we’ll focus on website caching and how it works.
What Is Website Caching?
Website Caching—or Web Caching for short—is the process of storing a copy of a web page on either the server or browser for users.
A typical website gets hundreds, thousands, and sometimes even millions of visits per day.
During each visit from each user, the website has to display the page, from scratch, to that user every single time.
The usual process for this begins when you type in the web address of the website you want to visit.
The following process then occurs:
- Browser does a DNS Lookup by going into the DNS server to find the IP address that the web address redirects to.
- This is followed by an HTTP request to the server asking for a copy of the website.
- Once the server approves the request, there’s a “200 OK” response from the server sent back to the client.
- After this, the server starts sending the website’s files in small chunks called “data packets” to the browser.
- The browser on receiving the data packets assembles them and renders them as a complete web page for the users.
This process is complex, and often, it’s time-consuming having the browser make the same request from the server all the time.
For large websites, it’s a significant issue due to the number of files their database processes.
Having users make a new request every time they want to access it leads to a poor user experience.
Website caching speeds up this process for a user’s future visits by saving a copy of the web page’s content and storing it in a temporary location.
As a result, when this user visits again, the content is already available— and can be fetched from the temporary location without making a new request.
With this, web pages tend to load faster.
This is due to the cache memory, which offers a low latency that allows the quick access of files.
However, a cache cannot store many files—it can only store a small chunk or part of a large file. In the case of websites, web texts and images are cached primarily.
Now that you understand the basics of website caching let’s look at how a website is cached and served to users.
How Does Website Caching Work?
- A user makes a web page request through their browser for an asset from the origin server.
This asset is a web address — and for this, let’s use https://www.edgemesh.com/how-it-works.
- Upon this request, the browser, CDN, or the server cache first checks to see if the copy of the requested web page (https://www.edgemesh.com/how-it-works) already exists.
- In the process of checking if the cache is available, the user makes a web page request, and the result splits between 2 possible scenarios.
Scenario 1: Cache Hit
- Suppose the copy of the requested web page (https://www.edgemesh.com/how-it-works) is stored in a cache. In that case, it results in a cache hit response, and the asset contained in the cache is delivered to the user.
Scenario 2: Cache Miss
- If there’s no copy of the requested web page (https://www.edgemesh.com/how-it-works) found in the cache, it will result in a cache miss response — and the browser will have to make a new request from the main server.
- Meanwhile, if the web page is cached, the browser continues delivering the cached versions from where it’s stored until it’s cleared or expires.
Types of Website Caching
When it comes to answering the question — “I want to cache my website, what type of caching should I use?”
The answer involves two options; you can either go with:
- Server-side Caching; or
- Client-side Caching
Both of these types of caching—although cache websites differently, serve the same purpose of making websites load faster without making new requests from the origin source.
Let’s take a deep dive into each.
What is Server-Side Caching?
Server-side caching is the temporary storing of web files and data on the origin server for reuse.
At the user’s first request of a web page on their first visit, the website undergoes the normal process of requesting the information from the server.
After making this request and sending a response back to the user, the server saves a copy of the web page.
Next time the user revisits the website, the server sends back the already saved web page without reconstructing or regenerating new content from its database.
This process helps avoid repeatedly making expensive database operations to serve up the same content to many different clients.
For websites with static content, server-side is the best option, as it significantly reduces the operation on the server—without having it recreate the entire content per user request.
This helps limit the cost servers and what they incur during the process of a data request from the database and back to the browser.
Types of Server-side Caching
Depending on your website and what you hope to achieve, there are three types of server-side caching, namely:
- Object Caching
- Opcode Caching
- CDN Caching
- Object Caching
Object Caching is a process that involves storing database query results; hence, it’s easily accessible next time there’s a request for it.
With this process, serving cached data is direct without sending multiple requests to the database.
- Opcode Caching
Opcode caching is a performance extension for PHP that compiles human-readable PHP codes to bytecodes understood by web servers.
This process occurs when a PHP file loads on the web page for the first time and is then saved on the server’s memory as bytecodes.
So, when the PHP file is requested at a later visit or in subsequent visits, the server returns the bytecodes instead of compiling them upon every request.
A bytecode cache engine, like OPcache, is used to complete the process of compiling the PHP code into bytecodes for the first time.
- CDN Caching
CDN stands for Content Delivery Network. It comprises a group of selected servers geographically distributed around the world to provide quicker content delivery to web visitors.
CDNs can do this by caching the content of the website on their network.
Once the content of your website passes through your registered CDN provider for the first time, the servers store a copy of the website.
When a user revisits the website, the CDN locates the nearest servers to the user’s location and delivers the stored copy of the website.
Though server-side caching seems to solve most websites’ major problems, it has some shortcomings that affect its usage.
The Problem With Server-Side Caching
The main problem with server-side caching for websites is High Latency.
What is High Latency in Web Caching?
Starting from the main word, latency is the delay between a user’s action and a web application’s response.
In technical terms, latency is the total time it takes a data packet to travel from source to destination.
Typically, latency is longer on a user’s first request due to the process involved —some of which include a DNS lookup, a TCP handshake, and a secure TLS negotiation.
However, the latency reduces in subsequent visits because there’s already an established connection to the server.
In this sense, latency can either be low or high.
Low latency for a website means there’s little to no delay between when a user takes action and when the server responds to it.
On the other hand, high latency means there’s a significant delay between a user’s action and the server’s response to that action—and this is the main problem with server-side caching.
When a website is cached on the server side, every request has to travel from the browser to the server and back to the browser.
This round trip caused by the server creates a high latency for a website which affects the user’s experience.
Although, once it establishes the first connection, the server doesn’t need to construct the whole page—instead, it can re-send the saved web page when the browser requests it.
However, if any of the data present on the saved web page changes, the server will have to delete the previously saved version and will now need to reconstruct the page again from scratch.
Nonetheless, server-side caching is one of the best methods for reducing the number of loads on a server.
With server-side caching, the server doesn’t always have to process the information in full; instead, it checks its temporary storage or cache first.
Now that we’ve covered server-side caching, let’s move to client-side caching.
What is Client-Side Caching?
Client-side caching, or browser caching, is a web-caching process that temporarily stores the copy of a web page in the browser memory instead of the cache memory in the server. This browser memory is located on the user’s device. So, when a user visits a website enabled with client-side caching, the browser keeps a copy of the webpage.
Browsers such as Safari, Microsoft Edge, Google Chrome, Opera, Brave, etc., have a browser cache memory on any device onto which they’re installed. This allows them to store HTML pages, Images, CSS files, and other multimedia files of a website.
However, this memory only complements the user’s cache memory, as it can only store minimal information.
In some cases, users eventually clear their browser cache. When this happens, the browser can no longer read the cache from the user’s device’s storage.
When the user revisits the website, the browser will load the website as if it’s the user’s first time and re-cache the website.
For both dynamic and static websites, client-side caching solves both latency and server crash as it reduces the load on the server.
Types of Client-Side Caching
The client-side caching of a website bases its technique on caching enough information for a user without creating repetitive requests for the same web page from the server.
This eliminates round trips and speeds up load time between the client and server for the re-transmissions of data packets.
Meanwhile, client-side caching is in three distinct parts, all of which have different uses depending on what you hope to achieve with your website.
- Browser Request Caching
- HTML 5 Caching
Browser Request Caching
The browser request caching is the oldest and most common type of client-side caching.
It’s built into the HTTP protocol standard. It lets the webmaster or developer control how often the browser requests a new copy of files from the server.
When it comes to browser request caching, most of the caching occurs in the header section of the website’s code.
This is because metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP) are the primary determinant of a website’s load time.
A few examples of headers and their roles in caching a website:
- Pragma (no-cache)
The “expires” tag in the header section creates an expiration date for cached content in the browser cache memory.
This header controls the type of content to be cached in the browser. The tag instructs the browser that specific content from the user’s response should never be cached.
The use case of pragma (no-cache) is mainly for dynamic websites susceptible to frequent changes based on a user’s interaction.
The ETag—or entity tag header is a designated hash value that controls what version of a cached web page or file is shown to the user upon request.
Similar to the expires tag, browsers use the if-modified-since header to make requests to the server to send data only if the currently cached data has been modified since the specified date.
The last-modified header is used to identify when the cached data was most recently changed—and then the response is sent to the if-modified-since header.
The cache-control header is the core control for headers that specify whether content should be cached on the browser memory with the following responses:
- A user makes a content request via the browser to the server.
- The server sends back a response to the browser.
- Cache-control header requests if the user’s response should be cached in the browser memory.
- If the response is “yes,” cache-control replies with “how long.”
- If the response is “no,” content is not cached.
The ultimate level of client-side caching is implementing a Service Worker, which is the model employed by Edgemesh. Service workers can have complete control over client side caches, and allow for complex cache logic outside of the limitations of the browser cache. The performance improvements can be astounding, with Google itself reporting a 39% reduction in First Contentful Paint on it’s properties.
All of these are types of client-side caching, and their main focus is keeping copies of web files on the browser—which is also called the client side.
This way, there’s no need to keep updating the same content.
However, if a user requests data that has been updated before that request, the user might not see the new version of the data.
In some cases, the browser might have to delete its cached data and request an updated one from the origin server.
And in other cases, users would have to clear their browser cache before seeing an updated version.
Client-Side or Server-Side Caching, Which Is Good For Your Website?
As long as you’re on the edge of caching your website or already doing it, your website is a step closer to improving users’ overall experience.
However, the type of web caching technique you use impacts your users’ perception of your business.
If, for example, you run an online ecommerce store where you sell customized Nike sneakers.
Due to how your business is, the content on your website is dynamic.
As a result, users have accessed your website smoothly whenever there’s a new design.
Considering that the bounce rates of websites increase the longer it takes to load, there’s a high chance users will leave before the content fully loads.
This creates a poor perception of your brand as low quality. It trickles down a negative effect on your bottom line, because you’ll eventually have a bad conversion rate.
For this example, the problem involves the type of caching used.
- Let’s say you use server-side caching.
In server-side caching, the website has to request from the server—but first, check if the requested page is cached.
If it’s cached, it can easily serve the cached version—but only if the content on the website is static.
As a result, the browser has to request the origin server and generate new content every time there is a request from a user.
The problem with this method is you’ll incur high latency and server overload.
Let’s try it out with client-side caching.
- Let’s say you use client-side caching.
When it comes to client-side caching, the copy of the website stores in the browser’s cache memory.
When there’s a request for that web page, it serves the cached version without requesting it from the server.
This way, whenever you upload a new design on your website, it automatically renders in real time to users without waiting to fetch from the server.
For most medium and major websites, the number of daily users makes client-side caching the preferred option.
This is due to how fast and simple it is to manage and implement multiple changes on the website without having to worry about incurring server cost or bandwidth.
Some other benefits of client-side caching include:
- Saving documents generated in web applications locally for offline use.
- Creating fall-back files for web application interaction while offline.
- Personalizing user’s site preferences based on previous activities.
Choosing a Client-Side Caching Provider
Looking for the best client-side caching provider for your website often leads to trial and error, which negatively impacts your bottom line.
Your primary focus should be compatibility in your search for a client-side caching provider.
Not every provider offers services for websites built on specific platforms.
Once you find a client-caching provider you’re interested in, gather information on what type of website they support and what content management systems (CMS) or custom sites they can integrate with.
By doing this, you’re saving yourself time and resources on a service that won’t be useful to you.
Meanwhile, a client-side caching provider like Edgemesh integrates perfectly with major CMS and custom site builds.
Using Edgemesh As Your Client-Side Caching Provider
Creating a fast website ultimately leads to an increase in conversion rate, which positively impacts the revenue of a business.
This is why businesses are constantly looking for ways to improve their website speed—even if it’s by a single second.
Client-side caching is the best for doing this, and that’s how we, as Edgemesh, help you.
We use your traffic to create automated, real-time optimizations for your website.
In doing this, our advanced pre-cached technology helps your customers pre-load your content before they request it.
As we’ve seen, this method results in your website running 20-50% faster without changing your database or front-end infrastructure—and it’s all done with a single line of code.
When it comes to compatibility, we integrate with most of the platforms you’re likely using or will use.
- Big Commerce
- Cloudflare, and
- Custom Sites (NodeJs, Netlify, Gatsby, Salesforce Commerce Cloud, etc.)
Edgemesh simply makes it easy to speed up your website without the need for a developer.
If you made it to the end of this article, that means you’d be interested in the rest of this series.
Below are related articles we think you’ll find helpful:
The Complete Guide to Google’s Core Web Vitals: What is Largest Contentful Paint (LCP)?
Complete Guide on First Input Delay (FID)
What is Cumulative Layout Shift (CLS)?
What is Conversion Rate Optimization?
Do customer experience, good conversions, low bounce rates and overall, speed, matter to you? Then you’ll love Edgemesh’s Enterprise-Grade Web Acceleration.
Our intelligent, automated, and next-generation client-side caching readies your website to move at full speed—with just a single line of code.
Plus, it takes less than 5 minutes to set up. What do you say?
Start your 14-day trial to get a feel for what speed means to your business.