声明：原文版权属于 google，原文以 CC BY 3.0 协议发布，原文中的代码部分以 Apache 2.0 协议发布。中文翻译部分并非官方文档，仅供参考。
PageSpeed Insights analyzes a page to see if it follows our recommendations for making a page render in under a second on a mobile network. Research has shown that any delay longer than a second will cause the user to interrupt their flow of thought, creating a poor experience. Our goal is to keep the user engaged with the page and deliver the optimal experience, regardless of device or type of network.
一个网页是否可以在移动环境下用不到一秒的时间完成渲染，是一项非常重要的性能指标。研究显示，任何超过一秒钟的延迟都将打断用户的思维顺流状态，带来较差的体验。我们的目标是不论在任何设备或网络条件下，都要维持用户在网页中的沉浸状态，提供更好的体验。
It is not easy to meet the one second time budget. Luckily for us, the whole page doesn’t have to render within this budget, instead, we must deliver and render the above the fold (ATF) content in under one second, which allows the user to begin interacting with the page as soon as possible. Then, while the user is interpreting the first page of content, the rest of the page can be delivered progressively in the background.
想要达到这个标准并不是那么容易。不过幸运的是，我们并不需要在这个时间指标内渲染出整个页面，而是要在一秒以内传输并渲染出“首屏内容”（ATF），让用户尽快与页面交互。接下来，当用户与首屏内容进行交互的同时，页面的剩余部分可以在后台持续加载完成。
（译注：原文中的“ATF”一词源自传统出版业，指的是报纸头版的中折线以上区域，这块黄金区域往往用来刊登最有吸引力的新闻。延伸到互联网领域，ATF 指的是页面中不需要滚动就可以看到的首屏内容。）
Adapting to high latency mobile networks
适应高延迟的移动网络
Meeting the one second ATF criteria on mobile devices poses unique challenges which are not present on other networks. Users may be accessing your site through a variety of different 2G, 3G, and 4G networks. Network latencies are significantly higher than a wired connection, and consume a significant portion of our 1000 ms budget to render the ATF content:
在移动设备上达到“首屏秒开”的准则，需要面对其它网络所遇不到的独特挑战。用户可能正通过 2G、3G 或 4G 等各种各样的网络来访问你的网站。移动网络的延迟要明显高于有线连接，并且将消耗我们“首屏秒开”预算中的一大部分：
3G is the dominant network type around the world, and while 4G deployments are in progress around the world, you should still expect that the majority of users will be accessing your page on a 3G network. For this reason, we have to assume that each network request will take, on average, 200 milliseconds.
3G 是全球范围内占据统治地位的移动网络，而 4G 网络正在普及之中，你需要明白你的主流用户仍然在使用 3G 网络来访问你的页面。基于这个原因，我们不得不假设平均每次网络请求将消耗 200 ms。
With that in mind, let’s now work backwards. If we look at a typical sequence of communication between a browser and a server, 600 ms of that time has already been used up by network overhead: a DNS lookup to resolve the hostname (e.g. google.com) to an IP address, a network roundtrip to perform the TCP handshake, and finally a full network roundtrip to send the HTTP request. This leaves us with just 400 ms!
明白了这一点之后，我们来倒推一下时间。如果我们来分析一下浏览器与服务器之间一次典型的通信过程，会发现 600 ms 的时间就已经被网络本身消耗掉了：一次 DNS 查询用于将主机名（比如 google.com）解析为 IP 地址，一次网络往返用于发起 TCP 握手，以及最后一次完整的网络往返用于发送 HTTP 请求。我们就只剩下 400 ms 了！
[Figure%201]%20Render%20a%20mobile%20page%20in%201%20second
[图%201]%20一秒渲染一个移动页面
600%20ms%20mandatory%203G%20network%20overhead%20which%20you%20cannot%20do%20anything%20about
这%20600%20ms%20是不可避免的%203G%20网络消耗，你对此无能为力。
400%20ms%20which%20you%20can%20optimize%20by%20updating%20your%20server%20and%20structuring%20your%20page%20Appropriately%20(what%20the%20tool%20tries%20to%20help%20you%20with)
这%20400%20ms%20是你可以优化的，只要你合理地更新你的服务器，并以适当的方式构建你的页面（这正是%20PageSpeed%20Insights%20这个工具可以帮到你的）。
Delivering%20the%20sub%20one%20second%20rendering%20experience
实现半秒渲染的体验
After%20subtracting%20the%20network%20latency,%20we%20are%20left%20with%20just%20400%20milliseconds%20in%20our%20budget,%20and%20there%20is%20still%20a%20lot%20of%20work%20to%20do:%20server%20must%20render%20the%20response,%20client-side%20application%20code%20must%20execute,%20and%20the%20browser%20must%20layout%20and%20render%20the%20content.%20With%20that%20in%20mind,%20the%20following%20criteria%20should%20help%20us%20stay%20within%20the%20budget:
在除去网络延迟之后，我们的预算只剩下区区%20400%20ms%20了，但我们仍然还有大量的工作要做：服务器必须渲染出响应内容，客户端应用程序代码必须执行，而且浏览器必须完成内容的布局和渲染。了解了这些之后，下面这些准则将帮助我们控制住预算：
(1)%20Server%20must%20render%20the%20response%20(<%20200%20ms)
(1)%20服务器必须在%20200%20ms%20以内渲染出响应内容
Server%20response%20time%20is%20the%20time%20it%20takes%20for%20a%20server%20to%20return%20the%20initial%20html,%20factoring%20out%20the%20network%20transport%20time.%20Because%20we%20only%20have%20so%20little%20time,%20this%20time%20should%20be%20kept%20at%20a%20minimum%20-%20ideally%20within%20200%20milliseconds,%20and%20preferably%20even%20less!
服务器响应时间就是在除去网络传输时间之后，一台服务器首先返回%20HTML%20所花费的时间。因为我们剩下的时间实在太少了，这个时间应该控制在最低限度——理想情况下应该低于%20200%20ms，而且越少越好！
(2)%20Number%20of%20redirects%20should%20be%20minimized
(2)%20重定向的次数应该减至最少
Additional%20HTTP%20redirects%20can%20add%20one%20or%20two%20extra%20network%20roundtrips%20(two%20if%20an%20extra%20DNS%20lookup%20is%20required),%20incurring%20hundreds%20of%20milliseconds%20of%20extra%20latency%20on%203G%20networks.%20For%20this%20reason,%20we%20strongly%20encourage%20webmasters%20to%20minimize%20the%20number,%20and%20ideally%20eliminate%20redirects%20entirely%20-%20this%20is%20especially%20important%20for%20the%20HTML%20document%20(avoid%20“m%20dot”%20redirects%20when%20possible).
额外的%20HTTP%20重定向会增加一次或两次额外的网络往返（如果需要再次查询%20DNS%20的话就是两次），这在%203G%20网络上将导致几百毫秒的额外延迟。因此，我们强烈建议网站管理员们减少重定向的次数，而且最好完全消除重定向——这对%20HTML%20文档来说尤其重要（尽可能避免重定向到%20“m.”%20二级域名的行为）。
(3)%20Number%20of%20roundtrips%20to%20first%20render%20should%20be%20minimized
(3)%20首次渲染所需的网络往返次数应该减至最少
Due%20to%20how%20TCP%20estimates%20the%20capacity%20of%20a%20connection%20(i.e.%20TCP%20Slow%20Start),%20a%20new%20TCP%20connection%20cannot%20immediately%20use%20the%20full%20available%20bandwidth%20between%20the%20client%20and%20the%20server.%20Because%20of%20this,%20the%20server%20can%20send%20up%20to%2010%20TCP%20packets%20on%20a%20new%20connection%20(~14KB)%20in%20first%20roundtrip,%20and%20then%20it%20must%20wait%20for%20client%20to%20acknowledge%20this%20data%20before%20it%20can%20grow%20its%20congestion%20window%20and%20proceed%20to%20deliver%20more%20data.
由于%20TCP%20在评估连接状况方面采用了一套特殊机制（参见%20TCP%20慢启动），一次全新的%20TCP%20连接无法立即用满客户端和服务器之间的全部有效带宽。在这种情况下，服务器在首次网络往返中，通过一个新连接（约%2014kB）只能发送最多%2010%20个%20TCP%20包，接下来它必须等待客户端应答这些数据，然后才能增加它的拥塞窗口并继续发送更多数据。
Due%20to%20this%20TCP%20behavior,%20it%20is%20important%20to%20optimize%20your%20content%20to%20minimize%20the%20number%20of%20roundtrips%20required%20to%20deliver%20the%20necessary%20data%20to%20perform%20the%20first%20render%20of%20the%20page.%20Ideally,%20the%20ATF%20content%20should%20fit%20under%2014KB%20-%20this%20allows%20the%20browser%20to%20paint%20the%20page%20after%20just%20one%20roundtrip.%20Also,%20it%20is%20important%20to%20note%20that%20the%2010%20packet%20(IW10)%20limit%20is%20a%20recent%20update%20to%20the%20TCP%20standard:%20you%20should%20ensure%20that%20your%20server%20is%20upgraded%20to%20latest%20version%20to%20take%20advantage%20of%20this%20change.%20Otherwise,%20the%20limit%20will%20likely%20be%203-4%20packets!
考虑到%20TCP%20的这种行为，优化你的内容就显得十分重要。传输必要数据、完成页面首次渲染所需的网络往返次数应该减至最少。理想情况下，首屏内容应该小于%2014KB——这样浏览器才能在一次网络往返之后就可以绘制页面。同时，还有一个关键点需要留意，10%20个数据包上限（IW10）源自%20TCP%20标准的最近一次更新：你应该确保你的服务器软件已经升级到最新版本，以便从这次更新中获益。否则，这个上限将可能降到%203～4%20个数据包。
(4)%20Avoid%20external%20blocking%20JAVAScript%20and%20css%20in%20above-the-fold%20content
(4)%20避免在首屏内容中出现外链的阻塞式%20JavaScript%20和%20CSS
Before%20a%20browser%20can%20render%20a%20page%20to%20the%20user,%20it%20has%20to%20parse%20the%20page.%20If%20it%20encounters%20a%20non-async%20or%20blocking%20external%20script%20during%20parsing,%20it%20has%20to%20stop%20and%20download%20that%20resource.%20Each%20time%20it%20does%20that,%20it%20is%20adding%20a%20network%20round%20trip,%20which%20will%20delay%20the%20time%20to%20first%20render%20of%20the%20page.
浏览器必须先解析页面，然后才能向用户渲染这个页面。如果它在解析期间遇到一个非异步的或具有阻塞作用的外部脚本的话，它就不得不停下来，然后去下载这个资源。每次遇到这种情况，都会增加一次网络往返，这将延后页面的首次渲染时间。
As%20a%20result,%20the%20JavaScript%20and%20CSS%20needed%20to%20render%20the%20above%20the%20fold%20region%20should%20be%20inlined,%20and%20JavaScript%20or%20CSS%20needed%20to%20add%20additional%20functionality%20to%20the%20page%20should%20be%20loaded%20after%20the%20ATF%20content%20has%20been%20delivered.
结论就是，首屏渲染所需的%20JavaScript%20和%20CSS%20应该内嵌到页面中，而用于提供附加功能的%20JavaScript%20和%20CSS%20应该在首屏内容已经传输完成之后再加载。
(5)%20Reserve%20time%20for%20browser%20layout%20and%20rendering%20(200%20ms)
(5)%20为浏览器的布局和渲染工作预留时间%20(200%20ms)
The%20process%20of%20parsing%20the%20HTML,%20CSS,%20and%20executing%20JavaScript%20takes%20time%20and%20client%20resources!%20Depending%20on%20the%20speed%20of%20the%20mobile%20device,%20and%20the%20complexity%20of%20the%20page,%20this%20process%20can%20take%20hundreds%20of%20milliseconds.%20Our%20recommendation%20is%20to%20reserve%20200%20milliseconds%20for%20browser%20overhead.
解析%20HTML%20和%20CSS、执行%20JavaScript%20的过程也将消耗时间和客户端资源！取决于移动设备的速度和页面的复杂度，这个过程将占用几百毫秒。我们的建议是预留%20200%20ms%20作为浏览器的时间消耗。
(6)%20Optimize%20JavaScript%20execution%20and%20rendering%20time
(6)%20优化%20JavaScript%20执行和渲染耗时
Complicated%20scripts%20and%20inefficient%20code%20can%20take%20tens%20and%20hundreds%20of%20milliseconds%20to%20execute%20-%20use%20built-in%20developer%20tools%20in%20the%20browser%20to%20profile%20and%20optimize%20your%20code.%20For%20a%20great%20introduction,%20take%20a%20look%20at%20our%20interactive%20course%20for%20Chrome%20Developer%20Tools.
执行复杂的脚本和低效的代码可能会耗费几十或上百毫秒——可以使用浏览器内建的开发者工具来收集概况、优化代码。如果你想深入这个话题，不妨看看我们的《Chrome%20开发者工具交互教程》。
Note:%20The%20above%20is%20also%20not%20the%20complete%20list%20of%20all%20possible%20optimizations%20-%20it%20is%20a%20list%20of%20top%20mobile%20criteria%20to%20deliver%20a%20sub%20one%20second%20rendering%20time%20-%20and%20all%20other%20web%20performance%20best%20practicesshould%20be%20applied.%20Check%20out%20PageSpeed%20Insights%20for%20further%20advice%20and%20recommendations.
请注意：以上并未列举出所有可能的优化方案——只列出了一些移动端达成半秒渲染时间的基本准则——其它所有的网页性能最佳实践也应该运用起来。到%20PageSpeed%20Insights%20来看看，获取进一步的建议和推荐方案。
For%20a%20deep-dive%20on%20the%20above%20mobile%20criteria,%20also%20check%20out
如果需要深入探索上述移动端准则，请参阅：
FAQ
常见问题
How%20do%204G%20networks%20impact%20above%20mobile%20criteria?
4G%20网络对上述移动端准则有何影响？
Lower%20roundtrip%20latencies%20are%20one%20of%20the%20key%20improvements%20in%204G%20networks.%20This%20will%20help%20enormously,%20by%20reducing%20the%20total%20network%20overhead%20time,%20which%20is%20currently%20over%2050%%20of%20our%20one%20second%20budget%20on%203G%20networks.%20However,%203G%20is%20the%20dominant%20network%20type%20around%20the%20world,%20and%20will%20be%20for%20years%20to%20come%20-%20you%20have%20to%20optimize%20pages%20with%203G%20users%20in%20mind.
较低的网络往返延迟是%204G%20网络的一处关键改良。减少所有的网络损耗时间对网页性能将有巨大帮助，而目前在%203G%20网络上这些损耗就占用了我们一秒预算中的大半时间。不管怎样，3G%20仍然是全球最主流的移动网络，并且在今后几年都将如此——我们在优化网页时不得不把%203G%20用户放在心上。
I%20am%20using%20a%20JavaScript%20library,%20such%20as%20JQuery,%20any%20advice?
我正在使用一个%20JavaScript%20类库，比如%20jQuery，有什么建议吗？
Many%20JavaScript%20libraries,%20such%20as%20JQuery,%20are%20used%20to%20enhance%20the%20page%20to%20add%20additional%20interactivity,%20animations,%20and%20other%20effects.%20However,%20many%20of%20these%20behaviors%20can%20be%20safely%20added%20after%20the%20ATF%20content%20is%20rendered.%20Investigate%20moving%20the%20execution%20and%20loading%20of%20such%20JavaScript%20until%20after%20the%20page%20is%20loaded.
大多数%20JavaScript%20类库，比如%20jQuery，通常用来增强页面、提供附加的交互、动画和其它效果。但是，大多数这些行为可以安全地在首屏渲染之后再加入进来。研究一下是否可以把这些%20JavaScript%20的加载和执行推迟到页面加载之后。
I%20am%20using%20a%20JavaScript%20framework,%20to%20construct%20the%20page,%20any%20advice?
我在正使用一个%20JavaScript%20框架来渲染整个页面，有什么建议吗？
If%20the%20content%20of%20the%20page%20is%20constructed%20by%20client-side%20JavaScript,%20then%20you%20should%20investigate%20inlining%20the%20relevant%20JavaScript%20modules%20to%20avoid%20extra%20network%20roundtrips.%20Similarly,%20leveraging%20server-side%20rendering%20can%20significantly%20improve%20first%20page%20load%20performance:%20render%20JS%20templates%20on%20the%20server,%20inline%20the%20results%20into%20HTML,%20and%20then%20use%20client-side%20templating%20once%20the%20application%20is%20loaded.
如果页面内容是由客户端%20JavaScript%20来渲染的，那么你应该研究一下是否可以把相关的%20JavaScript%20模块都内嵌进来，以免产生额外的网络往返开销。同样，利用服务器端渲染可以显著地改善首次页面加载的性能：在服务器端渲染%20JS%20模板，并内嵌到%20HTML%20中，然后一旦应用程序加载完成就立即在客户端渲染模板。
SPDY%20and%20HTTP%202.0%20both%20aim%20to%20reduce%20latency%20of%20page%20loads%20by%20making%20more%20efficient%20use%20of%20the%20underlying%20TCP%20connection%20(multiplexing,%20header%20compression,%20prioritization).%20Further,%20server%20push%20can%20further%20help%20improve%20performance%20by%20eliminating%20extra%20network%20latency.%20We%20encourage%20you%20to%20investigate%20adding%20SPDY%20support%20on%20your%20servers,%20and%20switching%20to%20HTTP%202.0%20once%20the%20standard%20is%20ready.
SPDY%20和%20HTTP%202.0%20协议的目标都是通过更有效地利用底层的%20TCP%20连接（多路复用、头压缩、优先化处理），来减少页面的加载延迟。而且服务器%20push%20通过消除额外的网络延迟，可以进一步促进性能的改善。我们建议你为服务器增加对%20SPDY%20协议的支持，并且当%20HTTP%202.0%20标准就绪之后就立即切换过去。
（译注：“Critical%20CSS”%20是指首屏渲染所必需的最小化的%20CSS%20代码集合。）
In%20Chrome%20Developer%20Tools,%20open%20the%20Audits%20panel,%20and%20run%20a%20Web%20Page%20Performance%20report,%20in%20the%20generated%20report,%20look%20for%20Remove%20unused%20CSS%20rules.%20Or%20use%20any%20other%20third%20party%20tool,%20or%20script,%20to%20identify%20which%20CSS%20selectors%20are%20applied%20on%20each%20page.
在%20Chrome%20开发者工具中，打开审计（Audits）面板，然后运行一次网页性能（Web%20Page%20Performance）报告。在生成的报告中，试一下“删除未使用的%20CSS%20规则（Remove%20unused%20CSS%20rules）”。也可以使用其它第三方工具或脚本，来识别每个页面分别应用了哪些%20CSS%20选择符。
Absolutely.%20There%20are%20many%20commercial%20and%20open-source%20web%20performance%20optimization%20(WPO)%20products%20which%20can%20help%20you%20meet%20some%20or%20all%20of%20the%20criteria%20above.%20For%20open-source%20solutions,%20take%20a%20look%20at%20the%20PageSpeed%20optimization%20tools.
当然可以。有很多商业的或开源的网页性能优化（WPO）产品都可以帮你达成上述部分或全部准则。对于开源解决方案，不妨看看%20PageSpeed%20优化工具。
First,%20ensure%20that%20your%20server%20is%20running%20an%20up-to-date%20version%20of%20the%20operating%20system.%20In%20order%20to%20benefit%20from%20the%20increased%20initial%20TCP%20congestion%20window%20size%20(IW10),%20you%20will%20need%20linux%20kernel%202.6.39+.%20For%20other%20operating%20systems,%20consult%20the%20documentation.
首先，确保你的服务器正在运行最新版的操作系统。为了从%20TCP%20初始拥塞窗口数量的增加（IW10）中获益，你需要%202.6.39+%20版本的%20Linux%20内核。对于其它操作系统，请查阅相关文档。
To%20optimize%20server%20response%20time,%20instrument%20your%20code,%20or%20use%20an%20application%20monitoring%20solution%20to%20identify%20your%20bottleneck%20-%20e.g.,%20scripting%20runtime,%20database%20calls,%20RPC%20requests,%20rendering,%20etc.%20The%20goal%20is%20to%20render%20the%20HTML%20response%20within%20200%20milliseconds.
为了优化服务器的响应时间，请测评你的代码性能，或使用监控程序来发现性能瓶颈——比如脚本运行时、数据库调用、RPC%20请求、渲染等等。最终目标就是在%20200%20ms%20内渲染出%20HTML%20响应内容。
If%20you%20are%20using%20CSP,%20then%20you%20may%20need%20to%20update%20your%20default%20policy.
如果你正在使用%20CSP，那么你可能需要更新你的默认策略。（译注：CSP%20是一项用于防范%20XSS%20的安全性规范，具体参见%20Content%20Security%20Policy%20-%20维基百科。）
First,%20inline%20CSS%20attributes%20on%20HTML%20elements(e.g.,%20<p%20style=...>)%20should%20be%20avoided%20where%20possible,%20as%20they%20often%20lead%20to%20unnecessary%20code%20duplication,%20and%20are%20blocked%20by%20default%20with%20CSP%20(disabled%20via%20“unsafe%20inline”%20on%20“style-src”).%20If%20you%20have%20inline%20JavaScript,%20then%20you%20will%20need%20to%20update%20the%20CSP%20policy%20with%20“unsafe-inline”%20to%20enable%20its%20execution.%20By%20default,%20CSP%20will%20block%20all%20inline%20script%20tags.
首先，尽可能避免在%20HTML%20元素中内联%20CSS%20属性（比如这样%20<p%20style=...>），因为它们常常导致不必要的重复代码，而且默认会被%20CSP%20拦截（对%20style-src%20字段使用%20unsafe-inline%20指令可以禁用此类拦截）。如果你使用了内联的%20JavaScript，那么你需要在%20CSP%20策略中使用%20unsafe-inline%20指令来令其执行。默认情况下，CSP%20将拦截所有内联脚本标签。（译注：这里的“内联%20JavaScript”包括多种形态的%20HTML%20内部的脚本代码，包括类似%20<script>foo();</script>%20这样的内嵌脚本标签、<a%20href="javascript:foo();">%20这样的伪协议%20URL、以及%20<a%20href="#"%20onclick="foo();">%20这样的事件处理属性。）
点赞+转发，让更多的人也能看到这篇内容（收藏不点赞，都是耍流氓-_-）
关注%20｛我｝，享受文章首发体验！
每周重点攻克一个前端技术难点。更多精彩前端内容私信%20我%20回复“教程”
原文链接：https://github.com/cssmagic/blog/issues/20
京公网安备 11010802035086号