Website caching is often the only thing that significantly improves your website speed in a matter of seconds. So, knowing what is caching will become extremely helpful when optimizing your site for faster speed.
Caching sometimes can feel like a complicated thing to understand especially because it has so many different usages. Yet, it is one of the core elements that you will come across everywhere in website speed optimization.
So, I have simplified everything you need to know about caching in this article. I will use WordPress as an example throughout this article for better understanding.
What Is Caching
Caching means temporarily storing a copy of any file or data in one or multiple storage locations for faster and efficient delivery of the file in the future. The stored copy can be an identical copy of a static file or a static snapshot of a dynamic file at a given time.
A webpage is made up of images, videos, HTML, CSS, JS, fonts, and some other types of files. So, every time you visit a webpage using a web browser like Chrome, Safari, Firefox, etc., the browser downloads all the files needed for the webpage and then compiles them together to show you a complete webpage.
These file types are divided into two categories such as static files and dynamic files and they are considered separately when caching them.
Static File Caching
If the same file can be delivered to everyone without modifying or recreating, then that file can be called a static file. File types like images, videos, CSS, JS, fonts, etc. are known as static files. For instance, if your website has an image, everyone who wants to see that image will be provided with that same image without needing to modify it for anyone. These static files generally make up the majority of any webpage’s weight.
Because these files don’t change on a per user basis, caching them is very simple. Therefore, caching these files only requires them to be temporarily copied to one or multiple locations and then to replace them with any updated files if they ever change.
Dynamic File Caching
If a file needs to be processed and generated based on user specific scenario every time it is delivered, then that file can be called dynamic file or dynamically generated file. Dynamic files can also contain contents that change based on user interactions or other events. HTML file type is generally considered as dynamic file.
For instance, when browsing a website, you may have seen your name come up at a corner of that site. But when others visit the same website, they see their name instead of yours. Because of this, these webpages need to be regenerated every time someone else visits the site. This makes the webpages dynamic file.
HTML files are actually a static file type but they are considered as dynamic files because in modern websites they are created dynamically based on user specific scenarios. For instance, every time any visitor requests a page in a WordPress website, the web server goes through the process of running PHP scripts, then fetching data from the database, and then generating the HTML file to respond to the visitor’s request.
However, even though a new HTML file is generated every time someone makes a request, the newly generated HTML file for a particular page might be the same as the previously generated HTML file for that page. In that case, generating a new HTML file will be a waste of server resources and some precious time. In fact, too many simultaneous requests of this type can require a lot of server resources which may ultimately take down your server.
Now, the way of serving dynamic pages without repeatedly recreating them is to use caching. This way, when an HTML page is dynamically created, you can temporarily store or cache that page and then server the cached page in response to any future request for the page.
But because dynamic files are subject to frequent change based on various scenarios, their caching always needs to be kept updated. This is what makes caching dynamic files relatively complicated. That is also why most caching challenges go into caching dynamic files and so the majority of the caching fundamentals outlined below are towards solving this problem.
For instance, if you are using a Content Management System (CMS) like WordPress for creating your website, then you may have created home page, about page, contact page, blog posts, and other sorts of pages on that WordPress website. Now, In order for people to view these pages, each one of these pages needs to have a separate HTML file which is required by web browsers to load your web pages.
So, your WordPress website should also have separate HTML files for each one of those pages. But if you go through the file structure your WordPress website, then you will notice that it doesn’t store HTML files for the individual pages in your website. That’s because every time someone makes a request to view any pages from your WordPress website, a new HTML file is created for that page and then served to that person.
This HTML file creation process requires PHP processing, database lookup, and assembling of the file. So, every time an HTML page is created, your web server needs to do some computations that use server resources and take some time to complete. Your server needs to go through this process for serving every page request on your WordPress site.
So, the more traffic your website gets the more resources are used from your server. And if the server resources aren’t enough to cope up with the traffic, then the server response time gets increased and ultimately the server goes down. That’s why caching for dynamic files is very important for server stability and for faster delivery of your web pages to the visitors.
Types of Caching
There are many types of caching available that you will come across. Some of them will be more common than others. Here, I will discuss the most common ones that you will need to know for having a good understanding of the subject.
Object Caching
Object Caching means temporarily storing the results of database queries to make their delivery faster and efficient in the future. This allows for faster delivery of query results for any subsequent request of the same query because the result will already be stored in the cache memory so it won’t be necessary to query the database again to get the same results.
In case of WordPress sites, when someone wants to visit a page, the page is created dynamically which requires PHP processing and making database queries to generate the requested page. And because WordPress uses needs to access data from the database, each page creation requires the execution of multiple database queries. Each of these queries can take a few milliseconds which adds up to the usage of your web server resources and the time taken to generate the pages.
Object caching can help here by storing the results of these queries so that the next time the same queries are made, the results can be provided from the cache memory saving time and computation power.
Default WordPress Object Caching
WordPress has a built in object caching system called WP_Object_Cache. This stores database query results in the PHP memory to avoid repeated queries to the database. However, WP_Object_Cache is a non-persistent method so the cached data will only be available in memory for the duration of a single page load.
This is helpful to avoid making the same query multiple times if it appears more than one time in the same page request. So, in this case, the cached data will be discarded after the page load is completed and so the cache will need to be created the next time that page is requested again.
Therefore, even though this can give a performance boost to your WordPress site by not repeatedly making similar database queries in a single page load, this isn’t an efficient way of caching across multiple page loads. That’s where a persistent caching solution will come handy.
Persistent Object Caching
Persistent object caching allows your website to avail the full potential of object caching by enabling the cached query results to be served from the cache memory whenever they are needed for any new page loads in the future.
The two most popular persistent object caching solutions are Redis and Memcached. Though they are used for the same purpose, Redis is the more popular one and provides more benefits than Memcached. If you want to know more, take a look at this comparison between Redis and Memcached.
You can also use any of them with your WordPress website for faster delivery of query results and for reduced usage of server resources.
When persistent object caching is working in WordPress, the database query results get cached and so subsequent requests for similar queries are served from the cache memory. However, this doesn’t completely eliminate queries to database, instead it significantly reduces the number of total queries.
For instance, to serve a very basic webpage the number of database queries may go from 22 to 2 after enabling object caching. This number of total database queries represents the lowest end and so the number generally goes a lot higher than 22.
Depending on various factors like your use of theme, plugins, and other setups the number of database queries can go upwards of 100. That’s why object caching can potentially save your server a lot of computation power and help accelerate the delivery of your web pages.
But your server will still need to make a few database queries and re-create HTML pages from scratch every time it receives any page request. In order to solve that inefficiency, you can use full page caching.
Full Page Caching
Full page caching (also referred to as page caching) means temporarily storing the static snapshots of dynamically generated HTML pages for making faster and efficient delivery of them in the future. When an HTML page has been cached, any request to the page can be served from the cache memory without going through the process of dynamically creating the page again. This reduces the load on server resources but helps with faster delivery of the web pages.
In WordPress, full page caching plugins like WP Rocket, WP Fastest Cache, W3 Total Cache, Swift Performance, and others will cache the dynamically generated HTML pages. These application level caching plugins generally save the cached pages in the WordPress file structure. So, if you look into the file structure, then you may find the saved pages there in the HTML file format.
Therefore, serving these cached pages won’t require making any database queries or even running PHP scripts to generate the HTML files. However, in order to serve a cached page, it will still be necessary to execute a PHP script of WordPress called advanced-cache.php that checks if a cache file exists for the requested page.
So, your web server will still need to be executing a PHP script to deliver a cached page. But you can even solve this inefficiency by using reverse proxy caching (it has been discussed in the later section in this article).
There are two types of full page caching one is public caching and the other one is private caching.
Public Caching
Public caching is a kind of full page caching that stores snapshots of dynamic pages that can be used by everyone. So, in case of public caching, the same web page will be delivered to everyone regardless of who is viewing the page. Therefore, the pages that qualify for public caching can’t contain any personalized contents like the name of the visitor, the number of items in someone’s shopping cart, etc.
There is a type of full page public caching called microcaching which is used to cache files for an extremely short period of time.
Microcaching is a kind of public caching that is used to cache HTML pages for a very short period of time like 1 second. It is helpful for high traffic websites that feature frequently changing contents like stock prices, sports scores, breaking news, and so on.
However, if a website has high traffic but doesn’t feature frequently changing contents, then it will be more beneficial to use regular full page caching that keeps cached files for a longer period of time like weeks, months, or even years. This long period of cache expiration time alleviates the server from unnecessarily creating a page every second when the same page could be used for a much longer time period.
Private Caching
Private caching is a kind of full page caching that stores snapshots of dynamic pages that are specific to individual users. So, in private caching, different versions of the same web page will be delivered to people based on who is viewing the page. These different versions of the pages generally differ by the personalized information or the user relevant information on the pages.
For instance, the differing information can be the name of the logged in user, a pending comment by a user, the WordPress admin bar, and so on. When private caching is implemented, a different cached version of the same page will be stored for every users (mostly logged in users) that requests the page. This will subsequently take up lots of storage on your server which may prove to be counterproductive when compared to the page speed benefit received from the private caching.
Additionally, because of the nature of private caching, the personalized pages will need to be created every time a new user scenario arises. So, whenever a new user visits a personalized page, the page may need to be created from scratch and then cached for later use by that user. That’s why the benefit of caching won’t be realized by the users until they visit the page again. So, private caching won’t be very beneficial if your personalized webpages don’t get repeat visits from the users.
There is a way of using public caching for web pages that have personalized contents. And that is the use of AJAX which can result in better efficiency than using private caching.
Public Caching for Personalized Pages
In case of private caching, you need to cache many different versions of the same page which uses a lot of server storage. Additionally, if you use public caching for the pages that have personalized contents, then your caching will mix things up where visitors may see contents that are intended for someone else but not for them.
If we see how WordPress works, then we will see that when a visitor makes a request to view a webpage, the page is dynamically created by running PHP scripts and making queries to the WordPress database and then served to that visitor.
When full page caching is in use, the webpage is dynamically created only for the first visitor (or the first user after the cache has been cleared) who makes the page request. And then the output of that dynamically generated page is stored as a cache file in the HTML file format. Consequently, the cached file is served to any subsequent visits to the same page.
So, the process of running PHP scripts to create the HTML pages are no longer followed when serving the cached pages. Therefore, if your web pages contain any user specific contents that are unique to individual users (like the name of individual users, the number of items in their shopping cart, and so on), then serving those user specific contents to individual users won’t be possible anymore. That’s because the pages are now being served from the cache memory without being dynamically created for every individual user.
Therefore, any user whose request is responded with a cached page will see the contents that were specific to the first user and not the user requesting the page. So, serving personalized web pages will prove to be a problem if you use public caching.
However, you can overcome this problem by taking advantage of AJAX.
AJAX (Asynchronous JavaScript and XML) is a technique in JavaScript that is used to update parts of a web page based on data fetched from a web server without needing to reload the page. AJAX works in the browser background to communicate with the server so it doesn’t interfere with how the page loads initially.
You may have seen this in action when browsing an ecommerce website. Where you see an empty cart when the page initially loads and then after a second the cart suddenly shows the actual number of items it has. This happens because of AJAX which updates the cart as soon as it receives the information from the server.
Because AJAX runs on browser background and not on the server, it allows for public caching of personalized pages.
Let’s go back to the earlier WordPress example where I talked about PHP not being able to change the contents of a fully cached page. This meant that public caching would not be suitable for web pages that have personalized contents.
However, if you will be able to overcome that problem by taking advantage of AJAX. Unlike PHP which runs on server side, JavaScript runs on client side or in web browsers. Therefore, even though PHP can’t modify the contents of a cached page, AJAX can. So, by using AJAX, you will be able to take advantage of public caching even for pages that have personalized contents.
Now, because cached pages don’t need to be dynamically created for every request, they substantially save your server resources. Therefore, AJAX will help reduce your server resource usage by allowing you to use public caching for personalized pages.
Conversely, if you used either no caching or private caching for the pages with personalized contents, then that would use a lot more of your server resources in terms of computation power and storage usage.
AJAX when combined with caching, therefore, also helps improve user experience by enabling the pages to load quickly.
There is another way of caching personalized pages and then serving them to the users. And that is using Edge Side Includes (ESI) which has been discussed under the CDN caching section later in this article.
Should I Use Full Page Caching or Object Caching
Full page caching can provide more efficient results than object cashing. This is because object caching only caches the results of database queries so the web pages still need to be dynamically created every time there is a new page request. But when full page caching is implemented, the entire pages are cached so new page requests can be served without making any database queries or recreating the page from scratch.
However, it isn’t always possible to efficiently implement full page caching in all sorts of web pages. This is because full page caching will cache the entire web page without considering if the web page needs to be uniquely created for individual users.
For instance, if your website has logged in users then you may want to personalize the web pages by showing their individual names on the header of the web pages. So, the same web page should show a different name in the header based on the user who is visiting the web page. But if you use full page caching, this may become a problem. Because the entire page will be cached and so everyone will see the name of the user whose visit has been cached instead of seeing their individual names.
As mentioned earlier, you will be able to overcome this problem using private caching, AJAX, or ESI. And you will need to choose which one of them best suits your specific website needs.
However, if your website pages aren’t very suitable for full page caching or if your website will need to largely depend on the faster delivery of database query results, then you will need to depend on object caching. That’s because object caching will cache the database queries results which will help with faster delivery of those query results and that will ultimately help with faster creation of dynamic pages.
Additionally, object caching won’t cause any problems with serving personalized pages. So, you will be able to use it for serving all kinds of websites. But of course, this won’t give as much performance boost as full page caching.
Now, if your website only has public pages or its pages are identical to every visitor, then you can use full page public caching without any problem. You won’t even need object caching in that case. But, if your website needs to generate personalized pages based on individual user scenario, then you can use object caching or consider using private caching, AJAX or ESI based on your specific scenario.
You can also use object caching and full page caching together if your website can take advantage of that. For instance, if your website has both public pages and personalized pages, then the public pages will benefit from full page caching and the personalized pages will benefit from object caching. In this setup, you should be careful about allowing public caching only to the public pages and not to any personalized pages.
One thing to note is that, if you are using WordPress, then you may find that private caching isn’t available in many caching plugins. And so they may either cause problems by caching personalized pages or they may not cache personalized pages at all. That’s why you will need to be careful about selecting a good caching plugin that works well with your specific website needs.
Reverse Proxy Caching
Reverse proxy is a type of server that works as an additional layer to your web server by managing all user requests in and out of the web server. It is also known as web server accelerator and HTTP accelerator.
When a user makes a request for a web page, the reverse proxy server receives the requests and then forwards that request to the web server. And after the web server responses to the request, the reverse proxy server receives the response and then forwards that response to the user.
Therefore, reverse proxy caching means temporarily storing a copy of the files that are sent by the web server in response to the user requests. So, when someone makes a similar request in the future, the reverse proxy server can respond to the request very quickly by serving the website files from its cache memory without even interacting with the web server.
So, for WordPress websites, no PHP processing or database queries are required if the page is cached in the reverse proxy server.
One of the most popular reverse proxies that you can use is Varnish. You can also use server level full page caching solutions like FastCGI cache module for NGINX to achieve the same caching solution as using reverse proxy caching. In fact, it generally provides faster results and better performance than using Varnish.
But if you want an even better solution, you can look into LiteSpeed server which provides server level full page caching and it even provides caching plugins for WordPress and other CMS platforms for easily managing the caching configurations. Here is a performance comparison between the web servers Apache, NGINX, and LiteSpeed.
Even though NGINX and LiteSpeed are generally used as web server applications, they can also be used as a reverse proxy server like Varnish that sits on top of the web servers like Apache, NGINX, LiteSpeed, and others. For instance, you can use a LiteSpeed server as a reverse proxy for an Apache, NGINX, or even another LiteSpeed server.
In case of WordPress, application level full page caching plugins like WP Rocket, W3 Total Cache, and others need to depend on PHP scripts to handle each page request. That’s why serving even cached pages require PHP processing. But, server level full page caching plugins like LiteSpeed Cache (requires using LiteSpeed server) will store and manage the cached pages from the server. So, serving the cached pages doesn’t require involving any PHP scripts or WordPress. Therefore, server level full page caching can eliminate the need for reverse proxy caching.
CDN Caching
CDN (Content Delivery Network) caching means temporarily storing a copy of different files in multiple storage locations around the world for faster delivery of those files to anyone at any geographical location.
CDN providers have many data centers around the world. So, if a file has been cached in a CDN, then any request for that file will be served from the data center that is closest to the person requesting for that file. Because of this, the file needs to travel a shorter distance which accounts for faster delivery of the file to the user. This is why using CDN caching can significantly reduce the load time of any websites.
If you want to know how CDNs affects websites that only have local visitors, then check out this article about CDN for local websites.
In order to use CDN caching for your website files, you will need to use a CDN provider like AWS CloudFront, Google Cloud CDN, and so on. Then your website files will need to be cached to the CDN provider’s data centers from your web server or storage location using methods like push or pull. Those files can then be accessed using one of the subdomains provided by the CDN provider.
So, once the files are cached in the CDN, any requests for the files using that subdomain will be served from the data centers of the CDN provider. You can also use one of your subdomains as an alternate domain name (also known as CNAME) to their provided subdomain. This way, those cached files will also be accessible from your subdomain.
CDN caching is mostly used for static files like the images, videos, CSS, JS, and so on. It is also used for static HTML files where the same HTML file is delivered to anyone requesting for the same webpage.
CDN caching can also be used for static snapshots of HTML files that need to be dynamically generated for every request like in a WordPress website. But this is mostly a feature provided by the reverse proxy CDN providers.
Reverse Proxy CDN
Reverse proxy CDN is a type of CDN that works as a reverse proxy, similar to what has been discussed in the earlier section about reverse proxy caching. Meaning that the reverse proxy CDN will work as an additional layer to your web server by handling all its incoming and outgoing traffic.
If you are using a traditional CDN, then you will need to use a subdomain of the CDN provider (or an alternate domain name) for delivering your website files. But when using a reverse proxy CDN, you don’t need to use any subdomains of the CDN provider. Instead, all the files will be cached and served from your main domain.
But if you want, then you can of course choose to use one of your subdomains to serve the static files. In fact, if you don’t want to use your reverse proxy CDN provider to serve those static files, then you can use a traditional CDN provider for that.
Using a reverse proxy CDN, however, requires changing your domain’s nameserver records to the ones provided by the CDN provider. Once you do that, all your website traffic will be handled by them exactly like the reverse proxy servers discussed in the earlier section about reverse proxy caching.
Therefore, the reverse proxy CDN will receive user requests on behalf of your web server then forward that request to your web server. And after the web server responds to the request, the reverse proxy CDN will receive the response and then forward that response to the user. Consequently, upon receiving the response from the web server, the reverse proxy CDN will be able to cache the response for future use. So, reverse proxy CDNs can eliminate the need for reverse proxy caching discussed in the earlier section.
If any webpage is fully cached (including the HTML file and other static files) on the CDN servers, then any request for that webpage won’t require going to the web server. This can consequently reduce the load on your server but increase the speed of your website all at the same time.
Edge Side Includes (ESI)
Edge Side Includes or ESI is a markup language that allows treating parts of dynamic web pages as separate fragments that can be processed separately and then assembled together to make a complete page.
This way any dynamic web page can be cached in parts. So, if a web page has some public contents that are the same for everyone and some personalized contents that are unique to individual users, then ESI will allow caching these public portions and the personalized portions of the web page separately. These separate portions can then be assembled together to make a complete page.
In other words, ESI lets you cache the entire web page by keeping gaps in it and the gaps can then be filled with different contents for making a complete page. Here, the gaps can represent the personalized contents while the rest of the page is public content.
So by using ESI, we can serve complete web pages from cache without actually using full page caching. This helps overcome the problem with full page caching that a page can either be cached entirely or not cached at all. Therefore, web pages that need to be unique based on individual user scenario, can be served more efficiently using ESI compared to private caching which takes substantially more storage for caching the same web pages.
ESI processing takes place at the CDN edge (data centers located across many geographical locations that deliver contents to the website visitors). When there are any ESI tags in an HTML page, the CDN edge will try to resolve the tags by using already cached contents that match those tags or by making requests to the web server to get the contents that can be used to resolve the tags.
Therefore, once all the ESI tags are resolved, the whole page is finished assembling and that is when the CDN starts delivering the page to the visitor. So, the more ESI tags found in a page the longer it will take for the page to be assembled and delivered.
Now, because the delivery of the web pages gets delayed by the process of resolving the ESI tags, the initial server response time and the Time to First Bite (TTFB) gets increased. This makes the website load speed appear to be slow to the web site visitors.
Here is an article you can read to know more about ESI.
Conversely, when we use AJAX (it has been discussed earlier in this article), which can be used as an alternative to ESI for allowing to cache personalized pages, the website load speed appears to be faster to the visitors. That’s because it doesn’t require assembling anything before starting the delivery of the web pages. Instead, AJAX updates the page contents by running JavaScript in the browser background.
This is why if you use ESI, as opposed to AJAX, then you will see that the number of items in your shopping cart gets loaded normally instead of suddenly updating the previously loaded empty cart which happens in case of AJAX.
If your website has some frequently changing contents that appears in many or all of your website pages, then ESI can largely improve your site performance. These type of contents can be something like a recent posts widget located at the sidebar in your WordPress website. Every time you write a new post, that post widget needs to be updated. So, all the pages where that post widget appears also need to be updated.
Now, if you use full page caching, then the cache for all your website pages that have the post widget will need to be purged and generated again. This is because full page caching can’t cache web pages in fragments. But if you use ESI, then the cache will need to be purged and regenerated only once and that is for the recent post widget. This also helps reduce server load because the CDN edge will only need to make request to the web server for only once in order to fetch the updated contents.
Then the newly cached version will be used for the post widget instead of the old cached version. So, the updated post widget will be reflected in all the web pages without needing to regenerate the pages again.
So, there won’t be any necessity to purge cache for all the pages on your website just because you added a new post. This is among the kind of scenarios where the benefit of using ESI can be very apparent.
However, every time someone makes a request for a page that contains the post widget, it will still be necessary to assemble the post widget and the rest of the page together before delivering the page to the visitors. But in full page caching, the page wouldn’t require assembling after the page has once been cached.
Even though ESI can be beneficial to your website in quickly delivering personalized pages, it isn’t an officially approved technology. That’s why you will see that its adoption is limited to this date.
Browser Caching
Browser caching means temporarily storing a copy of different files of any website in the visitor’s web browser like Chrome, Safari, Firefox, and so on. Web browsers save these files in the device that the visitor uses to browse the page. So, when the files of a webpage are saved in the browser, any subsequent visits to that page don’t require those stored files to be download again. Therefore, the browser can get away with downloading only the files that have been updated since the last visit or the files that haven’t been cached.
Other than browser caching, all the caching methods described above are server side caching so they either store cached files in the web server or in the CDN data centers. Therefore, the files need to be downloaded every time someone visits the webpage. But in case of browser caching, the cached files are stored in the visitor’s browser. So, once the files are cached, they don’t need to be downloaded again. That’s why browser caching can help make webpages load super quickly compared to any other caching methods. The performance difference can be even more apparent if the website visitor has a slow internet connection.
Browser caching, however, only benefits repeat visits of the users because they first need to visit your website before their web browser can cache your website files.
When configuring your website files for caching, you will need to be extra careful about browser caching. That’s because, after updating anything on your website, you will easily be able to clear the cache for any server side caching configurations but not for browser caching. Once a file has been cached in the visitor’s web browser, you won’t have much control over that.
Therefore, if your website files are cached on the browser for a long time, then any updates you make to your web pages may not be downloaded by the browser and so the visitor will keep seeing the outdated contents. That’s why in order to ensure that your website visitors are being served with up-to-date contents and not any outdated contents, you should be careful about setting up the cache expiration period also known as Time to Live (TTL) which has been discussed later in this article.
DNS Caching
Domain Name System or DNS is the process of linking a domain name with an IP address. An IP address is necessary by the web browsers to find out the server where the website for any particular domain name is being hosted. So, after you type a domain name in your web browser, the browser first finds the IP address associated with that domain name and then it connects to the web server at that IP address to fetch the website you want to visit.
Now, there are many different types of DNS servers that are used in the process of getting an IP address from a domain name. And this process of going through server to server is time consuming. So, after the IP address is found for a domain name, it can be temporarily saved in one of those server types called recursive DNS server and in the visitor’s web browser to accelerate any future visit to the same site. This way, DNS caching is implemented at both the server level and the browser level.
Now, in order to utilize DNS caching for your website, you need to set an appropriate Time to Live (TTL) period for your DNS records. And your DNS server provider will give you options to do that. Depending on your scenario, your DNS server provider can be the same as your web hosting provider, your domain registrar, a third party provider or a private nameserver that you created yourself.
If you are interested to know more about this, then take a look at this article about DNS servers and how they affect website speed.
Cache Management
Now, you know about all these different types of caching and how you can use them for your advantage. But there is one important piece left in all of these and that is the way you manage these cache. This part is essential to ensure that your website visitors don’t see outdated contents after your webpages get any updates.
Time to Live (TTL)
Time to Live or TTL denotes the period of time that any data or file should be kept in the cache before it needs to be removed or refreshed. In other words, TTL is used to mean the cache expiration time.
When you update your website pages or any of their contents, their respective cached files become stale or obsolete. That’s why you need to have a system to remove those cached files so that visitors can get up-to-date contents from your website. And TTL is part of such a system that helps discard cached files after they are certain periods old.
You can declare the TTL period for any of your files using a method called cache-control HTTP header. This is used to tell if the files should be cached and if they should be cached then for how long.
A file with a long TTL period will be kept in cache for a longer period of time than a file with a short TTL period.
Generally, static files aren’t updated frequently so they can have a long TTL period. Conversely, dynamic files like the HTML pages are subject to frequent changes and so caching them may result in outdated contents to the viewers. That’s why dynamic files should have a short TTL period if you choose to cache them.
However, you can only set TTL for the files that are served from your server. So, if you use externally hosted files in your website, then you won’t be able to define how long those files should be cached. If you are interested to know more about externally hosted files, then you can check out this article on how external file linking affects website speed.
In case of CDN caching, you will come across two different types of TTL. One of them is edge cache TTL and the other one is browser cache TTL. Edge cache TTL defines how long your website files should be kept as cache in the CDN data centers. And browser cache TTL defines how long the files should be kept as cache in the visitor’s browsers.
Cache Updating Process
When you will implement all these different kinds of caching together, you will end up with a multi stage caching process. So, whenever you will need to clear any cached files, you will need to clear the cache for all the related stages. That’s why you will want to have a simple process that will let you easily clear cache from all these different stages of caching. Otherwise, you may face situations where you have cleared the cache for your updated files but your visitors are continuing to see outdated contents because you forgot to clear the cache of another stage in your caching configuration.
Often times you will be able to manually clear the cache from all the different stages of your caching process. But a better solution will be to set up a process that will automatically do the cache clearing work for you. This way, any updates to your site will trigger an automatic action that will remove all cache for the files that are related to that update.
If you are using WordPress, then you will be able to find many caching plugins that will help with this caching automation process for your specific caching setup. For instance, LiteSpeed Cache, WP Rocket, and some other caching plugins will be able to keep your cached files up-to-date by automating most of the caching related activities.