网站性能优化——DNS预热与合并HTTP请求

DNS预热

一次DNS解析耗时 20-120ms, 当网页中使用的域名较多时，DNS预热节省的时间仍是很是可观的

先看效果

预热的目的：

1. 减小请求次数
2. 提早对DNS预获取

预热的方式

1. 爬虫
2. APP
3. 网页meta

<meta http-equiv="x-dns-prefetch-control" content="on" />
    <link rel="dns-prefetch" href="//webresource.english.c-ctrip.com" />
    <link rel="dns-prefetch" href="//webresource.c-ctrip.com" />
    <link rel="dns-prefetch" href="//s.c-ctrip.com" />
    <link rel="dns-prefetch" href="//pic.english.c-ctrip.com" />
    <link rel="dns-prefetch" href="//m.ctrip.com" />

另外，对于国际化站点尤为须要这么作，举个例子，在美国访问中国的网站，DNS解析会回源到中国，耗时一般在 400ms至 800ms，甚至更长，若是提早预热，那么能够节省这些时间。

合并HTTP请求

这里的合并主要针对当前页面上访问的资源文件，好比css,js,图片等。

为甚么要合并请求？

有人会很奇怪，现代浏览器均可以并发请求资源了，为何还要这么作？我只能说你还too young too simple了。浏览器虽然能够并发，可是PC接入互联网的带宽是有限的，浏览器所能用的TCP连接更是有限的，我来看一个网页请求的实例：

看到了吧，一个2KB的资源加载须要将近0.5s，而99%时间是等待, OMG! 因此还挣扎什么，老老实实的用webpack压在一块儿吧。

注意chrome在http和https下相同域名能够并发的请求数不一样：http = 6，https > 13，这里并发是有至关的水分，从上图中能够看出，连接虽然创建了，但并没什么卵用，依然要等待以前的资源下载下来才开始生效，至于浏览器为啥要这般？（谁知道能够留言告知，万分感谢！）

更多参考

• 浏览器请求静态资源的并发数