Send browsers caching directives that they will use to cache static assets on the client-side. Will have an appreciable impact on the perceived speed of website page loads since these static assets will not be re-served from the webserver while they exist in the browser cache.
To instruct web browsers to cache static assets for 30 days, use the following location block:
server {
# ...
location ~* \.(css|js|jpg|jpeg|png|gif|ico|txt|woff|woff2|ttf)$ {
expires 30d;
}
# ...
}
After the first request of a static asset whose extension is in the pipe-delimited list above, say logo.png, the browser will locally cache the file. Subsequent requests for the file logo.png will be served from the browser’s local cache rather than re-requesting logo.png from the server (until the cache expires, in this case 30 days, or until the user clears their browser cache or it is otherwise purged from their browser cache).
If you’d like more fine-grained control over the length of time specific types of static assets are cached, simply break them up into more specific groups:
server {
# ...
location ~* \.(jpg|jpeg|png|gif|ico|txt|woff|woff2|ttf)$ {
expires 30d;
}
location ~* \.(css|js)$ {
expires 7d;
}
# ...
}
The two rules above would cache images and fonts for 30 days, and css and javascript files for 7 days.
It’s noteworthy that one downside to using static asset caching is the loss of control when an updated logo.png might be introduced; if the old logo.png has been cached by the browser, IT will be served rather than the updated file. Renaming the file will cause the new file to be served, or cache-busting techniques such as appending a query_string to the static asset’s url, as in logo.png?v=1.2.3 will address this as well. This is a small tradeoff for the performance gains client-side caching provides.