Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[译] 如何做到一秒渲染一个移动页面 #20

cssmagic opened this issue Aug 12, 2013 · 30 comments

[译] 如何做到一秒渲染一个移动页面 #20

cssmagic opened this issue Aug 12, 2013 · 30 comments


Copy link

cssmagic commented Aug 12, 2013

[译] 如何做到一秒渲染一个移动页面(原名:使用 PageSpeed Insights 分析移动网站)

声明:原文版权属于 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 指的是页面中不需要滚动就可以看到的首屏内容。)

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 等各种各样的网络来访问你的网站。移动网络的延迟要明显高于有线连接,并且将消耗我们“首屏秒开”预算中的一大部分:

  • 200-300 ms roundtrip times for 3G networks
  • 50-100 ms roundtrip times for 4G networks
  • 3G 网络的往返时间将消耗 200-300 ms
  • 4G 网络的往返时间将消耗 50-100 ms

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. 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 查询用于将主机名(比如解析为 IP 地址,一次网络往返用于发起 TCP 握手,以及最后一次完整的网络往返用于发送 HTTP 请求。我们就只剩下 400 ms 了!

Render a mobile page in 1 second

[Figure 1] Render a mobile page in 1 second

[图 1] 一秒渲染一个移动页面

  • DNS Lookup (200 ms)
  • TCP Connection (200 ms)
  • HTTP Request and Response (200 ms)
  • DNS 查询 (200 ms)
  • TCP 连接 (200 ms)
  • HTTP 请求与响应 (200 ms)

600 ms mandatory 3G network overhead which you cannot do anything about

这 600 ms 是不可避免的 3G 网络消耗,你对此无能为力。

  • Server Response Time (200 ms)
  • Client-Side Rendering (200 ms)
  • 服务器响应时间 (200 ms)
  • 客户端渲染 (200 ms)

400 ms which you can optimize by updating your server and structuring your page appropriately (what the tool tries to help you with)

这 400 ms 是你可以优化的,只要你合理地更新你的服务器,并以适当的方式构建你的页面(这正是 PageSpeed Insights 这个工具可以帮到你的)。

Delivering the sub one second rendering experience


After subtracting the network latency, we are left with just 400 milliseconds in our budget, and there is still a lot of work to do: server must render the response, client-side application code must execute, and the browser must layout and render the content. With that in mind, the following criteria should help us stay within the budget:

在除去网络延迟之后,我们的预算只剩下区区 400 ms 了,但我们仍然还有大量的工作要做:服务器必须渲染出响应内容,客户端应用程序代码必须执行,而且浏览器必须完成内容的布局和渲染。了解了这些之后,下面这些准则将帮助我们控制住预算:

(1) Server must render the response (< 200 ms)

(1) 服务器必须在 200 ms 以内渲染出响应内容

Server response time is the time it takes for a server to return the initial HTML, factoring out the network transport time. Because we only have so little time, this time should be kept at a minimum - ideally within 200 milliseconds, and preferably even less!

服务器响应时间就是在除去网络传输时间之后,一台服务器首先返回 HTML 所花费的时间。因为我们剩下的时间实在太少了,这个时间应该控制在最低限度——理想情况下应该低于 200 ms,而且越少越好!

(2) Number of redirects should be minimized

(2) 重定向的次数应该减至最少

Additional HTTP redirects can add one or two extra network roundtrips (two if an extra DNS lookup is required), incurring hundreds of milliseconds of extra latency on 3G networks. For this reason, we strongly encourage webmasters to minimize the number, and ideally eliminate redirects entirely - this is especially important for the HTML document (avoid “m dot” redirects when possible).

额外的 HTTP 重定向会增加一次或两次额外的网络往返(如果需要再次查询 DNS 的话就是两次),这在 3G 网络上将导致几百毫秒的额外延迟。因此,我们强烈建议网站管理员们减少重定向的次数,而且最好完全消除重定向——这对 HTML 文档来说尤其重要(尽可能避免重定向到 “m.” 二级域名的行为)。

(3) Number of roundtrips to first render should be minimized

(3) 首次渲染所需的网络往返次数应该减至最少

Due to how TCP estimates the capacity of a connection (i.e. TCP Slow Start), a new TCP connection cannot immediately use the full available bandwidth between the client and the server. Because of this, the server can send up to 10 TCP packets on a new connection (~14KB) in first roundtrip, and then it must wait for client to acknowledge this data before it can grow its congestion window and proceed to deliver more data.

由于 TCP 在评估连接状况方面采用了一套特殊机制(参见 TCP 慢启动),一次全新的 TCP 连接无法立即用满客户端和服务器之间的全部有效带宽。在这种情况下,服务器在首次网络往返中,通过一个新连接(约 14kB)只能发送最多 10 个 TCP 包,接下来它必须等待客户端应答这些数据,然后才能增加它的拥塞窗口并继续发送更多数据。

Due to this TCP behavior, it is important to optimize your content to minimize the number of roundtrips required to deliver the necessary data to perform the first render of the page. Ideally, the ATF content should fit under 14KB - this allows the browser to paint the page after just one roundtrip. Also, it is important to note that the 10 packet (IW10) limit is a recent update to the TCP standard: you should ensure that your server is upgraded to latest version to take advantage of this change. Otherwise, the limit will likely be 3-4 packets!

考虑到 TCP 的这种行为,优化你的内容就显得十分重要。传输必要数据、完成页面首次渲染所需的网络往返次数应该减至最少。理想情况下,首屏内容应该小于 14KB——这样浏览器才能在一次网络往返之后就可以绘制页面。同时,还有一个关键点需要留意,10 个数据包上限(IW10)源自 TCP 标准的最近一次更新:你应该确保你的服务器软件已经升级到最新版本,以便从这次更新中获益。否则,这个上限将可能降到 3~4 个数据包。

(4) Avoid external blocking JavaScript and CSS in above-the-fold content

(4) 避免在首屏内容中出现外链的阻塞式 JavaScript 和 CSS

Before a browser can render a page to the user, it has to parse the page. If it encounters a non-async or blocking external script during parsing, it has to stop and download that resource. Each time it does that, it is adding a network round trip, which will delay the time to first render of the page.


As a result, the JavaScript and CSS needed to render the above the fold region should be inlined, and JavaScript or CSS needed to add additional functionality to the page should be loaded after the ATF content has been delivered.

结论就是,首屏渲染所需的 JavaScript 和 CSS 应该内嵌到页面中,而用于提供附加功能的 JavaScript 和 CSS 应该在首屏内容已经传输完成之后再加载。

(5) Reserve time for browser layout and rendering (200 ms)

(5) 为浏览器的布局和渲染工作预留时间 (200 ms)

The process of parsing the HTML, CSS, and executing JavaScript takes time and client resources! Depending on the speed of the mobile device, and the complexity of the page, this process can take hundreds of milliseconds. Our recommendation is to reserve 200 milliseconds for browser overhead.

解析 HTML 和 CSS、执行 JavaScript 的过程也将消耗时间和客户端资源!取决于移动设备的速度和页面的复杂度,这个过程将占用几百毫秒。我们的建议是预留 200 ms 作为浏览器的时间消耗。

(6) Optimize JavaScript execution and rendering time

(6) 优化 JavaScript 执行和渲染耗时

Complicated scripts and inefficient code can take tens and hundreds of milliseconds to execute - use built-in developer tools in the browser to profile and optimize your code. For a great introduction, take a look at our interactive course for Chrome Developer Tools.

执行复杂的脚本和低效的代码可能会耗费几十或上百毫秒——可以使用浏览器内建的开发者工具来收集概况、优化代码。如果你想深入这个话题,不妨看看我们的《Chrome 开发者工具交互教程》

Note: The above is also not the complete list of all possible optimizations - it is a list of top mobile criteria to deliver a sub one second rendering time - and all other web performance best practices should be applied. Check out PageSpeed Insights for further advice and recommendations.

请注意:以上并未列举出所有可能的优化方案——只列出了一些移动端达成半秒渲染时间的基本准则——其它所有的网页性能最佳实践也应该运用起来。到 PageSpeed Insights 来看看,获取进一步的建议和推荐方案。

For a deep-dive on the above mobile criteria, also check out


  • Optimizing the Critical Rendering Path for Instant Mobile Websites (slides, video).
  • Instant Mobile Websites: Techniques and Best Practices (slides, video)
  • 为极速移动网站优化渲染的关键路径 (幻灯片视频).
  • 极速移动网站:技巧与最佳实践 (幻灯片, 视频)



How do 4G networks impact above mobile criteria?

4G 网络对上述移动端准则有何影响?

Lower roundtrip latencies are one of the key improvements in 4G networks. This will help enormously, by reducing the total network overhead time, which is currently over 50% of our one second budget on 3G networks. However, 3G is the dominant network type around the world, and will be for years to come - you have to optimize pages with 3G users in mind.

较低的网络往返延迟是 4G 网络的一处关键改良。减少所有的网络损耗时间对网页性能将有巨大帮助,而目前在 3G 网络上这些损耗就占用了我们一秒预算中的大半时间。不管怎样,3G 仍然是全球最主流的移动网络,并且在今后几年都将如此——我们在优化网页时不得不把 3G 用户放在心上。

I am using a JavaScript library, such as JQuery, any advice?

我正在使用一个 JavaScript 类库,比如 jQuery,有什么建议吗?

Many JavaScript libraries, such as JQuery, are used to enhance the page to add additional interactivity, animations, and other effects. However, many of these behaviors can be safely added after the ATF content is rendered. Investigate moving the execution and loading of such JavaScript until after the page is loaded.

大多数 JavaScript 类库,比如 jQuery,通常用来增强页面、提供附加的交互、动画和其它效果。但是,大多数这些行为可以安全地在首屏渲染之后再加入进来。研究一下是否可以把这些 JavaScript 的加载和执行推迟到页面加载之后。

I am using a JavaScript framework, to construct the page, any advice?

我在正使用一个 JavaScript 框架来渲染整个页面,有什么建议吗?

If the content of the page is constructed by client-side JavaScript, then you should investigate inlining the relevant JavaScript modules to avoid extra network roundtrips. Similarly, leveraging server-side rendering can significantly improve first page load performance: render JS templates on the server, inline the results into HTML, and then use client-side templating once the application is loaded.

如果页面内容是由客户端 JavaScript 来渲染的,那么你应该研究一下是否可以把相关的 JavaScript 模块都内嵌进来,以免产生额外的网络往返开销。同样,利用服务器端渲染可以显著地改善首次页面加载的性能:在服务器端渲染 JS 模板,并内嵌到 HTML 中,然后一旦应用程序加载完成就立即在客户端渲染模板。

How will SPDY and HTTP 2.0 help?

SPDY 和 HTTP 2.0 协议会有什么帮助?

SPDY and HTTP 2.0 both aim to reduce latency of page loads by making more efficient use of the underlying TCP connection (multiplexing, header compression, prioritization). Further, server push can further help improve performance by eliminating extra network latency. We encourage you to investigate adding SPDY support on your servers, and switching to HTTP 2.0 once the standard is ready.

SPDY 和 HTTP 2.0 协议的目标都是通过更有效地利用底层的 TCP 连接(多路复用、头压缩、优先化处理),来减少页面的加载延迟。而且服务器 push 通过消除额外的网络延迟,可以进一步促进性能的改善。我们建议你为服务器增加对 SPDY 协议的支持,并且当 HTTP 2.0 标准就绪之后就立即切换过去。

How do I identify critical CSS on my page?

如何判断页面中的哪些 CSS 是 critical CSS?

(译注:“Critical CSS” 是指首屏渲染所必需的最小化的 CSS 代码集合。)

In Chrome Developer Tools, open the Audits panel, and run a Web Page Performance report, in the generated report, look for Remove unused CSS rules. Or use any other third party tool, or script, to identify which CSS selectors are applied on each page.

在 Chrome 开发者工具中,打开审计(Audits)面板,然后运行一次网页性能(Web Page Performance)报告。在生成的报告中,试一下“删除未使用的 CSS 规则(Remove unused CSS rules)”。也可以使用其它第三方工具或脚本,来识别每个页面分别应用了哪些 CSS 选择符。

Can these best practices be automated?


Absolutely. There are many commercial and open-source web performance optimization (WPO) products which can help you meet some or all of the criteria above. For open-source solutions, take a look at the PageSpeed optimization tools.

当然可以。有很多商业的或开源的网页性能优化(WPO)产品都可以帮你达成上述部分或全部准则。对于开源解决方案,不妨看看 PageSpeed 优化工具

How do I tune my server to meet these criteria?


First, ensure that your server is running an up-to-date version of the operating system. In order to benefit from the increased initial TCP congestion window size (IW10), you will need Linux kernel 2.6.39+. For other operating systems, consult the documentation.

首先,确保你的服务器正在运行最新版的操作系统。为了从 TCP 初始拥塞窗口数量的增加(IW10)中获益,你需要 2.6.39+ 版本的 Linux 内核。对于其它操作系统,请查阅相关文档。

To optimize server response time, instrument your code, or use an application monitoring solution to identify your bottleneck - e.g., scripting runtime, database calls, RPC requests, rendering, etc. The goal is to render the HTML response within 200 milliseconds.

为了优化服务器的响应时间,请测评你的代码性能,或使用监控程序来发现性能瓶颈——比如脚本运行时、数据库调用、RPC 请求、渲染等等。最终目标就是在 200 ms 内渲染出 HTML 响应内容。

What about Content Security Policy?

内容安全策略(Content Security Policy)怎么办?

If you are using CSP, then you may need to update your default policy.

如果你正在使用 CSP,那么你可能需要更新你的默认策略。(译注:CSP 是一项用于防范 XSS 的安全性规范,具体参见 Content Security Policy - 维基百科。)

First, inline CSS attributes on HTML elements(e.g., <p style=...>) should be avoided where possible, as they often lead to unnecessary code duplication, and are blocked by default with CSP (disabled via “unsafe inline” on “style-src”). If you have inline JavaScript, then you will need to update the CSP policy with “unsafe-inline” to enable its execution. By default, CSP will block all inline script tags.

首先,尽可能避免在 HTML 元素中内联 CSS 属性(比如这样 <p style=...>),因为它们常常导致不必要的重复代码,而且默认会被 CSP 拦截(对 style-src 字段使用 unsafe-inline 指令可以禁用此类拦截)。如果你使用了内联的 JavaScript,那么你需要在 CSP 策略中使用 unsafe-inline 指令来令其执行。默认情况下,CSP 将拦截所有内联脚本标签。(译注:这里的“内联 JavaScript”包括多种形态的 HTML 内部的脚本代码,包括类似 <script>foo();</script> 这样的内嵌脚本标签、<a href="javascript:foo();"> 这样的伪协议 URL、以及 <a href="#" onclick="foo();"> 这样的事件处理属性。)

Have more questions? Please feel free to ask and provide feedback in our discussion group at page-speed-discuss.

还有其它问题?请在我们的 page-speed-discuss 讨论组内随意提问或提供反馈。

原文版本:2013-08-06 (如果原文已更新,请提醒我。)

© Creative Commons BY-NC-ND 4.0   |   我要订阅   |   我要打赏

Copy link


Copy link
Owner Author

发现很多同学把焦点集中在“服务器 200 ms 响应”这一点上,这对后端的同学来说可能是一个挺大的压力。


所有跟用户身份无关的页面(首页、产品列表与详情、帮助中心等),一律采用“整页缓存”——当这些页面由服务器动态渲染完成之后,就保存到 Memcache 中。下次当用户请求相同页面时,直接从 Memcache 中取出已经渲染完成的整页 HTML 代码,返回给客户端。这样可以将页面响应时间控制在几十 ms 这个量级。

不过这些页面中也会出现一些和用户身份相关的少量信息,比如顶部导航中的用户名、用户状态、购物车数量等。我们的解决方案是通过 Ajax 接口异步加载这些信息,并在前端适量缓存。


Copy link

这篇文章已经很老了,你翻译的文章里的链接都是错的, 这个页面现在已经不存在了。








Copy link

edokeh commented Aug 12, 2013

呃,原来只知道 Varnish 根据 HTTP 头做缓存,原来还有 ESI 这种高级货,感谢推荐
不过去看了下感觉挺麻烦的,应用跟 Varnish 也有了耦合,对于不是足够大的网站来说是不是有点过了

Copy link

@edokeh 不麻烦,你只是不熟悉所以觉得觉得麻烦而已。





Copy link

edokeh commented Aug 12, 2013

PHP 荒废 N 年了,不过去搜了下 Rails ESI 还真发现不少资料,抓紧研究下,非常感谢!

Copy link

edokeh commented Aug 12, 2013

孤陋寡闻了,ESI 居然还有个 W3C 的标准,

Copy link


Copy link

@scourgen 评论不错,我读了之后的感觉:“貌似讲了些什么,但是又什么也没讲”。。。这个和yahoo的那34条建议不是类似嘛?貌似还没有那个多。



Copy link
Owner Author

哇,开博以来最长的评论,受宠若惊!链接已修正,谢谢提醒! 👍

链接错误的问题不是因为文章老(我也不确定是不是真的很老),是因为我在把 HTML 转换为 Markdown 的时候没有处理好相对链接,所以……你懂的,哈哈。


“整页缓存”的应用范围不广。这个还是要看业务。我们做电商,所以几乎所有的前台页面都可以用这个方法来加速,而且实际效果也很理想。如果是做 SNS,那确实会不一样。

把动态页面拆成许多个 component 分别做缓存。这其实跟“整页缓存”不冲突,因为我们也在用“区块缓存”,当整页缓存没有命中、需要动态渲染时,就会用到区块缓存,原理也跟你说的类似。但这个速度(在我们的系统上)要低一个数量级甚至更多,所以一般都会避免不必要的动态渲染。

Memcache vs Varnish/ESI,整页缓存 vs 区块缓存。坦白说我对后端架构完全不在行,对于技术选型和实施,我完全信赖我们的后端架构师。而且技术本身并不是目的,(在当前的系统架构、业务场景、甚至团队结构等等条件限制下)实现预期的优化效果才是真正的目的。所以,对于选用的技术是过时还是拉风,实际上作为产品负责人,我并不是那么纠结啦。当然你建议的方案我会转达给架构师,嘿嘿。

Copy link
Owner Author



我在动手翻译之前,就有点小犹豫。因为 36 氪转载了 TheNextWeb 的“一秒渲染”新闻并且 发到微博 后,立刻就有大牛出来拍砖,说 Google 炒冷饭、说 36 氪哗众取宠。我当时那个汗颜啊,因为我自己看了 Google 的这篇文档觉得很有收获啊!







Copy link
Owner Author


  • [微博] developerWorks: //
  • [微博] 伯乐在线官方微博: //
  • 伯乐在线: //
  • [微博] HTML5梦工场: //


Copy link




Copy link
Owner Author

@scourgen 谢谢回复。

我认同你在第一段所说的,媒体都喜欢“耸动”的标题,这个标题也必然会吸引大众。事实上,我自己就是被 36 氪的报道激发起好奇心,然后追踪至原文的。但只要读完原文,真相自然洞穿。从被挑逗勾引、到掀起盖头、然后摸清套路、再到据为己有,这是一次很过瘾的消化吸收的过程。但凡留点心眼,都能各取所需。


所以总的来说,我承认你指出的“耸动标题的危害性”,但我认为它同样会激发有心人的求知欲。甚至从传播的角度,我希望好文章们都能有一个“好标题”。 😄

Copy link
Owner Author


  • 《Creating High-Performance Mobile Websites》(英): //
  • 《创建高性能移动 web 站点 》(翻译): //
  • 《How To Make Your Websites Faster On Mobile Devices》(英): //
  • 《让你的网站在移动端健步如飞》(翻译 @jtyjty99999): //

Copy link



服务器必须在 200 ms 以内渲染出响应内容
避免在首屏内容中出现外链的阻塞式 JavaScript 和 CSS
为浏览器的布局和渲染工作预留时间 (200 ms)
优化 JavaScript 执行和渲染耗时


Copy link

ZE3kr commented Aug 4, 2014

推荐这本书《HTML 5 触摸界面设计与开发》 Stephen Woods著 ISBN:9787115343529

Copy link
Owner Author

cssmagic commented Aug 4, 2014


@ZE3kr 愿闻其详。

Copy link

ZE3kr commented Aug 4, 2014

iOS 1~5.0 缓存最大值0
iOS 5.1+ 缓存最大值100M,注意:每次退出浏览器缓存立即删除


Copy link
Owner Author

cssmagic commented Aug 5, 2014

iOS 1~5.0 缓存最大值0
iOS 5.1+ 缓存最大值100M,注意:每次退出浏览器缓存立即删除

@ZE3kr 谢谢。这倒是第一次听说,请问这些数据的出处是哪里?

Copy link

ZE3kr commented Aug 5, 2014

Copy link

markyun commented Aug 6, 2014


Copy link


Copy link


Copy link


Copy link

offbye commented Aug 17, 2016

现在是React,SPA,http2.0的时代了, 确实有点过时了

Copy link


Copy link
Owner Author

@lanzhiheng 感谢支持!

Copy link


Copy link

@offbye 从你说的三点是如何得出已过时的?文中不也提到了使用框架渲染页面的情况么,而且推荐了服务端渲染,也是现在的大势所趋,http2.0也提到了

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests