Google Developers：移动Web优化指南
（原标题：用PageSpeed进行移动页面性能分析）
注：由于这篇文章单独拿出来看与PageSpeed几乎无关，故改为更合适的题目
PageSpeed Insights可以用于分析一个页面是否遵循了我们的建议——“在移动网络下一秒之内渲染完毕”。研究已经显示，超过一秒的渲染时间会打断用户的思绪 流，造成糟糕的用户体验。我们的目标是，保持用户停留在页面上，并且提供最佳的体验，不管用户使用什么设备，或是在何种网络下浏览页面。
满足一秒渲染完毕的标准是很难的。但是幸运的是，我们没有必要让整个页面都满足这个条件，换句话说，
我们要首屏（above the fold，ATF）满足一秒渲染的条件，这样可以让用户尽可能快的与页面进行交互。然后，当用户在阅读第一页的内容时，剩下的页面可在后台逐渐的加载。
适应高延时的移动网络
在移动设备上满足“一秒首屏渲染标准”（ATF）相对于在其他设备上是一个独特的挑战。用户可能会在2G、3G或4G的不同网络下访问你的网站。与有线网络相比，无线网络延迟可能会非常高，并且消耗掉1秒（1000ms）渲染首屏时间中的相当一部分：
- 3G网络会有 200-300ms 的延迟
- 4G网络会有 50-100ms 的延迟
目前3G网络在世界范围内占有统治性地位，虽然4G网络正在全世界部署，但是你仍然应该考虑到大部分的用户会在3G网络下浏览你的页面。所以，我们不得不假设每个请求平均平均会花费200ms。
考虑到这个因素，让我们反向的思考一下。如果我们看看一个浏览器与服务器之间通信的典型序列（sequence），我们会发现1000ms中的 600ms已经被基本的网络开销占用了：DNS服务器查找域名（例如google.com）对应的IP地址的时间、用于完成TCP握手的网络延迟、还有最 后发送一整条HTTP请求的网络延迟。我们只剩下了400ms！
实现半秒的渲染体验
在减去网络延迟之后，我们的预算时间只剩下400ms，然而我们仍然有太多的事情要去做：服务器必须要去产生响应，客户端应用的代码必须要去执行， 并且浏览器必须要去布局（layout）和渲染（render）内容。再考虑到这些，下面的一些标准将帮助我们在预算时间内完成任务：
- (1) 服务器响应时间小于 200 ms
- 服务器响应时间是服务器向浏览器返回一个最初的HTML页面的时间，包括网络传输的用时。由于我们的时间预算非常紧张，这部分时间应该压缩到最小值——理想情况下是小于200ms，越小越好！
- (2) 减少重定向的数量
- 额外的HTTP重定向会增加一到两个网络往返（如果需要额外的DNS查找的话就是两个），在3G网络下导致数百毫秒的延迟。因此，我们强烈建议站长减少，甚至理论上完全弃用重定向——这对于HTML文档来说尤其重要（尽可能避免“m.xxx.com”的这种重定向）
- (3)尽可能减少首屏渲染所需要的请求数
- 由于TCP的慢启动算法(参考TCP Slow Start)， 一个新的TCP连接不能立即使用客户端与服务器之间全部可用的带宽。因此，服务器在一个新连接的第一次数据往返时，最多可以发送10个TCP包（不超过 14KB），接着服务器必须在它增加阻塞窗口和继续发送更多数据之前等待客户端确认（ACK）这些数据。 由于TCP 的这种行为，为了传输必要的数据来渲染首屏优化你的页面内容，减少需要的请求数是很重要的。理想情况下，首屏内容应该小于14KB——这允许了浏览器在第 一次数据往返（roundtrip）之后就开始渲染页面。另外，我们也要注意所谓的“第一次数据往返最多10个TCP包”的限制是TCP标准的一次最近的 更新：为了利用这个更新，你应该确保你的服务器升级到了最新版本。否则的话，可能受此数据往返的TCP包限制数量只有3-4个！
- (4)避免在首屏部分中引入外部的阻塞的JavaScript和CSS
- 在浏览器渲染并展示一个页面给用户之前，它首先要解析这个页面。如果浏览器在解析过程中遇到了一个非异步的（同步的）或者是阻塞的外部脚本，它就不得不停止解析转而去加载这个资源。每次都遇到这种情况，都会增加一次网络往返时间，这会导致页面首次渲染的延迟。 所以说，首屏渲染所需的JavaScript和CSS需要写成行内（inline）形式，其他的JavaScript和CSS文件应该在首屏内容已经展现给用户之后再加载。
- (5) 为浏览器的布局（layout）和渲染保留 200 ms 的时间
- 解析HTML、CSS和执行JavaScript的过程会耗费时间和客户端资源！取决于移动设备的速度和页面的复杂程度，这个过程可能会花费几百毫秒。我们的建议是为浏览器保留200ms的时间。
- (6) 优化JavaScript的执行过程和渲染时间
- 复杂的脚本和低效的代码会花费几十甚至几百秒去执行——可以用内置的开发者工具去分析和优化你的代码。为了更好的入门开发者工具，看看我们的interactive course for Chrome Developer Tools.吧！
注: 以上并不是所有的优化手段——这只是一个实现移动端半秒渲染的最高级别标准——你也应该继续使用所有其他的优化技巧
web performance best practices。来
PageSpeed Insights去发现更进一步的优化建议吧。 为了更深层次的了解以上的移动端优化标准，你也可以阅读：
Web Fundamentals: Critical Rendering Path. 优化关键渲染路径，打造极速移动站点 (
slides,
video). * 极速移动站点: 技巧和最佳实践 (
slides,
video)
常见问题（FAQ）
- 4G网络会如何影响以上的移动优化标准?
- 4G网络主要的进步之一就是更低的网络延迟。这降低了总的网络开销时间，对我们有巨大的帮助，要知道，在3G网络中，网络延迟几乎占我们“1秒 钟”时间预算的一半。然而，3G目前仍然是全世界范围内主要的网络类型，并且这种情况仍然会持续几年时间——你必须用心去为3G用户优化你的页面。
- 我使用JavaScript库，比如JQuery，对此有什么建议吗？
- 许多JS库，例如JQuery，都被用来为页面添加附加的交互、动画和特效。但是，大部分的这些行为本可以在首屏内容渲染完毕之后再加入页面。可以考虑把这些JavaScript的执行和加载放在页面加载完毕之后。
- 我用JavaScript框架去构建页面，对此有什么建议吗？
- 如果页面的内容是由客户端JavaScript构建的，你应该考虑直接在页面中插入（inlining）相关的JavaScript模块，以避免 额外的网络往返。类似的，使用服务端渲染可以显著提高首页（first page）的加载表现：在服务端渲染JS模板，在HTML中插入结果，然后当应用一加载完毕，就在客户端渲染模板。
- SPDY和HTTP 2.0 会对此有什么帮助吗?
- SPDY 和 HTTP 2.0 都旨在通过更有效的利用底层的TCP通信（多路复用、报头压缩、优先级请求）来降低页面加载的延迟时间。而且，服务端推送可以通过消除额外的网络延迟，大 大地改善页面的表现。我们鼓励你考虑在你的服务器上增加对SPDY的支持，并且等标准一定稿，就切换到HTTP 2.0协议。 （译者注：谷歌目前已经宣布Chrome将不会继续支持SPDY协议，但是会加强支持HTTP/2。实际上，HTTP/2的内容受到SPDY极大的影 响。）
- 我应该如何去找到那些关键的CSS代码?
- 在Chrome开发者工具中，打开“Audits”面板，运行“Web页面表现报告”（Web Page Performance report），在生成的报告中，找到“移除无效CSS规则”（Remove unused CSS rules）。或者使用任何其他的第三方工具或者脚本，去确定每个页面上应用了哪些CSS选择器。
- 这些最佳实践可以实现自动化吗?
- 当然可以。有许多商业的或是开源的Web性能优化产品能帮助你实现以上部分或是全部的优化标准。想找到开源的解决方案，不妨看看PageSpeed optimization tools。
- 我该如何调整我的服务器去适应这些优化标准呢？
- 首先，确保你的服务器运行了最新版的操作系统。为了从TCP协议的最初拥塞窗口数量的增加中获益，你需要Linux kernel 2.6.39+。对于其他的操作系统，请查阅文档。 为了优化服务器响应时间，审查（instrument）你的代码，或是使用一个应用监测方案去确定你的瓶颈——比如，脚本运行时、数据库调用、RPC请求、渲染等等。我们的目标是在200ms内渲染出HTML响应。
- 内容安全策略（Content Security Policy）怎么样？
- 如果你使用CSP，那么你需要更新你的默认策略。 首先，应该尽可能的在任何地方禁止行内的在HTML元素上的CSS特性（例如“< p style=...>”），因为这可能会导致不必要的代码重复，并且会被CSP默认屏蔽（通过"style-src"中的"unsafe inline"选项取消）。如果CSP是有效的，他将会默认屏蔽任何的行内脚本标签。如果你有行内脚本，那么你需要更新CSP策略，用script hashes or nonces或者是用"unsafe-inline"去使你所有的行内脚本可以执行。如果你有行内样式，那么你需要用style hashes or nonces或者还是用"unsafe-inline"去使你的行内样式可以使用。
有更多的问题？ 请自由的向我们的讨论群组提问
pagespeed-insights-discuss.
