网站加载速度将是明年谷歌官方排名因素，优化过程并不简单，你应该从现在开始。

为了帮助您，以下是我们分析中最重要发现的快速摘要：

关键页面速度调查结果摘要

• 根据 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 的核心任务——但这种变化将对网站在搜索结果中的有机性能产生影响。 搜索引擎优化再次成为一个横断面的功能，它必须将公司的许多领域结合在一起。

长期以来，我们自己都忽略了我们网站的加载时间。 在过去的几周里，我们已经解决了这个话题，并注意到（非常）好的价值观需要付出多少努力。 然而这是值得的：不仅谷歌对此感到满意，真正的用户也特别感谢我们。 因此：不要睡在这个话题上。 与其推迟到明年，不如从今年开始。