产品

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桌面Google PageSpeed Insights得分从96降低到69。

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

分析

从数字上看，对我来说最突出的是产品的FCP（第一内容油漆）为0.7秒，而舞台的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环境之间如何包含第三方脚本。

在大多数情况下，当我对pagespeed遇到问题时，都是由第三方脚本引起的。但是，YMMV。

只是一个开始的指针，当我比较两者之间的统计信息时，我注意到该特定的Wistia脚本的工作方式完全不同，也许不是脚本本身的问题，但是其嵌入方式有所不同。 / p>

在产品上

Wistia：主线程阻塞时间：3ms（部分：最小化第三方使用）
Wistia：CPU总时间：87毫秒（部分：Javascript执行时间）
Wistia：脚本评估：76毫秒（部分：Javascript执行时间）

登台

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

Answer 2

您遇到的问题

您已经正确地完成了许多工作，但是由于First Meaningful Paint和First Contentful Paint

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

这是您出问题的第一个指示，因为您必须加载所有HTML，然后浏览器才能开始考虑渲染。

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

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

在主站点上，它们会较早加载，在暂存站点上，它们会延迟加载，并在很晚之后开始加载，从而延迟了first Contentful paint等。

也许还有其他事情，但我很快就发现了这几对。

如何修复我提到的几项

HTML size-也许将JSON等的内在化，因为那里有很多内容，因此懒惰地加载它（仅建议，还没有研究过对您是否可行）< / p>

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

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

奖金-通过将图标从字体更改为SVG，可以帮助具有自己的样式表覆盖字体的人（因为图标的字体被覆盖并制作出来）没有意义。）

奖金2 -少了一个请求！

如何识别问题

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

打开开发人员工具，然后首先转到“网络”标签。

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

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

通常，您可以发现加载顺序的变化并开始调查它们-“游戏”是查找出现在折叠上方的项目，然后尝试将其删除，推迟它们或像使用某些CSS那样内联它们。 / p>

接下来的事情是学习使用“覆盖率”和“渲染”选项卡，因为它们很快会指出问题。

最后了解如何使用效果标签，并了解它产生的轨迹。

您可能已经知道如何使用上述内容，但是如果不学习它们，它们将使您快速找到所有问题。

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台式机）：

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

产品

阶段

问题

分析