Browser cache

  • The way a browser handles a Web page
  • Going to the negotiation cache returns 304
  • Going to the strong cache returns 200

  • Use browser caching wisely
  • Requests for page connections do not need to be cached for a long time
  • Sensitive data such as orders should not be cached
  • The static resource portion is usually set for a long cache time
  • Separate hot and cold data to reduce requests
  • Do not arbitrarily modify the file, recommended to use? Version =** calls multiple versions
  • ETag is not recommended, especially for distribution
  • Header field output mode
  • HTML output mode
<meta http-equiv="Cache-Control" content="max-age=7200">
  1. PHP output mode
<? php header('Cache-Control:max-age=7200');
  • Header field for the strong cache phase

State of strong cache enabled: 200

The timing of execution to a strong cache is:

Graph TD A[browser] --> B[cache] B --> C{Yes or No? } C -- - > | yes | D whether [date] D - > | no | E [the use of the contents of the cache]
  • Pragma (HTTP 1.0)
  • Expires (HTTP 1.0) (sets an exact time)

  • Cache-control (HTTP 1.1)

    • Max-age (maximum number of seconds in the cache)
    • Public \ private (also converted to private when set to Public and using the HTTPS protocol)
    • No-cache \ No-store (Not allowed on user’s hard drive) \ Must-revalidate (Must request authentication)

If all three parameters are present at the same time, the order of precedence is 1, Cache-Control 2, Pragma 3, Expires

  • Header field for the negotiation cache phase

The status of the negotiation cache enabled is 304 Not Modified

  1. Last-modified: The Last update mark, which indicates when the file was Last updated (downward response)
  2. If-Modified-Since: The last Modified time of the resource (upline request)
  3. E-tag: Entities and Tags (Downlink)
  4. If-none-match: resource content identifier (uplink)

The negotiation cache execution process is as follows:

Graph TD A[Browser makes first request to server] --> B[server Response Headers contains Last-Modified: Mon, 21 OCT 2019 00:44:35 GMT] B -- --> C[server Request Headers for the second Request to the browser with if-modified-since: Mon, 21 Oct 2019 00:44:35 GMT] C - > D {the if-modified-since and file the last-modified compare} D - > | yes | E [file was Last Modified time no change] E - > F [Status Code: 304 Not Modified]

Since the minimum granularity of the Last-Modified and If-Modified-Since fields is seconds (MON, 21 OCT 2019 00:44:35 GMT), a problem arises: When a file changes n times in 1s, the server has no idea if it needs to perform a forced cache. This introduces the concept of E-tag. When the file is modified, the e-tag regenerates a string, which is then carried by the if-none-match field the second time the browser requests it. “E-tag”, “If-None-Match” and “Last-Modified” and “If-Modified-Since” are executed exactly the same way.