明：原文版權屬于 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 等各種各樣的網絡來訪問你的網站。移動網絡的延遲要明顯高于有線連接，并且將消耗我們“首屏秒開”預算中的一大部分：

• 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. 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 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 practicesshould 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)
• 為極速移動網站優化渲染的關鍵路徑 (幻燈片、視頻).
• 極速移動網站：技巧與最佳實踐 (幻燈片, 視頻)

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();"> 這樣的事件處理屬性。）

希望本文能幫助到您！

點贊+轉發，讓更多的人也能看到這篇內容（收藏不點贊，都是耍流氓-_-）

關注 ｛我｝，享受文章首發體驗！

每周重點攻克一個前端技術難點。更多精彩前端內容私信 我 回復“教程”

原文鏈接：https://github.com/cssmagic/blog/issues/20