为什么我的 Google PageSpeed Insights 得分降低了这么多？

Question

产品

对于桌面，我有一个页面速度得分不错的网站（目前为 96）：https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.usstoragecenters.com%2Fstorage-units%2Fca%2Falhambra%2F2500-w-hellman-ave&tab=desktop

舞台

我正在努力提高分数（主要针对移动设备），但不知何故我让它变得更糟（目前，桌面设备为 69）：https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fstage.usstoragecenters.com%2Fstorage-units%2Fca%2Falhambra%2F2500-w-hellman-ave%3Fplain%3Dtrue&tab=mobile

问题

在将网站从 Angular（第一个链接）转换为纯 JavaScript（第二个链接）时，我设法将桌面版 Google PageSpeed Insights 得分从 96 降低到 69。

我大幅减少了 JavaScript 和其他资源的数量（产品为 2MB，舞台为 500KB）。

分析

查看数字，让我印象深刻的是 prod 的 FCP（First Contentful Paint）为 0.7 秒，而 stage 的 FCP 为 2.0 秒。这对我来说似乎很奇怪，因为阶段应该快得多，但显然要慢得多。

查看缩略图的移动时间轴（桌面有点难以看到），似乎舞台渲染第一个“完整内容”的速度要快得多：

我突出显示了在我看来看起来“完整”的那些（舞台在顶部，产品在底部）。

截图

这里有一些屏幕截图，您可以看到我在做什么（PageSpeed Insights 每次运行时都会有很大的不同）。

这里是舞台：

这是生产：

变更摘要

以下是我在尝试提高分数时所做的主要工作：

• 我将 JavaScript 从 Angular 转换为纯 JavaScript，显着减少了呈现页面所需的 JavaScript。
• 我延迟加载 JavaScript（例如，Google Maps JavaScript 在需要时才加载）。
• 我延迟加载图片（例如，幻灯片最初只加载第一张图片）。
• 我减少了 DOM 元素的数量（从 4,600 个减少到 1,700 个）。
• 我正在使用 HTTP/2 服务器推送以尽可能快地加载新的纯 JavaScript。

这些变化应该提高了分数。

问题

您知道为什么尽管我尽了最大努力，PageSpeed 的得分还是下降了？

Answer 1

我建议您研究一下在您的 Prod 和 Staging 环境之间包含第 3 方脚本的方式之间的区别。

大多数时候，当我遇到 pagespeed 问题时，是第 3 方脚本导致了问题。不过，YMMV。

只是一些开始的指针，当我比较两者之间的统计数据时，我注意到这个特定的 Wistia 脚本的工作方式完全不同，可能不是脚本本身的问题，而是它的嵌入方式不同或其他什么。

在生产中

• Wistia：主线程阻塞时间：3ms（章节：尽量减少第三方使用）
• Wistia：总 CPU 时间：87 毫秒（部分：Javascript 执行时间）
• Wistia：脚本评估：76 毫秒（部分：Javascript 执行时间）

暂存中

• Wistia：主线程阻塞时间：229 毫秒（部分： 减少第三方代码的影响）
• Wistia：总 CPU 时间：425 毫秒
• Wistia：脚本评估：376 毫秒

Answer 2

您遇到的问题

你做了很多正确的事情，但你的分数因为First Meaningful Paint和First Contentful Paint而受到影响

查看加载顺序等。我注意到您的主 HTML 文件的大小实际上增加了 33%，从 60kb 增加到 81.6kb。

这是您发现问题所在的第一个指标，因为您必须在浏览器开始考虑渲染之前加载所有 HTML。

下一个问题是 Lighthouse（PSI 背后的引擎）向您展示您没有渲染阻塞内容，但我认为该方法在显示阻塞渲染方面并不完美。

您的网站仍然需要 SVG logo 和 icomoon 文件来呈现首屏上的所有内容。

在主站点上这些加载较早，在暂存站点上它们被延迟并开始加载很晚，延迟您的first Contentful paint 等等。

可能还有其他东西，但这些是我一眼就发现的。

如何解决我提到的几项问题

HTML size - 可能会将您已内联的一些 JSON 等外部化，因为那里有很多内容，请延迟加载它（仅作为建议，尚未探索是否适合您）

SVG Logo - 易于修复，获取构成徽标的实际文本并将其内联，而不是使用外部资源。

icomoon - 不太容易修复，但将所有图标替换为内联 SVGs。

奖励 - 通过将您的图标从字体更改为SVG，您可以帮助那些拥有自己的样式表覆盖字体（因为图标的字体被覆盖并且没有意义）的人的可访问性)。

奖励 2 - 少一个请求！

如何识别问题

如果有人遇到这样的问题，您需要执行以下操作来弄清楚发生了什么。

首先打开开发者工具并进入网络标签。

在下拉框中将选项设置为“禁用缓存 - true”和“Slow 3G”。

加载网站的每个版本并比较瀑布。

通常，您可以发现加载顺序的变化并开始调查它们 - “游戏”是找到出现在首屏上方的项目并尝试删除它们、延迟它们或将它们内联，就像使用某些 CSS 一样。

接下来是学习使用 Coverage 和 Rendering 选项卡，因为它们会很快为您指出问题。

终于学会了如何使用性能标签并了解它产生的跟踪。

您可能已经知道如何使用上述方法，但如果不学习它们，它们会让您快速找到所有问题。

Answer 3

所以我发现了这个问题。 PageSpeed Insights 喝醉了。

好吧，无论如何它都不可靠。通过简单地删除 JavaScript 文件（不到 20KB）的服务器推送，我能够显着提高分数。

这很奇怪，因为页面实际上似乎需要更长的时间才能显示。但是，Google PageSpeed Insights 认为它​​显示得更快，因此它提高了分数。

我试了一次，手机分数升到了99：

我又试了一次，得到了更合理的82：

在桌面上，分数上升到 98：

显示 99 的移动屏幕截图的有趣之处在于，您可以在时间线缩略图中看到页面顶部的幻灯片图像尚未加载。因此，这似乎是 Google PSI 过早决定页面“加载完成”的情况，即使它还没有完成。

这几乎就像如果您将某些事情延迟足够长的时间，Google 就会忽略它们。换句话说，页面越慢，他们给你的分数就越高。这当然是倒退的。

无论如何，这可能是我将采用稍微不太理想的方法以获得更高分数的事情之一。我还可以探索一个中间地带（例如，让第一个 JavaScript 文件注入链接 rel=preload 标记，以便立即加载其余的 JavaScript 文件，而不是等待完整的模块链解析）。

如果有人能提出更令人满意的解释，我会将其标记为答案。否则，我可能最终会将此标记为答案。

中间立场方法

编辑：这是我采用的中间立场方法，似乎行之有效。首先，我加载了一个名为 preload.js 的 JavaScript 文件，其包含如下：

<script src="/preload.js" defer></script>

这是preload.js文件的内容：

// Optimization to preload all the JavaScript modules. We don't want to server push or preload them
// too soon, as that negatively impacts the Google PageSpeed Insights score (which is odd, but true).
// Instead, we start to load them once this file loads.
let paths = window.preloadJavaScriptPaths || [],
    body = document.querySelector('body'),
    element;
paths.forEach(path => {
    element = document.createElement('link');
    element.setAttribute('rel', 'preload');
    element.setAttribute('as', 'script');
    element.setAttribute('crossorigin', 'anonymous');
    element.setAttribute('href', path);
    body.appendChild(element);
});

后端在名为preloadJavaScriptPaths 的窗口对象上创建一个变量。它只是一个字符串数组（每个字符串都是 JavaScript 文件的路径，例如 /app.js）。

页面加载速度仍然很快，PSI 得分仍然不错（移动设备 80，桌面设备 97）：