为什么我的 Google PageSpeed Insights 得分降低了这么多？
Why Has My Google PageSpeed Insights Score Lowered So Much?
产品
对于桌面，我有一个网页速度得分不错的网站（目前为 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（第一个 link）转换为普通 JavaScript（第二个 link）时，我设法降低了桌面 Google PageSpeed Insights 得分从 96 到 69。
我已经大幅减少了 JavaScript 和其他资源的数量（产品上为 2MB，舞台上为 500KB）。
分析
通过这些数字，对我来说最突出的是 prod 的 FCP（First Contentful Paint）为 0.7 秒，而 stage 的 FCP 为 2.0 秒。这对我来说似乎很奇怪，因为舞台应该快得多，但显然慢得多。
查看缩略图的移动时间轴（桌面有点难以看清），好像舞台渲染第一个 "full content" 快得多：
我突出显示了在我看来 "complete" 的那些（舞台在顶部，产品在底部）。
截图
这里有一些屏幕截图，您可以看到我在做什么（PageSpeed Insights 每次 运行 时都会有相当大的不同）。
这是舞台：
这是生产：
变更摘要
以下是我在尝试提高分数时所做的主要事情：
- 我将 JavaScript 从 Angular 转换为纯 JavaScript，显着减少了呈现页面所需的 JavaScript。
- 我延迟加载 JavaScript（例如，Google 地图 JavaScript 直到需要时才会加载）。
- 我懒加载图片（例如，幻灯片最初只加载第一张图片）。
- 我减少了 DOM 个元素的数量（从 4,600 个减少到 1,700 个）。
- 我正在使用 HTTP/2 服务器推送来尽可能快地加载新的纯文本 JavaScript。
这些更改应该会提高分数。
问题
您是否知道为什么尽管我尽了最大的努力，PageSpeed 得分仍然下降？
我建议您查看 Prod 和 Staging 环境中包含第 3 方脚本的不同之处。
大多数时候当我遇到 pagespeed 问题时，是第 3 方脚本导致了问题。不过 YMMV。
只是一些开始的指针，当我比较两者之间的统计数据时，我注意到这个特定的 Wistia 脚本的工作方式完全不同，也许不是脚本本身的问题，而是它嵌入的方式不同或其他原因.
生产中
- Wistia：主线程阻塞时间：3ms（部分：最小化第三方使用）
- Wistia：总计 CPU 时间：87 毫秒（部分：Javascript 执行时间）
- Wistia：脚本评估：76 毫秒（部分：Javascript 执行时间）
分期
- Wistia：主线程阻塞时间：229 毫秒（部分：
减少第三方代码的影响）
- Wistia：总计 CPU 时间：425 毫秒
- Wistia：脚本评估：376 毫秒
您遇到的问题
您做对了很多事情，但由于 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 - 少一个请求！
如何识别问题
如果有人遇到这样的问题，您需要执行以下操作来确定发生了什么。
首先打开开发人员工具并转到网络选项卡。
在下拉框中将选项设置为'Disable Cache - true'和'Slow 3G'。
加载网站的每个版本并比较瀑布。
通常您可以发现加载顺序的变化并开始调查它们 - 'game' 是查找出现在首屏的项目并尝试删除它们、延迟它们或将它们内联，就像您对某些你的 CSS.
下一步是学习使用“覆盖率”和“渲染”选项卡，因为它们会很快指出问题所在。
终于学会了如何使用性能选项卡并了解它产生的跟踪。
您可能已经知道如何使用上述内容，但如果不学习它们，它们会让您快速找到所有问题。
所以我想通了这个问题。 PageSpeed Insights 喝醉了。
嗯，反正不靠谱。通过简单地删除 JavaScript 文件（少于 20KB）的服务器推送，我能够显着提高分数。
这很奇怪，因为页面实际上似乎需要更长的时间才能显示。但是，Google PageSpeed Insights 认为它显示得更快，因此提高了分数。
我试过一次，移动分数上去了99：
我又试了一次，比较合理的82：
在桌面上，分数上升到 98：
显示 99 的移动屏幕截图的有趣之处在于，您可以在时间轴缩略图中看到页面顶部的幻灯片图像尚未加载。因此，这似乎是 Google PSI 过早地决定页面具有 "finished loading" 的情况，即使它尚未完成。
这几乎就像如果您将某些事情拖延足够长的时间，Google 就会忽略它们。换句话说，页面越慢，他们给你的分数就越高。这当然是倒退的。
无论如何，为了获得更高的分数，这可能是我将采用稍微不太理想的方法的事情之一。可能还有一个我可以探索的中间地带（例如，让第一个 JavaScript 文件注入 link 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);
});
后端在 window 对象上创建一个名为 preloadJavaScriptPaths 的变量。它只是一个字符串数组（每个字符串都是 JavaScript 文件的路径，例如 /app.js）。
页面加载速度仍然很快，PSI 分数仍然不错（移动设备 80，桌面设备 97）：
产品
对于桌面，我有一个网页速度得分不错的网站（目前为 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（第一个 link）转换为普通 JavaScript（第二个 link）时，我设法降低了桌面 Google PageSpeed Insights 得分从 96 到 69。
我已经大幅减少了 JavaScript 和其他资源的数量（产品上为 2MB，舞台上为 500KB）。
分析
通过这些数字，对我来说最突出的是 prod 的 FCP（First Contentful Paint）为 0.7 秒，而 stage 的 FCP 为 2.0 秒。这对我来说似乎很奇怪，因为舞台应该快得多，但显然慢得多。
查看缩略图的移动时间轴（桌面有点难以看清），好像舞台渲染第一个 "full content" 快得多：
我突出显示了在我看来 "complete" 的那些（舞台在顶部，产品在底部）。
截图
这里有一些屏幕截图，您可以看到我在做什么（PageSpeed Insights 每次 运行 时都会有相当大的不同）。
这是舞台：
这是生产：
变更摘要
以下是我在尝试提高分数时所做的主要事情：
- 我将 JavaScript 从 Angular 转换为纯 JavaScript，显着减少了呈现页面所需的 JavaScript。
- 我延迟加载 JavaScript（例如，Google 地图 JavaScript 直到需要时才会加载）。
- 我懒加载图片（例如，幻灯片最初只加载第一张图片）。
- 我减少了 DOM 个元素的数量（从 4,600 个减少到 1,700 个）。
- 我正在使用 HTTP/2 服务器推送来尽可能快地加载新的纯文本 JavaScript。
这些更改应该会提高分数。
问题
您是否知道为什么尽管我尽了最大的努力，PageSpeed 得分仍然下降？
我建议您查看 Prod 和 Staging 环境中包含第 3 方脚本的不同之处。
大多数时候当我遇到 pagespeed 问题时，是第 3 方脚本导致了问题。不过 YMMV。
只是一些开始的指针，当我比较两者之间的统计数据时，我注意到这个特定的 Wistia 脚本的工作方式完全不同，也许不是脚本本身的问题，而是它嵌入的方式不同或其他原因.
生产中
- Wistia：主线程阻塞时间：3ms（部分：最小化第三方使用）
- Wistia：总计 CPU 时间：87 毫秒（部分：Javascript 执行时间）
- Wistia：脚本评估：76 毫秒（部分：Javascript 执行时间）
分期
- Wistia：主线程阻塞时间：229 毫秒（部分： 减少第三方代码的影响）
- Wistia：总计 CPU 时间：425 毫秒
- Wistia：脚本评估：376 毫秒
您遇到的问题
您做对了很多事情，但由于 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 - 少一个请求！
如何识别问题
如果有人遇到这样的问题，您需要执行以下操作来确定发生了什么。
首先打开开发人员工具并转到网络选项卡。
在下拉框中将选项设置为'Disable Cache - true'和'Slow 3G'。
加载网站的每个版本并比较瀑布。
通常您可以发现加载顺序的变化并开始调查它们 - 'game' 是查找出现在首屏的项目并尝试删除它们、延迟它们或将它们内联，就像您对某些你的 CSS.
下一步是学习使用“覆盖率”和“渲染”选项卡，因为它们会很快指出问题所在。
终于学会了如何使用性能选项卡并了解它产生的跟踪。
您可能已经知道如何使用上述内容，但如果不学习它们，它们会让您快速找到所有问题。
所以我想通了这个问题。 PageSpeed Insights 喝醉了。
嗯，反正不靠谱。通过简单地删除 JavaScript 文件（少于 20KB）的服务器推送，我能够显着提高分数。
这很奇怪，因为页面实际上似乎需要更长的时间才能显示。但是，Google PageSpeed Insights 认为它显示得更快，因此提高了分数。
我试过一次，移动分数上去了99：
我又试了一次，比较合理的82：
在桌面上，分数上升到 98：
显示 99 的移动屏幕截图的有趣之处在于，您可以在时间轴缩略图中看到页面顶部的幻灯片图像尚未加载。因此，这似乎是 Google PSI 过早地决定页面具有 "finished loading" 的情况，即使它尚未完成。
这几乎就像如果您将某些事情拖延足够长的时间，Google 就会忽略它们。换句话说，页面越慢，他们给你的分数就越高。这当然是倒退的。
无论如何，为了获得更高的分数，这可能是我将采用稍微不太理想的方法的事情之一。可能还有一个我可以探索的中间地带（例如，让第一个 JavaScript 文件注入 link 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);
});
后端在 window 对象上创建一个名为 preloadJavaScriptPaths 的变量。它只是一个字符串数组（每个字符串都是 JavaScript 文件的路径，例如 /app.js）。
页面加载速度仍然很快，PSI 分数仍然不错（移动设备 80，桌面设备 97）：