輕鬆提升網站效能 - 2018 年 Google I/O 大會版本

在 2018 年 Google IO 大會上,我們介紹了一系列工具、程式庫和最佳化技巧,協助您輕鬆提升網站效能。我們將透過 Oodles Theater 應用程式說明這些概念,並討論我們在預測載入和新版 Guess.js 計畫方面的實驗。

Ewa Gasperowicz

過去一年,我們一直忙於研究如何加快網站速度並提升效能。因此,我們在本文中提供新的工具、方法和程式庫。在第一部分,我們會向您展示在開發 The Oodles Theater 應用程式時,我們實際使用的部分最佳化技巧。在第二部分,我們會討論我們在預測載入和新的 Guess.js 計畫中進行的實驗。

效能需求

網際網路的負擔逐年增加,查看網路狀態,我們可以發現行動版網頁的平均大小約為 1.5MB,其中大部分是 JavaScript 和圖片。

網站大小日益增加,加上網路延遲、CPU 限制、轉譯阻斷模式或多餘的第三方程式碼等其他因素,都會導致複雜的效能問題。

大多數使用者都認為速度是使用者體驗層級中最重要的需求。這並非令人意外,因為網頁載入完成前,您無法執行太多操作。您無法從頁面中獲得價值,也無法欣賞其美學。

UX 階層金字塔
圖 1. 速度對使用者有多重要?(Speed Matters, Vol. 3)

我們知道使用者重視效能,但也知道要從何處著手進行最佳化,有時就像是個謎。幸運的是,我們有工具可以協助你完成這項工作。

Lighthouse:效能工作流程的基礎

Lighthouse 是 Chrome 開發人員工具的一部分,可讓您稽核網站,並提供改善網站的提示。

我們最近推出了一系列新的效能稽核,這些稽核工具在日常開發工作流程中非常實用。

新的 Lighthouse 稽核
圖 2. 新的 Lighthouse 稽核

讓我們透過實際範例探索如何運用這些功能:Oodles Theater 應用程式。這是一個小型示範網頁應用程式,您可以試用我們最喜愛的互動式 Google Doodle,甚至可以玩一兩款遊戲。

在建構應用程式時,我們希望確保應用程式盡可能提供最佳效能。最佳化作業的起點是 Lighthouse 報表。

Oodles 應用程式的 Lighthouse 報表
圖 3. Oodles 應用程式的 Lighthouse 報告

根據燈塔報告,我們的應用程式初始效能相當糟糕。在 3G 網路上,使用者必須等待 15 秒才能看到第一個有意義的繪圖,或等到應用程式可供互動。Lighthouse 醒目顯示網站的許多問題,而整體表現分數 23 也正好反映了這一點。

這個網頁的大小約為 3.4MB,我們必須盡力精簡內容。

這就是我們遇到的第一個效能挑戰:找出可以輕易移除的項目,而不影響整體體驗。

效能最佳化商機

移除不必要的資源

有些明顯的項目可以安全移除,例如空格和註解。

精簡所帶來的效益
圖 4. 壓縮 JavaScript 和 CSS

Lighthouse 會在 未經壓縮的 CSS 和 JavaScript 稽核中強調這項機會。我們使用 webpack 進行建構程序,因此為了壓縮,我們只使用 Uglify JS 外掛程式

縮減是常見的工作,因此您應該可以找到適合所用建構程序的現成解決方案。

在這個範圍內,另一個實用的稽核項目是「啟用文字壓縮」。您沒有理由傳送未壓縮的檔案,而且大多數 CDN 在現今都支援這項功能。

我們使用 Firebase 代管服務代管程式碼,而 Firebase 預設會啟用 gzip 壓縮,因此只要在合理的 CDN 上代管程式碼,就能免費獲得這項功能。

雖然 gzip 是相當熱門的壓縮方式,但ZopfliBrotli 等其他機制也開始受到重視。Brotli 在大多數瀏覽器中皆可使用,您可以使用二進位檔,在將資產傳送至伺服器前先行壓縮。

使用高效率的快取政策

我們接下來要做的是,確保不會在不需要時重複傳送資源。

Lighthouse 中的「不具效率的快取政策」稽核作業讓我們注意到,為了達成上述目標,我們可以改善快取策略。在伺服器中設定 max-age 到期標頭,可確保使用者在重複造訪時,可以重複使用先前下載的資源。

理想情況下,您應盡可能安全地快取最多資源,並在最長的時間內提供驗證權杖,以便有效重新驗證已更新的資源。

移除未使用的程式碼

到目前為止,我們已移除不必要下載作業的明顯部分,但不明顯的部分呢?例如未使用的程式碼。

開發人員工具中的程式碼涵蓋率
圖 5. 檢查程式碼涵蓋率

有時我們會在應用程式程式碼中加入不必要的內容。特別是在您長時間處理應用程式、團隊或依附元件發生變更,以及有時候遺留孤立的程式庫時,就會發生這種情況。我們也遇到了同樣的情況。

一開始,我們使用 Material 元件程式庫快速製作應用程式原型。隨著時間推移,我們改用更自訂的外觀和風格,因此完全忘了那個程式庫。幸運的是,程式碼涵蓋率檢查功能協助我們在套件中重新找出這項問題。

您可以在 DevTools 中查看程式碼涵蓋率統計資料,包括應用程式的執行階段和載入時間。您可以在底部的螢幕截圖中看到兩條大紅條紋,我們有超過 95% 的 CSS 未使用,以及大量的 JavaScript。

Lighthouse 在未使用的 CSS 規則稽核中也發現這個問題。顯示可節省超過 400kb。因此,我們回到程式碼,並移除了該程式庫的 JavaScript 和 CSS 部分。

如果我們放棄 MVC 轉接器,我們的樣式會降至 10KB
圖 6. 如果我們捨棄 MVC 轉接程式,我們的樣式會降至 10KB!

這讓 CSS 套件縮小了 20 倍,對於只有兩行程式碼的小型提交來說,這已相當不錯。

當然,這也讓我們的成效分數提高,互動時間也大幅改善。

不過,在這種情況下,光是檢查指標和分數是不夠的。移除實際程式碼絕對有風險,因此您應隨時留意潛在的回歸情形。

我們的程式碼在 95% 的情況下都未使用,但仍有 5% 的情況會使用。其中一個元件仍使用該程式庫的樣式,也就是塗鴉滑桿中的小箭頭。不過,由於它很小,我們可以手動將這些樣式重新整合到按鈕中。

按鈕因缺少程式庫而無法正常運作
圖 7. 一個元件仍在使用已移除的程式庫

因此,如果您移除程式碼,請務必採用適當的測試工作流程,以防範潛在的視覺回歸現象。

避免耗用大量網路酬載

我們知道大型資源可能會導致網頁載入速度變慢。這類內容可能會讓使用者付費,並對他們的資料方案造成重大影響,因此請務必留意這點。

Lighthouse 使用龐大的網路酬載稽核功能,偵測到我們在某些網路酬載上遇到問題。

偵測大量網路酬載
圖 8. 偵測大量網路酬載

我們發現,有超過 3 MB 的程式碼會傳送至下游,這會造成相當大的負擔,特別是在行動裝置上。

在清單最上方,Lighthouse 醒目顯示我們有一個 JavaScript 供應商套件,其未壓縮的程式碼為 2 MB。這也是 webpack 強調的問題。

如同俗諺所言:「最快的請求,就是不提出要求。」

理想情況下,您應該評估向使用者提供的每項素材資源的價值,評估這些素材資源的效能,並判斷是否值得將初始體驗提供給使用者。因為有時這些素材資源可以延後載入、延後載入,或在閒置時間處理。

在我們的例子中,我們處理了許多 JavaScript 套件,因此很幸運地擁有 JavaScript 社群提供的豐富 JavaScript 套件稽核工具。

JavaScript 套件稽核
圖 9. JavaScript 套件稽核

我們一開始使用 webpack bundle analyzer,該工具告訴我們,我們包含了一個名為 unicode 的依附元件,這是 1.6 MB 的剖析 JavaScript,因此相當大。

接著,我們前往編輯器,並使用 Visual Studio Code 的 Import Cost 外掛程式,以視覺化方式呈現我們要匯入的每個模組成本。這讓我們能夠找出哪個元件包含參照此模組的程式碼。

接著,我們改用另一個工具 BundlePhobia。這項工具可讓您輸入任何 NPM 套件的名稱,並實際查看其經過精簡和壓縮的大小。我們找到了一個不錯的替代方案,可取代我們使用的 slug 模組,而且檔案大小只有 2.2kb,因此我們改用這個方案。

這對我們的成效造成重大影響。在進行這項變更及發現其他可縮減 JavaScript 套件大小的機會之間,我們節省了 2.1 MB 的程式碼。

考量到這些套件的壓縮和精簡大小,整體效能提升了 65%。我們發現這項程序確實值得採用。

因此,一般來說,請盡量避免在網站和應用程式中提供不必要的下載項目。建立素材資源清單並評估其成效影響,可以帶來巨大的差異,因此請務必定期稽核素材資源。

透過程式碼分割縮短 JavaScript 啟動時間

雖然大型網路酬載可能對應用程式造成重大影響,但 JavaScript 也是另一個可能造成重大影響的因素。

JavaScript 是最昂貴的資產。在行動裝置上,如果您傳送大量的 JavaScript 套件,可能會延遲使用者與使用者介面元件互動的時間。也就是說,使用者可以輕觸 UI,但系統不會實際執行任何有意義的動作。因此,我們必須瞭解 JavaScript 的成本為何如此高。

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

JavaScript 處理
圖 10. JavaScript 處理

我們首先必須下載該指令碼,我們有一個 JavaScript 引擎,需要剖析該程式碼,需要編譯並執行該程式碼。

在高階裝置 (例如桌上型電腦或筆記型電腦,甚至是高階手機) 上,這些階段不會耗費太多時間。但在一般手機上,這項程序可能需要五到十倍的時間才能完成。這會導致互動性延遲,因此我們必須盡量縮短這段時間。

為協助您找出應用程式中的這些問題,我們在 Lighthouse 中推出了新的 JavaScript 啟動時間稽核

JavaScript 啟動時間
圖 11. JavaScript 啟動時間稽核

以 Oodle 應用程式為例,這項工具指出 JavaScript 啟動作業耗時 1.8 秒。我們將所有路徑和元件靜態匯入至單一 JavaScript 套件。

解決這個問題的方法之一,就是使用程式碼分割。

程式碼拆分就像披薩

程式碼分割的概念是,與其讓使用者一次取得整個 Pizza 的 JavaScript,不如只在他們需要時一次提供一片?

您可以在路徑層級或元件層級套用程式碼分割。它與 React 和 React Loadable、Vue.js、Angular、Polymer、Preact 和多個其他程式庫搭配使用時,表現非常出色。

我們將程式碼分割作業納入應用程式,並從靜態匯入切換為動態匯入,讓我們能夠在需要時異步延後載入程式碼。

使用動態匯入功能分割程式碼
圖 13. 使用動態匯入功能分割程式碼

這項做法不僅縮小了套件的大小,也縮短了 JavaScript 啟動時間。這項作業只花了 0.78 秒,讓應用程式加快 56%。

一般來說,如果您要建構大量使用 JavaScript 的體驗,請務必只將必要的程式碼傳送給使用者。

善用程式碼分割等概念、探索樹狀圖抖動等構想,並查看 webpack-libs-optimizations 存放區,瞭解如何縮減程式庫大小 (如果您正好使用 webpack 的話)。

最佳化圖片

圖片載入效能惡作劇

在 Oodle 應用程式中,我們使用了許多圖片。很遺憾,Lighthouse 對此的熱情遠不及我們。事實上,我們在所有三項圖片相關稽核項目中都未通過。

我們忘了對圖片進行最佳化,也沒有正確調整圖片大小,而且使用其他圖片格式可以帶來一些好處。

圖片稽核
圖 14. Lighthouse 圖片稽核

我們首先著手改善圖片。

如要進行一次性的最佳化,您可以使用 ImageOptimXNConvert 等視覺化工具。

更自動化的方法是使用 imagemin 等程式庫,在建構程序中加入圖片最佳化步驟。

這樣一來,日後新增的圖片就會自動進行最佳化處理。有些 CDN (例如 Akamai) 或第三方解決方案 (例如 CloudinaryFastlyUploadcare) 提供全面的圖片最佳化解決方案,因此您也可以直接在這些服務上代管圖片。

如果您不想因成本或延遲問題而這樣做,ThumborImageflow 等專案提供自架式替代方案。

最佳化前後
圖 15. 最佳化前後的比較

我們的背景 PNG 在 webpack 中被標示為太大,這點沒錯。在正確調整大小以符合可視區域,並透過 ImageOptim 執行後,我們將大小降至 100kb,這已是可接受的大小。

我們在網站上對多張圖片重複執行這項操作,因此大幅降低了整體網頁重量。

使用適當的動畫內容格式

GIF 動畫的製作成本可能非常高。令人驚訝的是,GIF 格式從一開始就不是用來做為動畫平台。因此,改用更合適的影片格式,可大幅縮減檔案大小。

在 Oodle 應用程式中,我們使用 GIF 做為首頁的開場動畫。根據 Lighthouse 的資料,如果改用更有效率的影片格式,可以節省超過 7 MB。我們的短片檔案大小約為 7.3 mb,對於任何合理的網站來說都太大了,因此我們將其轉換為包含兩個來源檔案的影片元素,分別為 mp4 和 WebM,以便支援更多瀏覽器。

將 GIF 動畫替換為影片
圖 16. 將 GIF 動畫替換為影片

我們使用 FFmpeg 工具將 GIF 動畫轉換為 mp4 檔案。WebM 格式可讓你節省更多空間 - ImageOptim API 可為你執行這類轉換。

ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4

這項轉換讓我們節省了超過 80% 的整體重量。這讓我們將大小縮減到約 1 mb。

不過,1 MB 仍是透過網路傳輸的大量資源,尤其是對於頻寬受限的使用者而言。幸運的是,我們可以使用有效類型 API 判斷使用者連線速度緩慢,並提供較小的 JPEG 檔案。

這個介面會使用有效往返時間和下載值,來估算使用者使用的網路類型。它只會傳回字串、慢速 2G、2G、3G 或 4G。因此,視這個值而定,如果使用者使用的是 4G 以下網路,我們可以將影片元素替換成圖片。

if (navigator.connection.effectiveType) { ... }

雖然這會稍微影響使用體驗,但至少在連線速度較慢的情況下,網站仍可供使用。

延遲載入畫面外圖片

輪轉介面、滑桿或超長網頁通常會載入圖片,即使使用者無法立即在網頁上看到這些圖片。

Lighthouse 會在離螢幕圖片稽核中標示這項行為,您也可以在開發人員工具的網路面板中查看。如果您發現大量圖片正在傳入,但網頁上只顯示少數圖片,表示您可能可以改為使用延遲載入功能。

瀏覽器尚未原生支援延後載入功能,因此我們必須使用 JavaScript 新增這項功能。我們使用 Lazysizes 程式庫,為 Oodle 封面新增延遲載入行為。

<!-- Import library -->
import lazysizes from 'lazysizes'  <!-- or -->
<script src="lazysizes.min.js"></script>

<!-- Use it -->

<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
    data-sizes="auto"
    data-src="image2.jpg"
    data-srcset="image1.jpg 300w,
    image2.jpg 600w,
    image3.jpg 900w"/>

Lazysizes 之所以聰明,是因為它不僅會追蹤元素的顯示變更,還會主動預先擷取靠近檢視區的元素,以提供最佳使用者體驗。它也提供 IntersectionObserver 的選用整合功能,可讓您非常有效率地查看曝光率。

這項異動後,系統會視需要擷取圖片。如要進一步瞭解這個主題,請參閱 images.guide 這項實用且全面的資源。

協助瀏覽器提早提供重要資源

並非所有傳送至瀏覽器的位元組都具有相同的重要性,瀏覽器也知道這一點。許多瀏覽器都會使用啟發式搜尋來決定應優先擷取哪些內容。因此有時會先擷取 CSS,再擷取圖片或指令碼。

我們可以做些有用的事,例如在網頁作者身分下,告知瀏覽器對我們來說真正重要的內容。幸運的是,過去幾年瀏覽器供應商一直在新增許多功能來協助我們解決這個問題,例如 link rel=preconnectpreloadprefetch資源提示

這些功能已導入網頁平台,可協助瀏覽器在適當時間擷取正確內容,而且比起使用指令碼執行的部分自訂載入邏輯方法,這些功能的效率稍微高一些。

讓我們來看看 Lighthouse 如何引導我們有效運用這些功能。

Lighthouse 首先建議我們避免多次往返任何來源的費用。

避免多次往返任何來源的昂貴行程
圖 17. 避免多次往返任何來源的昂貴費用

以 Oodle 應用程式為例,我們實際上大量使用 Google Fonts。每次將 Google 字體樣式表放入頁面時,系統都會連結至兩個子網域。Lighthouse 指出,如果我們能夠預熱該連線,就能將初始連線時間縮短至最多 300 毫秒。

我們可以利用 rel 預先連結連結,有效地掩蓋連線延遲時間。

特別是 Google Fonts 這類服務,因為我們的字體字型 CSS 會託管在 googleapis.com,而字體資源則會託管在 Gstatic,因此這類服務可能會受到極大影響。因此我們套用了這項最佳化功能,節省了幾百毫秒的時間。

Lighthouse 建議我們接下來預先載入關鍵要求。

預先載入關鍵要求
圖 18. 預先載入索引鍵要求

<link rel=preload> 非常強大,它會通知瀏覽器需要的資源,做為目前導覽的一部分,並嘗試讓瀏覽器盡快擷取資源。

這裡 Lighthouse 會告訴我們,我們應該預先載入主要的網路字型資源,因為我們正在載入兩種網路字型。

在網路字型中預先載入的情況如下:指定 rel=preload,您會傳入 as 並附上字型類型,然後指定要載入的字型類型,例如 woff2。

這可能會對你的網頁造成嚴重影響。

預先載入資源的影響
圖 19. 預先載入資源的影響

通常,如果網頁需要使用網頁字型,但未使用 link rel preload,瀏覽器就必須先擷取 HTML,然後解析 CSS,最後才會擷取網頁字型。

使用 link rel preload 後,瀏覽器在剖析 HTML 後,就能提早開始擷取這些網路字型。在我們的應用程式中,這項功能可縮短使用網路字型算繪文字所需的時間,節省一秒鐘。

不過,如果您想嘗試使用 Google Fonts 預先載入字型,請注意以下一點。

我們在樣式表中指定的字型面,其 Google 字型網址恰好是字型團隊定期更新的內容。這些網址可能會過期,或定期更新。如果您想完全掌控字型載入體驗,建議您自行代管網頁字型。這麼做很不錯,因為這樣就能存取連結 rel preload 等項目。

在我們的案例中,我們發現 Google Web Fonts Helper 工具非常實用,可協助我們離線下載部分網頁字型並在本機設定,因此請試試這個工具。

無論您使用的是網頁字型做為重要資源的一部分,還是 JavaScript,請盡可能協助瀏覽器盡快提供重要資源。

實驗功能:優先順序提示

今天我們要與你分享一些特別的內容。除了資源提示和預先載入等功能之外,我們也一直在開發一項全新的實驗性瀏覽器功能,稱為「優先順序提示」。

為初始可見內容設定優先順序
圖 20. 優先順序提示

這是一項新功能,可讓您向瀏覽器提示資源的重要性。這項功能會公開一個新的屬性 - importance - 其值為 low、high 或 auto。

這可讓我們降低非必要資源的優先順序,例如非必要的樣式、圖片或擷取 API 呼叫,以減少競爭。我們也可以提高更重要內容的優先順序,例如主圖片。

以 Oodle 應用程式為例,這項做法實際上讓我們找到了一個可實現最佳化的地方。

為初始可見內容設定優先順序
圖 21. 為初始可見的內容設定優先順序

在我們為圖片新增延遲載入功能之前,瀏覽器會在輪轉介面中顯示所有塗鴉,並在輪轉介面一開始時,以高優先順序擷取所有圖片。很遺憾,輪轉介面中間的圖片對使用者來說最為重要。因此,我們將背景圖片的重要性設為非常低,而將前景圖片的重要性設為非常高,這會在 3G 網路速度較慢的情況下,影響擷取和算繪這些圖片的速度,時間約為 2 秒。所以,這項服務的體驗相當不錯。

我們希望在幾週內將這項功能帶入 Canary,敬請密切留意。

制定網頁字型載入策略

排版是優質設計的基礎,如果您使用的是網路字型,建議不要阻擋文字的算繪作業,也不要顯示不可見的文字。

我們現在已在 Lighthouse 中以「避免在載入網站字型時顯示不可見的文字」稽核項目,突顯這項問題。

避免在網站字型載入期間顯示不可見的文字
圖 22. 避免在網站字型載入期間顯示不可見的文字

如果您使用字型樣式區塊載入網路字型,當網路字型擷取作業耗費很長的時間時,瀏覽器會決定要採取哪種行動。部分瀏覽器會等待最多三秒鐘,然後才會改用系統字型,並在字型下載完成後,將其換成該字型。

我們會盡量避免這種看不見的文字,因此如果網頁字型花太多時間,我們就無法看到本週的經典塗鴉。幸好,您可以透過名為 font-display 的新功能,進一步控管這項程序。

    @font-face {
      font-family: 'Montserrat';
      font-style: normal;
      font-display: swap;
      font-weight: 400;
      src: local('Montserrat Regular'), local('Montserrat-Regular'),
          /* Chrome 26+, Opera 23+, Firefox 39+ */
          url('montserrat-v12-latin-regular.woff2') format('woff2'),
            /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
          url('montserrat-v12-latin-regular.woff') format('woff');
    }

字型顯示功能可協助您根據網路字型交換所需的時間,決定字型如何算繪或備用。

在本例中,我們使用字型顯示交換功能。換字會為字體面提供零秒的區塊時間間隔和無限的換字時間間隔。也就是說,如果字型需要一段時間才能載入,瀏覽器會立即使用備用字型繪製文字。字體介面可供使用後,系統就會進行切換。

在我們的應用程式中,這麼做很棒的原因在於,我們可以盡早顯示一些有意義的文字,並在準備就緒後切換至網頁字型。

字型顯示結果
圖 23. 字型顯示結果

一般來說,如果您使用的是網路字型 (網路上有大量網路字型),請採用良好的網路字型載入策略。

您可以使用許多網站平台功能,改善字型載入體驗,但也請查看 Zach Leatherman 的 Web Font Recipes 存放區,因為這個存放區非常實用。

減少會妨礙顯示的指令碼

應用程式中還有其他部分可以在下載鏈結中提早推送,至少提供一些基本的使用者體驗。

在 Lighthouse 時間軸列上,您可以看到在前幾秒內,當所有資源載入時,使用者實際上無法看到任何內容。

減少產生轉譯阻斷的樣式表機會
圖 24. 減少會妨礙顯示的樣式表機會

下載及處理外部樣式表會阻斷轉譯程序,導致轉譯程序無法取得任何進展。

我們可以嘗試提前提供部分樣式,以便最佳化關鍵算繪路徑。

如果我們擷取負責初始轉譯作業的樣式,並在 HTML 中內嵌這些樣式,瀏覽器就能立即轉譯這些樣式,而無須等待外部樣式表到達。

在本例中,我們使用名為 Critical 的 NPM 模組,在建構步驟期間在 index.html 中內嵌關鍵內容。

雖然這個模組可為我們完成大部分繁重的工作,但要讓它在不同路徑上順利運作,仍有點棘手。

如果您不小心,或是網站結構非常複雜,而您一開始並未規劃應用程式殼結構,那麼導入這類模式可能會非常困難。

因此,盡早考量效能至關重要。如果您一開始就沒有以效能為設計考量,日後很可能會遇到問題。

最後,我們成功克服風險,讓應用程式提早開始提供內容,大幅改善首次有效顯示時間。

結果

這是我們在網站上套用的一長串效能最佳化措施。讓我們來看看結果。這是應用程式在 3G 網路上載入至中型行動裝置的情況,前後比較。

Lighthouse 效能分數從 23 提高到 91。就速度而言,這算是相當不錯的進展。我們持續檢查並遵循 Lighthouse 報告,因此做出了所有變更。如要瞭解我們如何在技術層面實作所有改善項目,歡迎前往我們的存放區,特別是存放於該處的 PR。

預測成效:以資料為依據的使用者體驗

我們認為,機器學習在許多領域都代表著未來的機會。我們希望這項概念能激發更多實驗,讓我們在日後的創作過程中,能以真實資料為依據來設計使用者體驗。

目前,我們會根據使用者可能想要或需要的內容,做出許多不確定的決定,進而決定哪些內容值得預先擷取、預先載入或預先快取。如果我們猜對了,就能將資源優先分配給少數人,但要將其擴大到整個網站,就很難了。

我們現在有資料可供參考,以便進一步改善最佳化成效。使用 Google Analytics 報表 API,我們可以查看網站上任何網址的下一個熱門網頁和離開百分比,進而得出結論,決定應優先使用哪些資源。

如果我們將這項功能與良好的機率模型結合,就能避免因過度預先擷取內容而浪費使用者資料。我們可以利用 Google Analytics 資料,並使用機器學習和模型 (例如 馬可夫鏈神經網路) 來實作這類模型。

網頁應用程式的資料導向捆綁
圖 25. 網頁應用程式的資料導向捆綁功能

為了協助進行這項實驗,我們很高興在此宣布推出名為 Guess.js 的新計畫。

Guess.js
圖 26. Guess.js

Guess.js 專案著重於以資料為依據的網頁使用者體驗。我們希望這項功能能激勵您探索如何運用資料改善網站效能,並進一步發揮效益。這項工具為開放原始碼,現已在 GitHub 上推出。這項工具是由 Minko Gechev、Gatsby 的 Kyle Matthews、Katie Hempenius 和其他許多人與開放原始碼社群合作開發。

歡迎試用 Guess.js,並提供寶貴意見。

摘要

分數和指標有助於改善網頁速度,但它們只是一種手段,並非目標本身。

我們都曾經歷過網頁載入速度緩慢的情況,但現在我們有這個機會,為使用者提供更快速的載入體驗。

提升效能是一條漫長的旅程。許多小改變累積起來就能帶來重大成效。只要使用適當的最佳化工具,並密切留意 Lighthouse 報表,就能為使用者提供更優質且更全面的體驗。

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