在过去的几年中，我们对移动网络性能的认知和优化已取得巨大的进步。然而，大多数情况下，移动网络浏览速度仍是缓慢的。来自谷歌分析的数据显示手机网页平均加载时间超过10秒。我们知道，用户通常在网页加载时间超过一秒后就停止等待，这就导致了用户开始流失。所以呈现一个网页的主要内容的时间至少应小于1秒。显然，我们在这方面仍有许多工作要做好。
但在优化移动网络的性能时我们需要注意些什么呢？我们知道移动网络具有高度可变的延迟和带宽特性，并且其延迟性大大高于传统网络。我们也知道对于现代网络而言，网页加载时间长短的主导因素是其往返时间，而非带宽。鉴于此，要提高移动网络浏览速度，我们必须把注意力集中如何在网页的内容显示到设备屏幕之前减少因网络阻塞而产生的往返次数。
是什么影响网页在屏幕上的显示？
首先，让我们了解一下从用户启动页面导航到浏览器将网页显示到屏幕这一系列事件的前后经过。往返可能发生于域名解析，TCP连接，发送请求到服务器和响应回流任何一个过程中。不幸的是，很少开发人员能做到避免额外的往返时间。对重复访问者而言，一个较长的DNS TTL设置能起到帮助，但TCP连接和请求/响应的开销将在每一个新导航到页面时产生(假设没有预备的TCP连接准备让客户端重复使用)
一旦产生初始往返，手机设备就会开始解析HTML的响应。但浏览器这时还不能将网页内容显示到屏幕上。在此之前，浏览器必须先构建渲染树以确定DOM元素将显示在屏幕上的哪个位置。并且在构建渲染树之前，浏览器必须先构建DOM树。DOM树的构建是通过解析HTML和可能执行的JavaScript组合而成。
所以是什么能阻碍HTML的解析、DOM树的构建、渲染树的构建？大多数情况下，解析HTML、构建DOM树、构建渲染树都是非常快的。但是仍存在一些使这些流程在网络上受阻的反模式。
外部的JavaScript是HTML解析过程中最明显的延迟来源。当浏览器在解析HTML时遇到（非异步）外部脚本时，它必须先中断后续HTML的解析，直到脚本下载、解析、执行整个过程结束。对手机设备而言，因此而产生的往返时间带来的代价尤为沉重。如果从不提供HTML服务的主机上加载脚本，这可能会在域名解析和TCP连接时产生额外的往返时间。
此外，样式表也能阻碍渲染树的构建，正如外部的JavaScript会延迟DOM树的构建，外部的样式表也会延迟渲染树的构建。
总之，在网页中过早地加载外部的JavaScript and CSS（例如在<head>文件里）会给性能带来致命性的伤害。这对手机设备来说无疑是代价沉重的，因为较高的往返时间与移动网络相关联。
要快速打开网页，必须确保手机网页所有需渲染在可见区域的内容不超过初始HTML有效载荷，并且没有受到外部JavaScript、CSS的阻碍。理想情况下，所有需渲染在可见区域的内容必须在网络上的首个15kB（这是用gzip压缩后的字节大小，未用gzip压缩前可以稍微大点），因为这是现代Linux内核初始拥塞窗口的大小。这并非意味着简单地内联所有从外部加载的JavaScript和CSS。相反，只需内联渲染可见区域所需的JavaScript和CSS，并且需要异步加载为网页添加额外功能的JavaScript或CSS。例如，假设我们有一个这样的网页，如下：
< html >
< head >
< link rel = " stylesheet " href = " my.css " >
< script src = " my.js " > </ script >
</ head >
< body >
< div class = " main " >
这里是我要显示的内容
</ div >
< div class = " leftnav " >
这里可以是一个左侧导航栏
</ div >
...
</ body >
</ html >
我们需要识别出渲染页面初始内容时所需的my.js和 my.css的部分，将其进行内联，延迟或者异步加载页面所需的JavaScript和CSS的剩余部分。这最终可能看起来像：
< html >
< head >
< style >
.main { ... }
.leftnav { ... }
/* ... 初始渲染时所需的任意样式 ... */
</ style >
< script >
//初始渲染时所需的任意脚本
//理想情况下，初始渲染时不需使用脚本
</ script >
</ head >
< body >
< div class = " main " > 这里是我要显示的内容 </ div >
< div class = " leftnav " > 这里可以是一个左侧导航栏 </ div >
...
<!--
注：延迟加载脚本和样式表可能是在异步同调中最好的方法 如’ requestAnimationFrame ‘，
而不是内嵌在HTML里，因为浏览器呈现较早 的HTML内容到屏幕上后才会调用回调函数。
-->
< link rel = " stylesheet " href = " my_leftover.css " >
< script src = " my_leftover.js " > </ script >
</ body >
</ html >
移动网络的现状
一个简单的移动网页调查显示几乎所有的网页在显示主要内容之前都调用了会引起阻塞的外部JavaScript和/或CSS。谷歌地图，谷歌搜索，雅虎新闻，如http://www.yummly.com/这类的网站，还有Kayak这些网站都不包括在其中。可惜一些网站内联了初始化渲染时所不需要的JavaScript和CSS，这样反而延长了网页的显示时间。
有趣的是，移动网络浏览禁用了JavaScript显示，尽管绝大多数网页加载了会引起阻塞的阻外部JavaScript，事实上没有几个网页需要在初始化渲染时使用这些脚本。延迟或异步加载JavaScript能够使JavaScript远离页面初始化渲染的关键路径，网页也将受益于此。
会引起阻塞的外部JavaScript和 CSS是网络上最常见的延迟来源。但其他一些常见的延迟来源也是手机开发人员所需要知道的。其中一个来源是主要的HTML文件的HTTP重定向。这些重定向将带来额外的往返时延，并且如果重定向导航到不同的主机名（例如从www.example.com到m.example.com），会给域名解析、TCP连接带来更多的时间延迟。另一个延迟来源是服务器后端生成HTML响应所花费的时间。所有花在生成初始HTML响应的时间都会阻碍将页面呈现到屏幕上，因此服务器后端的时间应保持在最低限度以内。
如果我们估计3G网络的往返时间为250毫秒，我们可以计算出用户发起页面导航请求和页面主要内容呈现到屏幕之间的最短时间估计值。假设没有受到外部JavaScript和CSS的阻碍,我们将域名解析，TCP连接和请求/响应产生的往返时间共计为750毫秒，加上后端时间100毫秒。这就给我们带来了850毫秒的等待时间。只要阻碍渲染的JavaScript和CSS被内联，初始HTML有效载荷大小被控制在最小限度以内（例如压缩后小于15kB）,解析和渲染的时间应远远低于100毫秒，加起来共950毫秒，刚好在我们的一秒目标内。
总之，为了快速打开你的手机网页，你应：
保持服务器后端生成HTML的时间在最低限度内（低于100毫秒）
避免主要的HTML文件的HTTP重定向
避免在初始化渲染之前加载外部的JavaScript和CSS
只内联初始化渲染时所需的JavaScript和CSS
延迟或异步加载任何初始化渲染时所不需要的JavaScript和CSS
渲染初始化内容时保持HTML有效载荷压缩后小于15kB
如果你寻找提高移动网页性能的方法，你可以尝试以上给出的优化方法。
3306
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
