Long wanted to sort out what the browser's caching mechanism, and we have no time, actually the lazy friends (* ^ ▽ ^ *), you know, people are lazy, this is just a false God Great God o ( '^ ` ) o, is no exception.
Today more rare leisure, or learn about successful human experience, combing it, a good memory as bad written, maybe interview which it met
In the front-end development, the performance is an eternal topic, there is no best, only better. Analyzing the performance of a site is good or bad, into a straight, i.e. the reaction rate Grossly page, there is a way to use the cache, the cache policy may be a good to shorten the time of the page request, reduce latency, and the web can be reused, can also reduce the bandwidth and reduce network load.
1: Why do we need the cache?
a: cache can reduce user wait time and enhance the user experience
b: reduce network bandwidth consumption
c: to reduce server stress
Note: improper use of caching, can also cause 'dirty data' problem
2: Common cache type
Strong Cache -
Expires server-side settings to indicate the expiration time of the resource, there will be drawbacks, inconsistent time client and server time.
Cache-Control: max-age indicates the maximum life cycle of cache resources, in seconds
So Expires used in conjunction with Cache-Control, is generally more suitable for large-scale site
Cache negotiation -
Last-Modified: The last time the cache value of resources, with the server response is returned
If-Modified-Since: By comparing the two time to determine whether the resource has been modified twice during the request, and if not, consult the cache hit
Message digest that uniquely identifies the content of the resource represented, namely resources: Etag
Has been modified by comparing the server requests during the If-None-Match header to determine whether the resource is consistent with the current request for resources in two Etag: If-None-Match
3: a flow diagram cache:
Icon resolved
a: the browser will first detect the type of strong cache (Cache-Control or Expires) is valid; get hit directly the local browser cache resources
b: miss. Server based on request headers Request Header verify this resource cache hit consultations, known as secondary HTTP authentication, hit, the server returns the request, but returns a resource, but to tell the client directly in directly from the browser cache
Note：
1. Strong cache does not request occurs, there is a cache server requests consultations
2. When the negotiation cache also misses the server resources will be sent to the client
3.F5 refresh the page, the cache will skip strong
4.Ctrl + F5 to refresh the page, skipping caches and strong negotiation cache
The situation does not cache
Cookie HTTPS POST request acquiring authentication information according Request Header Cache-Control: NO-Cache, max-Age = 0
6. stories truths
Above the whole concept made an exposition, the image is not enough, we have to understand a few vivid stories about:
Story: Last-Modified
Browser: Hi, I need jartto.min.js this document, if it is the Last-Modified: modified after 15 2019 19:57:31 GMT Fri Feb, please send me.
Modified server which checks the file)
Server: Oh, this document has not been modified after that time, you already have the latest version.
Browser: Great, I'll be displayed to the user.
Story Two: ETag
Browser: Hi, I need jartto.css this document, there is no mismatch 3c61f-1c1-2aecb436 this string
Server which checks ETag ...)
Server: Hey, here it is my version 3c61f-1c1-2aecb436, you have the latest version
Browser: Well, then you can use the local cache
After reading these two stories, whether a clearer understanding of the negotiation cache. With indeed very image
Reference links:
https://www.toutiao.com/i6719737927439483400/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1×tamp=1568456352&app=news_article&utm_source=weixin&utm_medium=toutiao_ios&req_id=201909141819110100140470141C9477FF&group_id=6719737927439483400