Performance problems are often simple and direct to users, such as slow loading of resources, slow running, or slow interaction. When these issues are presented to front-end developers, they are complex scenarios at the system level.
At the end of the above mentioned page life cycle, each link of this process is that we need to learn in depth, we need to do performance optimization and these are inseparable, are targeted at a local process optimization.
Everything from DNS resolution, TCP connection requests to HTTP, and subsequent front and back interactions, from resource requests to file parsing to critical render paths, can be a poor performance experience. To design workable optimizations, the browser page life cycle must be clear.
From entering the URL until the page loads
You all know the classic interview question: what happens from the moment you enter the URL until the page loads?
This question, which involves a lot of knowledge, can test the depth of the interviewer’s understanding and mastery of front-end performance optimization. Next, write your own understanding. From the perspective of the front end, the whole process is divided into several stages to be clear, and each stage can be further divided into different knowledge points.
-
The browser receives the URL to the web request thread to start.
-
A complete HTTP request.
-
The server receives the request and goes to the specific processing background.
-
HTTP interactions between the front and back and the caching mechanisms involved.
-
The key render path after the browser receives the packet.
-
JS engine parsing process.
There are also some optimization ideas mentioned above, we can see that there are corresponding places with the knowledge points here.
This diagram can be bookmarked as a complete structure of the page life cycle.
The network request thread is started
First, the URL is parsed, and then a new network thread is created to handle the resource download.
Because network requests are separate threads, the browser creates a network thread to request resources based on the parsed protocol.
A URL generally consists of several parts:
-
Protocol: indicates the protocol header, such as HTTPS, HTTP, or FTP
-
Host: indicates the host domain name or IP address
-
Port: indicates the port number
-
Path: indicates the directory path
-
Query: Query parameters, such as a=1&&b=2
-
Fragment: hash value after #, used to locate a location
Ps: process: minimum unit of CPU resource allocation. Thread: The smallest unit of CPU scheduling that is based on a process.
Setting up an HTTP request
It is mainly divided into two parts:
DNS resolution and TCP connection.
The DNS
DNS resolution is a process in which the host name is queried and the IP address corresponding to the host name is obtained. In short, the domain name is resolved into an IP address. You can think of a person has a lot of nicknames, sometimes you can’t remember the name, but the nickname you can call out directly, such as visiting Baidu, www.baidu.com is the domain name, we are using this address to visit, because baidu corresponding to an IP is 202.108.22.5 this, is not easy to remember. So IP, domain name can access the content that we want, but IP is not easy to remember, and domain name is easy to remember, like abbreviation.
There are two DNS query methods:
The client queries the local DNS server recursively
The local DNS server queries the root DNS server iteratively
When the local DNS server cannot answer DNS queries by itself, it needs to query other DNS servers. A recursive query is performed until the upper-level DNS server returns the resolution result. If the client submits requests to multiple DNS servers and obtains the resolution result, it is an iterative query.
Recursive query: The local DNS server queries other DNS servers as DNS clients instead of letting clients perform further query. The query result is returned to the local DNS server, and the local DNS server returns the query result to the client.
Iterative query: The local DNS server returns the next DNS server query to the client. The client queries the DNS server until the result is found. In other words, if the DNS server cannot return the IP address to be queried, the DNS server will not check the IP address, but will tell you which DNS server can handle the IP address, so that you can access the DNS server.
As you can see, there are only two returns for recursive queries: success or failure; An iterative query returns the best query point or host address.
There are many optimization strategies for DNS resolution speed. Details are generally considered from the following aspects:
-
DNS cache optimization
-
DNS preloading policy
-
Reasonable allocation of domain names for resources on the page
-
A stable and reliable DNS server
The DNS resolution beforehand
Through domain name access, each request will be resolved by DNS, and the time required for DNS resolution is very different, so DNS pre-resolution can significantly reduce the latency.
The solution
DNS Prefetch is a DNS pre-resolution technology. Domain names that may be used later are resolved in advance according to the rules defined by the browser. The resolution result is cached in the system cache, shortening the DNS resolution time and improving the website access speed.
How to use
-
When loading an HTML page, the automatic parser automatically obtains the domain names in the href attribute of all a tags on the current page and performs DNS pre-resolution.
When the browser encounters an HTTPS page, DNS pre-resolution is not automatically performed.
-
Automatic analytic control
If automatic parsing is enabled on HTTPS pages, you need to perform the following operations to add pre-parsing. If automatic parsing is not enabled on HTTP pages, you can disable it by setting off
<meta http-equiv="x-dns-prefetch-control" content="on"> Copy the code -
Manual parsing
<link rel="dns-prefetch" href=""> Copy the code
DNS Load Balancing
When the number of requests becomes large and the number of concurrent users is large, each time the resource requested is located on the same machine, the machine may crash at any time. In this case, DNS load balancing technology is needed. DNS load balancing is realized by DNS servers. Multiple IP addresses are configured to distribute client requests to different machines so that different clients can access different servers. An IP address can only correspond to one machine, so multiple IP addresses are a prerequisite.
Disadvantages: One is unable to distinguish whether the server is down, that is, whether the server is down, DNS will allocate. The other is not to care whether the request is cached by DNS, which may cause some servers to be stressed and others to be idle.
Ps: Common load balancers are as follows: 1. DNS load balancers between clients and reverse proxy servers. 2. Load balancing is performed between the reverse proxy server and the application server. Nginx load balancing falls into the second category.
Establish a TCP request connection
When static resources account for more than 90% of total page requests, the performance increase is only 10%, and the overall performance experience is significantly improved.
TCP ensures the reliability of transmission by sending, replying, and retransmitting. It is transmitted end-to-end. It is segmented in transmission, and the sender only sends several segments at a time. During this process, packets are segmented and sent sequentially for complete and correct assembly.
The process of establishing TCP requests between the browser and the server is based on TCP/IP, which is called Transmission Control Protocol/Internet Protocol. The Protocol consists of IP at the network layer and TCP at the transport layer.
After the BROWSER obtains the IP address from DNS, it establishes the TCP connection.
TCP establishes a connection with a three-way handshake, and disconnects with a four-way handshake.
These two diagrams can express these two processes in detail, so I will not elaborate on them here.
Two key elements: 1. Network transmission link establishment; 2. 2. Confirm data transmission.
In network transmission, not every link can be unblocked, and data transmission is inevitably lost or damaged.
In the second case, the data size needs to be optimized to reduce retransmission due to transmission loss or destruction, thus improving transmission efficiency.
In the first case, it is necessary to establish a high-speed proprietary network channel, or purchase third-party content network services to accelerate the optimization of the network channel between the browser and the server.
Front and back end interaction
Static resources use CDN
CDN provides the ability to access nearby, eliminating experience differences caused by different distances between users and the machine room. Optimization of CDN plays a key role in providing high-performance user experience. Compared with traditional access, CDN access is more cache server, if the cache hits, it will not go to the source site to obtain, if not, it needs to initiate a request to the source site, after obtaining data, it will cache a data in the cache server.
The CDN provides six main capabilities
-
Static acceleration capacity
The local cache acceleration capability provides a high-performance access architecture for nearby access, which caches the content accessed by users on edge nodes, eliminating the inconsistency of user experience caused by regional differences.
-
Uninstall the source site capability
For example, static resources such as pictures account for more than 90% of all requests of the website, and this visit is particularly huge. The existence of CDN will greatly reduce the pressure of the source site and improve the stability of the website.
-
Anti-attack capability
The existence of a large number of CDN can effectively disperse the malicious attack on the website from the center to the edge of CDN, so as to effectively prevent or reduce the harm caused by the attack.
-
Dynamic acceleration capacity
By caching resources on CDN edge nodes, the network distance for users to access resources is shortened, so as to achieve performance optimization.
-
User access sequence optimization capability
-
Intra-page resource prefetch
After obtaining the HTML of the page, the CDN server will prefetch the resources to the edge nodes of the CDN in advance to avoid obtaining resources from the source site and reduce performance loss.
-
Prefetch resources between pages
When the user visits the current webpage, the resources to be accessed are prefetched to the edge node of CDN in advance.
-
-
Ability to develop customized modules
Provide customized feature development, such as marginal image compression, adaptive image download, etc.
Ps: Edge node refers to the server that is actually provided for users to connect and access nearby.
HTTP related Protocols
HTTP is an application layer protocol based on TCP at the transport layer. There are differences between long links and short links at the TCP layer.
A long link is a TCP connection established between a client and a server. Multiple packets can be sent continuously, but the heartbeat check is required to maintain the connection.
When a client sends a request to the server, the CLIENT establishes a TCP connection. When the request is sent and the response is received, the client disconnects the connection.
In HTTP 1.0, short connections were used by default, and each HTTP operation of the browser would establish a TCP request, which would be disconnected at the end of the task.
In HTTP 1.1, long links are used by default. When a web page is opened, the established TCP connection is not broken, and the client continues to use the established connection for subsequent requests. But long links are not permanent either, and are made up of a duration that can be configured in the server.
After HTTP 2.0, there are more features than HTTP 1.1:
-
Multiplexing eliminates the need for multiple TCP connections because it allows multiple requests to be made on a single HTTP2 connection and therefore does not rely on establishing multiple TCP connections.
-
Binary framing, adding a binary framing layer between the application layer and the transport layer, and dividing the information into smaller frame requests.
-
Header compression reduces the packet transmission volume.
-
The server can send data before the client initiates a request. In other words, the server can send multiple responses to a request from the client. In this way, the server can actively push data to the client.
Ps: To use HTTP2, you must use HTTPS, and previous optimizations for HTTP 1.1 restrictions, such as Sprite images, are no longer needed.
Browser cache
Using caching in HTTP-based front and back end interactions can provide significant performance gains. There are two types of cache policies: strong cache and negotiated cache.
If the browser detects that the local cache is not expired, the browser directly reads the local cache without sending an HTTP request. In this case, the state changes to 200 from cache.
In cache negotiation, the browser sends an HTTP request to the server to check whether the file cached locally by the browser is modified. If the file is not modified, the file is read from the cache. In this case, the status is 304.
In the browser cache, the strong cache is superior to the negotiated cache. If the strong cache takes effect, the strong cache is used directly. If the negotiated cache request does not take effect, the server determines whether to use the cache.
The following diagram illustrates the logic triggered by the browser cache:
Key render path
Once we get the page we want to visit from the server, we need to parse the resource file and render it into the page content we see.
First of all, the browser will by parsing HTML and CSS files, to build a DOM tree and CSSDOM tree, the two are independent of the tree structure, but the DOM tree is to show the document content, CSSDOM tree is the document object corresponding style rules, need to merge the two object model for the render tree, so the browser to render the content according to the style rules to the page.
After the server returns the HTTP request, the browser begins to receive the data and finally displays the content on the screen. The following steps are required:
-
Parse the HTML header code and download the resource file referenced in the header code
-
Parsing HTML code and style file code produces two tree structures, the DOM tree and the CSSDOM tree.
-
By walking through the two tree structures, the browser calculates the size, location, color, and other styles of each node in turn, and combines them to construct the render tree.
-
Complete the drawing process according to the render tree.
Optimizing the critical render path is done in this resolution, rendering process in as little time as possible.
During this page parsing, the browser will block for various reasons.
-
JS code will block the DOM tree construction, because JS code may modify the DOM structure, so it must wait for the completion of JS code execution, the DOM construction will be restored. This is determined by the browser’s security resolution policy.
-
The browser must wait for the stylesheet to load before starting to build the CSSDOM tree.
-
In other cases, when the browser attempts to parse the HTML and encounters JS code before the CSSDOM tree is built, the browser will suspend the script execution (JS blocks the DOM tree construction, so the DOM tree construction will be blocked), and the original parsing will not resume until the CSSDOM is built.
As you can see, the harm of inline JS code execution in HTML is not in blocking DOM tree construction. It’s the time that the DOM tree build is blocked not just for the JS code to run, but also for the style resource file to download and the CSSDOM tree to build.
This process can be optimized from the following aspects:
-
Optimize HTML code and structure, shorten HTML download time, speed up parsing.
-
Optimize the CSS code and structure to shorten the download time and parsing time of CSS files.
-
Place JS code properly to avoid blocking DOM tree building.
summary
To see a lot of performance optimization related books, hope you can as far as possible comprehensive description of the whole life cycle process, finally found themselves with too much knowledge without contact, it is hard to describe clearly the contents of the knowledge points, so finally brought about the front-end system, let everybody principle can have a full understanding of the key knowledge points.
Zhejiang Dahua Technology Co., Ltd.- Soft Research – Smart City Product R&D Department Recruitment senior front-end ！！！！！ Welcome everyone to chat, you can send your resume to [email protected], join us, we can progress together, dinner together, travel together, let us from the world village partners into dahua village partners.