发现
很多人都知道现代浏览器都支持 DNS 的预解析，学名：DNS Prefetching。用法也很简单，就是在html代码里加入这样的 link 标签
<link rel="dns-prefetch" href="//delai.me">我们之前的用法是在 Head 为2个 静态资源服务器的域名 和 日志图片的域名 建了3条 dns-prefetch link。
<link rel="dns-prefetch" href="//tj.koudaitong.com/" />
<link rel="dns-prefetch" href="//imgqn.koudaitong.com/" />
<link rel="dns-prefetch" href="//kdt-static.qiniudn.com/" />我最近给移动web 关键静态资源做 File Prefetching，顺手看了下Chromium 和 Firefox 关于 DNS Prefetching 的官方文档 看到这么一句：
Manual Prefetch
Chromium uses the "href" attribute of hyperlinks to find host names to prefetch. However, some of those hyperlinks may be redirects, for example if the site is trying to count how many times the link is clicked. In those situations, the "true" targeted domain is not necessarily discernible by examining the content of a web page, and so Chromium not able to prefetch the final targeted domain.
上面这段文字包含两个信息：
chrome 会自动把当前页面的所有带href的link的dns都prefetch一遍
需要手动添加link标签的场景是：你预计用户在后面的访问中需要用到当前页面的所有链接都不包含的域名
看来，我们原先的姿势是不对的~
验证
我写了一个测试页面，代码是这样的：
<html>
<head></head>
<body>
<a href="http://a.youzan.com">a</a>
<a href="http://b.youzan.com">b</a>
<a href="http://c.youzan.com">c</a>
<a href="http://d.youzan.com">d</a>
</body>
</html>在chrome里打开他，然后访问 chrome://histograms/DNS.PrefetchQueue ，看到如下统计结果
当然，上图并不能说明什么问题，只能看出：从启动chrome到访问刚刚这个测试页面，一共有88次dns prefetching，其中67次直接命中耗时0ms，有4次耗时5ms。不过，如果把测试页面改成下面这个样子再跑一次就有点意思了：
<html>
<head></head>
<body>
<a href="http://a.youzan.com">a</a>
<a href="http://b.youzan.com">b</a>
<a href="http://c.youzan.com">c</a>
<a href="http://d.youzan.com">d</a>
<a href="http://a1.youzan.com">a1</a>
<a href="http://b1.youzan.com">b1</a>
<a href="http://c1.youzan.com">c1</a>
<a href="http://d1.youzan.com">d1</a>
<a href="http://a2.youzan.com">a2</a>
<a href="http://b2.youzan.com">b2</a>
<a href="http://c2.youzan.com">c2</a>
<a href="http://d2.youzan.com">d2</a>
<a href="http://a3.youzan.com">a3</a>
<a href="http://b3.youzan.com">b3</a>
<a href="http://c3.youzan.com">c3</a>
<a href="http://d3.youzan.com">d3</a>
<a href="http://a4.youzan.com">a4</a>
<a href="http://b4.youzan.com">b4</a>
<a href="http://c4.youzan.com">c4</a>
<a href="http://d4.youzan.com">d4</a>
</body>
</html>统计结果变成了：
可以看出：因为页面里有20个a标签带href属性，chrome做了20次dns prefetching，其中耗时为0的次数比之前加了4，那是因为头4个域名在上一次跑测试页面的时候已经被prefetch过了本地已经有记录，直接命中。其余的16个dns prefetching 耗时基本上离散分布不甚相同。
结论
实际情况如文档所说，我的理解也是对，我们之前的使用姿势确实有点问题。
正确的使用姿势是
1.对静态资源域名做手动dns prefetching。
2.对js里会发起的跳转、请求做手动dns prefetching。
3.不用对超链接做手动dns prefetching，因为chrome会自动做dns prefetching。
4.对重定向跳转的新域名做手动dns prefetching，比如：页面上有个A域名的链接，但访问A会重定向到B域名的链接，这么在当前页对B域名做手动dns prefetching是有意义的。
其他
1.假设页面Head里面有个css链接, 在当前页的Head里加上对应的手动dns prefetching的link标签，实际上并没有好处。
2.普遍来说合理的dns prefetching能对页面性能带来50ms ~ 300ms的提升，有人做了这方面的统计。
3.如chromium的官方文档所说，dns prefetching的网络消耗是极低极低的：
Each request typically involves sending a single UDP packet that is under 100 bytes out, and getting back a response that is around 100 bytes. This minimal impact on network usage is compensated by a significant improvement in user experience.
4.如chromium的官方文档所说，chrome使用8个线程专门做dns prefetching 而且chrome本身不做dns记录的cache，是直接从操作系统读dns —— 也就是说，直接修改系统的dns记录或者host是可以直接影响chrome的。
5.手动 dns prefetching 的代码实际上还是会增加html的代码量的，特别是域名多的情况下。
所以，最优的方案应该是：通过js初始化一个iframe异步加载一个页面，而这个页面里包含本站所有的需要手动dns prefetching的域名。事实上，我们已经这么做了，具体可以看这篇文章：《预加载系列二：让File Prefetching丝丝润滑无痛无痒》。
本文首发于我的
SegmentFault专栏：http://segmentfault.com/a/1190000004336839
个人技术博客：http://delai.me/code/file-frefetching/
转载请注明出处
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。