揭秘 WordPress 的核心網絡生命力

Core Web Vitals 現在代表了一組用於優化網站的強制性指標，尤其是在 SEO 和網站性能對您的數字策略很重要的情況下。 儘管如此，在嘗試改進您網站上的 Core Web Vitals 時，可能很難確定哪些 WordPress 工具和策略最重要。

觀看本次會議，深入了解用於理解和改進 WordPress 網站上的 Core Web Vitals 分數的最佳實踐和工具。

演講嘉賓：

• WP Engine 產品經理 Alex Zuniga
• Amsive Digital 網絡開發總監 Mark Davoli
• Vital Design 開發總監 Matt Chase
• WP Engine 高級 Web 開發人員 Sanjucta Ghose
• XWP 前端工程總監 Mike Crantea

成績單：

ALEX ZUNIGA：大家好，歡迎來到揭秘 WordPress 的 Core Web Vitals。 我是 Alex Zuniga，WP Engine 的產品經理。 今天，我們真的要討論您的 WordPress 網站的核心網絡生命力的來龍去脈。 如果您關心優化網站的 SEO 和網站性能，核心網絡生命力是一個必須優化的指標。 但可能很難知道哪些 WordPress 工具和策略最有影響力。 因此，加入本次會議，深入了解最佳實踐和工具如何幫助您提高 WordPress 的網絡重要分數。

現在，事不宜遲，我們將介紹本次會議的小組成員。 首先，我會請 Mike 做一個簡短的自我介紹。

邁克·克蘭蒂亞： 大家好，我是邁克·克蘭蒂亞。 我位於西班牙加那利群島。 我是 XWP 的前端工程總監，過去 17 年我一直在那里工作。 主要在前端技術領域，我喜歡網絡性能。 我很高興來到這裡。 嘿。

亞歷克斯祖尼加： 謝謝邁克。 接下來，我們有馬特蔡斯。

MATT CHASE：我是新罕布什爾州樸次茅斯 Vital Design 的開發總監。 我的工作重度關注前端。 所以我們做了很多 lighthouse 和 Core Web Vital 評分。

亞歷克斯祖尼加：太棒了。 謝謝，馬特。 還有馬克。

MARK DAVOLI：大家好，我是 Amsive Digital 的 Web 開發總監 Mark Davoli。 一直專注於我們團隊的 Core Web Vital 空間，因為 SEO 對我們公司非常重要。 因此，Core Web Vitals 也是如此。 很高興來到這裡。

ALEX ZUNIGA：很高興有你，伙計。 最後但同樣重要的是，Sanjucta。

SANJUCTA GHOSE： 大家好。 我也來自 WP Engine。 我是負責維護 WP Engine 網站的團隊的一員。 這包括 WP Engine 收購 Delicious Brains 時出現的網站。 去年我花了很大一部分時間為 Core Web Vitals 優化 Delicious Brain 網站。 所以我認為這應該是一次非常有趣的對話。 很高興來到這裡。

亞歷克斯·祖尼加： 謝謝。 謝謝。 那麼，歡迎來到我們所有的小組成員。 我們迫不及待地想听聽您的意見。 因此，當涉及到 Core Web Vitals 時，我們將通過衡量、管理、工具和客戶期望來分解這些問題。 所以我們想問大家的第一個問題是，我為什麼要首先關心 Core Web Vitals？ 我應該在多大程度上關注 Core Web Vital 優化？

MARK DAVOLI： 如果你願意，我可以談談。 對我來說，確保您擁有快速的頁面速度非常重要。 重要的原因在於最終結果的轉換。 正確的？ 因此，當有人訪問網站時，加載時間越長，他們離開的可能性就越大。 而且，如果您的頁面速度不快，那麼您將不走運並可能失去很多業務。 特別是在電子商務商店。

SANJUCTA GHOSE： 是的。 我有點同意您所說的，因為雖然它對 SEO 非常重要，但我們還需要記住，Core Web Vitals 是衡量您網站感知性能的指標。 用戶如何看待您的網站。 而且我認為，讓用戶注意到您的網站具有響應性、交互性和穩定性，這一點非常重要。 哪些是 Core Web Vitals 衡量的指標。 所以我認為用戶對你的表現的看法比 SEO 分數更重要。 這就是為什麼我們應該關注 Core Web Vitals。

亞歷克斯·祖尼加：當然。 馬特，你有——

MATT CHASE：是的，基本上，這就是我要說的，是的，SEO 方面很棒。 但最終，我們為人們編寫這些網站。 我們希望這些人擁有最快、最活潑的網站。 但這會影響兩個世界。 正確的？ 所以我們有點——當我們針對這些 Core Web Vitals 進行調整時，我們正在做很棒的用戶體驗。 但以一種讓 SEO 團隊滿意的方式，這有時並不總是一場容易獲勝的戰鬥。 所以它適用於每個人。

ALEX ZUNIGA：綜上所述，我們知道這很重要。 但是衡量我們分數的最佳方法是什麼？

MARK DAVOLI：因此，除了使用之外，我們的衡量方式之一是 Google 的 Page Speed Insight Tool，這很重要，因為這是他們用來衡量它的工具。 是的，所以如果你想產生影響，使用這個工具是至關重要的。 在 Chrome DevTools 中還有瀏覽器內的 Lighthouse，這非常重要。 Search Console 有一個很棒的頁面用戶體驗工具，可以監控過去 28 天的真實用戶指標，這對於長時間監控至關重要。

SANJUCTA GHOSE： 是的。 所以我想說 Page Speed Insights 是一個非常好的工具，因為它可以為您提供實時數據，因為核心 Web Vitals 本身基於過去 28 天的真實用戶數據。 但隨後您還可以查看基於實驗室數據的 Lighthouse 報告。 這就是您實際上可以立即改進的地方，因為您需要一些時間才能真正看到 Core Web Vitals 的改進，因為它是在一段時間內測量的。

所以如果你想提高你的分數，我認為 Lighthouse 是一個很好的工具，因為它為你提供——它告訴你有哪些機會可以提高。 因此，您可以立即嘗試實施這些機會，看看它如何提高您的分數。

亞歷克斯祖尼加：太棒了。 聽起來像是對那裡的 Lighthouse 大喊大叫。 出色的。 出色的。

MIKE CRANTEA：關於這個主題，我想補充一點，跟踪真實的用戶指標性能數據更好，以便能夠更快地對已經達到生產的性能下降做出反應。 當你在分期時，實驗室測試確實有幫助。 就像說有一種我們不想傳播的退化。 但是在生產中總會發生一些令人驚訝的事情。 無需等待數週時間讓 Search Console 和 crux 數據庫中的真實用戶指標顯示出來，通過使用 Web Vitals 庫自行跟踪它們，您可以保持領先地位。

亞歷克斯祖尼加：太棒了。 是的。 始終必須領先於有時會出現的生產意外。 好的。 好吧，感謝您回答有關測量的問題。 現在看看管理，你能做的一兩件事對 Core Web Vitals 影響最大？

MATT CHASE：所以我想我突然想到的一件事是盡可能地延遲加載。 並儘可能推遲加載所有內容。 對我來說，這是一種交鑰匙解決方案，你可以做到，並立即看到改進。 WP Rocket 有一堆非常簡單的複選框，您可以打開它們來啟用此類功能。

馬克·達沃利：是的。 對我來說，重點是我們所說的折疊渲染上方。 因此，請確保盡快呈現。 如前所述，延遲和延遲加載屏幕外的任何其他內容，以確保您獲得盡可能高的分數。 也就是說，WP Rocket 的延遲腳本功能非常出色。 但我們傾向於——就像我試圖將其限制在 GTM、谷歌廣告腳本或類似的東西上一樣。 並真正專注於改進為網站提供動力的主題的實際核心架構，以確保盡可能優化。 所以你不依賴第三方插件來產生那種性能影響。

馬特·蔡斯：哦，當然。 是的。 兩端。

ALEX ZUNIGA：明白了。 知道了。 澄清一下，你說的是 WP Rocket。 這就是延遲腳本功能？

馬克·達沃利：是的。

亞歷克斯祖尼加：太棒了。

MIKE CRANTEA：沒有得到足夠關注的一件事是緩存。 但快速的服務器響應時間並不能保證快速的體驗。 但是，如果您的服務器響應緩慢，那麼您的體驗肯定會很慢。 因此，利用所有可用的緩存層——瀏覽器緩存、對象緩存、頁面緩存——並將它們打開並發揮作用是很好的第一步。 做你的基礎知識。 然後你就可以開始工作——進行前端優化。 檢查你的腦袋裡有什麼。 等等等等。

亞歷克斯祖尼加：優秀

SANJUCTA GHOSE： 是的。 而且我認為我們也不應該忘記優化我們的圖像。 我認為這非常重要，因為現在很多網站都傾向於使用大量圖片。 所以我認為重要的是壓縮圖像，通過 CDN 提供它們，然後像您已經提到的那樣延遲加載圖像。 更重要的是，提供響應式圖像。 因此，您可以使用圖片標籤或圖像標籤的源集屬性來提供響應式圖像。 我已經看到這確實帶來了很大的改進，因為核心網絡生命力是移動優先測量。 因此，提供響應式圖像非常重要。 這是我們有時會忘記的事情。

所以我認為圖像。 還有一些非常簡單的事情，比如在構建步驟中最小化 CSS 中的 JavaScript。 我認為這也有很大幫助。 這很簡單。

馬特·蔡斯：是的。 關於這個主題，實際上，自從您提出這個問題以來，WordPress 分發了一種打包的 webpack 構建系統。 他們只是在 WordPress 腳本中調用它。 我們的代理機構為維護我們自己的 webpack 系統而苦苦掙扎了很長時間。 然後每隔八個月左右，一些節點依賴就會發生變化，並破壞我們的整個工具鏈。 但是 WordPress 為我們維護了這一點。 這是一個巨大的好處。

那裡的 webpack 我們已經開始使用動態導入來構建我們的主要 JavaScript 包。 所以我們有點在運行時導入我們的節點依賴項，而不是將它們全部捆綁到一個主要的 JavaScript 包中，這讓我們能夠真正微調控制相同類型的延遲腳本加載。 僅在特定情況下。 就像我們的塊在頁面上一樣。

馬克·達沃利：是的。 此外，我發現確保您對網站上使用的插件非常有選擇性非常重要。 安裝第三方插件可能會導致很多意想不到的過時軟件。 因此，請嘗試將它們限制在信譽良好、構建良好的插件上。 並註意那些插件加載的內容。 它真的可以幫助控制站點的性能。 不幸的是，WordPress 仍然嚴重依賴 jQuery 進行後端使用等等。 但這對於前端來說並不是必需的。 因此，如果可能的話，放棄網站前端的 jQuery 支持，並堅持使用原生 JavaScript 確實有助於提高性能。

亞歷克斯祖尼加：太棒了。 我認為我們已經開始涉足這一領域。 你提到了一些。 但是，讓我們使用工具進一步了解它。 您喜歡將哪些首選工具用於 Core Web Vital 優化？ 它們最適合什麼樣的用例？ 或者在某些情況下它們不適合？

MATT CHASE：我的意思是，它以前出現過。 但實際上，瀏覽器內的 Lighthouse 工具是我真正喜歡的，因為它是立竿見影的結果。 正確的。 Core Web Vitals 很棒，但它的力量在於它是一個隨著時間的推移而組合在一起的集合。 所以你不能真正改變一些東西並看到數字變化。 與 Lighthouse 相比，您在瀏覽器中進行更新。 您會看到本地開發環境並運行 Lighthouse 測試。 而且馬上就可以看到，哦，我的成績跳了15分。 涼爽的。 這是正確的做法。 將其推向生產。

亞歷克斯祖尼加：太棒了。 您還喜歡使用其他工具嗎？

MIKE CRANTEA： 我想對 Chrome 中的本地覆蓋功能大聲疾呼。 結合“性能”選項卡，您可以像外科手術一樣改變網站中項目的加載順序。 以及影響的大小。 它為您提供了必要的監督，讓您了解為做出某種改變而付出的努力是否值得，或者您只是喜歡將其留在那裡並專注於真正產生影響的其他事情。

MARK DAVOLI：我認為同樣重要的一件事是服務器架構監控。 正確的。 因此，您可以擁有世界上最棒的 Core Web Vitals，但如果您的服務器承受異常沉重的負載而您沒有意識到，您可能會突然發現您的第一個內容繪製急劇下降，然後影響幾乎所有其他內容。 因此，請密切關注 New Relic 之類的工具或其他僅用於監控性能的工具。 密切關注以確保您擁有適當的基礎設施來盡快呈現您的網站是至關重要的。

MIKE CRANTEA： 這就是啟用緩存並做好準備的地方。

馬克·達沃利：還有 CDN。

邁克·克蘭蒂亞： 是的。 避免一些潛在的災難。

亞歷克斯·祖尼加：非常好。 好吧，我很欣賞那裡的清晰度。 所以問題之一。 有許多優化插件可以優化 Core Web Vitals。 WordPress 插件的局限性是什麼？ 還是他們真的在優化網站？ 或者他們只是在某種程度上可能會欺騙谷歌的測量結果？ 我想這可能是一個問題，我們是否提到過使用插件或完成工作而不是依賴插件更好？

SANJUCTA GHOSE： 所以我認為插件很棒。 例如，WP Rocket 就很棒。 我們經常使用 EWWW Image Optimizer。 我認為這也很棒。 但就像我認為已經說過的那樣。 WP Rocket，你必須小心使用它，因為如果你打開延遲 JavaScript 功能，我已經看到它引入奇怪錯誤的情況。 一個錯誤。 所以我寧願有時推出我自己的解決方案而不是使用插件。 前提是你有開發專業知識。

因此，我們為 Delicious Brain 網站所做的大部分優化都是我們自己推出的，而不是使用插件。 但話雖如此，我認為插件是一個很好的起點。 因此，當您剛開始時，您可能想要，例如，在您的暫存站點上部署 WP Rocket，然後試一試，看看它是否會破壞東西。 或者它是否帶來了真正的改進。 所以我認為應該謹慎使用插件。 而且你必須知道後台發生了什麼，插件在做什麼。 以及它如何影響您的網站。

馬特·蔡斯：是的。 值得慶幸的是，我認為 WP Rocket 在最近的版本中至少在非常清楚地標記他們擁有的危險開關方面做得很好。 因為我也曾多次被延遲的腳本所困擾——甚至是那些你不會想到的，比如 CSS 優化以某種方式破壞了模型，它沒有得到說類名會使它們可見的東西. 所以那是令人興奮的一天。

但是，是的。 WP Rocket 絕對是我的首選，除了明顯的好代碼，好代碼。 正確的。 做這項工作永遠是接近它的最佳方式。 插件可以自動化東西。 但是，沒有什麼可以替代讓您的代碼真正精簡和精簡。

MIKE CRANTEA：還有一個插件被標記為實驗室類型的插件。 那是性能實驗室。 它由 WordPress 性能核心團隊完成。 儘管這聽起來很可怕，但它在我目前的所有測試中都提供了完全的穩定性。 這對於它應該是什麼以及最終在 Performance Lab 插件中的工作質量來說是非常令人印象深刻的。 所以值得一試。 幾個複選框。 那裡的一切都是安全的。 好吧，我不太確定數據庫切換。 當我讀到它時，這是更有爭議的事情。 是的。 只是不要觸摸那個按鈕。 就像他們在插件中添加了 SQLite 支持或類似的東西一樣，這絕對適用於一些較小的網站。

亞歷克斯祖尼加：有趣。

馬克·達沃利：是的。 對我來說，WP Rocket 太棒了。 我們確實限制了它在我們大多數網站上的使用，因為我們所做的大部分內容都是本地構建的。 但是 Core WordPress 中還有許多其他功能，如果使用得當，它們確實可以為您提供一個優化良好的網站。 就像使用塊編輯器而不是像 Elementor 等第三方一樣，會給網站增加很多膨脹。 因此，如果您像新的原生 Gutenberg 類型塊系統一樣構建，並真正根據需要加載文件，而不是例如在每個頁面上一次加載所有內容。 WordPress 現在內置了延遲加載功能。 因此，監控它的使用方式並適當地使用它，等等。 然後添加一個像 WP Rocket 這樣的工具來增強已有的東西。 但不能完全依賴它。

它可以幫助您到達那裡，尤其是當您的網站運行不佳時。 但如前所述，就像關鍵的 CSS 生成一樣，這些東西可能會有很多問題，因為它們會根據機器人在您的頁面上看到的內容做出很多假設。 但它無法預測不會呈現初始視圖的事物。 所以如果你有模型，如前所述，那些彈出，它不會知道這是一種可能性。 它不會為它生成 CSS，並正確地內聯它。 所以就像做一些事情，比如預加載你的關鍵字體或在首屏上渲染它。 同樣，這是關鍵。 真的是最重要的事情。

SANJUCTA GHOSE：關於關鍵 CSS 的話題，我只是想插話並提到 Addy Osmani 有一個很棒的工具，叫做 Critical。 您可以將其添加到您的構建過程中以生成您的關鍵 CSS。 這很棒。 而且非常可靠。 所以既然你提到了關鍵的 CSS，我想我會添加它。 抱歉打斷你。

邁克·克蘭蒂亞： 沒關係。 關於關鍵 CSS 的同一主題，Jetpack 團隊一直在努力使用 Jetpack Boost 插件做一些事情。 通過在 iframe 或類似的東西中呈現頁面，這是一種非常非常有趣的生成關鍵 CSS 的方式。 當它工作時提供，這是一個很好的解決方案。 如果沒有，它會告訴您，嘿，它在這裡不起作用。 繼續前進。 你需要別的東西。 獲得關鍵的 CSS 並不總是那麼容易。 另一方面，在 4 或 5 年前，關鍵 CSS 非常龐大。 它幫助了很多。

在過去的兩三年裡，隨著 HTTP/3 的進步，擁有一個呈現阻塞的關鍵 CSS 對擁有 100 KB 或一些內聯 CSS 的影響非常小。 使網站的運行速度與四五年前使用關鍵 CSS 的網站一樣快。 所以不要害怕在您的站點中使用合適大小的 CSS。 你不必擺脫它。 我見過超級優化的網站。

我們擁有關鍵的 CSS，例如 100 KB 的內聯 CSS。 以及渲染阻塞、jQuery 和其他兩個未使用的腳本。 就像，耶。 你這樣做是在破壞目的。 它可以幫助我們採用最後 5% 的方法。 但如果你從那裡開始，請看第一個。

亞歷克斯祖尼加：太棒了。 驚人的。 我認為所有這些工具。 很高興聽到那些喊叫聲。 很高興聽到這些建議和建議。 很多這樣的問題圍繞著我們的下一個問題。 專門使用 Core Web Vitals 在 WordPress 上工作有哪些獨特之處？ 是不是你必須通過插件來做到這一點，而不是通過任何其他技術堆棧來做到這一點？ 使用 WordPress 更容易嗎？ 有更多可用的工具嗎？ 正如我們剛剛提到的，你們都剛剛使用了很多工具。 使用 WordPress 更容易嗎？ WordPress 更難嗎？ 你們都拿什麼？

MATT CHASE：我認為使用 WordPress 非常容易。 所以我們談了一點——或者我提到了他們分發的 WordPress 腳本節點包，這是一種很棒的 webpack 構建系統。 他們還有 WordPress Create 塊，這是為基於 WordPress 的網站引導自定義塊的一種非常快速和簡單的方法。 但它的構建方式使得很多膠水代碼可以說是為您編寫的。 所以它已經很聰明了——馬克，你只在你應該提到的時候提到了這些腳本。 所以你知道你的街區是否正在做這件事。 你甚至不必考慮它。 所以 WordPress 使這類事情變得非常容易。

MARK DAVOLI： 是的，當然。 而且它是開源的。 正確的？ 所以你幾乎可以改變任何東西。 因此，與 WordPress 相比，當您使用封閉系統來優化 Core Web Vitals 時要困難得多。 當 Core Web Vitals 首次宣佈時，它還沒有完全實現。 這更具挑戰性。 他們在添加許多這些功能方面確實取得了長足的進步，尤其是塊編輯器和基於塊的構建等，以真正優化選擇性加載資產、CSS 文件、字體文件等的能力。 嗯是的。 太棒了。

ALEX ZUNIGA：這可能是封閉系統與開放源代碼的呼聲。 去吧，Sanjucta。

SANJUCTA GHOSE： 是的。 是的。 我認為是因為有很多專門用於 WordPress 的託管服務提供商。 就像你說的。 WordPress 是開源的。 因此，圍繞託管 WordPress 網站有很多優化。 因此，我認為如果您在 WordPress 之上構建，那裡已經有很多可用的支持，這意味著您不必重新發明輪子。 所以我認為如果您在 WordPress 之上構建以優化您的 Core Web Vitals 肯定會更容易。

亞歷克斯祖尼加：美麗。 所以我們已經討論了我們如何衡量這些工具，我們用什麼來實際增強我們的 Core Web Vitals，一些工具。 現在，當我們談論客戶期望時，您在新項目的哪個階段開始考慮將 Core Web Vitals 作為構建或策略的一部分？ 當你像你的基本樣板模板一樣開始時，這是正確的嗎？ 還是您在故事中進一步優化了一些東西？ 你們都做什麼？

馬特·蔡斯：是的。 我認為對我而言，它更像是一種構建事物的方式，而不是您對未優化的網站所做的事情。 這是從一開始。 它存在於您理想編寫的每一行代碼中。 我盡量不——我不想建立一個大的優化網站，然後再回去修復它。 我想從一開始就盡量寫得乾淨利落。 然後通常，我發現這樣做，在最後擠出最後一點優化汁液會更容易一些。

馬克·達沃利：是的。 他是絕對正確的。 我們從一開始就開始構建它。 我的意思是，有些組件不會像接近尾聲那樣發生。 在臨近發布之前，我們不會通過圖像優化來運行圖像。 但是你甚至不需要在構建本身，但有時甚至在設計過程中，如果你考慮到 Core Web Vitals，那麼考慮網站的設計方式是很重要的。 因為在架構上，實現某些設計比其他設計更快更具挑戰性。 因此，了解這一點並讓設計人員了解什麼可能會使實施變得更加困難，而不是什麼可能會非常有幫助。

MIKE CRANTEA： 並規定限制。 嘿，你最多只能擁有 x 部手機。 您不應該將 25 及其所有變體帶到桌面上。 這有助於設計階段。 此外，如果在項目期間沒有發生一些接觸點，有時很容易完成一些事情。 就像一個 sprint 的七個請求，要求將測驗插件添加到組合中。 如果不加以檢查，您會在最後發現它。 所以我的建議是每隔幾個衝刺就處理一次。 我們確實檢查了我們對事物如何演變的階段的自動測量。 最後被推動的事情發生了什麼事情變慢了嗎？ 我們是否需要提前採取任何糾正措施，而不是在項目結束時做出反應。

SANJUCTA GHOSE： 是的。 我同意。 從設計階段開始非常重要，因為喜歡簡單的事情，比如是否應該有彈出窗口、廣告橫幅或類似的東西。 有時，它可能會對您的累積佈局分數產生巨大影響。 所以提前知道會發生什麼是件好事。 無論您是彈出窗口還是橫幅。您不希望在項目結束時出現意外。 因此，我認為從設計階段就讓客戶或利益相關者參與進來非常重要，並告訴他們這可能會對您的 Core Web Vitals 產生影響，以便他們做出明智的決定。

MARK DAVOLI：這在發布後也非常有幫助，因為一旦您的網站上線，有時它可能就像，讓我們在以後添加一個聊天小部件或類似的東西。 然後突然間，有一個扭結。 然後你必須考慮我們如何進行整合和優化。 因此，延遲腳本功能可以推送大多數廣告像素，眾所周知，這些像素會破壞您的 Core Web Vitals 分數。 但有時你不能拖延一些事情，因為這對客戶真正想要的東西很重要。 所以盡可能地平衡它，並確保傳達潛在的影響。 最終的結果就是盡可能快地獲得它。 有時您必須為功能做出犧牲。 有時你不知道。 但是盡可能快地獲取它以增加這些轉化。

亞歷克斯·祖尼加：非常好。 出色的。 所以我聽到了這樣的說法，比如更好的成分從一開始就可以打造更好的網站。 並不是說我們只是要在最後加入一些 Core Web Vitals。 如果您想首先以這種方式考慮，這確實是一種生活方式。 好吧，太棒了。 所以這是我們的最後一個問題。 在向客戶傳達您花在 Core Web Vitals 上的時間價值時，您是否遇到過任何問題？ 這是他們曾經推回的任何事情嗎？ 他們不明白你為什麼要做那項工作嗎？

MATT CHASE：我認為我實際上從未遇到過任何形式的阻力。 如果有的話，這有點相反。 通常，這是我們想要的性能。 我們想要 Core Web Vitals。 一起讓它成為現實。 我會說我們並不總是反思 - 我們談到了跟踪像素以及它們如何因降低分數而臭名昭著。 但沒人在乎。 我們就像像素、像素、像素、像素。 因此，人們在添加跟踪功能時需要考慮實際權衡成本收益，因為這並不像僅僅投入使用並獲得結果那麼簡單。 因為有成本。

亞歷克斯祖尼加：太棒了。

MIKE CRANTEA：我認為表演缺乏耐心。 所以如果你在想，哦，讓我們在第一個衝刺之後做一些持續幾個衝刺的性能工作。 我什麼時候看到它？ 我什麼時候看到它？ 計劃以迭代方式發布它，例如增加一項功能，一項功能，一項功能增加了對這項工作所產生影響的信心。 你越多地看到這轉化為轉化和變化，就會越快地認識到價值，而無需花費大量時間進行教育工作。

馬克·達沃利：是的。 我認為客戶可能難以理解的一件事是真實用戶指標與實驗室數據之間的差異。 因為他們中的很多人可能會運行自己的測試等等。 並沒有完全理解。 因此，幫助他們了解頁面的原始摘要部分是見解，實際上是谷歌用來影響 SEO 排名和類似事情的部分。 因為他們中的很多人都在尋找那個分數並對其進行優化。 並幫助他們了解在全面了解您的變更對事物的影響之前，需要 28 天的時間來衡量生產中所做的任何變更。

ALEX ZUNIGA： 非常好。 大聲喊出來。

MIKE CRANTEA： 我應該指出最令人困惑的指標之一。 交互性指標。 這些都是出了名的不穩定。 對於某些更害怕分數變化的人來說，我們構建的新功能是否顯著降低了網站速度？ 然後就像再次進行測試一樣，上升 10 點，然後下降 10 點。 解釋這種變化非常耗時。 為什麼不是只有一個數字是一致的？ 好吧，這與命名事物和緩存一樣困難。

ALEX ZUNIGA：嗯，太棒了。 聽起來我們真的很感謝你們所有的投入，你們對 Core Web Vitals 的所有反饋。 如何使用它們，用什麼來衡量它們，如何為所有這些設定客戶期望。 這真是一個學習的教訓。 我們希望我們的小組成員在這裡過得愉快。 我們非常高興聽到您的所有反饋。 我們希望這裡的與會者也能得到一些很好的反饋。

所以你們所有人，非常感謝你們的時間。 好吧，那是我們的小組。 我們真的很想對我們所有的小組成員說聲謝謝。 我們要感謝您參加這個小組。 我們希望您在 DE{CODE} 觀看我們剩餘的會議時玩得開心。