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

在 2018 年 Google IO 大會上,我們發表了一系列工具、程式庫和最佳化技術,可以更輕鬆地改善網站效能。以下說明如何使用 Oodles Theater 應用程式來說明。我們也會介紹有關預測載入功能的實驗,以及新的 Guess.js 計畫。

Addy Osmani
Addy Osmani
Ewa Gasperowicz

過去一年來,我們一直忙於設法找出提升網頁速度和效能的方法。因此衍生出新的工具、方法和程式庫,我們想在這篇文章中與您分享。第一部分,我們將向您說明我們在開發 Oodles Theater 應用程式時,實際運用了哪些最佳化技巧。第二部分,我們將介紹預測載入功能的實驗,以及新的 Guess.js 計畫。

對效能的需求

網際網路每年的發展速度越來越驚人,如果我們檢查網路狀態,即可看到手機上的中位數網頁權重為 1.5 MB 左右,其中多數網頁是 JavaScript 和圖片。

隨著網站規模持續成長,加上網路延遲、CPU 限制、算繪封鎖模式或超載的第三方程式碼等其他因素,都成為複雜的效能難題。

大多數使用者將速度評比的是使用者體驗階層最頂端的位置。這種情況並不令人意外,因為網頁在完成載入之前,不會真的做太多。您無法從頁面上獲取價值,也無法欣賞美觀。

使用者體驗階層導覽
圖 1.速度對使用者來說有多重要?(Speed Matters,第 3 卷)

我們明白效能對使用者來說很重要,但也可能會覺得自己是個秘密,開始進行最佳化。別擔心,有些工具可以提供協助。

Lighthouse - 效能工作流程基底

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

我們最近推出了許多全新效能稽核功能,對於日常開發工作流程相當實用。

全新 Lighthouse 稽核
圖 2.新增 Lighthouse 稽核功能

我們再透過一個實用範例來瞭解如何加以運用:Oodles Theater 應用程式。這是一款小型的範例應用程式,您可以在其中體驗喜愛的互動式 Google Doodle,甚至玩一兩款遊戲。

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

Lighthouse 報告 (Oodles 應用程式)
圖 3.Lighthouse 應用程式報告 (Oodles 適用)

應用程式在 Lighthouse 報告中看到的初始效能很可怕,在 3G 網路上,使用者必須等待 15 秒才會看到有意義的所需時間,或讓應用程式可以互動。Lighthouse 發現我們的網站有大量問題,而整體效能分數為 23,也代表了這一點。

網頁加權約 3.4 MB - 我們一定要減少一些脂肪。

第一步就是開始我們的第一個效能挑戰:找出可以輕鬆移除的項目,而不影響整體體驗。

成效最佳化商機

移除不必要的資源

有些明顯可以放心移除的現象:空白字元和留言。

壓縮帶來的增益
圖 4.壓縮 JavaScript 和 CSS 並加以壓縮

Lighthouse 會在統合式 CSS 和 JavaScript 稽核中突顯這項商機。我們當時使用 Webpack 進行建構程序,因此為了壓縮,我們直接使用 Uglify JS 外掛程式

壓縮是常見的工作,因此您應針對要採用的建構程序尋找現成的解決方案。

該空間的另一項實用稽核功能是「啟用文字壓縮」。沒有理由傳送未壓縮的檔案,且大部分 CDN 目前立即支援這項設定。

我們使用 Firebase 託管來託管程式碼,而 Firebase 預設會啟用 gzip 壓縮功能,因此有利於我們把程式碼託管在合理的 CDN 上,而且完全免費。

雖然 gzip 是相當熱門的壓縮方式,但 ZopfliBrotli 等其他機制也逐漸遭到淘汰。Brotli 對大部分的瀏覽器都很熟悉,且您可以使用二進位檔預先壓縮素材資源,再將素材資源傳送至伺服器。

使用高效率的快取政策

下一步就是確保只在必要時不會重複傳送資源。

Lighthouse 的快取政策效率低落的稽核,讓我們注意到我們可以調整快取策略,從而實現這個目標。只要在伺服器中設定 max-age 到期時間標頭,就能確保使用者重複造訪時,可以重複使用先前下載的資源。

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

移除用不到的程式碼

截至目前為止,我們移除了非必要下載內容的明顯部分,但差別在於前者的部分呢?例如未使用的程式碼。

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

有時候,我們會在應用程式的程式碼中加入並非必要的程式碼。尤其是若您使用應用程式的時間較長,您的團隊或依附元件會變更,而有時遺留程式庫落後,就會發生這種狀況。這也是我們遇到的情況。

一開始,我們使用質感設計元件程式庫快速設計應用程式的原型。但後來我們改採更自訂的外觀和風格,這時我們就完全忘記該程式庫。幸好,程式碼涵蓋率檢查有助於我們在套件中重新發現。

您可以在開發人員工具中查看程式碼涵蓋率統計資料,包括執行階段和應用程式的載入時間。在下方螢幕截圖中,可以看到兩條紅色大條、95% 以上的 CSS 未使用,還有大量的 JavaScript。

Lighthouse 也在未使用的 CSS 規則稽核中發現這個問題。顯示節省了 400 KB 以上的空間我們返回程式碼,移除了該程式庫的 JavaScript 和 CSS 部分。

如果將 MVC 轉接器拖放至 10 KB
圖 6.如果將 MVC 轉接器拖放至 10 KB!

因此,我們的 CSS 組合的版面分為 20 倍,非常適合做為小型兩行修訂的修訂版本。

當然,我們的效能分數有所提升,互動時間也變得更加出色。

不過,光是這樣的變動並不足以單獨查看指標和分數。 移除實際程式碼絕不會承擔風險,因此請隨時留意潛在的迴歸問題。

我們有 95% 的程式碼未使用,這 5% 仍然沒有用。我們其中一個元件似乎仍在採用該程式庫的樣式,也就是 Doodle 滑桿的小箭頭。由於這個元件的尺寸很小,所以我們可以將這些樣式手動加入按鈕中。

按鈕因缺少程式庫而毀損
圖 7.有一個元件仍在使用已移除的程式庫

因此,當您移除程式碼時,請務必備妥適當的測試工作流程,以免發生視覺迴歸問題。

避免耗用大量網路酬載

我們知道大型資源可能會拖慢網頁載入的速度。他們可能會耗費使用者成本,而且可能會對數據方案造成深遠影響,因此請務必特別留意這一點。

Lighthouse 已透過 Enormous 網路酬載稽核,偵測出部分網路酬載發生問題。

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

我們發現,出貨的程式碼共佔了超過 3 MB

這份清單最上方的 Lighthouse 重點顯示,我們有一個 2 MB 的未壓縮程式碼 JavaScript 供應商套件。這也是 Webpack 會醒目顯示的問題。

如範例所示,最快的要求是指系統沒有送出的要求。

在理想情況下,您應評估向使用者提供的每項資產所帶來的價值,評估這些資產的成效,並主動說明這是否值得在初次體驗後實際出貨。這些資產有時可以在閒置期間延後、延後載入或進行處理。

在本例中,由於我們正在處理許多 JavaScript 套件,因為 JavaScript 社群有豐富的 JavaScript 組合稽核工具。

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

我們從 Webpack 套件分析器開始著手,當時提到我們加入了一個稱為 unicode 的依附元件,其中 1.6MB 被剖析 JavaScript 具有許多優勢。

接著進入編輯器,利用 Import Cost Plugin for Visual code,以視覺化方式呈現所匯入每個模組的成本。這可讓我們找出哪些元件包含參照此模組的程式碼。

我們隨後會換到其他工具 BundlePhobia。這項工具可讓您在任何 NPM 套件名稱中輸入這個工具,就能查看其壓縮和 gzip 壓縮大小的預估數值。我們找到了先前使用的 Sslug 模組,但這個模組只使用 2.2 KB 的理想替代方案,因此我們因此改變了該模組。

這對我們效能產生了莫大影響。從這項變更,到尋找縮減 JavaScript 組合大小的其他機會時,我們得以節省 2.1MB 的程式碼。

考慮到這些套件的 gzip 和壓縮後大小,我們發現整體效能提升了 65%。 而我們發現這一切都非常值得。

因此,一般而言,我們會嘗試刪除網站和應用程式中不必要的下載內容。 請務必列出資產的清點,並衡量其成效影響,會有極大的差距,因此請務必定期稽核您的資產。

使用程式碼分割功能,縮短 JavaScript 啟動時間

雖然大型網路酬載可能會對應用程式造成很大的影響,但還有一個可能會造成重大影響,就是 JavaScript。

JavaScript 是費用最高的資產。在行動裝置上,如果您傳送大量 JavaScript 套件,可能會延遲使用者與使用者介面元件互動的時間。這代表他們可以輕觸 UI,不用實際發生任何實質意義。因此,我們必須瞭解 JavaScript 為何如此重要。

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

JavaScript 處理
圖 10.JavaScript 處理

首先,我們必須先下載指令碼,然後有一個 JavaScript 引擎,接著需要剖析和執行該程式碼。

這些階段在高階裝置上不會花費太多時間 例如桌上型電腦、筆記型電腦,甚至是高階手機。但在手機上,此程序可能需要 5 到 10 倍的時間這就是延遲互動性的問題 因此我們必須盡量縮短時間

為協助您找出應用程式的問題,我們向 Lighthouse 推出新的 JavaScript 啟動時間稽核功能。

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

以 Oodle 應用程式為例,該公司指出 JavaScript 啟動作業有 1.8 秒的時間。這是因為我們以靜態方式,將所有路徑和元件匯入一個單體式 JavaScript 組合。

解決這個問題的一種技巧就是使用程式碼分割功能。

程式碼分割就像披薩

使用程式碼分割的概念,而非為使用者提供一整份 JavaScript 的 JavaScript,如果您一次只為他們提供一個片段呢?

程式碼分割功能可套用至路徑層級或元件層級。這項做法非常適合 React and React Loadable、Vue.js、Angular、Polymer、Preact 和其他多個程式庫。

將分割程式碼納入應用程式中,我們已從靜態匯入改為動態匯入,以便在需要時以非同步方式延遲載入程式碼。

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

這種做法不但縮小了套件的大小,也減少了 JavaScript 啟動時間。時間降至 0.78 秒,讓應用程式速度提升了 56%。

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

請運用程式碼分割等概念、探索樹狀搖晃等想法,以及查看 webpack-libs-optimizations 存放區,這樣在使用 Webpack 時,如何縮減程式庫大小。

最佳化圖片

圖片載入效能笑話

在 Oodle 應用程式中,我們使用大量的圖片,不幸的是,Lighthouse 計劃 比我們想像中少很多其實,我們未能完成這三項圖片相關的稽核。

我們忘了最佳化圖片、調整圖片大小的方式不正確,而且採用其他圖片格式或許也很有幫助。

映像檔稽核
圖 14.Lighthouse 映像檔稽核功能

我們首先將圖片最佳化。

針對一次性的最佳化作業,您可以使用 ImageOptimXNConvert 等視覺工具。

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

這樣日後新增的圖片就會自動最佳化。 部分 CDN 例如 AkamaiCloudinaryFastlyUploadcare 等第三方解決方案可提供全方位的圖片最佳化解決方案,因此您也可以僅透過這些服務託管圖片。

如果您因為成本或延遲問題而不想這麼做,ThumborImageflow 等專案提供了自行託管的替代方案。

最佳化前後對照
圖 15.最佳化前後的差異

我們的背景 PNG 被標記為大型的 Webpack

對網站上的多張圖片重複上述步驟,我們就能大幅降低網頁的整體權重。

使用適當格式製作動畫內容

GIF 的費用會非常高。令人驚訝的是,GIF 格式根本不是動畫平台。因此,改用更適合的影片格式可以大幅節省檔案大小。

在 Oodle 應用程式中,我們使用 GIF 做為首頁的前導廣告。Lighthouse 指出,改用效率更高的影片格式 可以節省超過 7 MB影片片段的權重大約是 7.3mb,但對任何合理的網站來說也太過重重,因此我們決定將其轉換為內含兩個來源檔案的影片元素: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 左右

不過,1mb 是個大型資源,可以向下推向電線,對使用受限頻寬的使用者而言更是如此。幸好,我們可以使用 Effective Type 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 Font 樣式表拖放到網頁時,會連結至最多兩個子網域。Lighthouse 表示,如果能夠暖機連線,就能將初始連線時間的任意儲存時間減少 300 毫秒。

利用 rel-connect 預先連線,我們可以有效遮蓋連線延遲的情況。

尤其是在 Google Fonts 等 Google Fonts 中,字型 CSS 是由 googleapis.com 代管,而字型資源則託管在 Gstatic,那麼這可能會帶來很大的影響。於是,我們採行了這項最佳化措施,只花了幾百毫秒。

Lighthouse 下一個建議是預先載入重要要求。

預先載入重要要求
圖 18.預先載入金鑰要求

<link rel=preload> 功能非常強大,會通知瀏覽器在目前導覽中需要資源,同時嘗試讓瀏覽器盡快擷取。

Lighthouse 表示,我們應該載入並預先載入重要的網路字型資源,因為我們已載入兩個網路字型。

網頁字型的預先載入看起來會像這樣;指定 rel=preload,您會透過字型類型傳入 as,然後指定要載入的字型類型,例如 woff2。

這可能會對你的網頁帶來極大影響。

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

一般而言,如果不使用 link rel 預先載入,如果網頁字型顯然對網頁很重要,瀏覽器就必須先擷取 HTML、剖析 CSS,而在不久後就會擷取網頁字型。

使用連結 rel 預先載入,這樣一來,只要瀏覽器剖析您的 HTML,就能稍早開始擷取這些網路字型。對應用程式來說,使用網頁字型轉譯文字所花的時間,可以減少一秒的時間。

如果您打算使用 Google Fonts 預先載入字型,還不太容易理解。

您在樣式表中指定的 Google Font 網址發生在字型團隊定期更新的情況。這些網址可能會過期,或定期進行更新,因此如果要完全掌控字型載入體驗,建議你自行代管網路字型。這項功能的好處是可以存取 連結 rel 預先載入的內容

以我們的例子來說,Google Web Fonts Helper 可以幫助我們離線並在本機設定一些網路字型,因此不妨試試這項工具。

無論您是在重要資源中使用網頁字型,還是以 JavaScript 形式編寫,請盡量協助瀏覽器盡快提供重要資源。

實驗:優先提示

今天有個特別要與您分享的東西。除了資源提示和預先載入等功能,我們也開發了「優先提示」這項全新的實驗性瀏覽器功能。

為最初顯示的內容設定優先順序
圖 20.優先順序提示

這是一項新功能,您可以告訴瀏覽器某項資源的重要性。這項新功能會公開「重要性」這項新屬性,具有低、高或高的值。

這可讓我們傳達較不重要資源 (例如非重要樣式、圖片或擷取 API 呼叫) 的優先順序,以減少爭用情形。我們也會優先處理更重要的事物 例如主頁橫幅

以 Oodle 應用程式的例子來說,這實際上是可以改進的地方。

為最初顯示的內容設定優先順序
圖 21.為最初顯示的內容設定優先順序

在我們為圖片加入延遲載入功能前,瀏覽器還採用了所有塗鴉的圖片輪轉介面,且瀏覽器在輪轉介面開始時,以高優先順序擷取所有圖片。很抱歉,這是輪轉介面中對使用者最重要的圖片。我們當時的作法是將這些背景圖片的重要性設為極低,將前景圖片設為非常高。如果使用緩慢 3G 技術,會帶來兩秒的影響,以及我們擷取及轉譯這些圖片的速度有多快。我們非常滿意

我們會在未來幾週內將這項功能引進初期測試階段,敬請密切留意。

擬定網站字型載入策略

字體排版是設計優良的基本要素。如果您使用網路字型,就不會希望文字顯示,甚至也不想顯示隱形的文字。

我們現在會在 Lighthouse 中強調這一點,方法是在網站字型載入期間避免顯示隱藏的文字稽核。

避免在載入網路字型時隱藏文字
圖 22.避免在載入網路字型時隱藏的文字

如果您使用字型區塊來載入網路字型,可以讓瀏覽器在擷取網頁字型很長的時間時,決定該執行什麼動作。有些瀏覽器會等待最多三秒鐘的時間,才會改回使用系統字型,下載後最終就會切換為字型。

我們也希望能避免這類隱藏的文字,因此如果網路字型太長,我們就無法查看這週的經典 Doodle。幸好,新增名為 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 皮革 man 的 Web Font Recipes 存放區,因為它非常好用。

減少會妨礙顯示的指令碼

我們可以提前將應用程式的其他部分推送到下載鏈結,至少提前提供一點基本的使用者體驗。

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

減少會妨礙樣式表的機會
圖 24.減少會妨礙轉譯樣式表的機會

下載和處理外部樣式表會阻礙轉譯程序產生任何進度。

我們可以稍早提供一些樣式,嘗試將重要轉譯路徑最佳化。

如果我們擷取負責此初始算繪的樣式,並將其內嵌在 HTML 中,瀏覽器就能直接轉譯這些樣式,不需要等待外部樣式表送達。

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

雖然這個模組已處理大部分的繁雜工作,但若要在不同路線之間順利執行,仍有些困難。

如果不留意,或者網站結構真的很複雜,假如您不打算從一開始就採用應用程式殼層架構,可能就很難導入這類模式。

因此盡早考量效能資訊的重要性。如果您不從一開始就進行效能設計,很有可能之後就會發生問題。

最終的風險獲得回報後,我們得以完成這項工作,應用程式也開始提早提供內容,大幅縮短了第一個有意義的繪製時間。

成果

這份白皮書提供了許多成效最佳化措施,幫助我們提升網站成效。我們來看看結果在最佳化前後的中等行動裝置上,這就是我們的應用程式載入方式。

Lighthouse 效能分數從 23 提升至 91,在速度方面可說是相當不錯所有變更都已持續檢查並遵循 Lighthouse 報告。如果您想瞭解我們如何技術實作所有改善項目,歡迎查看我們的存放區,尤其是實際導入的 PR。

預測成效 - 資料導向使用者體驗

我們相信機器學習在許多領域的未來,將帶來令人振奮的商機。 我們希望未來能夠激發更多實驗的實驗,因為真實資料能夠真正引導我們打造的使用者體驗。

目前,我們可任意決定使用者可能想要或需要的內容,判斷哪些項目值得預先擷取、預先載入或預先載入。如果我們猜得沒錯,我們能夠優先使用少量資源,但擴大規模涵蓋整個網站並不容易。

事實上,我們擁有數據資料,可提升最佳化的今日成效。透過 Google Analytics Reporting API,我們可以查看網站中任何網址的下一頁和離開百分比,進而判斷我們應該優先處理哪些資源。

我們將這種方法與良好的可能性模型結合後,就能避免使用者資料過於嚴格地預先擷取,因而浪費使用者資料。我們可以利用這些 Google Analytics (分析) 資料,並透過馬可夫鏈類神經網路等機器學習和模型實作這類模型。

以資料為導向的網頁應用程式套裝組合
圖 25.網頁應用程式適用的資料導向套裝組合

為了讓實驗更順利,我們很高興在此宣布,新計畫稱為 Guess.js

Guess.js
圖 26.Guess.js

Guess.js 專案著重於資料導向的網頁使用者體驗。我們希望能啟發探索如何利用資料 提升網頁效能,並提供其他實用資訊您可以使用所有開放原始碼,並可在 GitHub 上取得。這項計畫是由 Minko Gechev、Gatsby、Katie Hempenius 及許多 開放原始碼社群共同開發的

試試看 Guess.js,與我們分享你的想法。

摘要

分數和指標有助於改善網頁速度,但它們只是用來控制目標,而非改變目標。

雖然我們隨時隨地都能處理網頁載入速度緩慢的問題,但現在我們有機會為使用者提供更愉悅的使用體驗,並加快網頁載入速度。

改善成效是一段改善旅程。許多小小的改變可以帶來巨大的效益。只要使用正確的最佳化工具並留意 Lighthouse 報表,就能為使用者提供更優質且更多元包容的體驗。

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