不少人都知道现代浏览器都支持 DNS 的预解析,学名:DNS Prefetching。用法也很简单,就是在html代码里加入这样的 link 标签css
<link rel="dns-prefetch" href="//delai.me">
咱们以前的用法是在 Head 为2个 静态资源服务器的域名 和 日志图片的域名 建了3条 dns-prefetch link。html
<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 的官方文档 看到这么一句:web
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
上面这段文字包含两个信息:segmentfault
chrome 会自动把当前页面的全部带href的link的dns都prefetch一遍浏览器
须要手动添加link标签的场景是:你预计用户在后面的访问中须要用到当前页面的全部连接都不包含的域名服务器
看来,咱们原先的姿式是不对的~网络
我写了一个测试页面,代码是这样的:dom
<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/转载请注明出处