輕鬆實現 Web 性能優化

原文做者：Addy Osmani

譯者：UC 國際研發 Jothy

寫在最前：歡迎你來到「UC國際技術」公衆號，咱們將爲你們提供與客戶端、服務端、算法、測試、數據、前端等相關的高質量技術文章，不限於原創與翻譯。

這是一篇關於性能優化的文章，是一篇很是值得你閱讀的文章，文章的內容很是豐富，大概你花5-10分鐘閱讀。

在過去的一年裏，咱們忙於試圖弄清楚如何讓網絡更快、更高效。所以就有了咱們但願在本文中與你分享的新工具，方法和庫。在第一部分中，咱們將向你展現咱們在開發 The Oodles Theater App 時使用的一些優化技術。在第二部分中，咱們將討論咱們的預測加載實驗和新的 Guess.js 計劃。

Tip：你能夠在 Youtube 觀看視頻 https://www.youtube.com/watch?v=Mv-l3-tJgGk

性能的須要

互聯網每一年都在變得愈來愈重。若是咱們檢查網頁的狀態，咱們能夠看到一箇中等大小的移動端頁面大約爲 1.5MB，其中大部分是 JavaScript 和圖片。

網站規模不斷擴大，加上其餘因素，如網絡延遲，CPU 限制，渲染阻塞模式或多餘的第三方代碼，都會致使複雜的性能難題。

大多數用戶把速度當成用戶體驗須要層次理論（User Experience Hierarchy of Needs，見下圖）的最高層。這並不太使人驚訝，由於在頁面加載完成以前，你有不少事情都作不了。你沒法從頁面中獲取價值，你沒法欣賞它的美學。

圖1. 速度對用戶有多重要？

咱們知道性能對用戶很重要，但它又像是一個尋找從哪裏開始優化的祕密。幸虧有一些工具能夠幫助咱們。

Lighthouse ——性能工做流的基礎

Lighthouse 屬於 Chrome DevTools 的一部分，它容許你對你的網站進行審查，並提供優化建議。

咱們最近推出了一系列新的性能審查（https://developers.google.com/web/updates/2018/05/lighthouse），它們在平常開發工做流中很是有用。

圖2. 新 Lighthouse 審查

讓咱們來探索一下如何在一個實際的例子中利用它們：Oodles Theatre App。這是一個小型的 demo web app，你能夠在裏面試用咱們最愛的一些交互式 Google Doodle，甚至玩一兩局遊戲。

在構建 App 時，咱們但願確保它儘量高效。優化的起點是 Lighthouse 報告。

圖3. Oodles App 的 Lighthouse 報告

咱們的 App 在 Lighthouse 報告中的初始表現很是糟糕。使用 3G 網絡時，用戶須要等待 15 秒才能得到第一個有意義的（頁面）繪製，或者（說）讓 App 可交互。 Lighthouse 高亮標識了咱們網站的一堆問題，而 23 分的總體性能得分充分反映了這一點。

頁面大小約3.4MB - 咱們迫切須要減減肥了。

咱們的首次性能挑戰由此開始：找到能夠輕鬆刪除的內容，同時不影響總體體驗。

性能優化機會

1. 刪除沒必要要的資源

有一些顯而易見的東西能夠安全刪除掉：空白和註釋。

圖4. Minify和壓縮 JavaScript 和 CSS

Lighthouse 在 Unminified CSS & JavaScript 審查中突出了這個機會。程序使用 webpack 進行構建，所以爲了縮小體積，咱們選擇了 Uglify JS 插件。

縮小體積是一項常見任務，所以你得找到適合你的構建過程的現成解決方案。

該項目中另外一個有用的審查是啓用文本壓縮。咱們沒有理由發送未壓縮的文件，並且如今大多數 CDN 都開箱即用地支持這個。

咱們使用 Firebase Hosting 來託管咱們的代碼，Firebase 默認啓用 gzip，所以，經過在合理的 CDN 上託管咱們的代碼，咱們免費得到了這個功能。

雖然 gzip 是一種很是流行的壓縮方式，但其餘機制如 Zopfli 和 Brotli 也愈來愈吸引人。 Brotli 受大多數瀏覽器支持，你能夠在將資源發送到服務器以前使用二進制方式對其進行預壓縮。

2. 使用有效的緩存策略

咱們的下一步是確保在沒必要要的狀況下咱們不會重複發送資源。

Lighthouse 中的低效緩存策略審查使咱們注意到，咱們能夠經過優化緩存策略實現這一目標。經過在咱們的服務器中設置 max-age 過時頭，咱們能夠確保在重複訪問狀況下，用戶能夠重用他們以前下載的資源。

理想狀況下，你應該在儘量長的時間內儘量安全地緩存儘量多的資源，並提供驗證令牌，以便高效地從新驗證已更新的資源。

3. 刪除未使用的代碼

到目前爲止，咱們刪除了非必要下載文件的顯要部分，那不太明顯的部分呢？例如，未使用的代碼。

圖5.檢查代碼覆蓋率

有時咱們會在 App 中包含沒必要要的代碼。這種狀況尤爲是在你的 App 開發了很長一段時間，你的團隊或你的依賴項發生了變化，有時「孤兒庫」被遺忘的狀況下。這正是咱們經歷過的事情。

最初咱們使用 Material Components 庫來快速構建咱們的 App 原型。隨着時間的推移，咱們轉向了更加定製化的外觀，咱們徹底忘記了這個庫。幸運的是，代碼覆蓋率檢查幫助咱們在 bundle 中從新發現了它。

你能夠在 DevTools 中檢查代碼覆蓋率狀態，包括運行時和應用加載時間。你能夠在底部截圖中看到兩個大的紅色橫條 - 咱們有超過 95％ 的 CSS 是未使用的，還有一大堆 JavaScript。

Lighthouse 在未使用的 CSS 規則審查中也提到了這個問題。它表示咱們可能節省超過 400kb。因此咱們回到代碼裏，刪除了該庫的 JavaScript 和 CSS 部分。

圖6. 棄用 MVC 適配器，咱們的樣式降低到了 10KB！

這使咱們的 CSS bundle 減小了 20倍，這對於一個很小的，兩行長的 commit 來講太讚了。

固然，它使咱們的性能得分上升，並且可交互時間也獲得優化。

可是，經過這樣的更改，僅僅檢查指標和分數是不夠的。刪除實際代碼毫不是零風險的，所以你應該始終注意發掘潛在的風險。

咱們的代碼在 95％ 的代碼中未被使用 - 在某處仍有 5％ 在使用。顯然咱們的某個組件仍在使用該庫中的樣式 - 塗鴉滑塊中的小箭頭。由於它過小了，咱們能夠手動將這些樣式合併到按鈕中。

圖7.一個組件仍在使用已刪除的庫

所以，若是您刪除代碼，請確保您擁有適當的測試工做流，以幫助您防範潛在的可見的風險迴歸。

4. 避免巨大的網絡負載

咱們知道大量資源可能會減慢網頁加載速度。他們可能會消耗用戶的錢，他們可能會對他們的數據計劃產生重大影響，所以注意這一點很是重要。

經過使用巨大的網絡負載審查，Lighthouse 可以檢測到咱們的某些網絡負載存在的問題。

圖8.檢測巨大的網絡負載

從這裏能夠看到，咱們有超過 3mb 的代碼被傳輸 - 這不是通常的多，特別是在移動設備上。

在這個列表的最頂部，Lighthouse 告訴咱們有一個2mb大小的未壓縮JavaScript vendor 包。這也是 webpack 高亮顯示的問題。

俗話說：最快的請求是還沒發出的請求。

理想狀況下，你應該衡量你發送給用戶的每一項資源的價值，衡量這些資源的性能，並根據初始經驗判斷它是否真的值得被傳輸。由於有時這些資源能夠在空閒時間延遲發送，懶加載或處理。

在咱們的例子中，由於咱們處理的是大量的 JavaScript 包，因此咱們很幸運，由於 JavaScript 社區擁有豐富的 JavaScript 包審查工具。

圖9. JavaScript 包審查

咱們開始使用 webpack bundle analyzer，它告訴咱們，咱們有一個名爲 unicode 的依賴項，它是 1.6mb 的已解析 JavaScript，很是大的文件。

而後咱們轉到咱們的編輯器，並使用爲可視化代碼準備的 Import Cost 插件，透過它咱們可以看到咱們導入的每一個模塊的成本。它能幫助咱們發現哪一個組件包含引用此模塊的代碼。

而後咱們切換到另外一個工具 BundlePhobia。這個工具容許你輸入任何 NPM 包的名稱，並實際看到它通過壓縮和 gzip 後的預計大小。咱們找到了一個很好的替代方案，咱們使用的 slug 模塊只有 2.2kb，因此咱們用了它。

這對咱們的性能產生了很大的影響。在此更改和發現其餘減小 JavaScript 包大小的機會之間，咱們節省了 2.1mb 的代碼。

綜合考慮到這些 bundle 的壓縮和縮小尺寸，咱們整體上看到了 65％ 的提高。咱們發現這確實值得去作。

所以，總的來講，嘗試去消除你的網站和應用中沒必要要的下載吧。對資源進行清點並衡量其性能影響，這可能會帶來面目一新的改變，所以請確保按期審查你的資源。

經過代碼拆分下降 JavaScript 啓動時間

雖然大型網絡負載可能對咱們的應用程序產生重大影響，但還有另外一樣東西也能產生巨大影響——那就是 JavaScript。

JavaScript 是你最昂貴的資產。在移動設備上，若是您發送了大量的 JavaScript，它可能會延遲用戶與界面組件交互的時間。這意味着他們點擊 UI 的操做多是毫無心義的。所以，瞭解 JavaScript 成本爲什麼如此之高顯得極爲重要。

這是瀏覽器處理 JavaScript 的方式。

圖10. JavaScript 處理

咱們首先必須下載該腳本，咱們的 JavaScript 引擎須要解析該代碼，編譯並執行它。

如今，這些（處理）階段在臺式機或筆記本等高端設備、甚至是高端手機並不用花很長時間。但在中等配置手機上，這個過程可能要花上 5 到 10 倍的時間。這正是延遲交互的緣由，所以把它降下來很是關鍵。

爲了幫你發現 App 的這些問題，咱們向 Lighthouse 引入了一個新的 JavaScript 啓動時間審查工具。

圖11. JavaScript 啓動時間審查

在 Oodle App 的例子中，它顯示咱們花了 1.8 秒來啓動 JavaScript。而這段時間所作的，是將全部路由和組件靜態導入到一整個 JavaScript 包中。

解決此問題的方法之一是使用代碼分割。

代碼分割的概念是，不要一次把一整個披薩的 JavaScript 給到你的用戶，不妨一次給只他們所須要的一片？

代碼分割能夠應用於路由級別或組件級別。它適用於 React 和 React Loadable，Vue.js，Angular，Polymer，Preact 以及其餘多個庫。

咱們將代碼分割合併到咱們的應用中，從靜態導入切換爲動態導入，實現了咱們所需的異步懶加載代碼。

圖13.使用動態導入的代碼分割

這種影響既縮小了 bundle 的大小，也節省了咱們的 JavaScript 啓動時間。它把時間降到了 0.78 秒，爲應用提速 56％。

一般，若是你正在構建你的 JavaScript 體驗，請務必作到僅向用戶發送他們所須要的代碼。

利用代碼分割等概念，發掘 tree shaking 等思路，查看 webpack-libs-optimizations 倉庫，瞭解在使用 webpack 時如何減少庫的體積的方法。

優化圖片

圖片加載性能的笑話

在 Oodle App 中，咱們使用了大量圖片。不幸的是，Lighthouse 對它的熱情遠遠低於咱們。事實上，咱們在全部三個與圖片相關的審查上都掛掉了。

咱們忘了對圖片進行優化，沒有正確處理好它們的體積，咱們也本可使用其餘圖片格式來優化。

圖14. Lighthouse 圖像審查

咱們開始對圖片進行優化。

針對一次性的優化，你可使用 ImageOptim 或 XNConvert 等可視化工具。

更自動化的方法是使用像 imagemin 這樣的庫，在構建過程當中優化圖片。

這樣，你就能夠確保未來添加的圖片自動獲得優化。一些 CDN，例如 Akamai 或 Cloudinary 或 Fastly 等第三方解決方案，也提供了全面的圖像優化解決方案。因此你也能夠放心地把圖片託管到這些服務上。

若是因爲成本或延遲問題而不想這麼幹，Thumbor 或 Imageflow 等項目也提供自託管替代方案。

圖15.優化先後

咱們的背景 PNG 圖片在 webpack 中被標記爲大，事實的確如此。在將調整到 viewport 大小，並經過 ImageOptim 優化後，咱們把體積降到了 100kb，還能夠接受。

咱們對網站上的圖片重複執行了此操做，由此顯着下降了總體頁面的體積。

爲動畫內容使用正確的格式

GIF 的代價極其昂貴。使人驚訝的是，GIF 格式從未打算成爲動畫平臺。所以，切換到更合適的視頻格式能夠大大節省文件大小。

在 Oodle App 中，咱們在主頁上使用了 GIF 做爲介紹動畫。根據 Lighthouse 的說法，切換到更高效的視頻格式能節省超過 7mb。咱們的動畫就差很少 7.3mb 了，這對於任何網站來講都太大了，因此咱們把它變成了一個包含兩個源文件的視頻元素——mp4 和 WebM，以兼容更多瀏覽器。

圖16.用視頻替換動畫 GIF

咱們使用 FFmpeg 工具將動畫 GIF 轉換爲 mp4 文件。 WebM 格式則節免得更多——ImageOptim API 能夠作這種轉換。

這種轉換爲咱們節省了超過 80％ 的整體積。這讓咱們降到了 1mb 左右。

儘管如此，1mb 仍算是網絡傳輸中的大型資源，特別是對於帶寬受限的用戶而言。幸虧，咱們可使用 Effective Type API 來檢測到它們處於慢網絡，而後給它們提供體積更小的 JPEG。

此接口使用高效的往返時間和下降值來判斷用戶所用的網絡類型。它只返回一個字符串，像 slow 2G，2G，3G 或 4G。所以，根據此值，對 4G 如下的用戶，咱們使用圖像替換掉了視頻元素。

它確實犧牲了一點點用戶體驗中，但至少在慢網絡中，該站點也是可用的了。

懶加載屏幕外圖片

輪播動畫，滑塊或很是長的頁面一般會加載圖像，即便用戶並不能當即在頁面上看到它們。

Lighthouse 將在屏幕外圖像審覈中標記此行爲，您也能夠在 DevTools 的網絡面板中自行查看。若是你看到不少圖像傳入，但它們之中只有少數可見，則意味着你能夠考慮延遲加載它們。

瀏覽器自己尚不支持懶加載，所以咱們必須使用 JavaScript 來添加此功能。咱們使用 Lazysizes 庫爲咱們的 Oodle 封面添加懶加載行爲。

Lazysizes 很是智能，由於它不只能夠跟蹤元素的可見性變化，還能夠主動預獲取視圖附近的元素，以得到最佳的用戶體驗。它還提供了 IntersectionObserver 的可選集成，爲你帶來很是高效的可見性查找。

在此更改後，咱們的圖片將按需提取。若是你想深刻了解該主題，請查看 images.guide - 一個很是方便和全面的資源。

images.guide: https://images.guide/

幫助瀏覽器儘早提供關鍵資源

並不是每一個經過網絡發送到瀏覽器的字節都具備同等的重要性，瀏覽器知道這一點。許多瀏覽器都有試探性方法來決定他們應該首先獲取什麼。因此有時它們會在獲取圖片或腳本以前獲取 CSS。

可能有用的東西是做爲頁面做者的咱們，能夠告訴瀏覽器對咱們來講真正重要的是什麼。值得慶幸的是，在過去幾年中，瀏覽器已經添加了許多功能來幫助咱們實現這一功能，例如：使用 link rel=preconnect，preload 或 prefetch 實現資源提示。

這些 Web 平臺的功能能夠幫助瀏覽器在正確的時間獲取正確的資源，而且它們會比使用腳本完成的一些自定義加載，基於邏輯的方法更有效。

讓咱們看看 Lighthouse 如何實際指導咱們有效地使用這些功能。

Lighthouse 讓咱們作的第一件事就是避免屢次與任一源的昂貴往返請求。

圖17.避免屢次與任一源的昂貴往返請求

對於 Oodle App，咱們實際上重度使用 Google 字體。每當在頁面中使用 Google Fonts 樣式表時，它最多會鏈接兩個子域。Lighthouse 告訴咱們，若是咱們可以預熱這種鏈接，咱們能夠在初次鏈接時節省最多 300 毫秒。

利用 link rel preconnect，咱們能夠有效地屏蔽鏈接延遲。

特別是對像 Google Fonts 這種把字體 CSS 託管在 googleapis.com 上，以及把字體資源託管在 Gstatic 上的資源，這可能會產生很大的影響。因此咱們應用了這個優化，優化了幾百毫秒。

Lighthouse 建議的下一件事是預先加載關鍵請求。

圖18.預加載關鍵請求

<link rel=preload> 很是強大，它通知瀏覽器當前導航中須要該資源，而且嘗試讓瀏覽器儘快獲取它。

如今，Lighthouse 告訴咱們，咱們應該預加載咱們的關鍵網絡字體資源，由於咱們正在加載兩種網絡字體。

預加載網絡字體以下所示 - 指定rel = preload，將字體類型傳入 as 字段，而後指定要加載的字體類型，例如 woff2。

這對你的頁面產生的影響將很是明顯。

圖19.預加載資源的影響

一般，若是不使用 link rel preload，若是 Web 字體剛好對你的頁面相當重要，那麼瀏覽器必須作的是首先獲取 HTML，解析 CSS，以及接下來的其餘資源，最後纔去獲取你的網絡字體。

而使用了 link rel preload，一旦瀏覽器解析了 HTML，它就能夠提前開始獲取這些網絡字體。對咱們的 App 來講，這能夠減小咱們使用 Web 字體渲染文本所花費的時間。

如今，若是你想嘗試使用 Google Fonts 預加載字體，那還沒那麼簡單，咱們還有一個問題。

咱們在樣式表中的字體中指定的 Google Font URL 剛好是 Google 字體團隊按期更新的內容。這些 URL 可能會過時或按期更新，所以，若是你但願徹底控制字體加載體驗，咱們建議你自行託管你的 Web 字體。這也很棒，由於它讓你能夠訪問 link rel preload 等內容。

在咱們的例子中，咱們發現 Google Web Fonts Helper 工具在幫助咱們離線某些網絡字體並在本地設置它們時很是有用，所以請了解下該工具。

不管你是將 Web 字體仍是 JavaScript 做爲關鍵資源的一部分，都應使瀏覽器儘快提供該關鍵資源。

實驗：優先級提示

今天還有一個特別的東西要與你分享。除了資源提示和預加載等功能外，咱們還在開發一種全新的實驗性瀏覽器功能，咱們稱之爲優先級提示。

圖20.優先級提示

這項新功能容許你提示瀏覽器某資源的重要性。它暴露了一個新屬性 - importance - 可取值 low，high 或 auto。

這使咱們能下降不過重要資源的優先級，例如非關鍵樣式，圖片或 fetch API 調用，以減小流量搶佔。咱們還能夠提高更重要事物的優先級，例如咱們的英雄圖片。

對於咱們的 Oodle App，這實際上給了咱們一個能夠優化的機會。

圖21.設置初識可見內容的優先級

在咱們對圖像設置懶加載以前，瀏覽器的作法是，咱們將這個圖片輪播與全部塗鴉一塊兒使用，而瀏覽器會在輪播最開始時以高優先級獲取全部圖像。不幸的是，輪播中間的圖像對用戶來講是最重要的。因此咱們的作法是，將背景圖像的重要性設置得很是低，前景圖像的重要性設置得很是高，這在慢速 3G 時能帶來 2 秒的提速，咱們也可以快速地獲取和渲染這些圖像。這是一個很棒的體驗。

咱們但願在幾周內將這個功能帶到 Canary，還請密切關注。

制定一個網絡字體加載策略

排版是良好設計的基礎，若是你使用的是網絡字體，理想狀況下你並不想阻塞文本的渲染，並且你絕對不想顯示不可見的文本。

咱們在 Lighthouse 中強調了這一點，在 avoid invisible text while web fonts are loading 審查中能夠找到。

圖22.在加載網絡字體時避免使用不可見文本

若是你使用 font face 代碼塊加載網絡字體，而且該字體須要較長時間才能獲取到，你就是在讓瀏覽器決定該作什麼。有些瀏覽器會在退回到系統字體以前等待最多三秒鐘，而且一旦字體下載完畢，瀏覽器最終又會切換到字體。

咱們試圖避免這種不可見文本，在這種狀況下，若是網絡字體加載花了太長時間，咱們將沒法看到本週的經典塗鴉。幸虧，經過一個名爲 font-display 的新功能，你實際上能夠更好地控制這個過程。

Font display 可幫助你根據交換所需的時間來決定網絡字體的渲染或退階方式。

在這種狀況下，咱們使用字體顯示交換。交換爲字體提供零秒塊週期和無限交換週期。這意味着若是字體加載須要一段時間，瀏覽器會當即使用備用字體繪製文本。一旦字體可用，它就會轉換它。

對咱們的 App 來講，這功能很是棒，它容許咱們很早就顯示一些有意義的文本，並在網絡字體準備好後立刻轉換過去。

圖23.字體顯示結果

通常狀況下，若是你碰巧在使用網絡字體，且它佔據了網絡的很大一部分，那麼你得有一個很好的網絡字體加載策略。

有許多 Web 平臺能幫你優化字體的加載體驗，你還能夠查看 Zach Leatherman 的 Web Font Recipes 倉庫，由於它實在太棒了。

Web Font Recipes repo: https://www.zachleat.com/web/recipes/

減小渲染阻塞腳本

咱們的應用中還有其餘部分能夠在下載鏈中提早推送，以便提早提供一些基本的用戶體驗。

在 Lighthouse 時間軸上，你能夠看到在加載全部資源的前幾秒內，用戶沒法看到任何內容。

圖24.減小阻塞式渲染樣式表的機會

下載和處理外部樣式表阻塞了咱們的渲染過程的進展。

咱們能夠嘗試經過先提供一些樣式來優化咱們的關鍵渲染路徑。

若是咱們提取負責初始渲染的樣式並在 HTML 中內聯它們，瀏覽器能夠直接渲染它們而無需等待外部樣式表。

在咱們的例子中，咱們使用名爲 Critical 的 NPM 模塊在構建步驟中內聯 index.html 中的關鍵內容。

雖然這個模塊爲咱們完成了大部分繁重工做，但要讓它在不一樣路線上順利運行仍然有點棘手。

若是你不當心或者你的站點結構很是複雜，若你沒有從一開始就規劃 app shell 架構，那麼引入這種模式可能很是困難。

這就是爲何在早期就考慮性能因素很是重要的緣由。若是你從一開始就沒有設計性能，那麼以後再實施就可能遇到問題。

最終咱們的風險獲得了回報，咱們設法讓它發揮做用，App開始更早地提供內容，顯着改善了咱們的第一個有意義的繪畫時間。

結果

這是咱們應用在網站上的一長串性能優化。咱們來看看結果。結果代表了咱們的應用在優化以前和以後，在中等設備、3G 網絡上是如何加載的。

Lighthouse 表現得分從 23 上升到 91。在速度方面取得了至關不錯的進步。全部這些變化都是由咱們不斷檢查並遵循 Lighthouse 報告推進的。若是你想了解咱們如何在技術上實施全部改進，請隨時查看咱們的倉庫(http://github.com/google/oodle-demo)，尤爲是 PR。

預測性能 - 數據驅動的用戶體驗

咱們相信機器學習在將來的許多領域表明着使人興奮的機會。咱們但願未來能引起更多實驗的一個想法是，真實數據能夠真正指導咱們正在建立的用戶體驗。

今天，咱們對用戶可能想要或須要的內容作出了不少武斷的決定，由此判斷什麼資源該預先提取，預加載或預先緩存。若是咱們猜對了，咱們能夠優先考慮少許資源，但很難將其擴展到整個網站。

咱們實際上有數據能夠更好地爲咱們的優化提供支持。使用 Google Analytics reporting API，咱們能夠查看下一個首頁以及咱們網站上任意網址的退出百分比，從而得出咱們應優先考慮哪些資源的結論。

若是咱們將其與良好的機率模型相結合，咱們就會經過積極預獲取內容來避免浪費用戶的數據。咱們能夠利用 Google Analytics 數據，並使用機器學習和馬爾可夫鏈或神經網絡等模型來實現此類模型。

圖25.用於Web應用程序的數據驅動捆綁

爲了促進這個實驗，咱們很高興地宣佈一個叫作 Guess.js 的新計劃。

圖26. Guess.js

Guess.js 是一個專一於數據驅動Web用戶體驗的項目。咱們但願它能激發人們探索使用數據來改善網絡性能並超越它。它是徹底開源的，能夠 GitHub 上獲取。這是由 Minko Gechev，Gatsby 的 Kyle Matthews，Katie Hempenius 和其餘一些人與開源社區合做創建的。

總結

分數和指標有助於提升 Web 的速度，但它們只是手段，而不是目標自己。

咱們都經歷過慢網速頁面加載，但咱們如今有機會爲用戶提供更加愉悅的快速加載體驗。

性能提高是一個旅程。許多小的變化能夠帶來巨大的收益。經過使用正確的優化工具並密切關注 Lighthouse 報告，你能夠爲用戶提供更好、更具包容性的體驗。

特別感謝：Ward Peeters，Minko Gechev，Kyle Mathews，Katie Hempenius，Dom Farolino，Yoav Weiss，Susie Lu，Yusuke Utsunomiya，Tom Ankers，Lighthouse 和 Google Doodles。

英文原文：

https://developers.google.com/web/updates/2018/08/web-performance-made-easy

「UC國際技術」致力於與你共享高質量的技術文章

歡迎關注咱們的公衆號、將文章分享給你的好友