整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
前言
這是一篇有聲音的早讀課，今天繼續(xù)第三部分的內(nèi)容，今日早讀文章由@Cherry翻譯分享。
正文從這開(kāi)始～
靜態(tài)資源優(yōu)化
你是使用 Brotli 還是 Zopfli 進(jìn)行純文本壓縮？
在 2005 年，Google 推出了Brotli，一個(gè)新的開(kāi)源無(wú)損數(shù)據(jù)壓縮格式，現(xiàn)在被所有的現(xiàn)代瀏覽器所支持。實(shí)際上，Brotli 比 Gzip 和 Deflate更有效。取決于設(shè)置信息，壓縮可能會(huì)非常慢。但是緩慢的壓縮過(guò)程會(huì)提高壓縮率，并且仍然可以快速解壓。當(dāng)然，解壓縮速度很快。
只有當(dāng)用戶通過(guò) HTTPS 訪問(wèn)網(wǎng)站時(shí)，瀏覽器才會(huì)采用。Brotli 現(xiàn)在還不能預(yù)裝在某些服務(wù)器上，而且如果不自己構(gòu)建 NGINX 和 UBUNTU 的話很難部署。不過(guò)這也并不難。實(shí)際上，一些 CDN 是支持的，甚至可以也可以通過(guò)服務(wù)器在不支持 CDN 的情況下啟用 Brotli。
在最高級(jí)別的壓縮下，Brotli 的速度會(huì)變得非常慢，以至于服務(wù)器在等待動(dòng)態(tài)壓縮資源時(shí)開(kāi)始發(fā)送響應(yīng)所花費(fèi)的時(shí)間可能會(huì)使文件大小的任何潛在收益都無(wú)效。但是，對(duì)于靜態(tài)壓縮，高壓縮比的設(shè)置比較受歡迎—— （感謝 Jeremy!）
或者，你可以考慮使用Zopfli 的壓縮算法，將數(shù)據(jù)編碼為 Deflate，Gzip 和 Zlib 格式。Zopfli 改進(jìn)的 Deflate 編碼使得任何使用 Gzip 壓縮的文件受益，因?yàn)檫@些文件大小比 用Zlib 最強(qiáng)壓縮后還要小 3％ 到 8％。問(wèn)題在于壓縮文件的時(shí)間是原來(lái)的大約 80倍。這就是為什么雖然 使用 Zopfli 是一個(gè)好主意但是變化并不大，文件都需要設(shè)計(jì)為只壓縮一次可以多次下載的。
比較好的方法是你可以繞過(guò)動(dòng)態(tài)壓縮靜態(tài)資源的成本。Brotli 和 Zopfli 都可以用于明文傳輸 —— HTML，CSS，SVG， 等。
有什么方法呢？在最高等級(jí)和 Brotli 的 1-4 級(jí)動(dòng)態(tài)壓縮 HTML 使用 Brotli+Gzip 預(yù)壓縮靜態(tài)資源。同時(shí)，檢查 Brotli 是否支持 CDN，（例如KeyCDN，CDN77，F(xiàn)astly）。確保服務(wù)器能夠使用 Brotli 或 gzip 處理內(nèi)容。如果你不能安裝或者維護(hù)服務(wù)器上的 Brotli，那么請(qǐng)使用 Zopfli。
圖像是否進(jìn)行了適當(dāng)?shù)膬?yōu)化？
盡可能通過(guò)srcset，sizes和
元素使用響應(yīng)式圖片。也可以通過(guò)
元素使用 WebP 格式的圖像（Chrom，Opera，F(xiàn)irefox soon支持），或者一個(gè) JPEG 的回調(diào)（見(jiàn) Andreas Bovens 的code snippet）或者通過(guò)使用內(nèi)容協(xié)商（使用Accept頭信息）。
Sketch 本身就支持 WebP 并且 WebP 圖像可以通過(guò)使用WebP 插件從 中導(dǎo)出。也有其他選擇可以使用，如果你使用 或者 Joomla，也有可以輕松支持 WebP 的擴(kuò)展，例如Optimus和Cache Enabler（通過(guò)Cody ）
你可以仍然使用client hints，但仍需要獲得一些瀏覽器支持。沒(méi)有足夠的資源支持響應(yīng)式圖片？使用斷點(diǎn)發(fā)生器或者類似這樣的服務(wù)自動(dòng)優(yōu)化圖片。同樣，在許多情況下，只使用srcset和sizes會(huì)有不錯(cuò)的效果。
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 .
響應(yīng)圖像斷點(diǎn)發(fā)生器
響應(yīng)圖像斷點(diǎn)生成器自動(dòng)生成圖像和標(biāo)記生成。
將圖像優(yōu)化到下一個(gè)級(jí)別
現(xiàn)在有一個(gè)至關(guān)重要著陸頁(yè)，有一個(gè)特定的圖片的加載速度非常關(guān)鍵，確保 JPEGs 是漸進(jìn)式的并且使用Adept、mozJPEG（通過(guò)操縱掃描級(jí)來(lái)改善開(kāi)始渲染時(shí)間）或者Guetzli壓縮，谷歌新的開(kāi)源編碼器重點(diǎn)是能夠感官的性能，并借鑒 Zopfli 和 WebP。唯一的@fox/talk-the-state-of-the-web-">不足 是：處理的時(shí)間慢（每百萬(wàn)像素 CPU 一分鐘）。至于 png，我們可以使用Pingo，和svgo，對(duì)于 SVG 的處理，我們使用SVGO或SVGOMG
每一個(gè)圖像優(yōu)化的文章會(huì)說(shuō)明，但始終保持保持矢量資產(chǎn)清潔總是值得提醒的。確保清理未使用的資源，刪除不必要的元數(shù)據(jù)，并減少圖稿中的路徑點(diǎn)數(shù)量（從而減少SVG代碼）。（感謝，Jeremy！）
到目前為止，這些優(yōu)化只涵蓋了基礎(chǔ)知識(shí)。 Addy Osmani 已經(jīng)發(fā)布了一個(gè)非常詳細(xì)的基本圖像優(yōu)化指南，深入到圖像壓縮和顏色管理的細(xì)節(jié)。 例如，您可以模糊圖像中不必要的部分（通過(guò)對(duì)其應(yīng)用高斯模糊濾鏡）以減小文件大小，最終甚至可以開(kāi)始移除顏色或?qū)D像變成黑白色，以進(jìn)一步縮小圖像尺寸。 對(duì)于背景圖像， 從 導(dǎo)出的照片質(zhì)量為 0 到 10％ 也是絕對(duì)可以接受的。
那么 GIF 圖片呢？我們可以使用循環(huán)的 HTML5 視頻，而不是影響渲染性能和帶寬的重度 GIF 動(dòng)畫(huà)，而使用循環(huán)的 HTML5 視頻，會(huì)使得瀏覽器的性能很慢，而且與圖像不同的是，瀏覽器不會(huì)預(yù)先加載內(nèi)容。 至少我們可以使用Lossy GIF,或者添加有損壓縮 GIF。
好消息: 希望不久以后我們可以使用
來(lái)加載視頻, 早期的測(cè)試表明img標(biāo)簽比同等大小的 GIF 顯示的要快 20 多倍解析速度與要快 7 倍多。
還不夠好？那么，你也可以使用多種背景圖像技術(shù)提高圖像的感知性能。 記著，減少對(duì)比度和模糊不必要的細(xì)節(jié)（或消除顏色）也可以減小文件的大小。 你需要放大一個(gè)小照片而不失真？考慮使用.io
Zach 的字體加載策略綜合指南
Zach 的字體加載策略綜合指南提供了十幾種更好的網(wǎng)頁(yè)字體發(fā)送選項(xiàng)
Web字體是否優(yōu)化？
首先需要問(wèn)一個(gè)問(wèn)題，你是否能不使用UI 系統(tǒng)字體。 如果不可以，那么你有很大可能使用 Web 網(wǎng)絡(luò)字體，會(huì)包含字形和額外的功能以及用不到的加粗。 如果您使用的是開(kāi)源字體（例如，通過(guò)僅包含帶有某些特殊的重音字形的拉丁語(yǔ)），則可以只選擇部分 Web 字體來(lái)減少其文件大小。
WOFF2非常好，你可以使用 WOFF 和 OTF 作為不支持它的瀏覽器的備選。另外，從 Zach 的《字體加載策略綜合指南》（代碼片段也可以作為Web字體加載片段）中選擇一種策略，并使用服務(wù)器緩存持久地緩存字體。是不是感覺(jué)小有成就？Pixel Ambacht 有一個(gè)快速教程和案例研究，讓你的字體按順序排列。
如果你無(wú)法從你的服務(wù)器拿到字體并依賴于第三方主機(jī)，請(qǐng)確保使用字體加載事件（或?qū)Σ恢С炙臑g覽器使用Web字體加載器）FOUT 要優(yōu)于 FOIT; 立即開(kāi)始渲染文本，并異步加載字體 —— 也可以使用loadCSS。 你也可以擺脫本地安裝的操作系統(tǒng)字體，也可以使用可變的字體。
怎么才能是一個(gè)無(wú)漏洞的字體加載策略？ 從font-display開(kāi)始，然后回到 Font Loading API，然后回到 Bram Stein 的Font Face （感謝 Jeremy！）如果你有興趣從用戶的角度來(lái)衡量字體加載的性能， Andreas 探索了 使用 Font API 和 API 進(jìn)行性能跟蹤
此外，不要忘記包含font-display：描述符來(lái)提供彈性和快速的字體回退，unicode-range將大字體分解成更小的語(yǔ)言特定的字體，以及Monica 的字體樣式匹配器用來(lái)解決由于兩種字體之間的大小差異，最大限度地減少了布局上的震動(dòng)的問(wèn)題。
交付優(yōu)化
你是否異步加載 ？
當(dāng)用戶請(qǐng)求頁(yè)面時(shí)，瀏覽器獲取 HTML 并構(gòu)造 DOM，然后獲取 CSS 并構(gòu)造 CSSOM，然后通過(guò)匹配 DOM 和 CSSOM 生成一個(gè)渲染樹(shù)。如果有任何的 需要解決，瀏覽器將不會(huì)開(kāi)始渲染頁(yè)面，直到 解決完畢，這樣就會(huì)延遲渲染。 作為開(kāi)發(fā)人員，我們必須明確告訴瀏覽器不要等待并立即開(kāi)始渲染頁(yè)面。 為腳本執(zhí)行此操作的方法是使用 HTML 中的defer和async屬性。
事實(shí)證明，我們應(yīng)該把defer改為async（因?yàn)?ie9 及以下不支持 async）。 另外，如上所述，限制第三方庫(kù)和腳本的影響，特別是使用社交共享按鈕和嵌入的嵌入（如地圖）。大小限制有助于防止 庫(kù)過(guò)大：如果您不小心添加了大量依賴項(xiàng)，該工具將通知你并拋出錯(cuò)誤。 您可以使用靜態(tài)社交分享按鈕（如通過(guò)SSBG）和靜態(tài)鏈接來(lái)代替交互式地圖。
你是否懶加載了開(kāi)銷很大并使用 的代碼？
如果您需要延遲加載圖片、視頻、廣告腳本、A/B 測(cè)試腳本或任何其他資源，則可以使用 API，它提供了一種方法異步觀察目標(biāo)元素與 祖先元素或頂層文檔的視口。基本上，你需要?jiǎng)?chuàng)建一個(gè)新的 對(duì)象，它接收一個(gè)回調(diào)函數(shù)和一組選項(xiàng)。 然后我們添加一個(gè)目標(biāo)來(lái)觀察。
當(dāng)目標(biāo)變得可見(jiàn)或不可見(jiàn)時(shí)執(zhí)行回調(diào)函數(shù)，所以當(dāng)它攔截視口時(shí)，可以在元素變得可見(jiàn)之前開(kāi)始采取一些行動(dòng)。 事實(shí)上，我們可以精確地控制觀察者的回調(diào)何時(shí)被調(diào)用，使用（根邊緣）和（一個(gè)數(shù)字或者一個(gè)數(shù)字?jǐn)?shù)組來(lái)表示目標(biāo)可見(jiàn)度的百分比， 瞄準(zhǔn)）。 Garcia Anglada 發(fā)表了一個(gè)@/--in-action-簡(jiǎn)單的教程 關(guān)于如何實(shí)際實(shí)施的方便教程。
你甚至可以通過(guò)向你的網(wǎng)頁(yè)添加漸進(jìn)式圖片加載來(lái)將其提升到新的水平。 與 ， 和 Medium 類似，你可以首先加載低質(zhì)量或模糊的圖像，然后在頁(yè)面繼續(xù)加載時(shí)，使用 Guy 提出的LQIP (Low Quality Image ) （低質(zhì)量圖像占位符）技術(shù)替換它們的全部質(zhì)量版本。
如果技術(shù)提高了用戶體驗(yàn)，觀點(diǎn)就不一樣了，但它肯定會(huì)提高第一次有意義的繪畫(huà)的時(shí)間。我們甚至可以通過(guò)使用SQIP創(chuàng)建圖像的低質(zhì)量版本作為 SVG 占位符來(lái)實(shí)現(xiàn)自動(dòng)化。 這些占位符可以嵌入 HTML 中，因?yàn)樗鼈冏匀豢梢杂梦谋緣嚎s方法壓縮。 Dean Hume 在他的文章中描述了如何使用相交觀測(cè)器來(lái)實(shí)現(xiàn)這種技術(shù)。
瀏覽器支持成都如何呢？Decent，與 Chrome，火狐，Edge 和 Samsung 已經(jīng)支持了。 WebKit 目前正在開(kāi)發(fā)中。如果瀏覽器不支持呢？ 如果不支持交叉點(diǎn)觀察者，我們?nèi)匀豢梢訞/--in-action-">延遲加載 一個(gè)或立即加載圖像。甚至還有一個(gè)library。
通常，我們會(huì)使用懶加載來(lái)處理所有代價(jià)較大的組件，如 字體，，輪播，視頻和 iframe。 你甚至可以根據(jù)網(wǎng)絡(luò)質(zhì)量調(diào)整內(nèi)容服務(wù)。網(wǎng)絡(luò)信息 API，特別是..（Chrome 62+）使用 RTT 和下行鏈路值來(lái)更準(zhǔn)確地表示連接和用戶可以處理的數(shù)據(jù)。 您可以使用它來(lái)完全刪除視頻自動(dòng)播放，背景圖片或 Web 字體，以便連接速度太慢。
你是否優(yōu)先加載關(guān)鍵的 CSS？
為確保瀏覽器盡快開(kāi)始渲染頁(yè)面，通常會(huì)收集開(kāi)始渲染頁(yè)面的第一個(gè)可見(jiàn)部分所需的所有 CSS（稱為 “關(guān)鍵CSS” 或 “上一層CSS”）并將其內(nèi)聯(lián)添加到頁(yè)面的中，從而減少往返。 由于在慢啟動(dòng)階段交換包的大小有限，所以關(guān)鍵 CSS 的預(yù)算大約是 14 KB。
如果超出這個(gè)范圍，瀏覽器將需要額外往返取得更多樣式。和可以做到這一點(diǎn)。 你可能需要為你使用的每個(gè)模板執(zhí)行此操作。 如果可能的話，考慮使用 Group 使用的條件內(nèi)聯(lián)方法。
使用 HTTP/2，關(guān)鍵 CSS 可以存儲(chǔ)在一個(gè)單獨(dú)的 CSS 文件中，并通過(guò)服務(wù)器推送來(lái)傳遞，而不會(huì)增大 HTML 的大小。 問(wèn)題在于，服務(wù)器推送是很麻煩，因?yàn)闉g覽器中存在許多問(wèn)題和競(jìng)爭(zhēng)條件。 它一直不被支持，并有一些緩存問(wèn)題（參見(jiàn)Hooman 介紹的文章) 114 頁(yè)內(nèi)容）。事實(shí)上，這種影響可能是負(fù)面的，會(huì)使網(wǎng)絡(luò)緩沖區(qū)膨脹，從而阻止文檔中的真實(shí)幀被傳送。 而且，由于 TCP 啟動(dòng)緩慢，似乎服務(wù)器推送在熱連接上更加有效。
即使使用 HTTP/1，將關(guān)鍵 CSS 放在根目錄上的單獨(dú)文件中也是有好處的，有時(shí)甚至比緩存和內(nèi)聯(lián)更為有效。 Chrome 請(qǐng)求這個(gè)頁(yè)面的時(shí)候會(huì)再發(fā)送一個(gè) HTTP 連接到根目錄，從而不需要 TCP 連接來(lái)獲取這個(gè) CSS（感謝 Philip！）
需要注意的一點(diǎn)是：和preload不同的是，preload可以觸發(fā)來(lái)自任何域的預(yù)加載，而你只能從你自己的域或你所授權(quán)的域中推送資源。 一旦服務(wù)器得到來(lái)自客戶端的第一個(gè)請(qǐng)求，就可以啟動(dòng)它。 服務(wù)器將資源壓入 Push 緩存，并在連接終止時(shí)被刪除。 但是，由于可以在多個(gè)選項(xiàng)卡之間重復(fù)使用 HTTP/2 連接，所以推送的資源也可以被來(lái)自其他選項(xiàng)卡的請(qǐng)求聲明（感謝 Inian！）。
目前，服務(wù)器并沒(méi)有一個(gè)簡(jiǎn)答的方法得知被推送的資源是否已經(jīng)存在于用戶的緩存中，因此每個(gè)用戶的訪問(wèn)都會(huì)繼續(xù)推送資源。因此，您可能需要?jiǎng)?chuàng)建一個(gè)緩存監(jiān)測(cè) HTTP/2 服務(wù)器推送機(jī)制。如果被提取，您可以嘗試從緩存中獲取它們，這樣可以避免再次推送。
但請(qǐng)記住，新的cache-digest規(guī)范無(wú)需手動(dòng)建立這樣的 “緩存感知” 的服務(wù)器，基本上在 HTTP/2 中聲明的一個(gè)新的幀類型就可以表達(dá)該主機(jī)的內(nèi)容。因此，它對(duì)于 CDN 也是特別有用的。
對(duì)于動(dòng)態(tài)內(nèi)容，當(dāng)服務(wù)器需要一些時(shí)間來(lái)生成響應(yīng)時(shí)，瀏覽器無(wú)法發(fā)出任何請(qǐng)求，因?yàn)樗恢理?yè)面可能引用的任何子資源。 在這種情況下，我們可以預(yù)熱連接并增加 TCP 擁塞窗口大小，以便將來(lái)的請(qǐng)求可以更快地完成。 而且，所有內(nèi)聯(lián)配置對(duì)于服務(wù)器推送都是較好的選擇。事實(shí)上，Inian 對(duì)HTTP/2 Push 和 HTTP Preload 進(jìn)行了比較 深入的研究，內(nèi)容很不錯(cuò)，其中包含了您可能需要的所有細(xì)節(jié)。服務(wù)器到底是推送還是不推送呢？你可以閱讀一下 Colin Bendell 的Should I Push?。
底線：正如 Sam Saccone所說(shuō)，preload有利于將資產(chǎn)的開(kāi)始下載時(shí)間更接近初始請(qǐng)求， 而服務(wù)器推送是一個(gè)完整的 RTT（或更多，這取決于您的服務(wù)器反應(yīng)時(shí)間 —— 如果你有一個(gè)服務(wù)器可以防止不必要的推送。
<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>你使用流響應(yīng)嗎？通過(guò)流，在初始導(dǎo)航請(qǐng)求中呈現(xiàn)的 HTML 可以充分利用瀏覽器的流式 HTML 解析器。
你使用流響應(yīng)嗎?@streams經(jīng)常被遺忘和忽略，它提供了異步讀取或?qū)懭霐?shù)據(jù)塊的接口，在任何給定的時(shí)間內(nèi)，只有一部分?jǐn)?shù)據(jù)可能在內(nèi)存中可用。 基本上，只要第一個(gè)數(shù)據(jù)塊可用，它們就允許原始請(qǐng)求的頁(yè)面開(kāi)始處理響應(yīng)，并使用針對(duì)流進(jìn)行優(yōu)化的解析器逐步顯示內(nèi)容。
我們可以從多個(gè)來(lái)源創(chuàng)建一個(gè)流。例如，您可以讓服務(wù)器構(gòu)建一個(gè)殼子來(lái)自于緩存，內(nèi)容來(lái)自網(wǎng)絡(luò)的流，而不是提供一個(gè)空的 UI 外殼并讓它填充它。 正如 Jeff Posnick指出的，如果您的 web 應(yīng)用程序由 CMS 提供支持的，那么服務(wù)器渲染 HTML 是通過(guò)將部分模板拼接在一起來(lái)呈現(xiàn)的，該模型將直接轉(zhuǎn)換為使用流式響應(yīng)，而模板邏輯將從服務(wù)器復(fù)制而不是你的服務(wù)器。Jake 的The Year of Web Streams文章重點(diǎn)介紹了如何構(gòu)建它。對(duì)于性能的提升是非常明顯的。
流式傳輸整個(gè) HTML 響應(yīng)的一個(gè)重要優(yōu)點(diǎn)是，在初始導(dǎo)航請(qǐng)求期間呈現(xiàn)的 HTML 可以充分利用瀏覽器的流式 HTML 解析器。 在頁(yè)面加載之后插入到文檔中的 HTML 塊（與通過(guò) 填充的內(nèi)容一樣常見(jiàn)）無(wú)法利用此優(yōu)化。
瀏覽器支持程度如何呢?詳情請(qǐng)看這里Chrome 52+、Firefox 57、Safari 和 Edge 支持此 API 并且服務(wù)器已經(jīng)支持所有的現(xiàn)代瀏覽器.
你使用Save-Data存儲(chǔ)數(shù)據(jù)嗎?
特別是在新興市場(chǎng)工作時(shí)，你可能需要考慮優(yōu)化用戶選擇節(jié)省數(shù)據(jù)的體驗(yàn)。Save-Data 客戶端提示請(qǐng)求頭允許我們和定制為成本和性能受限的用戶定制應(yīng)用程序和有效載荷。 實(shí)際上，您可以將高 DPI 圖像的請(qǐng)求重寫(xiě)為低 DPI 圖像，刪除網(wǎng)頁(yè)字體和花哨的特效，關(guān)閉視頻自動(dòng)播放，服務(wù)器推送，甚至更改提供標(biāo)記的方式。
該頭部目前僅支持 ，Android 版 Chrome 或 桌面設(shè)備上的 Data Saver 擴(kuò)展。最后，你還可以使用 service worker 和 Network API 來(lái)提供基于網(wǎng)絡(luò)類型的低/高分辨率的圖像。
最后，為你推薦
關(guān)于本文
譯者：@Cherry
譯文：（掘金翻譯計(jì)劃）
原文：
*請(qǐng)認(rèn)真填寫(xiě)需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
