Interaction to Next Paint 是什麼？優化 INP 指標的實用教學！

在這篇「INP 優化教學」，我會跟你分享如何解決 INP 問題，讓你能通過 Google 的 INP 指標數值需在 200 毫秒以下的要求。

下圖是我在 INP 優化前 PageSpeed Insights 測出的結果 (失敗)：

下圖是 INP 優化後 PageSpeed Insights 測出的結果 (通過)：

一開始發現我的 Google Core Web Vitals (網站體驗核心指標) 未通過，是因為在 Google Search Console 裡看到「INP 問題：超過 200 毫秒 (行動版）」的警告。

看到這個警告讓我很緊張，害怕會影響 SEO 成效。

但是，經過一番努力研究和優化後，終於讓 INP 從需要改善變成良好。

雖然寫這篇筆記的當下，每個月只有幾十個人在搜尋 INP 問題，但我還是想和大家分享我的經驗。

我自己就因為 INP 問題困擾了很長一段時間，前前後後花了超過 300 小時才找到解答。

寫這篇文章的初衷很單純，就是希望能幫其他遇到相同問題的朋友節省寶貴的時間和精力。

身為曾經深陷其中的人，我非常了解找不到答案時的無助感。

如果你也遇到以下問題，應該能在這篇筆記中找到解答或至少有點頭緒。

• 在 Google Search Console 出現 INP 不良或需要改善
• 不了解相關專業名詞，像是 INP、FID、TBT 等等是什麼意思
• 看到 PageSpeed Insights 有很多診斷建議，但不知道該做什麼實際行動去改善
• 不知道如何有效降低網站的 INP 數值
• 在調整網站後，沒辦法馬上知道新的改動對 INP 到底有沒有幫助
• 努力嘗試優化 INP 後，數值還是超過 200 毫秒，感到非常沮喪

以下是我優化後的成效 (請容許我曬一下成果)：

想當初我半夜睡覺的時候都還在思考要怎麼解決 INP 問題，一有想法就跳起來開一堆 Chrome 分頁測試，在 PageSpeed Insights 跟 Chrome 開發者模式等各種工具裡點到手指跟手腕都在痛。

以下內容真的是我優化 INP 的寶貴經驗，如果你想進一步瞭解我是用什麼方法和使用什麼工具解決 INP 問題，請繼續看下去。

INP (Interaction to Next Paint) 是什麼？

INP (Interaction to Next Paint) 的 Google 官方中文翻譯是「與下一個顯示的內容互動」。

INP是個重要的網站性能指標，它會檢測網站對使用者互動行為的回應速度。

簡單來說，就是測量使用者點擊按鈕、敲打鍵盤或做其他操作後，網站需要多少時間才能做出回應。

這就像是在測試網站的反應靈敏度，讓我們知道使用者操作後要等多久才能看到結果。

INP 分數越低，代表網頁對使用者輸入的回應越快，使用者體驗也越好。

以下是不同區間 INP 分數對應的使用者體驗：

• INP 分數低於 200 毫秒：良好
• INP 分數介於 200 毫秒到 500 毫秒：需要改善
• INP 分數超過 500 毫秒：不良

讓我用一個實際的例子來解釋 INP 是什麼。

以打開摺疊式選單來說，在網頁中點擊後展開的摺疊式選單的互動就像下動圖那樣。

Google Chrome 瀏覽器會測量從使用者點擊按鍵到摺疊式選單完全展開的這段時間，來計算 INP 數值。

你只需要知道：

• 一個網站或網頁的 INP 高的話，代表回應速度較慢 (可能會發生點擊折疊式選單之後要很久一段時間才會完全展開)
• 而 INP 低的話，代表回應速度較快 (使用者在跟所有網頁元件互動的時候都可以得到很快的反應)

但其實 INP 是一個現場指標 (Field Metric)，它的值是透過收集大量 Chrome 瀏覽器的實際使用者 (網站訪客) 的現場數據計算出來的，而非由單一事件決定的。

實際的計算方法會在 這裡 做比較詳細的介紹。

你也可以透過 Google 官方的 INP 文章 進一步瞭解更詳細的資訊 。

互動是什麼？

互動是指使用者在網頁上執行的動作。

在網頁上，使用者可以做出各種動作來跟網頁互動，比如用滑鼠點擊、手指觸碰螢幕，或是按下鍵盤按鍵。

每當使用者做出這些動作時，網頁就會觸發相對應的事件處理程式，然後可能會更新畫面，讓使用者看到互動後的結果。

但是並不是所有的互動都會計入 INP 的計算。

以下動作會納入 INP 計算：

• 點選 (Clicking)
• 在觸控螢幕上點擊 (Tapping on touchscreens)
• 按按鍵 (Key pressing)

以下動作會不納入 INP 計算：

• 懸停 (Hovering) – 例：把滑鼠放在連結上
• 捲動 (Scrolling)

互動延遲是什麼？

INP 是「互動延遲指標」，它會測量使用者和網頁互動後要等多久才能看到畫面反應。

比如說，當你點擊按鈕、觸碰螢幕或是輸入文字時，要等多久網頁才會有視覺上的變化。

INP 分數高表示網頁回應使用者操作的時間比較長。當使用者點擊或互動時，網頁會反應緩慢、卡卡的，這會讓使用者感到不舒服和煩躁，瀏覽體驗較差。

INP 分數低表示網頁回應使用者操作的時間比較短。

當使用者點擊或互動時，網頁會迅速反應、流暢運行，這會讓使用者感到順暢和愉快，瀏覽體驗較佳。

互動延遲由 3 個元素組成。

1. 輸入延遲 (Input Delay)

輸入延遲是指從使用者開始跟網頁互動，到系統實際執行相關操作之間的等待時間。

這段延遲時間可能來自實體設備的反應時間，像是按下鍵盤、移動滑鼠或是點擊觸控螢幕。

同時也包括了系統內部處理這些輸入指令所花費的運算時間。

2. 處理時間 (Processing Time)

當系統接收到使用者的輸入後，就會展開一連串的處理流程。

這個流程包含了分析和解讀輸入的資料、執行必要的運算，最後產生對應的輸出結果。

而處理時間指的就是整個流程從開始到結束所需要的時間。

3. 演示延遲 (Presentation Delay)

系統在產生輸出和回應時，會需要一段處理時間，才能把結果顯示給使用者。

這段延遲包含了更新畫面、渲染圖形和使用者介面，以及把輸出內容傳送到使用者介面或輸出裝置等過程所需的時間。

INP vs FID

Google 在 2024 年 3 月把 INP 指標設定為網站體驗核心指標 (Core Web Vitals)，用來取代原本的 FID。

這項改變主要是因為 INP 能更完整地衡量網頁的回應速度，而且更接近使用者在瀏覽網頁時的真實感受。

FID (First Input Delay) 的 Google 官方中文翻譯是「首次輸入延遲時間」。FID 和 INP 都是衡量網頁回應速度的指標。

INP 會測量「所有使用者互動」的延遲時間，並記錄下最長的延遲數值。

這個延遲時間是指從使用者輸入到瀏覽器下一次繪製畫面之間的時間差。

FID 只會測量使用者「第一次和網頁互動」時的延遲時間。它計算的是從使用者第一次輸入到瀏覽器開始處理該事件之間的時間差。

理論上優化 INP 比優化 FID 更難，因為 INP 反映了網站對使用者互動的整體回應速度，而 FID 只衡量初始處理延遲。

你可以透過 Google 官方的 FID 文章 進一步瞭解更詳細的資訊 。

INP vs TBT

Total Blocking Time (TBT) 的 Google 官方中文翻譯是「總封鎖時間」。TBT 是用來衡量網站回應使用者操作的速度。

當 CPU 執行過長的運算任務時，會讓瀏覽器的主執行緒被卡住，導致網站無法快速回應使用者的點擊和其他互動行為。

TBT 的值是計算網頁載入期間所有長任務（超過 50 毫秒）的阻塞時間總和。

TBT 主要檢測網頁在載入時的回應速度，而 INP 則是監測整個網頁生命週期的回應表現。

如果網頁的 TBT 分數較高，代表載入過程中有許多執行時間過長的任務，這通常也會讓 INP 分數變差。

所以我們可以先著手改善 TBT 分數，這樣也能一起讓 INP 的表現變得更好。

你可以透過 Google 官方的 TBT 文章 進一步瞭解更詳細的資訊 。

INP 為什麼重要？會不會影響 SEO？

INP 是網站體驗核心指標 (Core Web Vitals) 的重要指標之一。

目前網站體驗核心指標包含了 LCP、CLS 和 INP 這三個指標。

為了提供更好的使用者體驗，我們需要持續改善 INP 等等網站體驗核心指標。

以下是網站體驗核心指標中的各項指標的簡單介紹：

LCP (Largest Contentful Paint )：中文是「最大內容繪製」，評估載入效能。為了提供良好的使用者體驗，我們要盡量讓 LCP 小於 2.5 秒。

CLS (Cumulative Layout Shift)：中文是「累計版面配置位移」，評估視覺穩定性。為了提供良好的使用者體驗，我們要盡量讓 CLS 分數低於 0.1。

INP (Interaction to Next Paint )：中文是「下一個顯示的內容互動」，評估回應速度。我們要盡量讓 INP 分數低於 200 毫秒。

Google 把網站體驗核心指標加入排名演算法中，作為評估網站體驗的重要指標。

這表示在做 SEO (搜尋引擎優化) 時，我們需要優化 LCP、CLS、INP 等等指標。

網站如果有好的網站體驗核心指標分數，就能在 Google 搜尋結果中拿到更好的排名，也能帶來更多自然流量。

INP 是我們今天要討論的核心主題。

優化 INP 指標不只能提升網站的 SEO 成效 ，也能帶給使用者更順暢的瀏覽體驗。

當瀏覽體驗提升後，網站在 Google 的排名也會跟著上升。

INP (Interaction to Next Paint) 如何影響 SEO？

INP (Interaction to Next Paint) 可以用來衡量網站對使用者互動的整體回應性能。

網頁的回應速度對使用者體驗有很大的影響。

當網頁能快速反應使用者的操作時，不只能讓使用者更願意和網頁互動，也能讓他們感到更滿意。

Google 最近把「與下一個顯示的內容互動」(INP) 納入核心網路評估指標。

INP 能夠評估使用者和網站的互動體驗品質，而且會直接影響網站在 Google 搜尋結果的排名。

想要在 Google 搜尋結果中獲得更好的排名，維持良好的 INP 數值是非常重要的。

INP、LCP、CLS 是少數 Google 會明確公布分數的 SEO 影響因素，所以我們應該把握機會，好好優化這些指標來提升 SEO 的整體效果。

以下是 INP 能間接或直接影響 SEO 的原因：

• INP 是 Google 網站體驗核心指標：Google 會在搜尋結果中，優先展示那些能提供良好使用者體驗的網站
• 跳出率：如果網站 INP 分數太高，使用者很容易失去耐心就離開網頁了。這樣不只會提高網站的跳出率，還會讓 Google 認為這個網站品質不佳，因而影響搜尋排名
• 停留時間：良好的 INP 分數能讓使用者更願意在網頁上停留更長時間，瀏覽更多內容。較長的停留時間表示使用者對網頁內容感興趣，這對 Google 來說是正面訊號
• 轉換率：流暢的網頁互動體驗可以幫助使用者更輕鬆地完成目標，像是填表單或是購買商品。當使用者能順利完成這些動作，網站的轉換率就會提高。高轉換率通常代表網頁提供了良好的使用者體驗，這也會對 SEO 帶來正面的影響。

如何測量 INP 指標並找出導致 INP 的問題？

要改善 INP，我們必須先找出實際影響網站反應速度的原因。

透過分析現場數據 (Field Data) 和實驗室數據 (Lab Data)，我們就能測量和評估 INP。

現場數據 (Field Data)

現場數據是指從實際使用者收集的數據，所以也可以稱為「實際使用者數據」，最能反映網頁在實際使用環境中的效能表現。

• PageSpeed Insights 的實際使用者體驗資料：
  只要收集到足夠的 Chrome 使用者體驗報告 (CrUX) 資料，PageSpeed Insights 就會在頁面上方顯示實際的 INP 分數。這個工具的好處是樣本數量大，能真實反映使用者的體驗。不過它也有限制，只能提供網站整體或單一頁面的 INP 分數，無法看到每個互動的細節資料。
• 即時使用者監控 (RUM) 數據：
  RUM 工具會在使用者的瀏覽器執行 JavaScript 程式碼，記錄使用者和網頁的互動資料。你可以透過 DebugBear 來收集數據。這些資料包括 INP 數值、造成 INP 延遲的網頁元素、互動時間點和互動類型等細節。

實驗室數據 (Lab Data)

實驗室數據是在模擬環境下收集的資料，通常透過瀏覽器開發者工具或線上測速工具來取得。這種方式雖然快速方便，但無法完全反映實際使用者的環境和行為模式。

• PageSpeed Insights 的效能診斷資料：
  PageSpeed Insights 會在頁面下方顯示經實驗室數據計算出的 INP 相關指標，包括總封鎖時間 (TBT)。也會給出一些診斷建議，像是避免 DOM 過大，以及盡量減少第三方程式碼的使用量等等。
• Chrome 開發者工具：
  Chrome 開發者工具中的「效能分析器」和「網路面板」可以幫你記錄網頁載入時的細節資訊，還能分析 INP 的相關實驗室數據。你可以用它來模擬不同的網路條件和裝置環境，讓測試結果更貼近實際使用者的情況。

INP 計算方法

INP 分數代表所有「使用者互動延遲時間」的第 98 個百分位數，這表示 98% 的使用者互動都比這個分數還快。

換個說法，只有 2% 的互動延遲時間會比 INP 分數更長。

計算網頁的 INP 分數時會使用第 98 個百分位數，這主要是為了過濾掉異常值。

當網頁的互動次數很多時，很容易出現一些極端的延遲情況，但這些延遲往往和網頁的整體表現沒有太大關係。

舉例來說，假設使用者在瀏覽網頁時有 100 次互動，其中 98 次的延遲時間都在 180 毫秒內 (包含 180 毫秒)，另外 2 次的延遲時間分別是 800 毫秒和 1000 毫秒。

在這種情況下，這個網頁的 INP 分數會是 180 毫秒，而不會是 800 毫秒或 1000 毫秒 (極端值被排除了)。

INP 在單次頁面瀏覽中的計算方式會依據互動次數而有所不同。

當頁面互動次數在 50 次以下時，系統會直接取用最差的互動延遲時間作為 INP。但如果互動次數較多，就會採用第 98 百分位的互動延遲時間來計算。

Google 在評估網站整體網站體驗核心指標時，主要看的是大量訪問中 INP 第 75 百分位的數據。

這代表要有 75% 的使用者體驗都要達到目標值才算及格。

而要讓使用者有良好的使用體驗，每次訪問 INP 必須盡量控制在 200 毫秒以內。

INP 工具

以下跟你分享幾個好用的工具來幫助你測量跟分析 INP。

1. Google Search Console

Google Search Console 會顯示哪些網址通過指標，哪些沒通過。

2. PageSpeed Insights

PageSpeed Insights 上方顯示的數據來自實際使用者數據，這些數據是根據過去 28 天的 Chrome 使用者體驗報告 (CrUX) 資料計算得出的，因此它不是即時數據，而是反映了一段時間內的累積效能表現。

實際使用者體驗數據有分成「這個網址」跟「來源」。

這個網址：目前正在測試的這個「網址 (URL)」。

來源：整個網站的平均值。當 URL 資料不足時整個網站的平均值。在流量較低的網站上，它通常會預設為「來源」。

PageSpeed Insights下面的數據是實驗室數據。雖然沒有直接顯示 INP。但你可以透過上面的診斷來優化 TBT (總阻塞時間)，進而來改善 INP。

3. DebugBear

DebugBear 是我覺得非常強大的免費 INP 工具，不僅可以搜集實驗室數據，還可以搜集現場數據。

1. DebugBear INP Debugger

DebugBear 提供免費的 INP Debugger，可以自動找出網頁上所有可以點擊的元素。系統會模擬使用者的點擊操作，分析每個互動的回應速度，並告訴你哪些互動反應比較慢。

2. DebugBear 的即時使用者監控 (RUM)

這個服務可以持續追蹤 INP 和其他網站體驗核心指標的表現。只要在網站 設定 DebugBear 提供的程式碼，就能從實際使用者收集 INP 數據，清楚掌握需要改善的網頁。你可以檢視每個使用者互動的細節資料，快速找出造成延遲的網頁元素。雖然長期使用這個功能需要付費，但我利用 7 天的免費試用期就順利解決了 INP 的問題。

DebugBear 的即時使用者監控真的是蠻厲害的，開始監測後，我們就可以看到每位使用者訪問頁面時的實際數值。

透過這個工具，我們可以更精確地知道是哪個頁面中的哪些元素導致了較高的 INP 數值 (如下圖)。

當我們掌握了造成互動緩慢的具體元素後，就能針對性地進行優化。

這個功能解決了 PageSpeed Insights 的一個明顯缺點，因為 PageSpeed Insights 只會顯示單一的 INP 數值，卻不會指出是哪些元素造成數值過高，讓開發者難以找到優化的切入點。

我的網站在優化前，行動裝置的 INP 超過 200 ms (需要改善)。在針對性地解決 INP 問題後，行動裝置的 INP 都降到了 200 ms 以下 (良好)。

4. Chrome 開發者工具

Chrome 開發者工具是一個最難上手的 INP 工具，但它是所有 INP 工具無法比擬的，因為它可以給出最詳細的資訊。

效能分析器跟網路面板可以提供許多有價值的資訊。

要解決 INP 的問題，我覺得最好的方法是先用 DebugBear 的即時使用者監控 (RUM) 來找出可能有問題的元素。找到問題之後，再透過 Chrome 開發者工具分析看看這些元素為什麼會出現問題。

效能分析器

Chrome 開發者工具裡面有一個「效能分析器」，可以幫助我們測量和優化網頁的 INP 指標。

效能分析器可以：

• 顯示網站體驗核心指標的實驗數據和現場即時數據 (這是新功能)
• 記錄效能追蹤
• 分析互動
• 識別瓶頸
• 模擬裝置 CPU 環境
• 模擬網路環境

Chrome 開發者工具的效能分析器是一個很棒的工具，它能幫助我們了解 CPU 資源的使用情況和網頁主執行緒的運作狀態。

我們可以利用它來分析使用者互動的時間數據，找出需要優化的地方。

在效能分析器裡，我們可以檢查 INP 元件的細節，看看頁面上最常發生的使用者互動，還有記錄互動過程中的 CPU 活動。

如果某個互動執行時間超過 200 毫秒，系統會用紅色條紋標記這個區塊，提醒我們這樣的互動速度不符合 Google 建議的 INP 標準。

在進行測試時，我會刻意把 CPU 速度降到原本的六分之一 (6x slowdown)，同時把網路速度調整為慢速 4G (Slow 4G)。

因為我們用來測試的電腦效能太好了，和大多數使用者的手機有很大的差距。透過這樣的降速測試，不只能更容易發現效能問題，也能更貼近使用者的真實體驗。

在這部影片 (5 分 17 秒處) 有簡單介紹怎麼使用 Chrome 開發者工具的「效能分析器」：

我這邊另外幫你整理一些學習 Chrome 開發者工具效能分析器的實用資源：

• Profile Site Speed With The DevTools Performance Tab (使用開發者工具效能面板分析網站速度)
• How To Improve INP With Chrome DevTools (如何使用 Chrome 開發者工具改善 INP)
• Brand New Performance Features in Chrome DevTools (Chrome 開發者工具的全新效能功能)
• Optimizing INP: A deep dive (優化 INP：深入探討)
• How to Improve Interaction to Next Paint (INP) (如何改善 INP)

另外，Chrome 開發者工具中的「網路面板」能幫你詳細分析網站的網路活動，方便找出相關影響效能的問題。

網路面板可以：

• 查看網路請求
• 分析網頁載入時間
• 檢查請求和回應的詳細內容
• 模擬網路環境。

我這邊幫你整理一些學習 Chrome 開發者工具網路面板的實用資源：

• The Chrome DevTools Network Tab: Debug PageSpeed (Chrome 開發者工具網路面板：調試頁面速度)
• Inspect Network Activity – Chrome DevTools 101 (檢查網路活動 – Chrome 開發者工具入門教學)

優化 WordPress 網站的 INP 指標的原理與方法

接下來，我來說明如何改善 INP 指標的原理和方法，這部分涉及比較進階的技術內容。

我自己也是為了讓 INP 指標變成良好，所以努力嘗試學習這些內容。

我當初雖然讀了很多技術細節，最後卻發現這些資訊對改善 INP 沒有直接的幫助。

這是因為和大多數使用 WordPress 架站的站長一樣，我沒辦法自己修改主題和外掛的程式碼。

為了幫助大家，我特別整理了一段不需要寫程式就能改善 INP 分數的實用方法。如果你想要立刻開始改善 INP，可以直接 點擊連結，跳過這段技術細節的說明。

好，那我們來說明優化 WordPress 網站 INP 指標的原理和方法，你只需要大概看過，知道最底層有這些棘手的東西需要改善就好。

導致 INP 問題的原因

要減少 INP 數值，最有效的做法就是盡量減少網頁執行的 CPU 運算量。

以下是導致 CPU 運算量過高的主要原因，我們要避免「過多的長任務」跟「過大的 DOM 結構樹」。

1. 過多的長任務

網頁在載入與互動過程中，瀏覽器的主執行緒需同時處理 HTML、CSS、JavaScript，以及第三方資源的解析與執行。

如果任務持續超過 50 毫秒，就會被認為是長任務，會阻塞主執行緒，造成滑鼠點擊或操作後，畫面無法即時回應。

造成長任務的可能因素如下：

• JavaScript 程式碼效率低落： 複雜和低效的 JavaScript 程式碼會產生長任務，讓畫面卡頓。
• 第三方腳本： 像是廣告、流量分析工具 常常會消耗大量的 CPU 運算資源，這些腳本運行時會產生很長的處理時間，影響網頁的效能。
• 未妥善處理的事件回調：如果事件回調 (callback) 函式的執行時間太長，就會產生阻塞的長任務。

主執行緒的任務最直觀的方法是用 Chrome 開發者工具 來查看。

以下是主要執行緒的任務範例：

任務	優先級
解析 HTML	緊急
建構 DOM	緊急
產生佈局樹	緊急
處理 CSS	緊急
處理 JavaScript	緊急
其他無數任務	也很緊急

2. 過大的 DOM 結構樹

DOM 結構樹是一種用來表示 HTML 文件的層次化結構，就像一棵樹一樣把網頁的架構和內容展示出來。

每個樹上的節點都對應到網頁中的一個部分，可能是一個 HTML 標籤、一段文字或是一個註解。透過這樣的結構安排，程式就可以很方便地找到和修改網頁裡的任何內容。

DOM 本身不是問題，但它的大小可能是問題。較大的 DOM 大小會影響瀏覽器快速有效呈現頁面的能力。

當網頁的文件物件模型 (DOM) 超過 1,400 個節點時，就會被視為結構過大。

以下我列出幾個可能造成過大的 DOM 結構樹的因素：

• 文章或頁面過長：長篇網頁通常包含許多內容元素，會讓頁面的 DOM 結構變得更加龐大。
• 使用頁面編輯器：頁面編輯器 (例如 Elementor 或 Divi) 雖然方便，但它們通常會在頁面中添加大量的 HTML 標籤，導致 DOM 結構樹過於複雜。
• 行動裝置選單：複雜的行動裝置選單也會增加 DOM 大小。

如何解決 INP 問題

造成 INP (Interaction to Next Paint) 數值過高的原因主要是因為「過多長任務」和「過大的 DOM 結構樹」導致 CPU 運算量太大。

那我們要怎麼解決這個問題呢？

以下是我從參考資料整理出的一些解決方法，但有點過於技術取向，但對於進一步了解怎麼優化 INP 是有幫助的。

如果你只是單純想知道一般不懂程式碼的站長如何解決 INP 問題，可以稍微看過有個印象就好，或是直接跳到 後面的章節，看看我們能採取什麼實際行動來改善 INP 。

你可以透過以下 3 個方法來嘗試解決 INP 過高的問題：

1. 縮短關鍵渲染路徑
2. 加快 WordPress 後端的處理時間
3. 優化網站前端互動

1. 縮短關鍵渲染路徑

關鍵渲染路徑是瀏覽器將 HTML、CSS 和 JavaScript 轉換成可視頁面的過程。如果能縮短此過程，網頁將能更快呈現關鍵內容，減少使用者等待與互動延遲。

1.1 減少與優化關鍵資源

• 精簡與動態載入 JavaScript：
  不再僅將多個 JS 檔合併為單一大檔，而是利用程式碼分割 (Code Splitting) 及延遲載入 (Lazy Loading)，讓頁面僅在需要時載入對應功能的程式碼。
• 移除未使用的程式碼與資源：
  刪除未使用的 CSS 選擇器、JavaScript 函式及函式庫，並可利用 Tree Shaking 精簡程式碼，減輕載入量。
• 內聯關鍵 CSS：
  將關鍵樣式直接內聯至 HTML，以降低額外請求並加速初始內容呈現。
• 圖片與字體優化：使用適當格式（如 WebP）與圖片壓縮技術，並採用字體子集與自託管字體檔案，以縮短載入時間並提升頁面渲染效率。

1.2 優化載入順序

• CSS 優先、JS 延後：
  將 CSS 放在 <head> 中，JavaScript 放在 <body> 底部，確保頁面框架與樣式優先呈現。
• 非同步或延遲載入 JavaScript：
  使用 <script async> 、 <script defer>，或將 JavaScript 設定為在最終渲染完成後載入，以避免阻塞頁面呈現。

1.3 利用瀏覽器快取

• 設定 Cache-Control：
  使用適當的快取標頭使瀏覽器重複使用資源，減少重新下載時間。
• 版本號控管：
  當更新資源時變更版本號，以確保使用者取得最新版本。

1.4 簡化與優化 DOM 結構樹

透過精簡 DOM 結構，可減少瀏覽器在解析、建構 DOM 時的壓力，降低長任務產生的機會，進而改善 INP 分數。

• 控制內容長度與結構：
  將過於冗長的內容分成多頁或摘要，減少單頁面上的 DOM 節點數量。
• 使用輕量化的主題與版面設計：
  選擇程式碼精簡的佈景主題與模板，減少額外標籤與不必要的容器。
• 審視頁面編輯器輸出：
  使用 Elementor 或 Divi 等頁面編輯器時，審查並刪除不必要的區塊、元素，或調整設計以減少不必要的嵌套標籤。
• 精簡行動裝置選單與導覽元素：
  確保選單結構精簡，避免過度複雜的下拉選單、巢狀清單，以控制 DOM 節點數量。

2. 加快 WordPress 後端的處理時間

提升主機效能 (後端優化) 與 WordPress 本身的執行效率能加快頁面產生速度，減輕前端負載。

2.1 主機端優化

• 使用最新版本的 PHP、資料庫：
  更新 PHP 與 MySQL/MariaDB 有助提升處理效率。
• 主機與快取機制選擇：
  使用 SSD 硬碟、啟用 PHP Opcode Cache，並利用 CDN（如 Cloudflare）分散靜態資源提高載入速度。
• 程式碼優化：
  精簡主題及外掛程式碼，減少不必要的查詢與邏輯運算。

2.2 精簡外掛

• 減少外掛數量：
  刪除不必要的外掛，改用主題內建功能或輕量替代工具。
• 選擇經過效能優化的外掛：
  選擇效能良好、程式碼簡潔的外掛，減少對 WordPress 執行時間的負面影響。

3. 優化網站前端互動

在頁面加載後的互動過程中，確保使用者操作時可快速得到回應。

3.1 優化 JavaScript 執行策略

• 精簡 JavaScript 檔案：
  壓縮及刪除未使用程式碼，並使用 Tree Shaking 減少執行負擔。
• 延遲或異步載入 JavaScript：
  使用 <script async> 、 <script defer> 或條件式動態載入 JS，降低主執行緒阻塞。
• 使用 Web Worker：
  將繁重的計算任務移至 Web Worker 執行，減少主線程負載，維持 UI 流暢度。

3.2 簡化動畫與特效

• 減少不必要動畫：
  僅在必要處使用簡單的淡入淡出、滑動特效。避開複雜 3D 效果以降低 CPU/GPU 壓力。
• 使用優化的動畫工具與 CSS 動畫：
  使用經過效能優化的輕量動畫庫或純 CSS Transform、Opacity 等高效能屬性。

3.3 控制第三方腳本

• 刪除不必要的第三方腳本：
  審查社群分享按鈕、廣告、分析工具程式碼，刪除不必要的外部資源。
• 異步與延遲載入第三方腳本：
  使用 async 或 defer 屬性，或透過腳本管理工具延遲第三方資源的執行。
• 選擇優化的第三方資源：
  優先使用輕量化、效能良好的第三方工具，或考慮自託管以降低延遲。

備註：
某些方法，例如使用 async 或 defer 屬性，可能會在不同的解決方案中出現，這是因為它們具有多重作用，能從不同角度同時改善 INP。

好，這些技術細節大致了解之後，接下來，我們就能進入實際我們應該可以採取什麼行動有效地優化 INP 指標了。

我的經驗：優化 INP 指標有用的實際行動

在這個章節中，我會分享一些能解決 INP 問題的實際行動。你不需要了解程式碼和技術細節，也能輕鬆上手。

我們會從主機、主題和外掛這三個面向著手改善，讓原本棘手的 INP 問題變得容易解決，有效優化網站的 INP 指標。

我們目標是要減少 INP 數值，讓 互動延遲 盡量控制在 200 毫秒內。

而要減少互動延遲，我們的核心目標是要降低瀏覽器在使用者設備上的 CPU 運算負載，然後加快主機端資料處理和傳輸速度。

雖然要達成這個目標會牽涉到很多技術細節，我們很難完全掌握，不過我們可以把重點放在自己能夠控制的部分，包括主機、主題和外掛的選擇和設定。

根據實際測試結果，只要做到以下三點，就可以讓我們的 WordPress 網站順利通過 INP 要低於 200 毫秒的門檻，不論是在電腦或行動裝置上都沒問題：

1. 選擇速度快的主機
2. 選擇輕量級主題
3. 慎選外掛

1. 選擇速度快的主機

選擇速度快的主機可以「加快 WordPress 後端的處理速度」，不僅能更快處理資料，還能提升傳輸效率，達到優化 INP 的目標。

如果你目前使用 Bluehost、Hostinger 或 A2 Hosting 這類較便宜的共享主機，建議可以升級到像 Cloudways 這樣的管理型雲端主機。

Cloudways 主機的資料處理跟傳輸速度都比共享主機快上不少，能降低互動延遲，優化 INP。

你現在看到的 諾特斯網站 就是使用 Cloudways 主機通過 INP 指標的門檻。

Cloudways 最便宜的方案每個月最低是 $11 美金 (約 $330 台幣)，如果你有心想解決 INP 問題的話，從共享主機搬家到 Cloudways 主機會是一個直得的投資。

備註：
台幣價格是用美金兌台幣匯率 30 來估算。不過，因為匯率會隨時間浮動，實際的台幣價格還是要看交易時的匯率喔。

⭐ 相關免費筆記

如何從 Bluehost 主機搬家到 Cloudways 主機

備註：如果你需要從其他共享主機搬家到 Cloudways，歡迎 透過這裡聯絡我。有機會我會專門為你製作免費的搬家教學。

以下我列舉一些選擇速度快／優質的主機能改善 INP 的原因：

1. 縮短輸入延遲

• 加快資源傳輸速度：
  優質主機配備了強大的硬體設備和穩定的網路連線，可以更快速地將網頁內容傳送到使用者的瀏覽器，讓網站回應更快。
• 提供額外的功能：
  良好的主機會針對 WordPress 進行優化，並提供 GZIP 或 Brotli 壓縮等功能，縮減檔案大小並加快傳輸速度，進一步減少輸入延遲。

2. 加快 WordPress 後端的處理時間

• 提升伺服器端程式碼執行效率：
  主機效能直接影響 WordPress 伺服器端 PHP 程式碼的執行速度。高效能主機可以縮短程式碼處理時間，加快網頁回應速度。
• 優秀的資料庫效能：
  好的主機服務商會提供優質的 MySQL 或 MariaDB 資料庫環境，像是配置更快速的 SSD 儲存設備，並且調校資料庫參數。這些優化可以讓資料庫執行效能更好，加快查詢速度和資料處理的時間，最終改善網站的 INP 表現。

2. 選擇輕量級主題

選擇輕量級 WordPress 佈景主題，可以同時「縮短關鍵渲染路徑」和「優化網站前端互動」，進而優化 INP。

很多人在挑選 WordPress 佈景主題時，隨意找個看得順眼的就開始製作網站了。

但是，有些主題的程式碼設計過於臃腫 (結構複雜且效率低下)，不僅會讓網站運作變慢，也會導致使用者和網站互動時的反應速度變差，最後使 INP 指標表現不佳。

我推薦以下 3 個輕量級 WordPress 主題：

1. GeneratePress：最輕量級的 WordPress 主題，對 INP 優化效果最佳。但是在調整某些網頁設計時，可能需要使用一些 CSS 程式碼才能達到目的。建議稍微對 CSS 有概念的人使用。
2. Blocksy：佛心的 WordPress 主題，免費版就夠用了，能有輕鬆過 INP 指標門檻。它的程式碼簡潔且執行效率高。在自訂設計彈性和程式碼輕量化這兩個面向上，取得了很好的平衡。你看到的 這個網站 就是使用 Blocksy 主題。
3. Astra：由知名公司 Brainstorm Force 開發的 WordPress 主題，擁有超過 1,400 萬次下載量。其程式碼精鍊且高效，同時提供豐富的自訂功能與設計選項，是可以通過 INP 指標門檻的主題。不過，缺點是完整功能需要付費才能解鎖。

另外，選用一個好的主題之後，我們可以做一些對 INP 指標加分的設定。

1. 簡化選單設定

在行動裝置上複雜的選單通常是導致 INP 數值過高的原因。

行動裝置上最常見的選單設計，就是三條橫線組成的漢堡選單圖示，點擊後會滑出真正的選單。

我自己在用 DebugBear INP debugger 發現行動版的選單導致 INP 問題後，比較激進地把行動版的選單功能移除了，然後在原本的位置改放一個重要的按鈕取代。

你可以先選擇移除行動版選單，或是把行動版選單改得簡潔一點，都能有效優化 INP。

2. 移除不必要的文章元件

在測試中我發現，每移除一個元件，確實都能多少降低 INP 數值，但是都不多，讓 INP 數值降最多的是移除留言功能。

備註：我在通過 INP 測試後，又嘗試把留言功能打開。一個月後重新測試，還是有通過 INP 門檻，所以移除這些功能應該只有對 INP 有小加分的效果。如果你 INP 數值在 200 多一點點，可以考慮移除一些文章元件。

3. 減少主題的動態元素

可以盡量減少使用動畫、彈出視窗等功能，因為他們很容易產生互動延遲。

4. 使用裝置預設字體

我在佈景主題中把字體設定成預設字體，這樣可以減少瀏覽器的處理負擔，降低 INP 數值。

備註：使用者的裝置會直接顯示 iPhone、Android、Mac、Windows 系統內建的預設字體，不用另外下載和載入指定字體。

以下我列舉一些選擇輕量級／優質的主題能改善 INP 的原因：

1. 縮短關鍵渲染路徑

• 減少渲染阻塞資源：
  優質的網站主題會把次要的 CSS 和 JavaScript 檔案延遲載入，你可以使用 async 或 defer 屬性，或是把這些檔案放在網頁的底部。這樣做可以讓瀏覽器不用等這些資源下載完，就能開始解析和顯示網頁的主要內容。
• 優化程式碼：
  優質的主題會想辦法讓 CSS 和 JavaScript 檔案變得更小，像是用程式碼壓縮和合併的方式來減少檔案大小。主題也會使用精簡而高效的程式碼和演算法，讓瀏覽器可以更快地下載和解析這些檔案，減少處理的時間。
• 使用快取機制：
  優質的主題會透過瀏覽器快取和伺服器端快取來存放網頁資源。當使用者再次造訪網站時，可以直接從快取中讀取資料，不用重新下載，這樣就能加快網頁載入的速度。

2. 優化網站前端互動

• 減少 DOM 大小：
  DOM 是網頁結構化表示的方式，它的大小會直接影響瀏覽器的效能。當 DOM 結構越龐大，瀏覽器需要處理的元素也就越多，這樣會增加 CPU 的負擔。好的主題都會想辦法讓 DOM 維持在合適的大小，像是把網頁結構設計得更簡單、移除不需要的元素，或是讓內容根據需要才載入等方式。
• 優化 JavaScript 程式碼：
  JavaScript 是處理網頁前端互動的主要程式語言。如果要讓網站運作更順暢，優化 JavaScript 程式碼可以減少執行時間，也能降低 CPU 的負擔。好的網站主題會使用效率高的 JavaScript 程式碼，並且運用程式碼分割和延遲載入等技術，讓瀏覽器處理 JavaScript 的時間變得更短。
• 使用 CSS 動畫代替 JavaScript 動畫：
  CSS 動畫相比 JavaScript 動畫更省資源，因為它可以善用瀏覽器的硬體加速功能。好的主題設計會盡可能使用 CSS 動畫來完成動態效果，這樣可以降低 CPU 的負擔。
• 使用預載入技術：
  透過預載入技術，瀏覽器可以在使用者需要前，提前載入圖片、字體和 CSS 檔案等資源。這樣做不只能減少使用者的等待時間，還能讓網頁的互動回應變得更快、更順暢。

備註：
如果網站速度優化外掛跟主題功能有重複，建議關閉主題功能，避免發生衝突。

3. 慎選外掛

選擇好的 WordPress 外掛並刪除不好的外掛，可以同時「縮短關鍵渲染路徑」、「加快 WordPress 後端的處理時間」和「優化網站前端互動」，進而優化 INP。

挑選 WordPress 外掛比想像中還不容易，因為我們無法實際了解外掛開發者的程式碼品質，也不能直接判斷安裝外掛後會讓網站的 INP 表現變好或變差。

我分成兩個部分來講解：

1. 選擇一個好的網站速度優化外掛
2. 刪除對 INP 表現有負面影響的外掛

1. 選擇一個好的網站速度優化外掛

WordPress 的網站速度優化外掛有一大堆 (WP Rocket、LiteSpeed、W3 Total Cache、Seraphinite Accelerator、FlyingPress、NitroPack 等等)，有的是付費的，有的是免費的。要從這麼多外掛中找出真正有效且值得付費的速度優化工具，並不是一件容易的事。

我先講我測試出的結論，我會推薦兩款外掛，並跟你說明適合的人。

以下是我花了一百小時以上的時間測試，發現真正好用的網站速度優化外掛：

1. FlyingPress

FlyingPress 是 Google 認證第 1 名的 WordPress 速度優化外掛 (調查報告)。

外掛的開發者 Gijo Varghese 是真的深耕網站速度優化領域的專家。

我覺得他是很厲害的人， 我從他的 部落格 發現很多有價值的內容 。

目前 FlyingPress 是我最推薦的網站速度優化外掛，你看到的這個 諾特斯網站 就是使用它優化的。

FlyingPress 雖然只有付費版，但絕對是值得的投資，預算充足的人建議直上 FlyingPress。

2. NitroPack

NitroPack 也是一個非常不錯的 WordPress 速度優化外掛。

這款外掛的優點是有免費版本而且非常易用，適合前期預算有限的站長。

我用 NitroPack 有超過 1 年半以上。速度優化效果僅次於 FlyingPress。

NitroPack 缺點是付費版 CP 值沒那麼高。

接下來我說明一下我會選推薦這兩款外掛的原因。

最主要的原因是它們真的有效，而且是多功能合一的外掛。

WordPress 的速度優化其實涉及很多需要優化的項目，以下我列出幾個常見的：

1. 快取
2. 圖片優化
3. 預先設置圖片尺寸
4. CSS 壓縮
5. HTML 壓縮
6. 延遲載入
7. 延遲 JavaScript 執行
8. 嵌入式媒體優化

如果你安裝了多個網站速度優化外掛，而不是使用單一的多功能整合外掛，可能會造成衝突問題，反而讓網站速度變慢。

我建議直接安裝像 FlyingPress 或 NitroPack 這樣包含所有優化功能的整合型外掛 (擇一就好)，這樣不僅能避免衝突，也能更有效地提升網站速度。

2. 刪除對 INP 表現有負面影響的外掛

接下來講解一下要如何判斷跟刪除對 INP 表現有負面影響的外掛。

這裡非常重要，因為你可能前面都有確實做對了，但單單因為一個不好的外掛，直接拖垮 INP 分數。

好，下面我跟你分享如何找出對 INP 有負面影響的外掛的步驟。

第 1 步：創建一個測試網站

我是使用 Cloudways 主機的內建的功能 創建一個測試網站 (測試環境)。

備註：
在 Cloudways 主機創建測試環境時，會自動將 X-Robots-Tag 設定為 noindex，這樣 Google 就不會收錄這個測試網站的內容，所以不用要擔心重複內容會影響 SEO 表現。

第 2 步：在測試網站把所有外掛都停用

請確實先把所有外掛停用，在測試網站盡情亂搞沒關係。

第 3 步：啟用一個外掛

接下來，啟用其中一個外掛就好。

測試完一個之後，請把該外掛停用，再測試下一個。

這樣才能有效一一排除造成 INP 問題的外掛。

第 4 步：判斷對 INP 是否有負面影響

由於計算真實的 INP 需要收集 30 天的使用者數據，我在實測時使用了一些替代的評估方式。

為了快速檢視設定調整的效果，我會透過 PageSpeed Insights 的 TBT 數值，以及觀察 Chrome 開發工具裡主執行緒的阻塞狀況，來評估這些設定是否能改善 INP 分數。

如果你發現開啟一個外掛 TBT 飆高或是在 Chrome 開發者工具的效能分析器 (CPU 6x slowdown) 中有阻塞狀況 (很多紅色條紋)。代表該外掛很可能對 INP 有負面影響

第 5 步：重複 2-4 步

請一一測試每個外掛，雖然可能會花很多時間，但當你找到是哪個外掛造成 INP 問題時，你會覺得這些時間花得很值得的。

根據以上步驟這樣你就能找出到底是哪個外掛拖垮 INP 分數了。

以下跟你分享一些可能對 INP 有負面影響的外掛。

1. 錨點設定外掛

我發現 Page scroll to id 會導致主程序封鎖產生很多阻塞 (在 CPU 6 被降速的狀況才明顯)。

這個外掛會持續監測滾動位置（scroll position），並頻繁觸發重新計算佈局（recalculate layout），從而增加瀏覽器的運算負擔。

我已經用這個外掛設定錨點很 3 年了，但後來發現這個外掛其實可以刪掉，用 WordPress 內建的 HTML 錨點功能就可以了。

2. 燈箱外掛

我原本有使用燈箱外掛，讓訪客點圖片時可以放大圖片。

但是，我發現各種燈箱外掛，就算是標榜輕量級的燈箱外掛都多少會讓 INP 扣分。

所以最後我索性就都把燈箱外掛刪掉了。

3. 頁面編輯器

在使用 Elementor 或 Divi 這類頁面編輯器時，雖然可以讓你很方便地設計網頁，但在優化 INP 效能時要特別小心。

這些頁面編輯器會產生大量臃腫的 HTML 程式碼，讓網頁的 DOM 結構變得過於龐大，最後會影響網頁的載入速度和使用者的互動體驗。

解決的辦法是盡量使用 WordPress 內建的古騰堡編輯器配上輕量化區塊外掛 (推薦 GenerateBlocks 或 Kadence Blocks)，來設計頁面。

這類區塊外掛會提供一些核心區塊，像是容器、標題和按鈕等。你可以靈活組合這些基本區塊，打造出複雜的頁面設計。

但我還是有保留 Elementor 頁面編輯器外掛來讓原本使用 Elementor 製作的頁面能順暢運行。

但未來我會盡量使用內建的古騰堡編輯器配上輕量化區塊外掛來設計頁面，避免使用頁面編輯器。

4. 其他外掛

雖然我原本就沒有在使用「動畫外掛」、「輪播圖片外掛」、「彈出視窗外掛」，但 參考資料 中有看到他們會對 INP 造成負面影響，所以也建議你盡量避免使用。

以下我列舉一些「選擇好的外掛」和「刪除不好的外掛」能改善 INP 的原因：

1. 縮短關鍵渲染路徑

• 延遲所有腳本：
  FlyingPress 和 NitroPack 可以延遲載入非關鍵 JavaScript，直到使用者互動或頁面載入完成後才執行，從而減少阻塞主執行緒的時間，加快頁面渲染速度。
• 移除未使用的 CSS：
  FlyingPress 和 NitroPack 可以識別和移除頁面上未使用的 CSS 程式碼，從而減少檔案大小，加快頁面載入速度
• 啟用壓縮技術：
  FlyingPress 和 NitroPack 外掛可以啟用 GZIP 或 Brotli 壓縮，縮小 HTML、CSS 和 JavaScript 檔案的大小，加快伺服器傳輸速度，進而改善 INP

2. 加快 WordPress 後端的處理時間

• 移除非必要功能：
  FlyingPress 的 Bloat Settings (冗餘設定) 有移除 WordPress 不必要設定的功能，能減少主機負擔，加快後端處理速度。
• 使用 CDN：
  FlyingPress 的 FlyingCDN 功能會自動與 Cloudflare 的 CDN 整合，加快主機回應速度。

3. 優化網站前端互動

• 減少 DOM 大小：
  盡量減少使用 Elementor 或 Divi 頁面編輯器增加 DOM 大小
• 避免過度使用 JavaScript 動畫和特效：
  動畫和特效可能會消耗大量的 CPU 資源，導致 INP 分數較差。
• 使用高效能的 JavaScript 程式庫和框架：
  好的外掛會選擇經過效能最佳化的程式庫和框架，可以減少 JavaScript 程式碼的執行時間。

優化 INP 時的心態與提醒

我來分享一下優化 INP 時的心態和一些小提醒。

在優化的過程中，你可能會感到無助、沮喪或煩躁，但這些感受都很正常。因為實驗結果往往不如預期，需要嘗試很多不同的方法才能達到目標。

但當你的網站體驗核心指標 (Core Web Vitals ) 通過時，一切都會是值得的！

網站體驗核心指標目前有三個，包含 LCP、CLS 和 INP。

INP 是其中我覺得最難優化的。

INP 優化是一個持續的過程，並不是花一天時間就可以處理好的問題。需要同時觀察實驗室指標跟現場指標來優化。

測量 INP 的工具也很多，每個工具測出來的數據可能也會有差異。

我推薦一開始先用 PageSpeed Insights 為主要測量工具就好。

因爲它是 Google 官方推出的軟體，而且同時有現場數據，也有實驗室數據 。

現場數據 (也稱為實際使用者數據) 是上面的網站體驗核心指標評估，會顯示有沒有通過。

實驗室數據是下面的診斷效能問題，會顯示效能分數跟診斷建議。

建議在測試時不要只測首頁，文章跟頁面也要測才能有效改善 INP。

因為下面的診斷建議有分數，所以很多人都拼命想把他優化到 90 分以上 (綠色)。

但是，PageSpeed Insights 的實際使用者數據 (上面的網站體驗核心指標評估) 通常代表體驗最慢的 25% 使用者的情況。

而實驗室數據（下面的診斷效能問題）則通常模擬網路條件較差的場景，接近速度最慢的 5% 到 10% 使用者的體驗。

所以診斷出下面的分數比較低是可以接受的，因爲它是模擬中低階手機 (Moto.G.Power) 網路慢速 4G 的狀況，目的是為了讓站長發現可能的效能問題。

通過 PageSpeed Insights 上面的網站體驗核心指標評估才是重要的。下面實驗室數據的效能分數當作輔助參考就好。

所以在網站速度優化的社群才會流傳以下這張梗圖。

如果只求效能分數 90 分以上，那測一個空白頁面一定會很接近 100 分。

我們要有耐心地等 Google 搜集 30 天的實際使用者數據，優化網站體驗核心指標的 INP，直到通過為止。

診斷跟效能分數參考看看就好。

如果一些剛開始的網站缺乏流量，沒有足夠的實際使用者數據，而沒辦法顯示網站體驗核心指標評估的話，建議參考診斷的 TBT 部分就好，先不要太在意效能分數。

照著我前面寫的 優化 INP 指標有用的實際行動 的建議改善，不需要刻意追求效能分數 90 分以上。

以我自己的經驗來說，就算我有能力把行動版的分數優化到 92 分，但是我知道這樣需要推遲一些 Javascript 腳本。這樣可能會讓 Google Analytics、Google Ads 的數據收集變得不精準。

所以在經過一番思考過後，我還是選擇在能通過網站體驗核心指標的前提下，不要推遲所有的 Javascript，讓行動裝置的效能分數有時可能會低於 90 分，目的是為了讓網站的數據搜集變得更精準。

如果你需要埋設追蹤程式碼、安裝一些客服聊天外掛，或是用好看的動畫讓使用者的體驗變更好，就算效能分數會變低一點也請放心去做，只要你知道你這麼做的目的就好。

跟你分享一個例子，就算是像 Apple 這樣的大公司，花了高額的薪水請工程師優化，他們也只是做到通過網站體驗核心指標評估，但效能分數只有紅色 48 分。

舉這個例子是為了告訴你，效能分數沒有辦法達到 90 分以上也不用太灰心。

我們不需要追求完美的效能分數，只要盡力達到讓「網站體驗核心指標評估通過」就好。

做網站的主要目的還是要放在持續提供有價值的內容，而不是追求表面的效能分數。

結語：改善 INP 讓網路世界變得更好

優化 INP 的過程真的會讓人感到很挫折，我也想過 Google 幹麻這樣搞我們，要我們通過這麼麻煩的指標。

但其實優化 INP 真的是能讓我們的網站體驗變得更好，當我通過所有網站體驗核心指標後，我真的感覺到瀏覽我的網站真的變得很絲滑。

就算是在模擬中低階設備和網路環境較差的狀況，也能做到比較不卡頓。

Chrome 團隊發表了一篇 文章，分享了他們在優化網站體驗核心指標上的成果。

根據這篇文章的內容，這些優化幫網路使用者省下了相當於 10,000 年的等待時間。

10,000 年耶！我們改善網站體驗核心指標真的是可以讓網路世界變得更好。

也希望我寫的這篇筆記，也能為網路世界稍微帶來一點正面的幫助。

參考資料

• Measure And Optimize Interaction to Next Paint (INP)
• How to optimize Interaction to Next Paint (INP) in WordPress
• How to Improve Interaction to Next Paint (INP) in WordPress – A Hands-On Guide
• Interaction to Next Paint (INP): What It Is & How to Improve It
• A faster web in 2024 – rviscomi.dev
• Chromium Blog: How Core Web Vitals saved users 10,000 years of waiting for web pages to load
• Core Web Vitals Technology Report
• Set Up Real User Monitoring
• How To Improve INP With Chrome DevTools
• Brand New Performance Features in Chrome DevTools
• Optimizing INP: A deep dive
• How to Improve Interaction to Next Paint (INP) | Google and NitroPack Webinar
• The Chrome DevTools Network Tab: Debug Page Speed
• Inspect Network Activity – Chrome DevTools 101
• DOM Size Test
• How To Optimize Interaction to Next Paint
• Measure And Optimize Total Blocking Time (TBT)
• First Input Delay (FID)
• FlyingPress Ranks #1 in Chrome UX Report for Core Web Vitals
• WP Speed Matters
• How to Create a Staging Environment
• 與下一個顯示的內容互動 (INP)
• 在開發人員工具中監控本地和實際使用者的 Core Web Vitals 效能
• 總封鎖時間 (TBT)