The Clever Ways Chrome Hides Latency by Anticipating Your Every Need

Ilya Grigorik has written another wonderful article lavishly detailing the extraordinary tactics Chrome employs to hide network latency from users: Chrome Networking: DNS Prefetch & TCP Preconnect. Ilya springs some surpising factoids on us, revealing how the web has slowed and super sized:

• The size of an average page has grown to 1059kB and is now composed of over 80 subresource requests.
• An average DNS lookup takes between 60 and 120ms. This creates a 100-200ms of latency before a request can be sent because of th full round-trip (RTT) to perform the TCP handshake.
• Slow mobile experiences are largely due to the much higher RTT's (200-1000ms) on wireless networks. Reducing the number of outbound connections and the total byte size of your pages is the single best optimization you can make for mobile today. 

Chrome reduces apparent latency using a host of clever anticipatory mechanisms:

• Learns the network topology as you use it via a Predictor object that anticipates user behavior and future resources based on historical browsing data, heuristics, and many other hints from the browser to anticipate the requests.
• Speculatively pre-resolves hostnames (DNS prefetching).
• Speculatively opens connections (TCP preconnect).
• Uses a pool of 8 threads to resolve DNS requests through the OS. A faster resolver is in the works.
• Resolves the first 10 most used URLs on startup.
• Specutively connects to the search engine when it looks like a search is being typed into the omnibar.
• Specutively connects to the most likely host when a URL is typed into the omnibar.
• Uses a speculative PreloadScanner that looks ahead in the document and queues up remote resources before the parser sees them. 
• Learns the most visited resource domains for each hostname and preemptively resolves and preconnects to these resource hosts before the parser even sees them. 
• Actions such as hovering over a link can kick off a prefetch.
• Adding a link element in the head of a document with rel=dns-prefetch hints to the browser to pre-resolve the DNS name of that host. A good and often overlooked reason for doing this is to pre-resolve redirects: if you know that a specific host request will return a 3XX to a different host, then you can also pre-resolve that via dns-prefetch.

These obviously sophisticated tactics may not apply directly to your application, but similar opportunities to hide latency could be hiding in your app. As Ilya says, "Small wins, but it all adds up!"

For more examples of good anticipatory design take a look at: 3 Secrets To Lightning Fast Mobile Design At Instagram.

Comments

[Ilya Grigorik]

Awesome, thanks for the summary! A quick comment on your concluding paragraph: "These obviously sophisticated tactics may not apply directly to your application, but similar opportunities to hide latency could be hiding in your app."

Yup, all of these patterns have been tested with real data and deployment use, hence definitely a good place to learn and adapt from. Having said that, the really cool part about this functionality is that it's not limited to just specific subsections of Chrome. Any web app running in Chrome will automatically inherit all of the above benefits.

Also, I'll add one more tip which I omitted in the post: if you add a link element in the head of your document with rel=dns-prefetch, then that will hint the browser to pre-resolve the DNS name of that host. A good and often overlooked reason for doing this is to pre-resolve redirects: if you know that a specific host request will return a 3XX to a different host, then you can also pre-resolve that via dns-prefetch. Small wins, but it all adds up!

[Jon Lundy]

Interesting to see an article from the future!

[FooBar]

Article from "Monday, June 18, 2012 at 9:15AM"? The datacenter where highscalability is hosted must take 1.21GW and ride at 88 miles an hour ;)

[HighScalability Team]

These things happen when you turn the flux capacitor up to 11. Or perhaps I published an article now set to publish in the futre, but that's not quite as exciting :-)