灯塔上最大的内容涂料 (LCP) 是 p 标签。 （使用盖茨比）

Question

我不知道为什么我的 LCP 会是一个 p 标签，我也不知道我会做些什么来减小它的大小。有时它会达到 2.6 秒并给出黄色评级（而不是绿色）。

这是 p 标签。所有这些类都是引导类。

<p className="text-center mb-md-5 mt-0 mb-5">{aboutText}</p>

这是变量aboutText

const aboutText = `Suddenly  Magazine highlights the uniqueness of Saskatchewan,  and its sudden rise in popularity and growth mentioned in publications such as USA Today and the New York Times.

Advertorials and Articles focus on its rare & particular tourism, its passionate sports, its character, and the prosperous opportunity for businesses and artists influenced by a Saskatchewan setting.

It is centred in Saskatoon, but contributors range from Lac La Ronge in the North, to provincial boundaries east and west, to the Outlaw Caves near the US border.`

---

域名是https://suddenlysask.com

Answer 1

人们似乎完全误解了最大内容绘制指标的目的。它旨在向您显示上述首屏内容的大部分内容何时准备就绪。

什么项是最大的内容绘画并不像何时出现那么重要。 什么项仅在确定可能导致您的页面变慢的原因时有用。

这是确定“首屏”内容何时被充分绘制以使最终用户将页面视为“完整”的主要指标（这是感知的完整性，仍然可以在页面下方/在加载内容背景）。

拆分段落、将其包装在 div 中、使其更高等的建议。没有任何作用，它们只是将 LCP 转移到其他东西上（可能）让你的分数看起来更好但实际上并没有解决问题。

您要做的是优化页面上的初始内容。

为此，您只想提供“首屏”HTML 以及首屏内容所需的 CSS 和 JS。

然后你为其他一切服务。

这篇文章很好地介绍了关键的 JS 和 CSS https://www.smashingmagazine.com/2015/08/understanding-critical-css/

不过，简而言之，内联关键 CSS 和 JS 意味着 在页面上呈现初始内容所需的 CSS 和 JS 应该内联在 HTML 中。现在我猜测像 Gatsby 这样的东西，你会内联呈现折叠内容上方、折叠 CSS 上方等的关键 JS，但原理是一样的。

关键是上面的折叠内容都应该在 HTML 中提供（非矢量图像除外），这样就没有等待 CSS 文件、JS 文件等的往返时间。

所以为了清楚起见，而不是：-

• 请求 HTML，（到服务器往返 200 毫秒）
• 已加载和解析 HTML，找到了呈现初始页面内容所需的 CSS 和 JS 链接
• 已请求 CSS 和 JS。 （到服务器往返 200 毫秒）
• 已加载 CSS 和 JS
• 足以呈现页面。

你有

• 请求 HTML，（到服务器往返 200 毫秒）
• HTML 已加载，所有必需的 CSS 和 JS 都内联在 HTML 中
• 足以呈现页面

这可能看起来不多，但 200 毫秒可以对感知速度产生巨大影响。

这也是一个简化的例子，通常一个页面需要 20 个或更多的请求来呈现上述折叠内容。由于一次限制 8 个请求（通常），这意味着最多可能有 3 个 200 毫秒的往返等待服务器响应。

查看您的网站，您会误读“关键请求链”，因为初始页面中没有提供 HTML，因为它都是通过 JS 呈现的。这可能就是您为什么不认为有问题。

如果您执行上述操作，假设您的图像经过优化，您将获得较低的 FCP 和 LCP 时间。

Answer 2

那么为什么你的 LCP 是 p 标签？

它只在手机上的一个p标签，这里看看手机尺寸。

很明显，p 标签在这里占据了最多的位置。

您可以尝试在移动设备上将图像放大，以便 lighthouse 将图像计为 LCP。

另一种解决方案是将您的 p 标签拆分为 2 个较小的 p 标签

另一种解决方案可能是（不推荐使用女巫）将您的 p 标记稍微从视口中剪掉，因为...

为最大内容绘制报告的元素大小是 通常是用户在视口中可见的大小。如果 元素延伸到视口之外，或者如果任何元素是 被剪裁或有不可见的溢出，这些部分不计算在内 朝向元素的大小。

我猜你的糟糕结果来自这里的这一行：

<link data-react-helmet="true" rel="preload" href="https://fonts.googleapis.com/css?family=Montserrat|Helvetica+Neue|Helvetica|Arial&amp;display=swap">

为什么最多需要 2.6 秒？

这是我的猜测：

加载 google 字体可能需要一些时间，并且不能保证它总是在同一时间加载，所以当加载字体时，它会交换你的字体，这意味着 p 标签交换。这意味着带有新字体的p 标记被视为新的LCP。

出于测试目的，您可以尝试删除 link 并查看它是否会影响您在 LCP 的速度得分

最后，我会将段落分成 2 个较小的段落，以便图像是 LCP。我认为这是最简单的解决方案。

Answer 3

最近有一些 Gatsby 用户抱怨 Lighthouse 分数大幅下降和下降，每个人都同意这一点：由于 LCP（最大内容绘制）响应时间过长，Lighthouse 的分数下降了很多。

这是new Lighthouse version (v6) 更改的结果，实际上，它引入了 LCP 作为一个新概念和度量标准。如您所见，更改日志可能写入但取决于用户，并且在站点上，更改到达的日期不同（我想这取决于 Google 的服务器以及此更改通过它们复制的时间）。

根据文档：

Largest Contentful Paint (LCP) 是感知负载的度量 经验。它在页面加载过程中标记主要或 “最大”——内容已加载并且对用户可见。 LCP 是一种 First Contentful Paint (FCP) 的重要补充 捕捉加载体验的最开始。 LCP 提供了一个 向开发人员发出关于用户实际能够看到多快的信号 一个页面的内容。低于 2.5 秒的 LCP 分数被视为 “很好。”

正如您所说，该指标与 FCP 密切相关，并且是对它的补充：提高 FCP 肯定会提高 LCP 分数。根据更新日志：

FCP 的权重已从 23% 降至 15%。仅当测量 第一个像素被绘制（FCP）并没有给我们一个完整的画面。 将其与衡量用户何时能够看到他们最喜欢的内容相结合 可能关心（LCP）更好地反映了加载体验。

您可以关注此Gatsby GitHub thread 以检查用户在其他情况下如何绕过此问题。

在你的情况下，我建议：

• 删除您的<p> 并再次检查分数以查看更改（只是为了确定）。
• 将<p> 包裹在<div> 中。
• 将您的 <p> 分成 2 或 3 小块，以供 LCP 和 FCP 使用。

如果以上都不起作用，我会尝试在<p> 的高度上玩，看看它是否会提高分数。

我猜 Gatsby（还有 Google）正在努力调整这个新功能并解决这个糟糕的分数问题。