前言

這是一篇有聲音的早讀課，今天繼續第三部分的內容，今日早讀文章由@Cherry翻譯分享。

正文從這開始～

靜態資源優化

你是使用 Brotli 還是 Zopfli 進行純文本壓縮？

在 2005 年，Google 推出了Brotli，一個新的開源無損數據壓縮格式，現在被所有的現代瀏覽器所支持。實際上，Brotli 比 Gzip 和 Deflate更有效。取決于設置信息，壓縮可能會非常慢。但是緩慢的壓縮過程會提高壓縮率，并且仍然可以快速解壓。當然，解壓縮速度很快。

只有當用戶通過 HTTPS 訪問網站時，瀏覽器才會采用。Brotli 現在還不能預裝在某些服務器上，而且如果不自己構建 NGINX 和 UBUNTU 的話很難部署。不過這也并不難。實際上，一些 CDN 是支持的，甚至可以也可以通過服務器在不支持 CDN 的情況下啟用 Brotli。

在最高級別的壓縮下，Brotli 的速度會變得非常慢，以至于服務器在等待動態壓縮資源時開始發送響應所花費的時間可能會使文件大小的任何潛在收益都無效。但是，對于靜態壓縮，高壓縮比的設置比較受歡迎—— （感謝 Jeremy!）

或者，你可以考慮使用Zopfli 的壓縮算法，將數據編碼為 Deflate，Gzip 和 Zlib 格式。Zopfli 改進的 Deflate 編碼使得任何使用 Gzip 壓縮的文件受益，因為這些文件大小比 用Zlib 最強壓縮后還要小 3％ 到 8％。問題在于壓縮文件的時間是原來的大約 80倍。這就是為什么雖然 使用 Zopfli 是一個好主意但是變化并不大，文件都需要設計為只壓縮一次可以多次下載的。

比較好的方法是你可以繞過動態壓縮靜態資源的成本。Brotli 和 Zopfli 都可以用于明文傳輸 —— HTML，CSS，SVG， 等。

有什么方法呢？在最高等級和 Brotli 的 1-4 級動態壓縮 HTML 使用 Brotli+Gzip 預壓縮靜態資源。同時，檢查 Brotli 是否支持 CDN，（例如KeyCDN，CDN77，Fastly）。確保服務器能夠使用 Brotli 或 gzip 處理內容。如果你不能安裝或者維護服務器上的 Brotli，那么請使用 Zopfli。

圖像是否進行了適當的優化？

盡可能通過srcset，sizes和

元素使用響應式圖片。也可以通過

元素使用 WebP 格式的圖像（Chrom，Opera，Firefox soon支持），或者一個 JPEG 的回調（見 Andreas Bovens 的code snippet）或者通過使用內容協商（使用Accept頭信息）。

Sketch 本身就支持 WebP 并且 WebP 圖像可以通過使用WebP 插件從 中導出。也有其他選擇可以使用，如果你使用 或者 Joomla，也有可以輕松支持 WebP 的擴展，例如Optimus和Cache Enabler（通過Cody ）

你可以仍然使用client hints，但仍需要獲得一些瀏覽器支持。沒有足夠的資源支持響應式圖片？使用斷點發生器或者類似這樣的服務自動優化圖片。同樣，在許多情況下，只使用srcset和sizes會有不錯的效果。

On , we use the postfix-optfor image names — for example,brotli--opt.png; an image that postfix, on the team knows that the image has already been .

響應圖像斷點發生器

響應圖像斷點生成器自動生成圖像和標記生成。

將圖像優化到下一個級別

現在有一個至關重要著陸頁，有一個特定的圖片的加載速度非常關鍵，確保 JPEGs 是漸進式的并且使用Adept、mozJPEG（通過操縱掃描級來改善開始渲染時間）或者Guetzli壓縮，谷歌新的開源編碼器重點是能夠感官的性能，并借鑒 Zopfli 和 WebP。唯一的@fox/talk-the-state-of-the-web-">不足 是：處理的時間慢（每百萬像素 CPU 一分鐘）。至于 png，我們可以使用Pingo，和svgo，對于 SVG 的處理，我們使用SVGO或SVGOMG

每一個圖像優化的文章會說明，但始終保持保持矢量資產清潔總是值得提醒的。確保清理未使用的資源，刪除不必要的元數據，并減少圖稿中的路徑點數量（從而減少SVG代碼）。（感謝，Jeremy！）

到目前為止，這些優化只涵蓋了基礎知識。 Addy Osmani 已經發布了一個非常詳細的基本圖像優化指南，深入到圖像壓縮和顏色管理的細節。 例如，您可以模糊圖像中不必要的部分（通過對其應用高斯模糊濾鏡）以減小文件大小，最終甚至可以開始移除顏色或將圖像變成黑白色，以進一步縮小圖像尺寸。 對于背景圖像， 從 導出的照片質量為 0 到 10％ 也是絕對可以接受的。

那么 GIF 圖片呢？我們可以使用循環的 HTML5 視頻，而不是影響渲染性能和帶寬的重度 GIF 動畫，而使用循環的 HTML5 視頻，會使得瀏覽器的性能很慢，而且與圖像不同的是，瀏覽器不會預先加載內容。 至少我們可以使用Lossy GIF,或者添加有損壓縮 GIF。

好消息: 希望不久以后我們可以使用

來加載視頻, 早期的測試表明img標簽比同等大小的 GIF 顯示的要快 20 多倍解析速度與要快 7 倍多。

還不夠好？那么，你也可以使用多種背景圖像技術提高圖像的感知性能。 記著，減少對比度和模糊不必要的細節（或消除顏色）也可以減小文件的大小。 你需要放大一個小照片而不失真？考慮使用.io

Zach 的字體加載策略綜合指南

Zach 的字體加載策略綜合指南提供了十幾種更好的網頁字體發送選項

Web字體是否優化？

首先需要問一個問題，你是否能不使用UI 系統字體。 如果不可以，那么你有很大可能使用 Web 網絡字體，會包含字形和額外的功能以及用不到的加粗。 如果您使用的是開源字體（例如，通過僅包含帶有某些特殊的重音字形的拉丁語），則可以只選擇部分 Web 字體來減少其文件大小。

WOFF2非常好，你可以使用 WOFF 和 OTF 作為不支持它的瀏覽器的備選。另外，從 Zach 的《字體加載策略綜合指南》（代碼片段也可以作為Web字體加載片段）中選擇一種策略，并使用服務器緩存持久地緩存字體。是不是感覺小有成就？Pixel Ambacht 有一個快速教程和案例研究，讓你的字體按順序排列。

如果你無法從你的服務器拿到字體并依賴于第三方主機，請確保使用字體加載事件（或對不支持它的瀏覽器使用Web字體加載器）FOUT 要優于 FOIT; 立即開始渲染文本，并異步加載字體 —— 也可以使用loadCSS。 你也可以擺脫本地安裝的操作系統字體，也可以使用可變的字體。

怎么才能是一個無漏洞的字體加載策略？ 從font-display開始，然后回到 Font Loading API，然后回到 Bram Stein 的Font Face （感謝 Jeremy！）如果你有興趣從用戶的角度來衡量字體加載的性能， Andreas 探索了 使用 Font API 和 API 進行性能跟蹤

此外，不要忘記包含font-display：描述符來提供彈性和快速的字體回退，unicode-range將大字體分解成更小的語言特定的字體，以及Monica 的字體樣式匹配器用來解決由于兩種字體之間的大小差異，最大限度地減少了布局上的震動的問題。

交付優化

你是否異步加載 ？

當用戶請求頁面時，瀏覽器獲取 HTML 并構造 DOM，然后獲取 CSS 并構造 CSSOM，然后通過匹配 DOM 和 CSSOM 生成一個渲染樹。如果有任何的 需要解決，瀏覽器將不會開始渲染頁面，直到 解決完畢，這樣就會延遲渲染。 作為開發人員，我們必須明確告訴瀏覽器不要等待并立即開始渲染頁面。 為腳本執行此操作的方法是使用 HTML 中的defer和async屬性。

事實證明，我們應該把defer改為async（因為 ie9 及以下不支持 async）。 另外，如上所述，限制第三方庫和腳本的影響，特別是使用社交共享按鈕和嵌入的嵌入（如地圖）。大小限制有助于防止 庫過大：如果您不小心添加了大量依賴項，該工具將通知你并拋出錯誤。 您可以使用靜態社交分享按鈕（如通過SSBG）和靜態鏈接來代替交互式地圖。

你是否懶加載了開銷很大并使用 的代碼？

如果您需要延遲加載圖片、視頻、廣告腳本、A/B 測試腳本或任何其他資源，則可以使用 API，它提供了一種方法異步觀察目標元素與 祖先元素或頂層文檔的視口。基本上，你需要創建一個新的 對象，它接收一個回調函數和一組選項。 然后我們添加一個目標來觀察。

當目標變得可見或不可見時執行回調函數，所以當它攔截視口時，可以在元素變得可見之前開始采取一些行動。 事實上，我們可以精確地控制觀察者的回調何時被調用，使用（根邊緣）和（一個數字或者一個數字數組來表示目標可見度的百分比， 瞄準）。 Garcia Anglada 發表了一個@/--in-action-簡單的教程 關于如何實際實施的方便教程。

你甚至可以通過向你的網頁添加漸進式圖片加載來將其提升到新的水平。 與 ， 和 Medium 類似，你可以首先加載低質量或模糊的圖像，然后在頁面繼續加載時，使用 Guy 提出的LQIP (Low Quality Image ) （低質量圖像占位符）技術替換它們的全部質量版本。

如果技術提高了用戶體驗，觀點就不一樣了，但它肯定會提高第一次有意義的繪畫的時間。我們甚至可以通過使用SQIP創建圖像的低質量版本作為 SVG 占位符來實現自動化。 這些占位符可以嵌入 HTML 中，因為它們自然可以用文本壓縮方法壓縮。 Dean Hume 在他的文章中描述了如何使用相交觀測器來實現這種技術。

瀏覽器支持成都如何呢？Decent，與 Chrome，火狐，Edge 和 Samsung 已經支持了。 WebKit 目前正在開發中。如果瀏覽器不支持呢？ 如果不支持交叉點觀察者，我們仍然可以@/--in-action-">延遲加載 一個或立即加載圖像。甚至還有一個library。

通常，我們會使用懶加載來處理所有代價較大的組件，如 字體，，輪播，視頻和 iframe。 你甚至可以根據網絡質量調整內容服務。網絡信息 API，特別是..（Chrome 62+）使用 RTT 和下行鏈路值來更準確地表示連接和用戶可以處理的數據。 您可以使用它來完全刪除視頻自動播放，背景圖片或 Web 字體，以便連接速度太慢。

你是否優先加載關鍵的 CSS？

為確保瀏覽器盡快開始渲染頁面，通常會收集開始渲染頁面的第一個可見部分所需的所有 CSS（稱為 “關鍵CSS” 或 “上一層CSS”）并將其內聯添加到頁面的中，從而減少往返。 由于在慢啟動階段交換包的大小有限，所以關鍵 CSS 的預算大約是 14 KB。

如果超出這個范圍，瀏覽器將需要額外往返取得更多樣式。和可以做到這一點。 你可能需要為你使用的每個模板執行此操作。 如果可能的話，考慮使用 Group 使用的條件內聯方法。

使用 HTTP/2，關鍵 CSS 可以存儲在一個單獨的 CSS 文件中，并通過服務器推送來傳遞，而不會增大 HTML 的大小。 問題在于，服務器推送是很麻煩，因為瀏覽器中存在許多問題和競爭條件。 它一直不被支持，并有一些緩存問題（參見Hooman 介紹的文章) 114 頁內容）。事實上，這種影響可能是負面的，會使網絡緩沖區膨脹，從而阻止文檔中的真實幀被傳送。 而且，由于 TCP 啟動緩慢，似乎服務器推送在熱連接上更加有效。

即使使用 HTTP/1，將關鍵 CSS 放在根目錄上的單獨文件中也是有好處的，有時甚至比緩存和內聯更為有效。 Chrome 請求這個頁面的時候會再發送一個 HTTP 連接到根目錄，從而不需要 TCP 連接來獲取這個 CSS（感謝 Philip！）

需要注意的一點是：和preload不同的是，preload可以觸發來自任何域的預加載，而你只能從你自己的域或你所授權的域中推送資源。 一旦服務器得到來自客戶端的第一個請求，就可以啟動它。 服務器將資源壓入 Push 緩存，并在連接終止時被刪除。 但是，由于可以在多個選項卡之間重復使用 HTTP/2 連接，所以推送的資源也可以被來自其他選項卡的請求聲明（感謝 Inian！）。

目前，服務器并沒有一個簡答的方法得知被推送的資源是否已經存在于用戶的緩存中，因此每個用戶的訪問都會繼續推送資源。因此，您可能需要創建一個緩存監測 HTTP/2 服務器推送機制。如果被提取，您可以嘗試從緩存中獲取它們，這樣可以避免再次推送。

但請記住，新的cache-digest規范無需手動建立這樣的 “緩存感知” 的服務器，基本上在 HTTP/2 中聲明的一個新的幀類型就可以表達該主機的內容。因此，它對于 CDN 也是特別有用的。

對于動態內容，當服務器需要一些時間來生成響應時，瀏覽器無法發出任何請求，因為它不知道頁面可能引用的任何子資源。 在這種情況下，我們可以預熱連接并增加 TCP 擁塞窗口大小，以便將來的請求可以更快地完成。 而且，所有內聯配置對于服務器推送都是較好的選擇。事實上，Inian 對HTTP/2 Push 和 HTTP Preload 進行了比較 深入的研究，內容很不錯，其中包含了您可能需要的所有細節。服務器到底是推送還是不推送呢？你可以閱讀一下 Colin Bendell 的Should I Push?。

底線：正如 Sam Saccone所說，preload有利于將資產的開始下載時間更接近初始請求， 而服務器推送是一個完整的 RTT（或更多，這取決于您的服務器反應時間 —— 如果你有一個服務器可以防止不必要的推送。

<iframe data-src="[https://www.youtube.com/embed/Cjo9iq8k-bc](https://www.youtube.com/embed/Cjo9iq8k-bc)" width="600" height="480" frameborder="0" webkitallowfullscreen="" mozallowfullscreen="" allowfullscreen=""></iframe>

你使用流響應嗎？通過流，在初始導航請求中呈現的 HTML 可以充分利用瀏覽器的流式 HTML 解析器。

你使用流響應嗎?@streams經常被遺忘和忽略，它提供了異步讀取或寫入數據塊的接口，在任何給定的時間內，只有一部分數據可能在內存中可用。 基本上，只要第一個數據塊可用，它們就允許原始請求的頁面開始處理響應，并使用針對流進行優化的解析器逐步顯示內容。

我們可以從多個來源創建一個流。例如，您可以讓服務器構建一個殼子來自于緩存，內容來自網絡的流，而不是提供一個空的 UI 外殼并讓它填充它。 正如 Jeff Posnick指出的，如果您的 web 應用程序由 CMS 提供支持的，那么服務器渲染 HTML 是通過將部分模板拼接在一起來呈現的，該模型將直接轉換為使用流式響應，而模板邏輯將從服務器復制而不是你的服務器。Jake 的The Year of Web Streams文章重點介紹了如何構建它。對于性能的提升是非常明顯的。

流式傳輸整個 HTML 響應的一個重要優點是，在初始導航請求期間呈現的 HTML 可以充分利用瀏覽器的流式 HTML 解析器。 在頁面加載之后插入到文檔中的 HTML 塊（與通過 填充的內容一樣常見）無法利用此優化。

瀏覽器支持程度如何呢?詳情請看這里Chrome 52+、Firefox 57、Safari 和 Edge 支持此 API 并且服務器已經支持所有的現代瀏覽器.

你使用Save-Data存儲數據嗎?

特別是在新興市場工作時，你可能需要考慮優化用戶選擇節省數據的體驗。Save-Data 客戶端提示請求頭允許我們和定制為成本和性能受限的用戶定制應用程序和有效載荷。 實際上，您可以將高 DPI 圖像的請求重寫為低 DPI 圖像，刪除網頁字體和花哨的特效，關閉視頻自動播放，服務器推送，甚至更改提供標記的方式。

該頭部目前僅支持 ，Android 版 Chrome 或 桌面設備上的 Data Saver 擴展。最后，你還可以使用 service worker 和 Network API 來提供基于網絡類型的低/高分辨率的圖像。

最后，為你推薦

關于本文

譯者：@Cherry

譯文：（掘金翻譯計劃）

原文：