Framehole：PageSpeed 6.0漏洞轻松满分

每个优秀的 Web 开发人员都知道，Google 的 PageSpeed Insights 和幕后使用的开源 Lighthouse 是帮助确定网站相对性能的最先进的工具。 它们还提供了有关您可以进行哪些更改以提高这种感知速度的关键见解。 PageSpeed 已成为衡量网络快慢的黄金标准。

谷歌自己现在正在跟踪每个网站的 PageSpeed 分数并将其用作确定谁到达搜索结果顶部以及谁被流放到第 10 页的炼狱的众多输入之一，这并没有什么坏处。

整个行业和数百万美元的交易只是为了优化和提高这一分数，以期接近无法达到的完美分数 100。最新版本的 PageSpeed/Lighthouse 6.0 包括一组新的受世界各地开发人员青睐的指标进行优化。 这些新指标是：最大内容绘制 (LCP)、累积布局偏移 (CLS) 和总阻塞时间 (TBT)。 谷歌有一整篇文章解释了这些新的“Web Vitals”，它很好地详细说明了它们是如何衡量的。

有了这个新版本，对于网络性能行业来说，这是一个销售更多服务的全新机会，因为网站现在需要新的和不同的变化来追求最高分。 好吧，不用花一分钱，我会告诉你一个简单的改变，它会立即带你从 60 分地狱的深处，一路上升到 100 分的天堂。

TLDR：PageSpeed 不再考虑 YouTube 和 Ads 等第 3 方嵌入对速度的影响

如果您只是想要其中的内容，答案是 Google 的最新更改将重心放在最大内容的绘制上。 这是加载网站时屏幕上最大元素出现所需时间的度量。 它可以很好地代表用户对加载速度的看法。 问题是最大内容绘制不考虑任何嵌入的内容，即使该内容在技术上符合最大的首屏元素。

在不推测不暴露 3rd 方嵌入内容（如 YouTube 视频和大型广告嵌入）的性能影响的动机的情况下，我只想说它会激励人们做出错误的改变以提高速度，并使网络倒退。

例如，这似乎很荒谬，尽管考虑到 PageSpeed 分数变得多么重要，这并非不可能。 我们将网站的 PageSpeed 分数从 60 一直提高到 100，只需对网站的原始慢速版本进行 iframe。 用于确认结果的快速命令在这里，但请继续阅读下面的内容，以了解用户如何优化他们的分数，从而获得我们最终的 Framehole 解决方案。

 # Verify you have the new Lighthouse 6.0 installed npm install -g lighthouse # This one should have a score somewhere around 60 :( lighthouse https://webvitalsfail.b-cdn.net/ --view # Instantly to 100 lighthouse https://webvitalsfail.b-cdn.net/anything-100.html --view

猫舞 v1 - 链接

这是一个简单的示例网站，展示了我们的移动应用程序“猫舞”的典型促销页面。 它有一个超酷的动画 gif 来展示你在手机上安装我们的热门应用程序时得到的跳舞猫。 现在让我们看看这个网站的 Lighthouse 6.0 分数：

哇，60 分的成绩对我们这种成绩优异的人来说是痛苦的。 根据谷歌的说法，这个简单的网站怎么会这么慢？ 让我们关注“最大的内容绘制”，因为这是此版本中引入的全新指标之一。

这非常有用，因为它建议使用视频来制作动画内容，并向我们展示最大的内容绘画元素是我们跳舞猫的动画 gif。 酷，让我们继续：

猫舞 v2 - 链接

在这个版本中，我们将动画 gif 替换为使用原生 HTML5 视频元素播放的 mp4。 这应该会好得多，因为 mp4 确实是为动画内容制作的，并且比可比较的动画 gif 小得多。

嗯，这肯定是朝着正确的方向发展。 仅通过切换到 mp4 来播放我们令人敬畏的跳舞猫的动画，我们就提高了 14 分。 从 104.9s 到 9.9s 的 LCP 无疑是一个巨大的进步。 但我们对 74 分并不满意。这就像一个“C”级，我们是一群 A+ 成就者。

看起来我们的 LCP 现在是由有意义的视频生成的，而不是以前的动画 gif。 但也许我们在编码、海报图像或其他方面做得很差，所以让我们接下来玩一下。

猫舞 v3 - 链接

对于这个版本，我们将只使用 YouTube 来制作动画猫视频。 这样，如果它与视频编码有关，这将有助于消除这种情况。 一般来说，也许我们幼稚的视频编码阻碍了我们，所以让我们看看我们通过这种方式得到了什么分数。

等一下，这些家伙是天才，他们把我的 PageSpeed 分数提高到了 99。我们的视频编码一定是真的搞砸了，导致了 76 的分数，对吧？

这里有什么问题吗？ 在之前的版本中，跳舞的猫一直是屏幕上最大的元素。 从这个测试的截图来看，这个版本的视频仍然是相同的大小。 那么为什么它声称我们的<h1>的文本是最大的元素呢？ 答案在 Google 对最大内容绘制指标的描述中。 该指标包括最大的元素，包括视频、图像、SVG，但不包括 IFRAME

等等，什么？ 这不可能。 如果 iframe 是最大的元素并且像糖蜜一样加载缓慢，那没关系……不算！ 所以 iframe 就像神奇的性能黑洞，我们可以在其中嵌入慢速或大型元素，它们不会影响我们的性能得分。 没门！ 让我们试试这个。

猫舞 v4 - 链接

为了验证我们的理论，我们将返回到我们的确切版本 1 站点，其中包含大型动画 gif 和所有内容。 我们只会做一个改变。 让我们将动画 gif 加载到 iframe 中，看看我们的 PageSpeed 分数会发生什么变化。

废话……这真的是解决方案吗？ 我们只是采取任何导致网站速度得分下降的问题，将它们放入 iframe，然后 BOOM，没有更多问题。 我的意思是我们知道这并没有真正改变加载速度，因为它是相同的文件，相同的大小，只是加载到 iframe 中。 就像使用 YouTube 嵌入时发生的情况一样，它实际上并没有太大地改变速度。 iframe 似乎只是击败 PageSpeed 分数的神奇门户。

但是不得不将我们所有的慢元素移动到 iframe 中，这有点让人头疼……

Cat Dance v5 - Framehole'd Link

我们需要一种更简单的方法来立即提高任何网站的速度。 必须有选择地用 iframed 版本替换元素非常复杂，从长远来看可能不值得。 我们知道如何更聪明地工作而不是更努力地工作。

如果我们将整个网站放在一个 iframe 中会怎样？ 这样，我们的解决方案将与网站的实际代码库分开。 我们甚至可以在边缘或 NGINX 中做这种事情，完全将其与影响任何现有代码分开。

我们的 v5 只是 v1 中的页面，将 iframe 放入一个空包装器中。 相同的大动画 gif，没有优化。 我们现在已经从 60 到 100。这是圣杯，无需对实际网站进行任何工作。

这是愚蠢的

如果您认为这是您见过的最大的蛇油，并且由于基本速度没有改变一点，因此没有头脑正常的开发人员会关心这个分数变化，那么我认为您是正确的蛇油前沿，但是在人们是否关心的问题上是非常错误的。

请记住，PageSpeed 是网络性能的黄金标准。 谷歌甚至使用这个分数来提供他们的算法。 如果您从未从客户那里听说过他们想了解您的产品如何影响他们的 PageSpeed 分数，那么您就没有与足够多的客户交谈。 他们关心，因为谷歌关心，分数应该意味着什么。 看看我用了多少字来解释这一点，想象一下告诉客户他们对您的产品减慢网站速度是错误的，而不是简化、易于理解的 PageSpeed 分数，宣称您是多么错误。

无论原因是什么，归根结底，选择从计算最重要的内容出现在网站上需要多长时间的计算中排除 iframe 是错误的！

使用最大元素的显示时间作为网站速度的指标在世界范围内都是有意义的。 即使加载到 iframe 中，它仍然会影响对速度的感知。 并且以不包括嵌入内容的分数向前发展，不利于使网络更快的目标。 嵌入式内容不会获得免费通行证，尤其是当它是加载时间缓慢的原因时。

如果评分与这些网络指标一起推出，那么我们将进入一个网络，它会被激励回到一个有大量广告和第三方嵌入的拼凑网站，完全不考虑这些项目的速度成本。 毫无疑问，会有人准确地实施本文中提到的整个网站的 iframe，因为管理层想要尽可能高的 PageSpeed 分数。

行为取决于我们如何记分