21

I'm trying out the <link rel="dns-prefetch"> and <link rel="preconnect"> tags and I'm trying to see whether they help for my site. I can't find any online resources about how verify if these hints are working using browser dev tools, extensions, or other software. It seems like you just evaluate whether they may be useful to you based on some criteria and then drop them in and hope for the best.

In my case, I have a single page app that renders the entire contents of the <body> in the browser, so the browser can't really scan the initial HTML to lookahead for domains to resolve so it seemed like this might be useful for me.

webbower
  • 756
  • 1
  • 7
  • 21
  • You need to find a way to test the server a great many times (1000) and statistically calculate the waterfall data with the optimization and without. this so be repeat for each browser type (FF, chrome, IE, safari...). I do not know of such a tool.. – vsync Dec 28 '16 at 17:22
  • Slightly related: https://stackoverflow.com/questions/26034706/ – jakub.g Jun 19 '18 at 13:35

3 Answers3

10

In order to just make sure that the features are working in a given browser (very synthetic test), you can do as follows

Test 1: test dns-prefetch (just DNS) with Chrome

  • serve the following HTML on localhost

    <!doctype html><html><head>
    <link rel="dns-prefetch" href="//ajax.googleapis.com">
</head><body></html>

  • go to chrome://net-internals/#dns and clear host cache

  • open new tab in Chrome on http://localhost
  • refresh chrome://net-internals/#dns and observe it to have the DNS entry - this confirms that DNS resolution has been done

Test 2: test preconnect (DNS+TLS+TCP) with Chrome and Fiddler (Windows-only)

  • serve the following HTML on localhost

    <!doctype html><html><head>
    <link rel="preconnect" href="https://ajax.googleapis.com">
</head><body></html>

  • go to chrome://net-internals/#dns and clear host cache

  • start Fiddler and make it listen to the traffic
  • open new tab in Chrome on http://localhost
  • observe Fiddler to have a "Tunnel to ajax.googleapis.com:443" session - this confirms that DNS resolution and TLS handshake were done (and you can probably trust the browser that it established a TCP connection too)
Rice_Crisp
  • 1,242
  • 1
  • 16
  • 33
jakub.g
  • 38,512
  • 12
  • 92
  • 130
8

Run your page through webpagetest.org. Requests to the domains you specified in your dns-prefetch or preconnect tags should begin sooner because the initial connection will have been established.

This will show in the waterfall graph, for those requests - at the left of the bar the DNS, connect and SSL (if applicable) segments will detach from the response and move to the left in the waterfall, to reflect the fact that they occurred earlier.

monkeyboy
  • 532
  • 4
  • 8
3

To test the impact on DNS time in a very granular and customizable way, here's another approach: HAR file parsing.

Load the site with the network panel open, then download the HAR file

Read that HAR file in as JSON (either in Node with readFile, or browser with FileReader), and you'll end up with an object like this:

const har = {
  log: {
    version: {},
    creator: {},
    page: {},
    entries: {}, // <-- You want these
  }
}

Then you can look at (and do math with) har.log.entries[idx].timing.dns, so you can answer things like:

How much total time was spent waiting for DNS fetching?

const ms = har.log.entries.map(e => e.timing.dns).reduce(sum); // NOTE: should rm all the -1s
console.log('Total DNS Time: ' + ms);

// Total DNS Time: 242 ms

Which requests were waiting for DNS at all?

const display = har.log.entries
  .filter(e => dnsTime(e) > 0)
  .map(e => ({
      method: e.request.method,
      url: e.request.url,
      dns: dnsTime(e),
    })
  );

console.table(display);
// Prints a nice table with things like: [GET foo.com 72ms]
SimplGy
  • 20,079
  • 15
  • 107
  • 144