DNS Prefetching / Preconnecting
snuggs opened this issue · 10 comments
Summary
In lieu of CDNs is this of any value to us for unpckg.com and or a "Best practice" with our conventions? Do remember this is not just a library but a set of best practice hints for modern web development as well.
At minimum can add to our internal example references to test out.
Prefetching
<link rel=dns-prefetch href=//unpckg.com>Preconnecting
<link rel=preconnect href=//unpckg.com>Support
- Preconnect - http://caniuse.com/#feat=link-rel-preconnect
- DNS Prefetch (far greater support) - http://caniuse.com/#search=dns-prefetch
Related Links
- https://varvy.com/rel/dns-prefetch.html
- W3C Spec for DNS Prefetch - https://w3c.github.io/resource-hints/#dns-prefetch
- W3C Spec for DNS Preconnect - https://w3c.github.io/resource-hints/#preconnect
Please advise.
@brandondees @pachonk @tmornini @mrbernnz
yeah, i haven't had time to experiment with this in practice enough to know exactly what the best practice should be, other than to benchmark both with and without. as i understand it, the primary document should include dns prefetch links as close to the top of the document as possible (without overriding other best practices like charset, etc.) for any 3rd party hosts that should be accessed in order to fully present the page. i'm not sure yet if it should apply to 3rd party hosts used by other pages that are expected to be visited by a user, but i'm guessing the default recommendation for that will be no, even though it might be advantageous for some sites to do. i'd like to see some benchmarks with and without to understand how important this really is for user experience, but i would expect that for worst-case scenarios connectivity-wise, it might be able to save significant time, especially for sites that load resources from multiple external domains.
dns prefetch should be ready to start using where appropriate. preconnect doesn't have the same kind of support yet but might be worth experimenting with as a progressive enhancement. i'm not clear on whether it's desirable to layer both techniques on top of each other for the same domain, whether the html payload weight is worth it, or whether they have conflicting behavior in any way (i.e. does triggering dns prefetch block preconnect from being effective, or vice versa, does page order make a significant difference, or are the browsers doing the smart/right thing and initiating the most advantageous form available in an optimal way?)... need benchmark experiments to know for sure.
@tmornini any idea on conventions with connecting to DNS? Fairly new hooks in the platform. Wondering the benefits.
Just guessing here.
This is likely to move DNS lookup and outbound connection negotiation to page load time (hopefully asynchronous!) to avoid delays during user interaction.
Essentially, no need to make the user wait for DNS+Open Connection when they click a link, all of that can be done in advance.
@tmornini just got feedback from GOOGLE team. You are 100% CORRECT SIR! So basically this gives us no advantage on initial load? Perhaps if we do it early enough in the markup? (think near <title>). Would this be advantageous for CDNS? See following spec reference. Do realize rules are more being made up than a common set of rules. And you know this is an area that i'm weak at. :-)
it explicitly does provide speedup on initial page load for any 3rd party resources that will be needed. if you're using a CDN for static assets or 3rd party content such as iframes, analytics tools, like buttons, memes hosted elsewhere, etc. all those external connections begin only when the part of the page that calls for them has been parsed. if you bump the hint up to the top of with charset and title, the browser can asynchronously begin the DNS lookup for those if needed, which makes the first blocking network round-trip for each of those domains happen as early as possible so that it won't be blocking anymore by the time those resource references are parsed and an actual TCP connection is needed. it seems as if rel=preconnect or rel=prerender will end up replacing this for a lot of use cases but they are not as widely available yet, and they each come with more caveats.
(to avoid confusion, I don't think putting a dns prefetch link directly in front of your snuggsi.es link will make it go any faster under typical circumstances, but if you're using a giphy embed in the footer of the site, letting the browser know it should go ahead and have DNS on hand for giphy.com right up front might shave a little bit of delay from that time to interactive
That makes total sense @brandondees. I think we're just getting an understanding of this bleeding edge thing. Best part is they move fast on specs/implementations so look how far it's gone just this year. Definitely a "it depends" answer worthy of at least a lightening talk in 2018 😎