網站加載速度將是明年谷歌官方排名因素，優化過程並不簡單，你應該從現在開始。

為了幫助您，以下是我們分析中最重要發現的快速摘要：

關鍵頁面速度調查結果摘要

• 根據 Google 的預期，英國 29 %的加載時間是不可接受的：它們超過了 2.5 秒的最大值。
• 然而，趨勢正指向正確的方向。 近幾個月來，快速網站的比例增加了 2%。
• 從英國訪問網站的速度沒有想像中那麼快。 歐洲領先的是瑞士、瑞典、挪威和德國。
• Jimdo 表明基於雲的 CMS 可以提供非常好的 Core Web Vitals 價值。 但開源也可以做到這一點——Typo3只是慢了一點。
• 沒有 CMS比 Wix 慢。 它是 CMS 類別中的木勺架。 排在 WordPress 之後，它表明基於雲的解決方案並不總是很快。
• Lightspeed提供了一個極其快速的商店系統。 Shopify僅位於列表的下半部分。 WordPress 插件WooCommerce是最慢的商店系統。
• 編程語言對於 Web 技術並不重要： Ruby （on Rails）、 PHP （Yii 和 Laravel）、 Python （Django）和其他語言都有快速框架。 只有Angular真的很慢。
• AMP不會自動導致快速網站。 只有大約 70% 的 AMP 頁面符合 Core Web Vitals 標準。

如果您有更多時間，這裡是完整的分析，其中包含所有數據和許多其他有趣的發現，包括加載時間、快速和慢速系統以及它們背後的連接。

為什麼網站加載時間很重要？

用戶體驗是網站成功的最重要因素之一。 加載時間是良好用戶體驗的基礎，因為如果訪問者必須等待（太）長時間才能加載頁面，他們會跳轉並尋找另一個來源。

在一項研究中，谷歌發現加載時間從一秒增加到三秒會導致跳出率增加32% 。 如果加載時間增加到 5 秒，訪問者離開頁面的概率將增加多達 90%。

網站性能如何衡量？

有多種工具和方法可以使網站上的用戶體驗可衡量。 借助 Core Web Vitals，Google 提供了三個標準化且可比較的關鍵數據。 這些核心 Web Vitals 也將成為明年（2021 年）的排名因素，因此它們將直接影響頁面在 Google 結果中的位置。

我們已經在另一篇文章中展示了改進三個核心網絡生命力的背景、各種測量方法和方法。 所以這裡只是一個快速的提醒：

• 最大內容繪製 (LCP) – 加載最大內容部分所需的時間。 好：小於 2.5 秒。
• 首次輸入延遲 (FID) – 用戶可以與頁面交互之前的時間。 好：小於0.1秒。
• Cumulative Layout Shift (CLS) – 加載期間佈局偏移量的指標。 好：小於0.1。

在此分析中，我們使用了最大含量塗料 ( LCP ) 的值，但顯示所有三個測量值的第一個圖表除外。 在三個 Core Web Vitals 中，這是衡量頁面加載時間的基本值。

英國 – 29% 的網站速度不夠快

第一步，我們分析了來自英國的網站訪問對三個Core Web Vitals 關鍵數據的表現。 谷歌為每個領域定義了三個領域：

• 良好（綠色），如果價值在 Google 的預期之內，
• 需要改進（黃色） ，如果它超出預期，但還沒有偏離太遠，並且
• 壞（紅色） ，如果測量值遠遠偏離目標。

在此基礎上，以下是英國基於三個核心網絡生命力的結果。

使用最大含量塗料 (LCP) ，所有結果中有 70% 已經很好了。 谷歌將 12.9% 的結果評為差。 LCP 是 Core Web Vitals 的關鍵指標，因為它最直接地反映了實際加載時間。

首次輸入延遲 (FID )，即交互之前的時間，具有最佳值：90% 的訪問已經是好的，只有 2% 的訪問被谷歌評為壞。 如果您在這裡還有一些工作要做，您將不得不快點，以免被拋在後面。

使用Cumulative Layout Shift (CLS) ，即加載過程中的佈局變化，很明顯網站要么通過了這個測試（綠色），要么完全失敗（紅色）——只有少數情況需要改進。 （黃色的）。

積極趨勢：網站每個月都在變快一點

為了了解過去幾個月加載時間的變化情況，下一個評估顯示了最近幾個月最大內容繪畫的每月變化：

進展並不迅速，但有輕微的積極趨勢。 自 2019 年 11 月以來，不良測量的數量減少了約 2 個百分點，良好測量的數量從 73% 增加到 75%。 方向是積極的：網站每個月都在變快一點。

平板電腦只是糟糕的台式機

我們進入下一個分析，根據設備類型將評估分開：台式機、手機和平板電腦。 結果如下：

不出所料，網站在台式機上的加載速度比在手機上更快。 經常有線的互聯網連接和更多的計算能力在這裡是決定性的。 然而，台式機和手機之間的差異並沒有想像中那麼大。

平板電腦的性能不佳很有趣。 一種可能的解釋是，平板電腦通常通過更大的屏幕看到桌面版本的網站——但平板電腦的硬件更接近智能手機。 這導致加載時間性能顯著變差。

第 20 位：來自英格蘭的網站訪問需要改進

最終用戶為 Core Web Vitals 測量的值僅部分取決於網站的性能：用戶 Internet 連接的速度、吞吐量和延遲也會對結果產生影響。

作為網站運營商，沒有辦法優化您自己的訪問者的互聯網連接，但對每個國家/地區的 Core Web Vitals 的分析非常清楚地顯示了這些差異。 以下是對部分國家/地區的評估：

在中國和韓國，82% 的網站符合谷歌的性能預期——這是最高價值，迄今為止是世界領先的。 其次是北歐國家（瑞典、挪威、丹麥），還有日本和台灣。

德國在這項分析中排名第九：四分之三的用戶請求已經符合谷歌的速度預期。 英格蘭排在第 20 位，這可能反映了來自國外（尤其是美國）以及可能來自歐洲其他地區的服務消費的內容量。

俄羅斯和美國的加載時間大致相當。 泰國和越南的糟糕價值觀表明，亞洲並不總是等同於快速互聯網。

基里巴斯是太平洋上的一個島國，它展示了一個非常偏遠的位置和通過衛星連接互聯網的影響：只有大約四分之一的訪問已經很好了。 幾乎 60% 的訪問被 Google 評為不良訪問。

CMS：Jimdo 最快，Wix 甚至比 WordPress 還慢

內容管理系統 ( CMS ) 是 Internet 的支柱：大多數網站都是在此類軟件的核心之上運行的。 從隔壁的理髮店到SMB ，再到每天有數百萬訪客的網站。

我們將我們的 Web 技術數據庫與 Core Web Vitals 的測量值相結合，以便能夠評估最常用的內容管理系統的加載速度。 讓我們直接進入分析：

Jimdo是來自德國漢堡的網站建設者，它為最大內容塗料提供了最佳性能。 在 Jimdo 上運行的網站中，超過 82% 的訪問量符合 Google 的性能預期。

Typo3表明，即使是自託管的 CMS 也可以提供非常好的性能，如評估中的第二名所示。 任何曾經使用 Typo3 進行開發的人都經常會驚恐地記得複雜性。 但是，這並不影響這個基於 PHP 的 CMS 的速度。

WordPress是迄今為止最廣泛使用的 CMS，遠遠落後於倒數第二位。 大約一半的網站都在 WordPress 上運行——但也有很多人使用它，他們不重視良好的加載時間。 谷歌將基於 WordPress 的網站上大約 20% 的點擊分類為差，另外 21% 為需要改進。

WordPress 在此分析中沒有攜帶木勺的事實要歸功於名為Wix的提供商。 這個雲解決方案僅提供大約一半的訪問，加載時間很長。 將近四分之一的人認為谷歌的核心網絡生命力很差。

當您考慮到該分析的獲勝者（Jimdo）和失敗者（Wix）具有相同的起始條件時，這種糟糕的性能尤其值得注意：提供者控制整個系統並可以優化每個部分的雲解決方案（但顯然沒有不要總是這樣做）。

商店系統：Shopify 在中間，WooCommerce 在底部

早在 2006 年，亞馬遜就確定加載時間增加 0.1 秒會導致銷售額減少 1%。 在過去的 14 年裡，情況並沒有好轉。 良好的加載時間對於在線商店至關重要。

我們的技術數據庫和加載時間數據相結合，對我們在開放的 Internet 荒野中經常看到的所有商店系統進行了以下分析：

獲勝者Lightspeed名副其實。 使用 Lightspeed 的域為最大內容繪製貢獻了93% 的“好”評級。 只有 2% 被評為差。 這些是我們在所有評估中在此分析中測量的最佳數字。

Lightspeed 具有與系統相關的優勢，即它是一種雲解決方案。 提供商控制整個系統，並可以優化所有區域的速度。 開源解決方案 osCommerce 表明，自託管商店也可以實現非常好的加載時間，達到非常好的84 %。

當前的流星Shopify只進入了分析的下半部分。 儘管原則上它使用與 Lightspeed 相同的基線架構（完全由提供商自己託管），但這種優勢並沒有轉化為高於平均水平的加載時間。

WordPress 擴展WooCommerce遠遠落後於最後一位。 目前，只有不到一半的 WooCommerce 商店符合 Google 規範。 令人震驚的26%實際上是壞的。 低性能海量供應商的自營託管解決方案在這裡一目了然。

網絡技術：AMP 比預期慢

該評估涉及多種網絡技術：從用於創建網站的後端技術到用於設計和交互的JavaScript和CSS庫，再到 Google AMP 。

下表僅列出了我們數據中用途最多的技術。 較少使用的網絡技術被排除在外。 當然，只能評估可公開訪問的網站。 以下是分析：

Ruby on Rails是 Basecamp 的創始人開發的基於 Ruby 的框架，目前處於領先地位：幾乎 85% 的使用該技術的網站提供的網站都在 Google 設定的限制範圍內，從而獲得了最大內容繪製的良好評級。

但像Yii (74%) 或Laravel (73%) 這樣的PHP 框架也帶來了好時光。 所以沒有人會感到被冷落： Python也很好地代表了Django 框架(75%) 和 ASP.NET (77%) 甚至位居第二。 我們從中學到什麼？ 速度不取決於編程語言，而是取決於實現。

值得注意的是， AMP並不是最快的技術之一。 Accelerated Mobile Pages (AMP) 是主要由 Google 推動的 HTML 的衍生產品。 許多限制應該意味著 AMP 頁面在手機上的加載速度明顯快於經典 HTML 頁面。

結果並不令人信服：不到 70%的 AMP 域符合 Google 的要求。 谷歌顯然已經意識到了這一點，並且未來還將把熱門故事框中的 AMP 特權留給擁有快速核心 Web Vitals 的網站。

移動頭條新聞中的故事不再需要 AMP； 它將打開到任何頁面。

Google 網站管理員中心博客，評估頁面體驗以獲得更好的網絡

唯一不能使超過一半的域滿足谷歌要求的網絡技術是Angular 。 具有諷刺意味的是，由谷歌開發和提供的前端應用程序框架......

CDN。 快速網站正在使用 Fastly

內容交付網絡(CDN) 提供分佈在世界各地的服務器，以便內容可以覆蓋更短、因此更快的傳輸路徑到站點訪問者。 除了 Akamai 等專家之外，主要的雲提供商還提供 CDN。

本質上，所有 CDN 的工作方式都是相似的。 他們也無法改變其架構的物理限制。 因此，在下面的分析中，必須區分因果關係和相關性：

不能假設更快的 CDN 是領先的原因，但以性能為導向的網站運營商可能會依賴這些 CDN。

平均而言，依賴Fastly作為 CDN 加載的域比依賴其他提供商的域快得多。 谷歌位居第二，但亞馬遜和微軟（Azure）也不甘落後。

Akamai落後的事實可能與 Akamai 的典型客戶有關：這些是相當大的國際公司，通常運行緩慢的遺留系統，而不是交付現代和快速網站的最佳先決條件。

Fireblade在此分析的底部，不提供經典的 CDN，而是提供Web 應用程序防火牆：該應用程序過濾 Internet 流量以查找潛在的危險呼叫並阻止它們。 那些不得不依賴這種架構的人，平均而言，也會運行較舊的和未優化的 Web 應用程序，因此在本次評估中已經存在結構上的劣勢。

背景：我們測量了什麼（以及如何測量）

加載速度的測量有著悠久的歷史：從最初測量交付純 HTML（ TTFB ，Time to first Byte）到First Contentful Paint到現在Core Web Vitals的三個測量值以最大內容繪畫為中心指標發生了很大變化。

為了進行分析，我們使用了 Google Core Web Vitals 的官方計算基礎。 為此，本質上有兩種不同的測量方法：實驗室數據，即在自己的實驗室條件下自己測量的值和現場數據。 這些由用戶面板測量。 我們評估了該分析的現場數據。 在 SISTRIX 中，您可以訪問實驗室和現場數據。 我們總共分析了 1850 萬個域的加載時間。

除了前三個評估僅與來自英國的測量值相關外，其餘分析包括來自世界各地的測量值。 桌面、移動和平板電腦的價值也在那裡評估。

我們將這些測量值與 SISTRIX 中的技術檢測相結合，以便能夠就軟件解決方案和技術堆棧做出陳述。 對於技術識別，我們會定期抓取 Internet 的大部分內容，並將發現的特徵（“指紋”）與我們列出的 1,000 多種相關 Internet 技術進行比較。 我們僅在最終分析中包含了那些具有足夠數量的域以實現統計顯著性的技術-核心-網絡-生命組合。

結論

Google 通過將Core Web Vitals 列為官方排名因素，將用戶體驗置於聚光燈下。 在我們的分析中，我們能夠顯示當前值的範圍有多大。 根據所使用的軟件和技術，一切都在“已經完美”和“一堆工作”之間表示。

就像 SEO 中的很多東西一樣，提高加載時間必須是一個持續的過程。 這不是一次性的任務，而是一個持續的、受監控的過程。 這將需要定期關注，並且需要不時調整目標。

優化加載時間並不是 SEO 的核心任務——但這種變化將對網站在搜索結果中的有機性能產生影響。 搜索引擎優化再次成為一個橫斷面的功能，它必須將公司的許多領域結合在一起。

長期以來，我們自己都忽略了我們網站的加載時間。 在過去的幾周里，我們已經解決了這個話題，並註意到（非常）好的價值觀需要付出多少努力。 然而這是值得的：不僅谷歌對此感到滿意，真正的用戶也特別感謝我們。 因此：不要睡在這個話題上。 與其推遲到明年，不如從今年開始。