Using a cache to serve static assets is a great way to reduce the load on your web server by decreasing the number of requests it receives. It’s most useful for content that doesn’t change often.
A static asset is a file that’s not directly associated with a web page or application. Think of the header images you see on pages that don’t reside in the actual document — they’re just there to provide a visual. Another example might be an embedded video. The point is that static assets — such as images, videos, sounds, or even PDFs — aren’t directly tied to a particular piece of content.
One of the easiest ways to speed up a website is to use a cache for these types of assets.
- What is static asset caching?
An asset is a generic term used to describe a file sent from a web server to a browser. Assets can be HTML files, images, videos, stylesheets, and more.
Serving static assets is a fundamental feature of the web. The static asset is the same for anyone who visits the website. An example of a static asset is a logo; no matter who accesses the website, it will always be the same.
A dynamic asset is one that changes based on certain conditions. The most common is a personalized page where the content changes depending on the user. For example, the page could display a user’s name; it could display different content depending on browser location, or show other content depending on the user’s role.
With dynamic assets, every time a user accesses the website, the page must be regenerated.
Even though serving static assets is a fundamental part of the web and requires the least resources, it is still wasteful to repeatedly resend the same file when a user reaches a site.
One way to avoid such a waste of resources is to use browser caching. That’s when a browser keeps a local copy of static assets in its cache instead of requesting the static assets every time a user goes to a site.
Let’s look at the logo example again. The logo never changes, even though the rest of the page may change. As a user navigates from one page to another, instead of the browser requesting a new instance of the logo — which never changes — the server can tell the browser to keep a local copy. That way, until the logo changes, a browser does not need to request a new version.
The logo is only one example of a static asset that the browser can cache. Other common assets are JavaScript code, CSS files, and static HTML files.
Another caching option is a server cache. A server cache is useful when a web server uses code to generate HTML. Instead of executing the code and generating the HTML file every time a page is accessed, the server runs the code periodically and saves the generated HTML so a browser can cache it. When a user accesses a specific URL on the site, instead of getting a copy generated by code (like PHP), the browser receives a copy of the already-generated static HTML.
When the code changes, the browser generates a new static version of the HTML file, which replaces the previous one. Then, when a browser requests that HTML file, it will get the more recent copy and override the previous one in its cache.
- The benefits of caching static assets
When sites load fast, users are likely to have a better user experience. But if a site is slow, they will quickly lose patience and try to find that particular information elsewhere. To keep users on your website, loading your site as fast as possible is one of your primary goals.
Caching static assets
- provides a better user experience and helps with search result rankings when it meets Google’s requirements for a site’s loading time and performance .
- How to implement caching for static assets
The way to implement caching for your website is to put a caching policy in place. This consists of several rules telling the server which assets can be cached and which ones cannot. The server tells the browser which assets to cache and how long to keep using that version of the asset before requesting a new one.
Let’s be clear, though, that caching static assets is not a cure-all for all that ails your site. There are several other things to consider before you implement caching on your site:
- There isn’t one right recipe to implement caching. Each website has its own idiosyncrasies and may need different types of caching.
- It requires good analysis and monitoring to get it right and to keep it working efficiently over the long run.
- If you get your caching expiry wrong, it might make things even worse. For example, say there is a problem with some JavaScript code, and you have set a long expiry for the browser cache. You fix the bug and upload the code to the server. When the user returns to that page, the caching policy tells the browser to use the JavaScript from its cache, because the expiry date has not been reached yet. The user will still experience the problem that the code fix was supposed to solve because they are still using the older, buggy version.
- If the expiry is too short, it’s almost the same as not having implemented a cache at all..
Implementing the right caching policy for static assets is an ongoing concern and should be part of your regular monitoring as your site evolves.
There isn’t one “right” way to cache static assets, and the most suitable approach depends on your website and what you’re trying to accomplish.
- Caching static assets using .htaccess
The easiest way to set up a caching policy is to use the .htaccess file. Using the .htaccess file allows you to specify caching by type. This is the simplest method, because you set the policy once, and you never have to touch it again.
- Caching static assets using the Cache-Control header
A Cache-Control header instructs the server to tell the browser how an asset is cached, where it is cached, and how long to cache it before fetching a new version.
Cache-Control headers also support other options to tailor the caching policy:
- public – Anyone can cache the asset, including browsers, proxies, and CDNs. This is useful for most static assets.
- private – The asset can only be cached by the user’s browser. Use this option when a page contains sensitive data.
- no-cache – This option forces the browser to verify with the server every time it requires an asset. It puts more load on the server, but is useful for assets that are updated irregularly.
- no-store – This disables caching completely. It can be used to prevent the browser from caching information at all. An example of when to use this setting is when the price of a product on a page changes regularly.
While we’ve covered the basics of serving static assets, there are other avenues to explore, such as using on-demand caching using a WordPress plugin, caching on CDNs (Content Distribution Networks), or caching on proxy servers.
Don’t rely on the default caching configuration provided by your hosting provider. While it may be suitable for many websites, each website is different and should be treated as such. Your users — and your revenues — depend on it.