Prefetch & Preconnect-DNS priority

By JUSTIN AVERY

If you want the browser to perform DNS resolution before you access a domain name, you can use both preconnect and prefetch- DNS, which will save time on critical render paths. This paper mainly analyzes the difference between the two, the conclusion can not be summarized in a sentence.

concept

For example, when we visit responsivedesign. Is/articles/pr… What happens at the beginning of this page is that the browser needs to know where responsiveDesign. is is — what’s known as the DNS handshake. If you look at the waterfall diagram of the network, you’ll see that the first part of the request is aqua green, which represents DNS resolution.

The purpose of preconnect and prefetch- DNS is to allow DNS resolution to take place as quickly as possible, before a request is actually sent to the domain corresponding to that DNS. This saves time when you want to request resources (preconnect does a little more than prefetch- DNS, but after DNS resolution)

How much time did you save? The time for DNS resolution in the waterfall diagram example above is

  • Ms – 150 / / cdnjs.cloudflare.com
  • Ms – 185 / / production – assets. Codepen. IO
  • Ms – 167 / / s3-us-west-2.amazonaws.com

Each is over a hundred milliseconds, but when you add them up you get 502ms. Subtract them from the load time of the critical render path and you get half a second of load speed.

Dns-prefetch is different from preconnect

The difference between these two is — DNS-Prefetch will only do DNS resolution, preconnect will do DNS resolution, TLS negotiation and TCP handshake, which means you can avoid two additional RTT (rount-trip Time) when downloading resources.

However, when I tested it in Web Page Test it seemed to only avoid DNS resolution, which I couldn’t explain properly. Probably because the browser supports DNS-Prefetch much better than PreConnect, I suspect that the Version of Chrome I used for testing is not fully supported, but it still avoids DNS resolution.

Question – Does order matter?

The reason for writing this article is that when I was browsing the Website of Victoria and Albert Museum, I found that the website used the following code fragment to complete DNS resolution in advance to save the time for future requests:

<link rel="dns-prefetch" href="//vanda-production-assets.s3.amazonaws.com" />

This is written in the tag, but the site also uses the

  1. Does the browser start downloading resources as soon as it sees an image URL, so DNS resolution starts before the DNS-prefetch tag.
  2. Will the browser parse the entire HTML document before requesting resources?

The priority of the test order

To Test, I wrote a series of Code pens to Test when DNS resolution would occur under the following five scenarios, each of which was tested using Web Page tests on Chrome and Fast 3G networks. I chose this network condition because the difference between them is magnified on this mobile network condition (I haven’t used 2G yet).

Each code pen has a style tag in the head, and background-image is set. The difference between them is the order and type of DNS pre-resolution, as follows:

  1. dns-prefetch after styles
  2. dns-prefetch before styles
  3. preconnect after styles
  4. preconnect before styles
  5. No preconnect prefetch

(Translator’s note: I don’t know why I can’t see the code page in the code pen above… But you can still see the HTML structure by examining the elements…)

There is no preconnect prefetch

Without any resource hints we can see how a page is typically requested, noting that DNS resolution is part of the critical path:

<style>
body {background-image:url('https://s3-us-west-2.amazonaws.com/s.cdpn.io/7635/Ayers-Rock-Australia.jpg')}
</style>

Critical load path when no prefetch/preconnect of the DNS is included in the

Dns-prefetch comes after styles

<style>
body {background-image:url('https://s3-us-west-2.amazonaws.com/s.cdpn.io/7635/Ayers-Rock-Australia.jpg')}
</style>
<link href="https://s3-us-west-2.amazonaws.com" rel="dns-prefetch">

As you can see from the waterfall diagram, although background-image is declared before the link tag of dnS-prefetch, DNS parsing starts immediately after the entire HTML document is parsed and is performed in parallel with the DNS parsing of other resources requested at the beginning of the page. Normalise. CSS from //cdnjs.cloudflare.com.

Critical load path when preconnect is included in the after the <style> tag

Dns-prefetch precedes styles

As you can imagine, if we want the handshake to happen when it wants to happen, declaring DNS pre-resolution before or after the image is the same.

<link href="https://s3-us-west-2.amazonaws.com" rel="dns-prefetch">
<style>
body {background-image:url('https://s3-us-west-2.amazonaws.com/s.cdpn.io/7635/Ayers-Rock-Australia.jpg')}
</style>

Critical load path when dns-prefetch is included in the before the <style> tag

Preconnect comes after styles

In this test, I wanted to see how much more time preconnect could save by executing all three RTTS ahead of time than DNS-Prefetch. Unfortunately, there was no difference, so I’ll have to look at that later.

<style>
body {background-image:url('https://s3-us-west-2.amazonaws.com/s.cdpn.io/7635/Ayers-Rock-Australia.jpg')}
</style>
<link href="https://s3-us-west-2.amazonaws.com" rel="preconnect" crossorigin>

Critical load path when dns-prefetch is included in the after the <style> tag

Preconnect comes before styles

The result of this test is that the DNS preresolution occurs immediately, but also does not see TCP/TLS handshake..

<link href="https://s3-us-west-2.amazonaws.com" rel="preconnect" crossorigin>
<style>
body {background-image:url('https://s3-us-west-2.amazonaws.com/s.cdpn.io/7635/Ayers-Rock-Australia.jpg')}
</style>

Critical load path when preconnect is included in the before the <style> tag

conclusion

As you can see above, no matter what you do to prevent the link tag in head, as long as it’s there it will do the DNS pre-resolution and therefore save you time browsing the web.

It is worth adding pre-resolution to all external domain names in your site, especially image CDN, font library (such as Google Fonts) or external JS files that you may use.

.

Chrome Canary + 3G preconnect before Styles preconnect before styles Chrome Canary + 3G Expect more browser support for PreConnect!

Test results: Web Page Performance Test fors. Codepen. IO/justincavery/debug/jBVdxE

The translator note again

In fact, this article mainly talks about two points:

  1. Preconnect provides more TCP and TLS preresolution than dnS-prefetch.
  2. DOM tree construction cannot be completed until the entire HTML document is downloaded, and node information can be read until DOM Tree construction is completed.