“This is the fourth day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021.”

The introduction

Following the previous web front-end performance optimization, the browser optimization module mentioned the browser cache strategy

Why do browsers use caching when they can store the first access to the resource locally and then access it on the second attempt without having to pull it from the server

The cache location

First of all, let’s talk about the browsing cache location, which is generally divided into the following types:

  • Service Worker: a separate thread running behind the browser that has free control over which files are cached, how the cache is matched, how the cache is read, and the cache is persistent
  • Memory Cache: Memory based cache, efficient and fast to read, but once the page is closed, memory is released.
  • Disk Cache: Disk – based cache with large capacity and slow access
  • Push Cache: push cache, http2 content, cached in session session

Caching strategies

There are two types of browser cache policies: strong cache and negotiated cache, and both cache policies are implemented by setting HTTP headers

  • Strong caching: Resources are read directly from the Cache without sending a request to the server. Strong caching can be implemented by setting two HTTP headers: Expires and cache-Control

    • Expires:

      Cache expiration time, used to specify the expiration time of resources, is a specific point in time on the server

      Expires is a product of HTTP/1 and is limited to local time, which can invalidate a cache if you change it
    • Cache-Control:

      A product of HTTP/1.1, such as cache-control :max-age=300, in seconds, means that the Cache will be strong for a second request within 5 minutes

    Comparison: Cache-control takes precedence over Expires

  • Negotiated cache: Negotiated cache forces the browser to send a request to the server with the cache id after the cache expires. The server decides whether to use the cache based on the cache id. Negotiated cache can be implemented by setting two HTTP headers: Last-Modified and ETag

    • Last-Modified:

      http1.0

      Principle: When the browser accesses the resource for the first time, the server adds last-Modified time to the response header. This time is when the server Last Modified the file. Then, when the browser accesses the resource for the second time, it detects last-Modified in the cache file. If the request header contains if-modified-since, the server compares this value with the Last Modified time of the request file. If there is no change, the server returns 304. If it is less than the Last Modified time, the server returns 304. If the file is updated, a new resource is returned with the status code 200
    • ETag:

      http1.1

      Principle: This is similar to last-Modified, except last-Modified returns the Last Modified point in time, whereas ETag returns a new token each time the server is visited. On the second request, if-none-match with the value buried in the request header is sent to the server. The server compares whether the old and new tokens are the same. If they are the same, the server returns 304 to inform the browser to use the local cache. If they are not the same, the server returns a new resource, a new ETag, and the status code is 200

    Comparison: ETag is more accurate and last-Modified

  • If no cache policy is set: in this case, the browser uses a heuristic algorithm that typically takes 10% of the Date minus last-Modified value in the response header as the cache time

conclusion

Although the browser cache is set by the server, but as the front-end students we must also understand the extended knowledge system, the interview will be handy! Welcome to like attention!