Pentium286
commented
11 years ago 谢谢分享
Open cssmagic opened 11 years ago
Pentium286
commented
11 years ago 谢谢分享
cssmagic
commented
11 years ago 发现很多同学把焦点集中在“服务器 200 ms 响应”这一点上，这对后端的同学来说可能是一个挺大的压力。
这里分享一下我们网站的实践，抛砖引玉：
所有跟用户身份无关的页面（首页、产品列表与详情、帮助中心等），一律采用“整页缓存”——当这些页面由服务器动态渲染完成之后，就保存到 Memcache 中。下次当用户请求相同页面时，直接从 Memcache 中取出已经渲染完成的整页 HTML 代码，返回给客户端。这样可以将页面响应时间控制在几十 ms 这个量级。
不过这些页面中也会出现一些和用户身份相关的少量信息，比如顶部导航中的用户名、用户状态、购物车数量等。我们的解决方案是通过 Ajax 接口异步加载这些信息，并在前端适量缓存。
而对于那些跟用户身份直接相关的页面（比如用户中心、结算流程等），就无法使用“整页缓存”的方法来做优化了。
scourgen
commented
11 years ago 这篇文章已经很老了，你翻译的文章里的链接都是错的，https://github.com/speed/pagespeed/optimization 这个页面现在已经不存在了。
现在稍微复杂一点的网站，没有多少页面是和用户身份完全无关的。你提到了用Memcache存页面内容，但有没有考虑过在这之上其实还是有一个程序需要去负责根据URL和session判断应该显示什么内容，以及连接memcache的实例，并把memcache的内容提取出来再发送给客户端的，这个程序的逻辑本身也是会耗费一定的时间的。
你的“一律采用整页缓存”能够应用到的页面是很少的，对于整站的整体性能提高帮助并不会很大。
而其实解决这个问题的思路和整页缓存很类似：不是整页缓存，而是把动态页面拆成许多个component，然后根据实际的逻辑需要去分别做缓存。
任何页面都是由很多个逻辑组成的，就好比现在github的这个页面，可以分为：页头，项目头，issue信息，帖子（又分为主贴和N个回帖），然后是页尾。我们假设页面逻辑也是分为这么几块来处理的，在普通情况下，这几块内容都需要经过程序的处理和渲染才能被输出给用户，即使是简单地内容例如页脚，也至少需要一个文件读取的过程，但这也是需要一些时间的。而最佳的作法，则是将页面的某一部分也缓存起来。
关于具体的实现办法，有很多技术解决方案，入门成本最低的当属用Varnish实现ESI，如果有兴趣的话可以研究一下。
回头说到这篇文章，其实真正影响到页面渲染速度的地方反而一点都没有讲，倒是为了推销他们的那个pagespeed模块打了很多广告，至少从技术上我不觉得这是一篇值得学习的文章。这篇文章就好比告诉你“家用车如何百公里跑进5秒”，但通篇却说了很多马路，天气，赛车手的因素在里面，并不是说不对，但我想读者最想看的是你汽车的引擎到底是怎么设计的，轮胎用了什么技术之类的技术点。而就篇文章也是如此，对于如何减少dom节点，如何进行做css优化，如何做lazyload……倒是没提，反而讲了一些不那么相关的东西。
总之这种文章可以看看，但认真你就输了
edokeh
commented
11 years ago @scourgen 呃，原来只知道 Varnish 根据 HTTP 头做缓存，原来还有 ESI 这种高级货，感谢推荐 不过去看了下感觉挺麻烦的，应用跟 Varnish 也有了耦合，对于不是足够大的网站来说是不是有点过了
scourgen
commented
11 years ago @edokeh 不麻烦，你只是不熟悉所以觉得觉得麻烦而已。
相对技术投入和产出来说，用Varnish实现ESI是对页面片段做缓存的方案里代码改动最少以及性能提高最高的做法。
页面端只需要把模板拆开，本来的include代码现在变成了
基本的ESI方案就已经完成了。
当然如果你项目所用的框架支持那就更好了，就比如Symfony2就可以对ESI做无缝的集成，而且Symfony2模拟了Varnish对ESI的实现，也就是说即使你没有Varnish，依然可以用ESI。
edokeh
commented
11 years ago @scourgen PHP 荒废 N 年了，不过去搜了下 Rails ESI 还真发现不少资料，抓紧研究下，非常感谢！
edokeh
commented
11 years ago 孤陋寡闻了，ESI 居然还有个 W3C 的标准，http://www.w3.org/TR/esi-lang
scourgen
commented
11 years ago 这个标准有点年头了，最早是Akamai定的，完整的实现也只有Akamai自己的系统才能支持，开源的方案里Varnish只是支持了一部分而已。
wangxiao
commented
11 years ago @scourgen 评论不错，我读了之后的感觉：“貌似讲了些什么，但是又什么也没讲”。。。这个和yahoo的那34条建议不是类似嘛？貌似还没有那个多。
不过，感谢翻译。
另，对优化感兴趣推荐下淘宝的这个PPT http://www.slideshare.net/leneli/after-yahoo-34-rules-5088505
cssmagic
commented
11 years ago @scourgen 哇，开博以来最长的评论，受宠若惊！链接已修正，谢谢提醒！ :thumbsup:
链接错误的问题不是因为文章老（我也不确定是不是真的很老），是因为我在把 HTML 转换为 Markdown 的时候没有处理好相对链接，所以……你懂的，哈哈。
另外，顺着你提到的几个槽点展开讨论一下吧。
“整页缓存”的应用范围不广。这个还是要看业务。我们做电商，所以几乎所有的前台页面都可以用这个方法来加速，而且实际效果也很理想。如果是做 SNS，那确实会不一样。
把动态页面拆成许多个 component 分别做缓存。这其实跟“整页缓存”不冲突，因为我们也在用“区块缓存”，当整页缓存没有命中、需要动态渲染时，就会用到区块缓存，原理也跟你说的类似。但这个速度（在我们的系统上）要低一个数量级甚至更多，所以一般都会避免不必要的动态渲染。
Memcache vs Varnish/ESI，整页缓存 vs 区块缓存。坦白说我对后端架构完全不在行，对于技术选型和实施，我完全信赖我们的后端架构师。而且技术本身并不是目的，（在当前的系统架构、业务场景、甚至团队结构等等条件限制下）实现预期的优化效果才是真正的目的。所以，对于选用的技术是过时还是拉风，实际上作为产品负责人，我并不是那么纠结啦。当然你建议的方案我会转达给架构师，嘿嘿。
cssmagic
commented
11 years ago 接着聊。
“此文没有技术含量/假大空/做广告/炒冷饭”。这个观点是最有意思的，可以好好聊一聊。我实在是忍不住要把这个话题展开，单独写一段。
我在动手翻译之前，就有点小犹豫。因为 36 氪转载了 TheNextWeb 的“一秒渲染”新闻并且 发到微博 后，立刻就有大牛出来拍砖，说 Google 炒冷饭、说 36 氪哗众取宠。我当时那个汗颜啊，因为我自己看了 Google 的这篇文档觉得很有收获啊！
犹豫了一下，还是决定翻译出来、给更多人看到。因为我自己觉得有用，应该也会有其它人喜欢。于是花了一天左右的时间翻译出来，发到微博，随后很快被几个大号转发转载。这篇文章目前在微博上的累计转发量超过两百，是本人开博以来最受欢迎的文章，没有之一。
很多同学都表示“有收获”、“有启发”，我就觉得这一天时间花得很值。不过还是有大牛出来拍砖，说没有干货……所以我觉得吧，每篇文章都有不同的受众。就像我在微博评论里说的：
大牛们食之无味，不代表我等小白学不到东西，哈哈。
说它夸大其词夺人眼球，我觉得只要学到东西了，就算真被“忽悠”、被“广告”了又何妨？
说它言之无物避重就轻，没错，文章确实没有手把手地教授读者如何逐一实践这六条准则；不过俗话说得好，“师父领进门，修行靠各人”。一篇文章告诉我们一些准则和思路，甚至带来一些启发，它的作用就已经达到了。文章的价值在于激发你去思考，而不是代替你去思考。
没有干货，就去创造干货吧，少年！
cssmagic
commented
11 years ago 转发转载记录：
记录这个并不是为了显摆，主要是想收集反馈，顺便观察一下传播效果。
scourgen
commented
11 years ago 朋友，转载多不代表就是正确的，与其说这些媒体和转载者是被内容吸引，倒不如说是被标题吸引，毕竟“如何做到一秒渲染一个移动页面”这个标题实在是太有诱惑力了，很轻易就会让人漏看“移动”二字，以为任何页面都可以一秒内渲染完成。大部分小白没有自己判断的能力，看到满篇的英文也不会去细心阅读，他们只是看到文章来自Google，就盲目地认为Google大神又出来拯救地球，于是带着崇拜的心理盲目地进行转载罢了。
这篇文章最关健字的字不是“1秒”，而是“移动”，不是因为Google的这个工具有多强悍，而是因为在给移动设备使用的页面中，页面中的元素普遍很少，图片尺寸小，各种外链少，所以整个页面被优化在1秒以内是可以达到的。
这就像耍了个花招一样，还是具个汽车的例子：就像某厂商说自己的车在某小城市测试下来发现车性能很好，市区里也开得很快。但其实呢？不是因为车有多好，而是因为小城市里车流量本来就很少，车自然可以开的很快。
cssmagic
commented
11 years ago @scourgen 谢谢回复。
我认同你在第一段所说的，媒体都喜欢“耸动”的标题，这个标题也必然会吸引大众。事实上，我自己就是被 36 氪的报道激发起好奇心，然后追踪至原文的。但只要读完原文，真相自然洞穿。从被挑逗勾引、到掀起盖头、然后摸清套路、再到据为己有，这是一次很过瘾的消化吸收的过程。但凡留点心眼，都能各取所需。
如果看完了中文翻译，仍然没有抓到重点，仍然在盲目转发，这样的“资深小白”我承认可能真的会有。但我不会因为有这种特例的存在，就否定文章的价值，然后放弃传播。
所以总的来说，我承认你指出的“耸动标题的危害性”，但我认为它同样会激发有心人的求知欲。甚至从传播的角度，我希望好文章们都能有一个“好标题”。 :smile:
cssmagic
commented
11 years ago 再发几个延伸阅读：
qubaomingg
commented
11 years ago 谢谢作者翻译。 整理下原作者的思路：
读两边上面的，就有种被骗的感觉，=-=。
ZE3kr
commented
10 years ago iPhone上的Safari可以说是没有缓存的。可以用Cookie或者是应用存储。 其实最佳方案是将所有JS移到末尾（异步加载除外）。使用一个CDN。 推荐这本书《HTML 5 触摸界面设计与开发》 Stephen Woods著 ISBN：9787115343529 这本书前半部分都是在讲如何让页面加载/渲染更快。 其实这本书和本文介绍的方法基本一致，非常详细。
cssmagic
commented
10 years ago iPhone上的Safari可以说是没有缓存的。
@ZE3kr 愿闻其详。
ZE3kr
commented
10 years ago iOS 1~5.0 缓存最大值0 iOS 5.1+ 缓存最大值100M，注意：每次退出浏览器缓存立即删除 所以只能用其他缓存方式，例如直接存到Cookie，也有“应用缓存”方式
不知道最新的iOS有没有改进，看起来没有变
cssmagic
commented
10 years ago iOS 1~5.0 缓存最大值0 iOS 5.1+ 缓存最大值100M，注意：每次退出浏览器缓存立即删除
@ZE3kr 谢谢。这倒是第一次听说，请问这些数据的出处是哪里？
ZE3kr
commented
10 years ago http://www.guypo.com/uncategorized/mobile-browser-cache-sizes-round-2/ 这个大概讲了一下。不过至于资料从何而来我也不清楚
markyun
commented
10 years ago mark
joycewen
commented
9 years ago 作为菜鸟的我，读了大神们的翻译及评论后，很有收获！感谢大神们的知识输出！
BingoBingo
commented
8 years ago 总之还是感谢分享
huangjihua
commented
8 years ago 都讲了啥，似懂非懂
offbye
commented
8 years ago 现在是React，SPA，http2.0的时代了， 确实有点过时了
lanzhiheng
commented
7 years ago 不管怎样，还是感谢翻译。赏金已经发送。
cssmagic
commented
7 years ago @lanzhiheng 感谢支持！
lvleihere
commented
7 years ago 尴尬了#
miafan23
commented
6 years ago @offbye 从你说的三点是如何得出已过时的？文中不也提到了使用框架渲染页面的情况么，而且推荐了服务端渲染，也是现在的大势所趋，http2.0也提到了
[译] 如何做到一秒渲染一个移动页面（原名：使用 PageSpeed Insights 分析移动网站）
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 了！
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 开发者工具交互教程》。
FAQ
常见问题
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 讨论组内随意提问或提供反馈。
© Creative Commons BY-NC-ND 4.0 | 我要订阅 | 我要打赏