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