This is the sixth day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021
As a front-end, you should know the parameters of the browser console. But as far as I’m concerned, the console is just checking to see if the interface is returning 200, and what data is being returned. Almost nothing else, until one day, I had a problem.
The problem
I have a Dashboard page with N pictures and N charts, which has no problem loading and switching tabs at ordinary times. However, I found that if I stay on other TAB pages for more than five minutes and then switch to Dashboard, the relevant CSS package will be pending, which is about 2.5 seconds later. Only when the relevant content is requested back can the page be displayed normally. Normally, the request of millisecond level reaches close to 3 seconds in this case, as shown in the figure below.
Waterfall Parameter Introduction
Waterfall: Means Waterfall flow, and in Waterfall we can see exactly what part of the time is spent.
- Queueing: The time for the browser to queue resources, such as higher priority requests or requests with more than 6 concurrent requests.
- 例 句 : time of stagnation due to time in queue
As can be seen from the figure above, the problem I encountered is that this stage takes a long time. To avoid this stage, I can do some general optimization, such as CSS/JS merge compression, image compression, using Sprite image, and CDN on static resources.
That if the relevant optimization, time is still relatively long, is generally Stalled. That is, the time between a TCP connection being established and actually being able to transmit data,
- Proxy negotiation: Negotiates the time with the Proxy server.
- DNS Lookup: DNS Lookup time. The browser needs to convert the domain name to an IP address.
Optimization measures: use DNS cache; Using the Connection: keep-alive feature to establish persistent connections, multiple requests can be made on the current Connection without domain name resolution.
- Initial Connection: Time required to establish an HTTP Connection before the browser sends a request.
- SSL: If the site uses HTTPS, this is the time for the browser to establish a secure connection with the server.
- Request sent: Indicates the time when the Request is sent.
- Waiting (TTFB) : The time spent Waiting for the server to return data. This time is subject to the server processing performance.
- Content Download: The time it takes for the browser to Download a resource, which is subject to file size and bandwidth.
After understanding the above related parameters, let’s look at the specific problems I am facing and the solutions.
Reasons for screening
The possible cause is that the browser has a limit on the number of concurrent connections to the same host name. If the number of concurrent connections exceeds the limit, other requests will be blocked waiting for new connections to be available. Scripts also block downloads of other components.
And I don’t have the above problem, the server is handled. My time and Initial connection have been relatively long The meanings of these two parameters are described above. Based on this, I locked the problem down to the interface’s response header.
In the response header, Connection is not set for static resource requests and the value is keep-alive: Since HTTP/1.1, all browsers have keep-alive enabled by default. Both the client and server can choose to close the connection at any time. Therefore, connection:close is displayed in the request header. Simply put, when a web page is opened, the TCP connection between the client and the server for the transmission of HTTP data is not closed. If the client accesses the web page on the server again, the established TCP connection is used. But keep-Alive does not hold a connection forever, it has a hold time that can be set in different server software such as Apache.