開發者應該了解的web性能
英文原文：Developers: What you should know about web performance
網站的快和慢有什么區別呢？
存在一種正確答案嗎？
沒有，很不幸，還沒有。原因在于網站具備很多因素，每種因素都有可能減慢網站。因此，本文不會給你提供一份需要完成的清單，而是打算解釋清楚，某些因素是怎樣減慢網站的，以及相應地你能做些什么。
正如諺語所說的：
授人以魚，不如授之以漁；授人以魚只救一時之及，授人以漁則可解一生之需。
除了讓你給腳本增加 “async” 標簽，或按照特定順序布局頁面之外，我還打算解釋這些修改所帶來的差異。這樣，你就能折騰你的應用程序，并確認哪些修改是有用的。
順便說一句，這些提示來自于我和 Ilya Grigorik 的一次精彩交談。
介紹下 Ilya Grigorik，他是 W3C Web Performance Working Group 的聯任主席，Google 的 web 性能工程師。嗯，他對性能頗有見地。
「每個人都應該做的一件事就是加速頁面載入」
正如我剛才提過的，不存在這樣的事情。web 有些出乎意料地復雜。使頁面載入速度降低的現象，對你而言，或許不能成為專注的正確標準！（我們稍后再細談）
然而，有些相當重要的因素，通常會帶來顯而易見的不同。你之前或許碰到過，但是或許不理解它們為什么重要。
1. 壓縮
用 gzip 壓縮傳輸 HTML、CSS 和 JavaScript，減少了需要流經線纜的字節數。這可以顯著減少下載資源的時間。瀏覽器渲染頁面，離不開 HTML 和 CSS，因此我們想盡快下載這些資源。
2. 優化圖片
我有個朋友，他給客戶搭建 WordPress 網站，有很多網站常常上傳大量圖片，我最近和他聊了一次。他遇到了一個問題，客戶直接把相機里的圖片上傳到他們的網站。
手機拍攝的照片超過 1MB。就算你用 CSS 調整大小，仍然需要通過線纜下載這副非常大的圖片。網速慢的用戶需要等待很長時間才能打開。
幸虧有應付的方法。我有段節目和優化圖片相關。如果你還沒有看過，我強烈推薦給你。
3. 不要傳輸不必要的東東
查看不同頁面里的腳本和 CSS 文件，自問一下，這些文件對于頁面是不是真的需要。你很可能找到一些文件，它們被添加上去之后就再沒去掉。
插件在這方面的表現，真的很糟糕。我接觸的相當一部分 ebordPress 網站，載入了一大堆 CSS 文件，其中有一半文件在某些頁面根本用不到！很多非 WordPress 網站也有類似現象。我早些時候檢查 scaleyourcode.com 上的某些頁面時，也發現它們正載入一個不必要的腳本。
清除腳本或樣式表，會讓人害怕。如果它對于那個頁面真的是必需的、只是你不記得了，該怎么怎么辦？有一些工具可以幫我們確認，推薦 DevTools（在 Audits 下）。
你能看出這些優化措施之間的共同點嗎？它們都減少了我們需要傳輸的字節數。
漸進式渲染（Progressive rendering）
你需要盡早將 HTML 字節給到瀏覽器。
比如：一個請求進來了，（理想狀態下）你的數據被緩存起來，因此服務器能夠快速獲取。然后，瀏覽器開始解析數據，并在屏幕上呈現出來。
我剛才提到了，頁面載入時間可能不是你需要專注的性能標準，這得感謝漸進式渲染。
漸進式渲染（來源）
頁面可以龐大，不過，只要你在短時間內（最好少于 1 秒）呈現給用戶一些內容，他們仍然覺得載入很快。
Amazon 在這方面就做得不錯：
Amazon 的漸進式渲染
對于此次 WebPageTest，在 1.5 秒就得到了第一屏，但是你能看到，它沒有包含所有內容。它包含的內容足以讓你開始瀏覽頁面、或查看假日交易。
然后，到 3.5 秒，另一部分載入了更多交易。到 6.5 秒，一些東西仍然在載入！事實上，整個頁面載入的完成一直持續到 18 秒。你能等那么長時間嗎？我表示懷疑！
如果 Amazon 專注于最慢的頁面載入，那么一定有人被激怒。他們卻專注于在最早的 packet 里發送最重要的字節。再進一步，他們可能在第一個 packet 里塞滿最重要的字節。我敢打賭，他們還專注于盡快地為你發送那些字節。
這就是 TTFB (Time To First Byte) 注1 的由來。
當瀏覽器發起一個頁面請求時，它就處于等待響應的狀態。TTFB 代表了它需要多長時間才能收到第一個響應的字節。這個時間不但代表了你的服務器產生響應所需要的時間，而且意味著經過線纜傳輸所需要的時間。
這張圖有著非常快速的 TTFB。如果你去網上逛逛，就能看到不同的 TTFB，你看到的情況類似于下圖：
為什么會是這種情況，我們該如何最小化該時間呢？你應該專注對其優化了嗎？不錯的問題，我就此準備了更多資料。
如果你有興趣了解更多信息，那么，請參考 Steve Souders 的精彩演講，談到了用來測量的性能標準。頁面載入時間不總是最好的標準。
能讓內容更快呈現的其它因素？
既然我們有了更快的 TTFB，那么每個地方都會極速呈現嗎？不一定，我們看看關鍵呈現路徑。
關鍵呈現路徑是瀏覽器為了得到 HTML、構建 DOM、得到樣式信息、執行關鍵的 JavaScript 以及繪制內容、而不得不執行的步驟順序。
天哪，要做的工作真不少呀。
這就是我們需要慎重對待它的原因。HTML、CSS 和 JavaScript 越多，需要的時間就越長。當載入 JavaScript 文件時，添加 async 標簽，原因就在于此。
當瀏覽器遇到 JavaScript 時，它可能不知道這里的 JS 是否要改變 DOM。因此，它不得不假定它會改變，然后它阻止渲染，直到 JavaScript 完成了執行過程。如果增加了 async 標簽，相當于向瀏覽器保證，該 JS 對于頁面不是關鍵的，因此瀏覽器可以繼續渲染，而不必等待 JS 執行完成。
如果碰到修改頁面的腳本，那么是否意味著不應該異步呀？可能。盡管如此，即使你異步化了修改頁面的腳本，那么從用戶視角看，這種做法也是實用的。用戶能夠看到內容，并開始產生交互。的確，某些地方或許無法呈現，也可能需要多等一會兒。當然，這都取決于你的應用程序，因此嘗試一下，看看是否滿足你的需求。
關鍵路徑對于盡可能快地接收字節如此重要，原因在于你能夠越早地開始處理整個過程，就能越快地完成。關于優化關鍵渲染路徑，請參考這里。
你該怎樣測量異步（或其它優化方式）對應用程序的好與壞？
有個不錯的測量工具，WebPageTest。你能夠得到各種有用信息，包括幻燈片視圖。幻燈片視圖就是我剛才用以展示 Amazon 頁面的可視化過程。你可以用在你的網站上，并列比較有無異步的差異。
直到最近，DevTools 實現了自己的幻燈片視圖。
打開 Chrome DevTools，點擊 TimeLine -> 開啟 Screenshots -> 重新載入頁面。
你就能看到頁面載入過程的截屏了。不錯吧？
現在，你可以：
- 切換你的網絡速度（記住，不是每個人都有超快的互聯網）
- 查看幻燈片視圖
- 把腳本改成異步（或做出其它調整）
- 對比幻燈片
你可以在 DevTools 里調整網速
另一個工具是 SpeedCurve，這是我最近無意間發現的。它由兩個聰明的家伙開發：Mark Zeman 和 Steve Souders，看起來很有幫助。
DevTools 非常優秀了，我們怎樣才能更好地理解其用法呢？
難點在于增加了太多功能所不幸引起的副作用。
除了看上面的例子，我們開始學習并實踐的更好方式是什么呢？對于怎樣在實際網站中使用 DevTools，Paul Lewis 和其他人已經體驗了。這里是關于修復滾動性能問題的極好例子。
更多
本文只是整個采訪過程的簡短摘要，我們在采訪中深入了大量細節，涵蓋了更多重要的主題（比如 HTTP/2 有什么不同，以及我們是否仍然需要最小化和串連）。
你可以在這里閱讀全部摘要或收聽采訪。如果你需要，請參考下面的視頻：https://youtu.be/Aayh2FAYGqc
譯文： 《開發者應該了解的 web 性能 》 臘八粥
注釋
- TTFB，是最初的網絡請求被發起到從服務器接收到第一個字節這段時間，它包含了 TCP 連接時間，發送 HTTP 請求時間和獲得響應消息第一個字節的時間。http://baike.baidu.com/view/4538320.htm
來自: www.labazhou.net