1、 Timing panel analysis
1. Load picture for the first time
The browser loads a picture for the first time, which is the request process that can be viewed through F12.
Queued at 840.08ms: indicates the time to wait for the queue (queuing: queuing time)
Started at 840.66ms: indicates that the picture begins to be processed (start request)
Stalled: start to establish connection (waiting for the time allocated by the browser, waiting for 0.96ms)
DNS Lookup: time spent parsing DNS
Initial connection: establish a connection with the server (TCP handshake)
SSL: the time when HTTPS was established (Hypertext Transfer Protocol, SSL verification encryption)
Request sent: when the request was sent
Waiting: waiting for a response from the server
Content DownloadResponse time of data received:
It can be seen that a picture takes 52.27ms from request to response. The response time of the picture is related to the queue process, the size and cache of the picture.
2. 304 cache load picture
When the expires and cache control cache time are set for the image, the requested time becomes 9.57ms when the image is requested again, which saves the time of connecting to the server and DNS query. Of course, the browser also has negotiation cache. When the expires and cache control time expire, the server will request the server. The server will judge whether the resources are changed through if modified since, last modify, Etag and if none match If the resource is not changed, return 304 to use the local cache, otherwise return 200.
2、 Optimization measures
- Use DNS cache;
- Establish a persistent connection through the connection: keep alive feature, which can make multiple requests on the current connection without domain name resolution;
- Reduce HTTP requests by using CSS sprites, inline images, merge scripts and style sheets
- Set expires
- Use CDN to improve the response speed (the cache server directly responds to user requests)
4. Content download
- If modified since and last modified, reduce the size of the response (304 cache response)
- Remove duplicate scripts, streamline and compress code, such as with the help of automated build tools such as grunt and gulp
- Compress the response content and enable gzip compression on the server side to reduce the download time
3、 Negotiation cache vs strong cache
Caching can improve the overall loading speed of web pages and improve the user experience. At the same time, the cache is divided into
Cache usageThis paper mainly discusses browser caching.
Browser cache is divided into
1. Strong cache
Strong cache determines whether to use cache through expires and cache control.
Set the response header expiration time and use the cache during this period.
Max age = 600. In the next 110 minutes, this request will use strong cache when accessing again.
Cache control: no cache: do not use local cache. You need to use cache negotiation. First confirm with the server whether the returned response has been changed. If Etag exists in the previous response, it will be verified with the server when requesting. If the resource has not been changed, you can avoid downloading again.
Cache control: no store is the real way to not cache data locally
Cache control: public can be cached by all users (shared by multiple users), including intermediate proxy servers such as terminals and CDNs
Cache control: private can only be cached by the terminal browser (and private cache), and the relay cache server is not allowed to cache
2. Negotiation cache
When the expires and cache control time expires, it will request the server to verify whether the negotiation cache is hit. If the negotiation cache is hit, it will return 304 status code and display (not modified) string.
Negotiation cache is determined by [if modified since, last modify], [Etag, if none match].
When the web server responds to the request, it tells the browser the unique identification of the current resource in the server (the generation rule is determined by the server). Etag will also be updated when the server-side request resource changes.
The header of if none match will send the Etag returned last time to the server and ask whether the Etag of the resource has been updated. If there is any change, it will send a new resource back
Last modify identifies the last modification time of the resource. When the browser requests the resource again, the request header of the request will contain if modify since, which is the last modify returned before caching. After receiving if modify since, the server determines whether to hit the cache according to the last modification time of the resource.
It is equivalent to returning Etag and last modified in the received response header in each request. The request header will bring the two (if modify since, if none match) in the next request. The server will compare the identification to determine whether the resource has changed. If the resource has not changed, Etag and last modified will not change. The server returns 304 status and the client uses cache. If the resource has changed, it will return 200, Use new resources.
For last modify and Etag, the server will verify Etag first. If Etag is the same, compare last modify to decide whether to use 304 cache.
3. Status code difference
200: when the strong cache expires / cache control memory fails, a new resource file is returned
200 (from cache): strong cache expires / cache control both exist and are not expired. When cache control takes precedence over expires, the browser successfully obtains resources from the local browser
304 (not modified): when the negotiation cache last modified / Etag has not expired, the server returns the status code 304
3. Flow chart