Browser caching problem principle and solution

Browser caching issues:

Simply put, browser caching is to store a copy of a requested web resource (such as html page, image, js, data, etc.) in the browser. The cache keeps a copy of the output content based on incoming requests. When the next request comes, if it is the same URL, the cache will decide whether to directly respond to the access request with a copy or send the request to the origin server again according to the caching mechanism. It is more common that the browser will cache the webpage of the visited website. When the URL address is accessed again, if the webpage is not updated, the webpage will not be downloaded again, but the locally cached webpage will be used directly. The browser will download the page again only if the website clearly identifies that the resource has been updated.

Why use cache:

(1) Reduce network bandwidth consumption

(2) Reduce server pressure

(3) Reduce network delay and speed up page opening

Browser-side caching rules:

Freshness (expiration mechanism) : that is, the validity period of the cached copy.

Check value (verification mechanism): Entity tag Etag (EntityTag) of the resource

Solution:

(1) Use HTMLMeta tags

Web developers can add the <meta> tag to the <head> node of the HTML page, the code is as follows

<metahttp-equiv="Pragma"content="no-cache">

In fact this form of disabling the cache is of limited use:

a. Only IE can recognize the meaning of this meta tag, and other mainstream browsers only recognize the meta tag of "Cache-Control: no-store".

b. Recognizing the meaning of the meta tag in IE does not necessarily add Pragma to the request field, but it does make the current page send a new request every time (only the page, the resources on the page are not affected) .

(2) Use cache-related HTTP message headers

Among the message headers of HTTP requests and responses, common cache-related message headers are:

rule	message header	Value/Example	Types of	effect
Freshness	Pragma	no-cache	response	Tell the browser to ignore the cached copy of the resource, and every time you visit, you need to go to the server to pull [the fields that exist in http1.0, which have been abandoned in http1.1 and are replaced by Cache-Control, but in order to make the http protocol backward compatible , many websites will still bring this field]
	Expires	Mon,15Aug201603:56:47GMT	response	Enable caching and define caching time. Tell the browser the expiration time of the resource cache. If the time point has not passed, the request will not be sent. [A field that exists in http1.0, the cache time defined by this field is relative to the time on the server. If the time is inconsistent with the time on the server (especially if the user has modified the system time of his computer), the cached time may be meaningless. Since HTTP version 1.1, use Cache-Control:max-age=seconds instead]
	Cache-Control	no-cache	response	Tell the browser to ignore the cached copy of the resource, force every request to go directly to the server, pull the resource, but not "don't cache"
		no-store	response	Force the cache not to keep any copies under any circumstances
		max-age = [seconds]	response	Indicates how long the cached copy is valid, the number of seconds between the request time and the expiration time
		public	response	Cachers of any path (local cache, proxy server) can unconditionally cache and change resources
		private	response	Cache resources only for a single user or entity (different users, windows)
	Last-Modified	Mon,15Aug201603:56:47GMT	response	Tell the browser when this resource was last modified. When the server passes the resource to the client, it will add the last modified time of the resource to the entity header in the form of "Last-Modified:GMT" and return it to the client [only accurate to the second level, if some files are in 1 Within seconds, if it is modified many times, it will not be able to accurately mark the modification time of the file]
	If-Modified-Since	Mon,15Aug201603:56:47GMT	ask	Its value is the Last-Modified value of the last response header, and the header If-Modified-Since is included when requesting the web server again. After the web server receives the request and finds that there is a header If-Modified-Since, it compares it with the last modification time of the requested resource. If the last modification time is newer, indicating that the resource has been changed again, it will respond to the entire resource content (written in the response message package), including updating the value of Last-Modified, HTTP200; if the last modification time is older, indicating that the resource is not new If it is modified, it will respond with HTTP304 (no package body, save browsing), and tell the browser to continue to use the saved cache
check value	ETag	"fd56273325a2114818df4f29a628226d"	response	Tell the browser the unique identifier of the current resource on the server (the generation rule is determined by the server)
check value	If-None-Match	"fd56273325a2114818df4f29a628226d"	ask	When the resource expires (using the max-age identified by Cache-Control), it is found that the resource has an Etage declaration, and the header If-None-Match (the value of Etag) is added to the request to the web server again. After the web server receives the request and finds that there is a header If-None-Match, it compares it with the corresponding check string of the requested resource and decides to return 200 or 304

Browser caching problem principle and solution

Guess you like