BETWAY登录功用优化 – 资源预加载

　　当说到BETWAY登录功用优化时，咱们首先会联想到文件的兼并、紧缩，文件缓存和敞开服务器端的 gzip 紧缩等，这使得页面加载更快，用户能够赶快运用咱们的 Web 运用来到达他们的方针。

　　资源预加载是另一个功用优化技能，咱们能够运用该技能来预先奉告阅览器某些资源或许在将来会被运用到。

　　引证 Patrick Hamann 的解说：

　　预加载是阅览器对将来或许被运用资源的一种暗示，一些资源能够在当时页面运用到，一些或许在将来的某些页面中被运用。作为开发人员，咱们比阅览器愈加了解咱们的运用，所以咱们能够对咱们的中心资源运用该技能。

　　这种做法从前被称为 prebrowsing，但这并不是一项单一的技能，能够细分为几个不同的技能：DNS-prefetch、subresource 和标准的 prefetch、preconnect、prerender。

　　DNS 预解析 DNS-Prefetch

　　经过 DNS 预解析来奉告阅览器未来咱们或许从某个特定的 URL 获取资源，当阅览器实在运用到该域中的某个资源时就能够赶快地完结 DNS 解析。例如，咱们将来或许从 example.com 获取图片或音频资源，那么能够在文档顶部的标签中参加以下内容：

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

　　当咱们从该 URL 恳求一个资源时，就不再需求等候 DNS 的解析进程。该技能对运用第三方资源特别有用。

　　在 Harry Roberts 的文章中说到：

　　经过简略的一行代码就能够奉告那些兼容的阅览器进行 DNS 预解析，这意味着当阅览器实在恳求该域中的某个资源时，DNS 的解析就现已完结了。

　　这似乎是一个十分细小的功用优化，显得也并非那么重要，但现实并非如此 – Chrome 一直都做了相似的优化。当在阅览器的地址栏中输入 URL 的一小段时，Chrome 就主动完结了 DNS 预解析(乃至页面预烘托)，然后为每个恳求节省了至关重要的时刻。

　　预衔接 Preconnect

　　与 DNS 预解析相似，preconnect 不只完结 DNS 预解析，一起还将进行 TCP 握手和树立传输层协议。能够这样运用：

<link rel="preconnect" href="https://www.nucmc.com/">

　　在 Ilya Grigorik 的文章中有更具体的介绍：

　　现代阅览器都试着猜测网站将来需求哪些衔接，然后预先树立 socket 衔接，然后消除贵重的 DNS 查找、TCP 握手和 TLS 往复开支。可是，阅览器还不行聪明，并不能精确猜测每个网站的一切预链接方针。好在，在 Firefox 39 和 Chrome 46 中咱们能够运用 preconnect 奉告阅览器咱们需求进行哪些预衔接。

　　预获取 Prefetching

　　假如咱们确认某个资源将来必定会被运用到，咱们能够让阅览器预先恳求该资源并放入阅览器缓存中。例如，一个图片和脚本或任何能够被阅览器缓存的资源：

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

　　与 DNS 预解析不同，预获取实在恳求并下载了资源，并储存在缓存中。但预获取还依赖于一些条件，某些预获取或许会被阅览器疏忽，例如从一个十分缓慢的网络中获取一个巨大的字体文件。而且，Firefox 只会在阅览器搁置时进行资源预获取。

　　在 Bram Stein 的帖子中说到，这对 webfonts 功用提高十分显着。现在，字体文件有必要比及 DOM 和 CSS 构建完结之后才开端下载，运用预获取就能够轻松绕过该瓶颈。

　　留意：要测验资源的预获取有点困难，但在 Chrome 和 Firefox 的网络面板中都有资源预获取的记载。还需求记住，预获取的资源没有同源战略的约束。

　　Subresources

　　这是另一个预获取方法，这种方法指定的预获取资源具有最高的优先级，在一切 prefetch项之前进行：

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

　　依据 Chrome 文档：

　　rel=prefetch 为将来的页面供给了一种低优先级的资源预加载方法，而 rel=subresource 为当时页面供给了一种高优先级的资源预加载。

　　所以，假如资源是当时页面有必要的，或许资源需求赶快可用，那么最好运用 subresource 而不是 prefetch。

　　预烘托 Prerender

　　这是一个核武器，由于 prerender 能够预先加载文档的一切资源：

<link rel="prerender" href="https://www.nucmc.com/">

　　Steve Souders 在他的一篇文章中写到：

　　这相似于在一个躲藏的 tab 页中打开了某个链接 – 将下载一切资源、创立 DOM 结构、完结页面布局、运用 CSS 款式和履行 JavaScript 脚本等。当用户实在拜访该链接时，躲藏的页面就切换为可见，使页面看起来便是瞬间加载完结相同。Google 查找在其即时查找页面中现已运用该技能多年了，微软也声称将在 IE11 中支撑该特性。

　　需求留意的是不要乱用该特性，当你知道用户必定会点击某个链接时才能够进行预烘托，不然阅览器将无条件地下载一切预烘托需求的资源。

　　更多相关评论：

　　一切预加载技能都存在一个潜在的危险：对资源猜测过错，而预加载的开支(抢占 CPU 资源，耗费电池，糟蹋带宽等)是昂扬的，所以有必要慎重行事。尽管很难确认用户下一步将拜访哪些资源，但高可信的场景的确存在：

　　假如用户完结一个带有显着成果的查找，那么成果页面很或许会被加载

　　假如用户进入到登陆页面，那么登陆成功的页面很或许会被加载

　　假如用户阅览一个多页的文章或拜访一个分页的成果集，那么下一页很或许会被加载

　　最终，运用 Page Visibility API 能够避免页面实在可见前被履行。

　　Preload

　　preload 是一个新标准，与 prefetch 不同(或许被疏忽)的是，阅览器必定会预加载该资源：