dns-prefetch's future

[yoavweiss]

During an Intent-to-ship discussion for Link header support for dns-prefetch, certain use-cases were raised where authors may be interested in dns queries, but may not be interested in full preconnecting:

• Author is not aware if the connection will be used in anonymous CORS mode or not
• Author is not sure the connection will be used, and full-preconnect (with TLS) may incur too large of a bandwidth hit.
• Author is not sure the connection will be used, and full-preconnect (with TLS) may increase server load.

Do these cases justify the case for dns-prefetch to stay as a separate hint?
I think <link rel=preconnect pr> can address the uncertainty of the latter 2 cases, and delegate handling them to the browser, but I'm interested in gathering feedback on this.

[yoavweiss]

We may also want to discuss possible deprecation/removal path for dns-prefetch and if we don't see a feasible one, it may make sense to spec it, even if we don't see particular value. I'll add usecounters for the various existing hints to see how widespread their usage is, but it may take a couple of months until we get proper data out of that.
@toddreifsteck - do you happen to have such (shareable) data handy?

[foolip]

Is there an existing spec for dns-prefetch, or should it be part of the Resource Hints spec perhaps?

[yoavweiss]

There's no existing spec. If it should in fact be specced (which is the question I'm raising in this issue :D), it makes sense for it to be as part of Resource Hints.

[foolip]

Thanks, I've tried to clear up my confusion on blink-dev too.

[toddreifsteck]

I don't have this data handy and am unlikely to be able to get it quickly enough to know actual real world usage in a short amount of time. Have you queried http archive for the data?

[foolip]

I searched in the 20150101 httparchive data, and 74014 out of 10138268 resources (not pages) have a case-insensitive match for "dns-prefetch". That's ~0.7%.

If having better data on this would help move the discussion along we could measure usage in Blink. Since that's per page view my hunch is that the number would be higher than 0.7%, and it would be surprising if it's in the 0.01% range where we usually talk about removing things.

[yoavweiss]

Thanks for looking into the data! :) That certainly looks like something we can't talk about deprecating and removing.

Having a better performing alternative may move the niddle somewhat, but as is, it looks like we may need to add it to the spec.

[igrigorik]

My previous argument for "upgrading" dns-prefetch to preconnect was based on premise that there are no instances where you want to dns-prefetch and not preconnect. However, as Ryan and Matt pointed out (blink-dev thread), there are cases where you might not know the type of socket (crossorigin or not) ahead of time, or may not want to trigger the full handshake.

As such, I think dns-prefetch is a valid stand-alone optimization, and I don't think we should deprecate it. Also, I don't think pr attribute is the right solution here, as it doesn't address the crossorigin case.

If there are no objections to above, I'm OK with adding dns-prefetch to Resource Hints.

/cc @toddreifsteck @mcmanus @plehegar

[toddreifsteck]

Agreed that dns-prefetch should be added to the spec.