部分转载自 前端性能优化-资源预加载

使用<link>rel="prefetch"可以进行资源的预加载.

这种预加载是浏览器实现的,它提前加载资源缓存在浏览器中,在下次请求该资源时就会从缓存加载资源.

使用<link>onload事件可以监听资源加载完成.

dns-prefetch

DNS预解析。

它可以提前进行域名的DNS解析

通过简单的一行代码就可以告知那些兼容的浏览器进行 DNS 预解析,这意味着当浏览器真正请求该域中的某个资源时,DNS 的解析就已经完成了。

<link rel="dns-prefetch" href="//example.com">

它看起来是一个非常微小的优化,但并非如此。 Chrome一直有类似的优化 ,当在地址栏中输入一小段URL时,Chrome就自动完成了DNS解析

preconnect

预连接。

与dns-prefetch相比,不仅完成DNS预解析,还进行TCP握手和建立传输层协议。

现代浏览器都试着预测网站将来需要哪些连接,然后预先建立 socket 连接,从而消除昂贵的 DNS 查找、TCP 握手和 TLS 往返开销。然而,浏览器还不够聪明,并不能准确预测每个网站的所有预链接目标。好在,在 Firefox 39 和 Chrome 46 中我们可以使用 preconnect 告诉浏览器我们需要进行哪些预连接。

<link rel="preconnect" href="http://example.com">

prefetch

预获取。

它真正请求并下载某个资源并储存在缓存中。用于预加载将来一定会用到的资源。

不同浏览器的实现,某些特别大的预获取资源在慢速网络中可能会被忽略,有的浏览器只会在空闲时进行预获取。

在调试预获取时,chrome和firefox在网络面板中有预获取记录。

预获取没有同源限制。

预获取对webfonts的性能提升非常明显。因为字体文件要等到DOM和CSS构建完成后才开始下载,使用预获取可以突破这个瓶颈。

<link rel="prefetch" href="image.png">

subresource

优先级更高的预获取。

当资源是当前页面必须的,或者资源要尽快可用,那么最好使用subresource而不是prefetch。

rel=prefetch 为将来的页面提供了一种低优先级的资源预加载方式,而 rel=subresource 为当前页面提供了一种高优先级的资源预加载。

<link rel="subresource" href="styles.css">

preload

与 prefetch 不同(可能被忽略)的是,浏览器一定会预加载该资源

<link rel="preload" href="image.png">

它还未被所有浏览器兼容

prerender

预渲染。

它将预先加载文档中的所有资源。

这类似于在一个隐藏的 tab 页中打开了某个链接 – 将下载所有资源、创建 DOM 结构、完成页面布局、应用 CSS 样式和执行 JavaScript 脚本等。当用户真正访问该链接时,隐藏的页面就切换为可见,使页面看起来就是瞬间加载完成一样。Google 搜索在其即时搜索页面中已经应用该技术多年了,微软也宣称将在 IE11 中支持该特性。

不要滥用该特性,只有当知道用户一定会点击某个链接时才可以进行预渲染,否则浏览器将下载所有资源

<link rel="prerender" href="http://example.com">

更多讨论

所有预加载技术都存在一个潜在的风险:对资源预测错误,而预加载的开销(抢占 CPU 资源,消耗电池,浪费带宽等)是高昂的,所以必须谨慎行事。虽然很难确定用户下一步将访问哪些资源,但高可信的场景确实存在:

如果用户完成一个带有明显结果的搜索,那么结果页面很可能会被加载

如果用户进入到登陆页面,那么登陆成功的页面很可能会被加载

如果用户阅读一个多页的文章或访问一个分页的结果集,那么下一页很可能会被加载

分类: htmljavascript

发表评论

电子邮件地址不会被公开。 必填项已用*标注