Browser page resource loading process and optimization

One of the keys to evaluating page performance is page loading speed, and the key to page loading speed is the loading of page resources. This article will analyze the browser page resource loading process, to introduce the concept of page critical request path, and give some methods on how to optimize the critical request path. The following related content, are chrome browser as an example to introduce. There may be some differences between browsers, but the basic process is the same.

The browser load resource process

First, two questions:

• How does the browser know which resources to load?
• In what order does the browser load these resources? When a browser intercepts a page request, it does four things in sequence, as shown in the figure below.
  

  

1. All the resources that need to be loaded are sorted first.
2. The load permission of the resource is then determined according to the security policy associated with the browser.
3. Then the load priority of each resource is calculated and sorted.
4. The last step is to load the resources in order of load priority.

Step 1: Resource classification

Chrome divides resources into 14 categories, as shown in the following table.

type	introduce
kMainResource	The main resource, the HTML page file resource, is of this type
kImage	Various picture resources
kCSSStyleSheet	Cascading Style Sheet CSS resources, as the name suggests
kScript	Script resources, such as JS resources
kFont	Font resources, such as font sets commonly used in web pages. Woff resources
kRaw	Mixed type resources, the most common Ajax requests fall into this category
kSVGDocument	SVG scalable vector graphics file resources
kXSLStyleSheet	XSLT, the Extended Stylesheet Language, is a transformation language; consult W3C XSL for information on this type
kLinkPrefetch	Link prefetch for HTML5 pages, such as DNS-prefetch. More on this below
kTextTrack	Subtitles resources for video, – i.e<track>The label
kImportResource	HTML Imports, import an HTML file into another HTML document, for example<link href="import/post.html" rel="import" />. For more information, please refer to the relevant documentation.
kMedia	Multimedia resources, video or audio belong to this category
kManifest	HTML5 application cache resources
kMock	Reserved test type

Step 2: Security policy check

Content Security Policy (CSP) is a whitelist system provided by the browser. Developers improve web security by configuring the browser to tell the browser what limits external resources can load and enforce. One of the most common applications is to prevent XSS attacks by limiting the loading of untrusted domain name scripts. CSP can be configured in two ways. The first is through the content-security-policy field in the HTTP request header of the page. This is the request header for the www.google.com page, as shown below:

<meta>
<meta>

1. For prevention of XSS:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; style-src nos.netease.com kaola.com;">
Copy the code

Script-src stands for script resources; Style-src stands for style resources; ‘self’ means that only foreign resources in the current domain are trusted, and all resources in other domains are intercepted. Nos.netease.com kaola.com means to trust the resources under the two domains nos.netease.com and kaola.com. Therefore, the above label means that only script resources in the local domain are trusted. For style resources, nos.netease.com and kaola.com are loaded in addition to the local domain.

2. Site request protocol upgrade transition (HTTP to HTTPS) :

<meta http-equiv="Content-Secur****ity-Policy" content="upgrade-insecure-requests">
Copy the code

The upgrade-insecure requests above means exactly what it means: upgrade all non-secure requests. When this meta tag is added, the browser will automatically upgrade all HTTTP requests in the HTTPS page to HTTPS. For example, when we need to transform the whole site from HTTP to HTTPS, for the original large number of HTTP resources will be directly forced to send the request in HTTPS or WSS SSL encryption form without error. Of course, if the resource server does not support SSL encryption such as HTTPS, the resource will not be loaded.

3. Use to block Mixed Content:

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">
Copy the code

Mixed Content is the second example of an HTTP request made on an HTTPS site. This type of content is called mixed content when unsecured request content is mixed in the secure link. When such a request occurs, we can find the corresponding warning message in the browser console, as shown in the following figure.

MDN

Step 3: Resource priority calculation

The priority of resources is divided into five levels. The naming and description of these levels may vary from source to source. This is mainly because the data itself may be presented in one of three directions: the network level, the browser kernel, or the client console display. These three directions, although different names for the five levels, are all one-to-one correspondence. At the network level, the five levels are: Highest, Medium, Low, Lowest, Idle; Browser kernel, level 5 are: VeryHigh, High, Medium, Low, VeryLow; The user console shows that the five levels are: Highest, High, Medium, Low, and Lowest;

The following is the browser kernel as the research direction, to introduce the browser resource priority calculation process:

• The first step is to set the default priority based on the type of resource. The browser has a default load priority rule for each resource class:

1. HTML, CSS, and FONT have the highest priority.
2. This is followed by preload resources (preloaded via the tag), script, and XHR requests.
3. Then pictures, voice, video;
4. The lowest is prefetch.

• The second step is to adjust the priority according to certain practical rules. After the initial priority is set, the browser will adjust the priority based on the actual property of the resource and its location in the document to determine the final load priority order. The adjustment rules for several common resource types are as follows:

1. For XHR request resources: Adjust the priority of synchronous XHR requests to the highest. XHR requests can be divided into synchronous and asynchronous requests, and browsers prioritize synchronous requests to the highest level in order to get data early and speed up page display.
2. For image resources: Priority changes depending on whether the image is in the visible view. The default priority of image resources is Low. In order to improve the user’s experience on the first screen, modern browsers calculate whether the Image resources are in the visible view of the first screen during rendering. If so, the priority of the Image in viewport resources will be elevated to High.
3. forThe scriptResources: Browsers prioritize three types of scripts based on their location and attribute tags. First, the priority of scripts that have added defer/async attribute tags will all be reduced to Low. Then, scripts that do not have this attribute added fall into two categories, based on whether the script is placed in the document before or after the first image shown by the browser. In the previous(mark early * *)It’s going to be High priority, after that(tag newest * *)Will be set to Medium priority. The following figure summarizes the priorities of various resources after the resource priority calculation, especially the three common resources mentioned above. The red box indicates the script type, the purple box indicates the picture type, and the blue box indicates the XHR request. photoClick here to.
   

   

Step 4: Load or block resources according to the security policies and priorities calculated above.

Critical request chain and optimization

The above describes the browser resource loading process in detail, the core of which is the calculation of resource loading priority. We can optimize the load priority order of resources, to effectively improve the page loading response speed.

Let’s first introduce the concept of critical-Request-chains. The resource request queue that must be loaded when the visual area is rendered (the first screen) and available to the user is called the critical request chain. In this way, we can use the critical request chain to determine which resources to load first and in what order, so that the browser can load the page as quickly as possible.

How do you find pagesCritical request chain

1. Obtain key image resources from the snapshot on the first screen. As shown in the following figure, we use the snapshot of the first screen to obtain the image resources to be loaded on the first screen. (in red box)
   

   

2. throughLightHouseThe plug-in gets the key JS and CSS resources in the critical request chain.LightHouseDetailed usage method can be clickhereTo get to know. By executing the plug-in, you can eventually produce a report that contains a comprehensive report and recommendations on the performance of the page. A report on the critical request chain looks like this:
   

   

3. Open the Chrome console and switch to the Network TAB to view the Priority of the resource. If you do not have a Priority column, you can choose Priority from the right click drop-down menu. As shown in the figure below:
   

   

To optimize theCritical request chain

There are many ways to optimize a critical request chain, but here are two.

• The first method: use Preload and Prefetch.

  Both of these tags were introduced earlier in this article and are part of the preload performance optimization technique. As a developer, we probably know more about our application than the browser does. This technique can be used to inform the browser that certain resources are likely to be used in the future, so that the browser can load these resources in advance. Preload:

  <link rel="preload" href="test.jpg">
  Copy the code

  Prefetch: Prefetch includes resource preloading, DNS preresolution, HTTP preconnection, and page prerendering.

  Resource preloading:<link rel="prefetch" href="test.css">DNS preresolution:<link rel="dns-prefetch" href="//haitao.nos.netease.com">HTTP preconnection:<link rel="prefetch" href="//www.kaola.com">Prerender the TCP link page for this domain name:<link rel="prerender" href="//m.kaola.com">All resources for the linked document will be preloadedCopy the code

  So what’s the difference between Prefetch and Preload? Specifically, Preload tells the browser to pre-request the resources required for the current page, thereby increasing the request priority for those resources. For example, we can set Prefetch to increase the priority of critical requests that would otherwise have a lower priority. Prefetch tells the browser what resources the user may use in the future on other pages (other than this page), so the browser will preload these resources into the HTTP cache when it is idle. The most common method is DNS-prefetch. For example, when we are browsing page A, if we will jump to page B through the link in page A, and there are some resources in page B that we want to load early, we can Prefetch these resources in page A, so that when the browser is idle, we will load these resources. Therefore, Prefetch can be used for resources that may be used in the current page, and Preload can be used for resources that may be used in some future pages. In terms of load priority, Prefetch increases the request priority; Preload, on the other hand, puts resources at the lowest priority and preloads only when the browser is idle.

  • Pour cold water: SincePrefetchandPreloadSo powerful, we can rest assured to use it? In practice, however, the compatibility of all but DNS-Prefetch is worrisome. In particular, None of these preloading technologies are supported on Safari because of Apple’s stringent security requirements.PreloadAs you can see below, the new version of Chrome has better support, but Safari is dead.
    

    

    dns-prefetchThe support was good.

    

    PrefetchSafari, too, was wiped out.

    

• The second: use LocalStorage. Since the first preloading technology for resource caching support is poor, then you can usually use LocalStorage to cache part of the request data and results, save the time to send HTTP requests, so as to improve the response speed of web pages. Such practices are already widespread on mobile. The following respectively introduces goose, cat, dog page is how to use LS to request caching.

• Wechat: use LS to cache JS files. As shown in the figure below, open a wechat public account article with a browser, open the console, and find that there is no need to load a JS file in the Network? A face meng force!

  

  Cut to LS only in an uproar, all the original JS are hidden here!

  

  Wechat is using this technique to cache the JS resources in the critical path, thus greatly speeding up the page access speed. Of course, the actual implementation, not like the surface looks like that, the first access to js into LS, every time come out to perform so simple, the core is actually need to design a set of cache update mechanism. First of all, we need to set a unique version identifier for the cached JS file through the suffix; Second, each time the back-end needs to transmit a resource configuration file, and the front-end will match the version identifier of the configuration file with the files cached in LS, so as to decide whether to use LS cache or send a request again to update resources. For example, the configuration file in wechat is synchronized to the front end through moon_map, as shown in the figure below:

  

• Tmall: Use LS to cache critical XHR asynchronous requests. Take the home page of Tmall supermarket as an example: as shown in the figure below, it is found that LS caches the data of the round play and 10 classified entries in the first screen.

  

  After formatting the JSON content above, it is found that it contains the attributes of Banner and flowIcons, and the data in it corresponds to the data of the rosette and classification entry respectively. This can greatly improve the rendering time of the first screen.

• Jd: Use LS to cache non-critical requests. Take the PC version of jingdong home page as an example. Jd thinks in reverse and adopts another way to use LS in a strange way. That is to strip out non-critical requests and store them in LS. Specifically, for the first screen of data, it still loads and displays normally. However, the loading and rendering of non-first-screen data will block and preempt resources, thus affecting first-screen page rendering. Therefore, the resources such as HTML/CSS that are not on the first screen are extracted and put into LS. When the page is rolled to the visible area, the data can be obtained from LS and inserted into DOM. This is similar to lazy module loading today. As shown in the figure below, each LS contains the HTML/CSS resources required by a module.

  

PS: A wave of advertising, Kaola.com front-end recruitment ~ interested poke me to send resumes

END

References:

1. From the Chrome browser source code to see how to load resources: https://zhuanlan.zhihu.com/p/30558018.
2. Preload, Prefetch and their priority among the Chrome: https://yq.aliyun.com/articles/226240
3. Talk about browser resource loading optimization: http://qingbob.com/let-us-talk-about-resource-load/
4. Key request: http://www.zcfy.cc/article/the-critical-request-css-tricks-3843.html
5. Others: related MDN documents and Google Web Develop documents.