提升網站速度：達到 99% 效能等級（從 30 開始！）

「早在 2018 年，Google 就曾表示，頁面速度現在將影響桌面和行動搜尋結果的排名。然而，受頁面速度影響的不僅是位置。根據研究，3 秒的頁面載入持續時間會導致 13% 的跳出率，這表明頁面速度不僅與搜尋結果有關，還與使用者體驗有關。

那麼，如果您的網站運作緩慢，該怎麼辦？提高網站效能不是在公園散步那麼簡單；因此，許多公司只是做了一些小的優化來確保自己在搜尋結果中的位置。

請繼續閱讀，了解我們如何從 30 分的績效評級轉變為 99 分，以及為什麼（除了對我們的成就感到無比自豪之外）擁有該行業最快的網站之一是值得付出努力的。

開始：障礙和解決它的必要性

透過改進我們的網站，我們的重點是實現三個主要目標：

1. 透過快速的頁面載入、改進的使用者體驗和一流的內容來提高轉換率。
2. 提升 SEO 並在搜尋引擎上獲得更好的可見度。
3. 透過展示新項目和客戶評論來提升我們的品牌形象。

這些目標引導我們確定需要整合的功能。以下是我們為實現目標所提出的關鍵功能：

• 結構新穎的網頁具有令人印象深刻的外觀，可以展示我們的服務、產業、技術和案例研究。
• 增強的部落格文章頁面，具有搜尋功能、標籤和類別。
• 「聯繫」和其他方便溝通的形式。
• 各種第三方整合：Google 標籤管理器、Cookiebot 和 Hubspot 等。

總的來說，我們的目標是建立一個安全的靜態網站。因此，我們選擇了 GatsbyJS，一個與此目標無縫契合的 React 框架。

你問為什麼是蓋茲比？的潛在實力 @GatsbyJS 在於它能夠透過在編譯過程中協調預先建置的 HTML、CSS 和 JavaScript，將 Web 開發轉變為平穩、快速的流程。 GatsbyJS 使用 React 構建，使我們能夠利用 React 生態系統的擴展來創建單獨的模板和元件。

改版後的網站另一個需要關注的方面是 API 後端。我們的偏好是 @斯特拉皮，一個開源內容管理系統。該系統不僅允許我們自訂資料結構並擴展 API 功能來管理文字、圖像和視訊等多種內容格式，而且還為我們節省了大量的時間和資源 - 得益於其用戶友好的管理面板和補充功能這就避免了從頭開始開發一切的必要性。

最後，對於伺服器請求，我們利用 GraphQL。它與 GatsbyJS 無縫兼容，使我們能夠定義查詢格式並僅指定必需的字段和關係，從而避免多餘的數據，從而加快頁面加載時間。

技術的融合使我們能夠實現最佳的網站穩定性和安全性

完成後，新網站脫穎而出，為我們帶來了更高的排名和更新的設計。最初……但隨後，事情開始逐漸惡化。隨著新頁面的添加、一系列修改以及第三方軟體的集成，程式碼庫迅速發展，以至於我們對 Google 的 Lighthouse（一種分析網頁速度的工具）的效能評級大幅下降。

在開始改進工作之前，燈塔對我們的網站進行了評分

由於分數如此下降，Google 不會為我們帶來有利的位置。最重要的是，即使確實如此，用戶也不會忍受等待載入。

愛立信的研究 說明行動裝置上的頁面載入延遲所引起的壓力類似於面對恐怖電影。就性能而言，每一秒都至關重要。在認識到這一困難後，我們立即致力於改善網站的效能。

有條不紊地提高網站效率

為了實現顯著的效能提升，我們仔細檢查了困擾網站的主要問題，並開始努力糾正每個問題。以下闡述了我們如何克服主要挑戰。

1. 網路連線建立速度加倍

G指標是一種描述網站載入模式的工具，可幫助我們從導致連線持續時間延長的外部網域中找出資源。

紫色時間表示網域名稱伺服器接收網域名稱 IP 位址請求的持續時間，而淺綠色表示伺服器連線時間。這些間隔很長，因此，我們透過限制伺服器連線時間來加快它們。

為了加快網站速度，我們實施了各種技術改進。最初，我們利用 HTML 部署了資源提示 <link> 屬性。這些提示有助於瀏覽器在將資源請求轉發到伺服器之前主動建立連線。對於來自外部網域的資源，我們結合了 DNS 預取和預連線提示，事先指示瀏覽器啟動與指定網域的連線。因此，當瀏覽器需要來自外部網域的資源時，由於初步設定已經完成，因此可以輕鬆載入它們。

對於腳本和樣式表等內部文件，我們採用了「預先載入」和「預取」提示。這些提示確保當使用者瀏覽我們網站的頁面時，可以從本地快取中獲取必要的資源，從而無需從遠端伺服器檢索它們，從而加快了流程。

這些優化有助於將 *Largest Contentful Paint 從 2.9 秒縮短至 0.8 秒，將 *First Contentful Paint 從 1 秒縮短至 0.6 秒，讓瀏覽器加快資源載入速度。

*LCP，a基本 Web Vitals 測量 它量化了從用戶開始加載頁面到最突出的圖像出現在視口中的持續時間。

*FCP 表示使用者首次造訪頁面和內容在螢幕上呈現之間的時間間隔。

透過快速文字渲染增強字體加載

在我們的平台中，我們混合使用個人化和公開可用的字體。我們透過 Google 託管公共字體“Manrope” 字體來源 集合，因為它代表了獲取字體的最快方法。

然而，儘管從 HTML 文件中檢索了文本，但在加載字體包時還是出現了延遲。為了避免文字和字體載入之間的這種脫節，我們最初的策略是顯示一個模糊的後備字體，直到我們首選的網頁字體完全載入。這種方法雖然有效，但延長了 LCP 指標，促使我們調整策略以支援快速文字渲染。

工作流程如下：最初，瀏覽器識別指定字體系列中的可存取字體，並將其部署用於文字渲染。隨後，在載入原始字體後，瀏覽器會無縫地用必要的字體取代初始字體。這種策略是最快的字體載入方法，儘管它存在著由於字體大小改變而導致文字意外移動的風險。為了減輕佈局變化並細化累積佈局變化（CLS，一種用於追蹤頁面加載期間意外元素位移的儀表），我們實現了 CSS 字體模組等級 5，一套包含屬性的規範，例如 尺寸調整, 下降覆蓋， 和 行間隙覆蓋，這幫助我們避免了內容變化。

CSS 字體模組等級 5 表現無可挑剔，確保字體變更而不影響佈局

因此，三個指標——首次內容繪製、最大內容繪製和累積佈局偏移得到了增強。特別是，CLS 從 0,143 秒減少到 0 秒。

增強圖片、影片的載入

我們遇到的另一個效能挑戰是大量的網路負載。網站審核發現有必要在不影響品質的情況下縮小圖像和影片的大小，從而簡化圖像和影片的載入過程。

黃色實驗室工具 評估表明，在所有文件類型中，影片和圖像給我們的網站帶來了巨大的負擔

我們的網站包含兩種圖像變體 - 向量圖像（可擴展向量圖形 (SVG) 格式）和光柵圖像（PNG 和 JPG 格式）。每個 category 採用了不同的最佳化技術。

3.1 向量影像的增強

向量圖像通常具有輕量級的性質；然而，當每個映像都需要一個新的 HTTP 請求來載入時，問題就出現了，從而降低了效能。為了解決這個問題，我們選擇採用內嵌 SVG，以便將圖片直接嵌入到 HTML 中。這是透過 'gatsby-plugin-react-svg' ，Gatsby 框架內的一個插件，簡化了流程。

3.2 光柵影像的增強

為了加快 PNG 和 JPG 影像的載入速度，我們將它們轉換為現代的 .webP 格式，以確保卓越的壓縮效果和最小的品質妥協。同樣，影片從 .mp4 轉換為 .webM，確保增強的壓縮和品質。雖然採用 .webP 和 .webM 作為主要格式，但預計會出現與舊瀏覽器版本的兼容性問題。為了緩解這個問題，對於不支援 .webP 和 .webM 的瀏覽器，保留了 .png、.jpg 和 .mp4 格式的回退。

此外，影像顯示需要跨不同裝置進行最佳化。手機、平板電腦、筆記型電腦或 4K 顯示器等各種裝置都需要不同的影像尺寸。為手機和 4K 顯示器上傳相同的影像會延長網站載入時間。作為解決方案，我們實現了自適應圖形，在程式碼中嵌入了不同的圖像選項，使瀏覽器能夠根據視窗大小、螢幕解析度、網路速度等因素選擇最佳圖像。透過利用像這樣的包 '蓋茲比-背景圖像' 和 '蓋茲比形象' ，我們創建了針對不同設備量身定制的多個圖像變體。在裡面 網路選項卡 下面的快照中，我們在頁面顯示模式之間切換時顯示了「切換裝置工具列」。

在這裡，我們啟用了設備工具列來優化不同設備的圖像加載

此處顯示的是針對不同設備優化且尺寸減小的相同文件

3.3 幕後影像的延遲載入

最後，我們實現了延遲加載和圖像模糊效果，以確保僅在用戶查看圖像時才加載圖像，豐富了資源有限的用戶的體驗。

定價表或網路連線速度慢。

這舉例說明了視覺內容延遲載入功能的運作方式

所有的努力都得到了回報——我們在不影響品質的情況下顯著縮小了網站上視覺效果的大小。

經過增強後，Yellow Lab Tools 發現影片仍然佔據頁面權重的較大部分（毫不奇怪），但視覺效果的負荷已大大減少（紫色部分）

這些增強功能極大地豐富了使用者體驗和 CLS 和 LCP 等指標。透過在 Gatsby 生態系統中專門利用視覺優化擴展，我們促進了提高性能的過程。

4. 簡化緩存

我們必須承認，快取是一種網頁伺服器保存網頁副本的方法，最初在網站建立過程中被忽略了。不可否認，這是一個錯失的前景，因為有效的快取可以加快網站速度並減輕伺服器負擔。我們決心在快取優化方面迎頭趕上，但遇到了各種具體障礙。

我們的目標是透過為即將到來的訪問保留資源來加速資源的加載，而不是每次都下載它們。為了實現這一點，我們在 HTTP 標頭中使用了「快取控制」屬性，並確定了檔案在快取中應持續的時間。然而，另一個困境出現了。對網站內容或設計進行修改後，變更不會立即顯示，因為瀏覽器仍然使用舊儲存的副本。

我們是如何解決的？我們在文件面額中附加了一個哈希值，該值會隨著每次文件編輯而刷新。這種方法使我們能夠在快取中長時間保留文件，同時仍然可以輕鬆地進行更改。因此，首次內容繪製 (FCP) 指標從較高轉變為中等。

目前，我們正在考慮另一種形式的緩存，稱為瀏覽器快取。與需要永久伺服器連線並消耗頻寬來載入回應的伺服器快取不同，瀏覽器快取使用戶無需網路連線即可存取網頁。然而，它也存在局限性——如果用戶設備的儲存空間不足，瀏覽器可能會刪除舊資料以適應新內容。

為了讓您更好地理解，這裡並列了伺服器端快取和客戶端快取的功能

5. 消除大量 JavaScript 集合

捆綁包本質上由文件（通常是 JavaScript、CSS 和其他屬性）組成，這些文件合併為統一文件，以便更有效地分發。隨著我們網站的複雜性不斷提高，我們的捆綁包的大小不斷擴大，從而使網站變得超重。現在是找出有問題的部分並丟棄它們的適當時機。

有幾種有用的工具可用於識別和糾正有問題的捆綁包。其中之一， 捆綁恐懼症，深入了解 NPM 套件對套件大小的影響有多大，有助於避免過大的檔案編譯。 進口成本，一個 VSCode 擴展，計算導入包的“成本”，幫助做出明智的決定。作為我們優化策略的一部分，我們取代了重量級的 JS 庫，例如用更有效率的替換廣泛使用的「classnames」套件 'clsx'，一個更快、更小巧的直接替代品，專為我們的網站需求量身定制。

隨後，利用 Webpack 捆綁分析器 插件，我們找出了捆綁包中的問題區域。

捆綁分析器揭示了我們最重要的捆綁 - 客戶位置和帶有閃爍點的地圖

為了剖析這些文件組合，我們利用程式碼分割和延遲載入將大包分割成更小的元件。 Webpack 的整合程式碼分割功能允許我們將 import 命令修改為指向檔案路徑而不是直接匯入檔案的函數。這會產生一個承諾，類似於文件將被載入的承諾。當程式碼中出現類似的結構時，就會兌現這項承諾，並載入檔案。

對於非必要的視圖、HTML 和 JS，我們利用動態匯入來減少網頁的初始大小。在這種情況下，動態意味著網站根據特定條件確定是否載入補充文件，確保它不會破壞使用者體驗。

這是我們優化的結果：沒有孤立的擴充包的精細加載過程

將大量包分割成更小的部分後，我們有效地減輕了頁面的重量並消除了所有大量的文件集合。

6.透過程式碼壓縮壓縮HTML和CSS

程式碼壓縮徹底改變了我們的方法。透過壓縮程式碼並省略不必要的空間，我們實現了減小檔案大小、快速下載和最小化頻寬使用。目前，我們的伺服器以gzip 格式分發網站文件，從而提高了速度，尤其是將FCP 和FID（首次輸入延遲，一種衡量初始點擊和瀏覽器響應之間的延遲的指標）等關鍵指標從次優提升到中等性能等級。

7. 提高程式碼品質並解決記憶體洩漏問題

經過仔細檢查，我們在程式碼庫中發現了一些狡猾的記憶體洩漏。這個問題源於記憶體中揮之不去的對象，即使不再需要它們，也會導致環境擁擠。

為了糾正這個問題，我們實施了兩種方法。如果事件監聽器只需要一次，我們選擇使用 {only: true} 參數。此參數保證偵聽器在觸發後自動刪除，從而減輕任何與記憶體相關的複雜性。此外，我們確保透過利用removeEventListener()方法明確消除事件偵聽器。此步驟是在刪除元素之前或偵聽器過時後執行的。此類操作有助於元素和函數之間的無縫斷開，從而避免記憶體洩漏。

關於 addEventListener 需要考慮的另一個面向是合併 {passive: true } 參數。事實證明，這種調整有利於滾動互動、防止介面中斷並有助於增強使用者體驗。

useEffect(() => { setScrolled(document.documentElement.scrollTop > 50); window.addEventListener('scroll', handleScroll, { Passive: true }); return () => { document.body.style.overflowY = '滾動'; window.removeEventListener('滾動',handleScroll);

從之前到之後：效能增強對我們網站的影響

坦白說，我們最初的定位並不理想——載入時間緩慢，伺服器不堪重負，嚴重影響了使用者體驗。然而，憑藉寶貴的見解和優化策略，我們致力於這項任務並取得了令人印象深刻的成果。我們對結果滿意嗎？無疑。

頁面速度洞察 為我們提供了一份值得稱讚的成績單，強調了實質的改進

為期一個月的績效評估顯示出顯著的進步 - 與我們的起點相比，所有指標都顯示出多項改進

如果沒有無數日夜的專注努力，這些轉變是不可能實現的。然而，對我們的勝利有重大貢獻的另一個因素是使用適當的工具。某些工具不僅節省了我們的時間，而且值得認可。

提升效能的工具：PageSpeed Insights 和 Lighthouse

在效能評估和增強領域，有兩個 Google 實用程式脫穎而出： PageSpeed 見解 和 燈塔。這些工具會仔細檢查網頁的各個方面，以提供有關其速度、使用者體驗和整體效能的見解。以下是他們共同評估的指標：

• 最大內容塗料 (LCP) – 測量可見區域中最大內容元素（例如圖像或文字區塊）對使用者可見的持續時間。
• 首次內容繪製 (FCP) – 測量瀏覽器呈現初始內容片段（例如文字或圖像）的時間。
• 首次輸入延遲 (FID) – 評估使用者的主要互動（例如，按鈕點擊）和瀏覽器對該操作的回應之間的延遲。
• 累積佈局偏移 (CLS) – 計算頁面生命週期內發生的所有單獨佈局轉變分數的總和。當頁面上的可見元素意外移動時，就會發生佈局變更。
• 與下一個油漆的互動 (INP) – 計算瀏覽器透過更新頁面上的視覺內容對使用者互動（例如點擊或點擊）做出反應的時間。
• 第一個字節的時間 (TTFB) – 確定瀏覽器在請求後從伺服器接收初始資料位元組的持續時間。
• 總阻塞時間 (TBT) – 量化瀏覽器主執行緒受阻且無法回應使用者輸入的總持續時間。
• TTI（交互時間） – 評估頁面完全互動所需的時間，這表示所有必需的資源均已加載，並且頁面會立即回應使用者輸入。
• FID（首次輸入延遲） – 仔細檢查使用者的初始互動和瀏覽器對該互動的反應之間的延遲。

您可以利用這些工具之一來深入了解網站的效能。 Lighthouse 提供更大的靈活性和詳細的見解，而 PageSpeed Insights 則專注於監控單一頁面的效能。

雖然這兩個被廣泛使用，但它們並不是我們的唯一建議。以下是一些可能對您的效能優化之旅非常有價值的額外資源。

全面探索的補充工具

GTMetrix：一個強大的工具，不僅可以審核頁面，還可以以易於理解的格式可視化加載，從而使性能增強切實可見。

黃色實驗室工具：一個富有洞察力的儀表板，可對眾多指標進行分類和評估。它不僅可以識別問題，還可以提供詳細的最佳化建議。

這些工具充當了我們的指路明燈，幫助我們提高效能並提供卓越的使用者體驗。當您著手提高網站效能時，請記住它們。

結論

如果您的業務取決於您的網站，那麼忽視其效能是不可選擇的。這方面可以將您推到 Google 搜尋結果的前列，或者相反，提示用戶遷移到速度更快、提供卓越體驗的網站。為了避免這種困境，我們分享了我們網站的轉變故事。

我們追求最佳性能的旅程仍在繼續，因為總有改進的空間。最近，我們觀察到 GatsbyJS 面臨一些挑戰，並考慮過渡到 NextJS。然而，這種審議值得在另一篇文章中單獨討論。

正如沒有兩個企業是相同的一樣，也不存在提高網站效能的通用藍圖。每個場景都是獨特的，需要採用量身定制的方法來解決您的情況中遇到的特定挑戰。雖然這不是一項輕鬆的任務，但我們隨時準備好提供協助。如果您想提高網站的效能，請隨時 聯絡我們，我們將探討我們能為您做些什麼。
`