# Mastering Front-End Development: Understanding Browser Caching
Written on
Chapter 1: Introduction to Browser Caching
This article aims to clarify browser caching strategies, catering to both junior front-end engineers seeking to learn and senior developers looking to refresh their knowledge. Over the next month, I will delve into various aspects of front-end development to strengthen my own skills and share valuable insights.
The following sections will cover a range of topics:
- Relearning Front End — HTML
- Relearning Front End — CSS
- Relearning Front End — JavaScript Basics
- Relearning Front End — JavaScript Object Oriented
- Relearning Front End — JavaScript V8 Engine Mechanism
- Relearning Front End — Browser Rendering Mechanism
- Relearning Front End — Browser Caching Strategy
- Relearning Front End — Sorting Algorithm
- Relearning Front End — Design Patterns
- Relearning Front End — Network
- Relearning Front End — Front End Security
Chapter 2: Exploring Cache Types
This section details the locations and priorities of various caching strategies utilized by browsers:
- Service Worker: Similar to a Web Worker, it operates in a separate thread. It enables the caching of files, which can be accessed later by the main thread. This method allows for selective caching and the establishment of rules for matching and retrieving files, with persistent cache storage.
- Memory Cache: Often referred to as the RAM cache, it is not persistent. This cache is cleared when the process ends.
- Disk Cache: This type resides on the hard drive and offers improved persistence and capacity compared to memory cache. It decides which resources to cache based on HTTP header fields.
- Push Cache: A less common HTTP/2 feature, this cache is used for specific content delivery.
Chapter 3: Caching Strategies in Browsers
In this chapter, we will discuss caching strategies that determine how a browser interacts with cached resources:
Strong Caching
In this scenario, the server is not consulted for a cache. The strategies include:
- Setting Expires: This establishes an expiration time for the cache. For instance, "Expires: Thu, 26 Dec 2019 10:30:42 GMT" indicates that the cache will be invalid after this timestamp.
- Setting Cache-Control: Introduced in HTTP/1.1, this allows for setting expiration through the max-age directive, such as Cache-Control:max-age=3600. Additionally, it can designate the cache as private or no-cache.
Cache Negotiation
This involves checking with the server to determine if the cache has expired. Key components include:
- Last-Modified: When first requested, the server appends the Last-Modified date to the response header. On subsequent requests, the browser includes the If-Modified-Since header with the previously received date. If unchanged, the server responds with a 304 status; otherwise, it sends the updated resource along with a new Last-Modified date.
- ETag: A unique identifier for a file that changes when the content does. The process mirrors that of Last-Modified: the server sends the ETag, and the browser checks it on subsequent requests with the If-None-Match header. If the ETag matches, a 304 status is returned; if not, the new resource is sent.
Comparing Last-Modified and ETag
ETags are generally more precise than Last-Modified values, as the latter can change even if the file itself remains unchanged. Last-Modified has a one-second resolution, meaning if a file is altered within that timeframe, it may still utilize the cache.
If no caching policy is established, browsers typically default to using the response header's Date minus 10% of the Last-Modified value for cache duration.
Conclusion
Thank you for your attention. I hope you found this exploration of browser caching strategies informative. Stay tuned for more insightful articles.
For more resources, visit PlainEnglish.io and consider subscribing to our free weekly newsletter. Connect with us on Twitter, LinkedIn, YouTube, and Discord. If you're interested in Growth Hacking, check out Circuit.