Front-end performance optimization-resource preload

Reprint: Https://css-tricks.com/prefetching-preloading-prebrowsing When it comes to front-end performance optimizations, we first associate file merging, compression, file caching, and unlocking server-side gzip compression, This makes the page load faster and users can use our Web app as soon as possible to reach their goals.

Resource preloading is another performance optimization technique that we can use to inform browsers beforehand that certain resources may be used in the future.

Citing Patrick Hamann's explanation:

Preloading is a hint that a browser might use resources in the future, and some resources can be used on the current page, some of which may be used in some future pages. As developers, we know more about our applications than browsers, so we can use that technology with our core resources.

This practice was once called prebrowsing, but this is not a single technology that can be subdivided into several different technologies: DNS-prefetch , subresource and Standard prefetch , preconnect prerender .

DNS Pre-parsing Dns-prefetch

DNS pre-parsing tells browsers that we might get resources from a particular URL in the future, and that DNS resolution can be done as quickly as possible when the browser is actually using a resource in that domain. For example, we might example.com get a picture or audio resource in the future, so we can add the following to the label at the top of the document :

1	<link rel= "Dns-prefetch" href= "//example.com" >

When we request a resource from the URL, It is no longer necessary to wait for the DNS parsing process . This technique is particularly useful for using third-party resources.

In Harry Roberts's article, he mentions:

A simple line of code tells those compatible browsers to pre-parse DNS, which means that when a browser actually requests a resource in that domain, DNS parsing is done.

this seems to be a very small performance optimization, and it doesn't seem so important, but it's not true – Chrome has been doing similar optimizations all the time . when you enter a small segment of the URL in the address bar of the browser, Chrome automatically completes DNS pre-parsing (and even page pre-rendering), saving critical time for each request.

Pre-connected Preconnect

Similar to DNS pre-parsing, it preconnect not only completes DNS pre-parsing, but also makes TCP handshake and Transport layer protocol. This can be used:

1	<link rel= "Preconnect" href= "http://example.com" >

In Ilya Grigorik's article, there is a more detailed description:

modern browsers try to predict which connections the site will need in the future, and then set up a socket connection beforehand. This eliminates costly DNS lookups, TCP handshake, and TLS round-trip overhead . However, the browser is not smart enough to accurately predict all the pre-linked targets for each site. Fortunately, in Firefox 39 and Chrome 46 We can use to preconnect tell the browser what we need to do to pre-connect.

Pre-fetch prefetching

If we determine that a resource will be used in the future, we can ask the browser to pre-request the resource and put it in the browser cache. For example, a picture and script or any resource that can be cached by the browser:

1	<link rel= "prefetch" href= "Image.png" >

Unlike DNS pre-parsing, pre-fetch really requests and downloads the resources and stores them in the cache . But prefetching also relies on conditions where some prefetching may be ignored by the browser, such as fetching a large font file from a very slow network. Also, Firefox will only pre-fetch resources when the browser is idle.

In Bram Stein's post, it's obvious that webfonts performance is improving. Currently, font files must wait until the DOM and CSS build is complete before downloading, and using pre-fetching can easily bypass the bottleneck.

Note: It's a bit difficult to test the pre-fetching of resources, but there are pre-fetched records in the Web panel of Chrome and Firefox. It is also necessary to remember that pre-acquired resources do not have the same origin policy restrictions.

Subresources

This is another pre-fetch method, which specifies that the prefetch resource has the highest priority, prefetch before all items:

1	<link rel= "Subresource" href= "Styles.css" >

According to the Chrome document:

rel=prefetchProvides a low-priority resource preloading method for future pages, and provides a high- rel=subresource priority resource preload for the current page.

Therefore, if the resource is required for the current page, or if the resource needs to be available as soon as possible, then it is best to use subresource instead prefetch .

Pre-rendered Prerender

This is a nuclear weapon because prerender all the resources of the document can be loaded in advance:

1	<link rel= "PreRender" href= "http://example.com" >

In one of his articles, Steve Souders wrote:

This is similar to opening a link in a hidden tab page – All resources are downloaded, the DOM structure is created, the page layout is completed, CSS styles are applied, and JavaScript scripts are executed. When the user actually accesses the link, the hidden page is switched to visible, making the page appear to be loaded instantaneously. Google search has been applying the technology to its Instant Search page for years, and Microsoft claims it will support the feature in IE11.

It is important to note that this feature should not be abused when you know that the user is sure to click on a link to pre-render, otherwise the browser will unconditionally download all the resources required for pre-rendering.

More related discussions:

there is a potential risk to all preloaded technologies: forecast errors on resources , while preload overhead (seizing CPU resources, consuming batteries, wasting bandwidth, etc.) is expensive, so be cautious. Although it is difficult to determine which resources the user will access next, a high-trust scenario does exist:

• If a user completes a search with obvious results, the resulting page is likely to be loaded
• If the user enters the landing page, the successful landing page is likely to be loaded
• If a user reads a multi-page article or accesses a paginated result set, the next page is likely to be loaded

Finally, use the page Visibility API to prevent the page from being executed until it is actually visible.

Preload

preloadis a new specification, and prefetch unlike (which may be ignored), the browser is bound to preload the resource:

1	<link rel= "preload" href= "image.png";?

Although the specification is not yet compatible with all browsers, the idea behind it is still very interesting.

Summarize

Predicting which resources the user will access next is difficult and requires a lot of testing, but the performance gains are obvious. If we are willing to try these pre-acquisition technologies, it will definitely improve the user experience.

Deep reading

• Slides from a talk by Ilya Grigorik called Preconnect, PreRender, prefetch
• MDN Link prefetching FAQ
• Preload spec
• Harry Roberts on DNS prefetching
• HTML5 prefetch
• Preload hints for webfonts

Original: prefetching, preloading, prebrowsing

Front-end performance optimization-resource preload