优化 LCP Resource Load Delay

优化 LCP Resource Load Delay

Largest Contentful Paint (LCP) 由四个阶段组成：TTFB、Resource Load Delay、Resource Load Duration 和 Element Render Delay。开发工作通常侧重于通过文件压缩来减少 Load Duration，但这忽略了 Resource Load Delay，而它往往是更大的延迟来源。下载开始之前的这段延迟可能会为你的 LCP 增加数百毫秒，导致其超过 2.5 秒的"良好"阈值。 

快速提示：如果你的 LCP 是图片，它的表现几乎总是比文本更差。你必须在 RUM 数据中跟踪 LCP 元素类型，否则你就是在盲目飞行。

精确定义：下载前的关键等待

Resource Load Delay 是 TTFB 与浏览器发起下载 LCP 资源之间的时间。它不是下载时间；它是在获取开始之前发生的发现延迟。此处的高值表示存在架构问题，浏览器无法在初始 HTML payload 中找到资源 URL。  这个 Resource Load Delay 可以被视为浏览器花在识别需要 LCP 资源并决定获取它上面的时间。

对于基于文本并使用系统字体渲染的 LCP 元素，这个 Resource Load Delay 通常为零，因为不需要获取外部资源。较高的 Resource Load Delay 值特定于依赖外部网络资源（如图片或视频文件）的 LCP 元素。

发现引擎：预加载扫描器与 DOM 解析器

要减少 Resource Load Delay，你必须了解浏览器如何发现资源。这个发现过程的效率是决定延迟的主要因素。浏览器使用两种机制：快速路径和慢速路径。

• 预加载扫描器（快速路径） 预加载扫描器（快速路径）：这是一个高速的辅助解析器，它扫描原始 HTML 以查找资源 URL，例如 <img> 或 <link> 标签中的 URL。它在 CSS 被解析或 JavaScript 被执行之前立即将这些资源排队下载。这是任何关键资源的最优路径。
• DOM 解析器（慢速路径）：这是构建完整文档对象模型（DOM）和 CSS 对象模型（CSSOM）的主解析器。在初始 HTML 中未找到的资源（例如 CSS background-image 或由 JavaScript 注入的元素）只能由此解析器发现。这是慢速路径，因为它依赖于其他文件先下载和执行，从而创建了一个引入高延迟的依赖链。

优化 Resource Load Delay 的整个策略基于一个原则：确保 LCP 资源 URL 可被预加载扫描器发现。任何将 URL 隐藏在初始 HTML 文档之外的模式都会迫使浏览器使用慢速发现路径。这个等待期直接转化为 Resource Load Delay。每一个有效的优化都是关于构建你的 HTML 以将 LCP 资源放在快速路径上

为什么 Load Delay 很重要

一个常见的误解是，慢速 LCP 是一个"文件大小"问题。这导致团队只关注图片压缩以减少 Resource Load Duration。虽然资源优化是一个因素，但对真实用户现场数据的分析表明，对于许多 LCP 表现不佳的网站，Resource Load Delay 才是主要的性能瓶颈，而不是 Resource Load Duration。

现场数据显示，LCP 分数不佳的网站中位数具有 1.3 秒的 Resource Load Delay。这超过了整个 2.5 秒"良好"LCP 分数预算的一半，全部在 LCP 资源下载开始之前就被消耗了。数据表明，这些网站等待下载开始的时间几乎是下载本身时间的四倍。

这些数据揭示了开发工作方向的频繁偏差。团队可能花费数周时间从图片中减少几千字节以将 Load Duration 缩短几毫秒，而导致 1.5 秒 Load Delay 的架构问题仍未得到解决。LCP 是一个顺序过程；早期阶段的延迟无法通过优化后续阶段来弥补。如果获取延迟超过一秒，下载时间 100 毫秒的差异对最终 LCP 分数是无关紧要的。影响最大的优化涉及架构变更，例如提高资源可发现性，而不仅仅是资源压缩。重点必须从使资源变小转向这些数据揭示了开发工作方向的频繁偏差。团队可能花费数周时间从图片中减少几千字节以将 Load Duration 缩短几毫秒，而导致 1.5 秒 Load Delay 的架构问题仍未得到解决。LCP 是一个顺序过程；早期阶段的延迟无法通过优化后续阶段来弥补。如果获取延迟超过一秒，下载时间 100 毫秒的差异对最终 LCP 分数是无关紧要的。影响最大的优化涉及架构变更，例如提高资源可发现性，而不仅仅是资源压缩。重点必须从使资源变小转向确保它们更早被发现。。

如何检测 Resource Load Delay

要修复 Resource Load Delay，首先需要准确测量它。 专业的工作流程是先用真实用户数据（RUM）定义问题，然后再转到 Chrome DevTools 进行深入分析。

步骤 1：分析现场数据（RUM）

现场数据，即 Real User Monitoring (RUM)，是从实际用户会话中收集的。RUM 工具，如公共的 Chrome User Experience Report (CrUX) 或我自己的工具 CoreDash，回答的问题是：现实世界中正在发生什么？全面的 RUM 工具还会提供 LCP 子部分的分解，向你展示用户之间的中位 Resource Load Delay。这些数据验证了 LCP 问题的存在，显示哪些 URL 受到影响，并揭示了你的用户实际看到的常见 LCP 元素。你必须从这里开始，以确认你正在解决一个真实的问题。

步骤 2：使用 DevTools 诊断

一旦你的 RUM 数据确定了目标页面和 LCP 元素，你就可以使用 Chrome DevTools 来诊断原因。这里的目标是重现问题并测量 LCP 子部分以获得精确的 Resource Load Delay 值。DevTools 也是你执行主线程分析的地方，可以准确看到哪些任务正在运行并可能阻塞渲染过程。

Chrome DevTools 性能面板的分步指南

Chrome DevTools 中的性能面板是分析 LCP 和量化 Load Delay 的必备工具。

1. 设置和配置：

• 通过右键单击页面并选择"检查"或使用快捷键 Ctrl+Shift+I (Windows/Linux) 或 Cmd+Option+I (Mac) 打开 Chrome DevTools。   
• 导航到 Performance 选项卡。
• 确保在捕获设置中启用了 Web Vitals 复选框。这将在性能时间线上叠加 Core Web Vitals 信息。   
• 为了模拟真实的用户条件，应用 CPU 和网络节流。CPU 的"4x slowdown"和"Fast 3G"或"Slow 4G"网络配置是移动测试的常见起点。   

2. 录制性能配置文件：

• 单击性能面板中的"录制并重新加载页面"按钮（圆形箭头图标）。这将开始录制，重新加载页面，然后在页面完全加载后停止录制。   

3. 分析和解读：

• Timings 轨道：在主时间线视图中，找到 Timings 轨道。你会看到一个标记为 LCP 的标记。将鼠标悬停在此标记上将在主视口截图中突出显示相应的 LCP 元素并显示总 LCP 时间。   
• LCP 分阶段分解：单击 Timings 轨道中的 LCP 标记。在面板底部的 Summary 选项卡中，你将找到 LCP 时间的详细分解。此分解明确显示四个子部分中每个部分的持续时间，包括以毫秒为单位测量的 Load delay。此值是该特定页面加载的 Resource Load Delay 的最直接和精确的测量。   
• 主线程分析：在检查时间线时，查看 Main 轨道中的长任务（带有红色三角形标记的活动块）。如果这些长任务出现在 LCP 资源加载完成之后但在 LCP 标记之前，它们可能导致了 Element Render Delay，这是一个相关但不同的问题。   

常见原因和高影响解决方案

高 Resource Load Delay 由以下两种情况之一引起：LCP 资源被发现得太晚，或者它被赋予了较低的获取优先级。以下是最常见的架构错误及其解决方案。

原因：LCP 通过 CSS 加载

问题：预加载扫描器不解析 CSS 文件。当你的 LCP 图片使用 CSS background-image 定义时，其 URL 对这个高速扫描器是不可见的。浏览器只能在下载 HTML、找到 CSS 文件链接、下载 CSS 文件、构建 CSSOM，然后应用样式之后才能发现该图片。这个依赖链直接导致了高 Resource Load Delay。

解决方案：正确的实现方式是避免对任何关键 LCP 元素使用 background-image。改用标准的 <img> 标签。这将图片 URL 直接放在 HTML 中，预加载扫描器可以立即找到它。你可以使用 CSS 实现相同的视觉效果。

实现示例：

反模式（不要这样做）：

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

最佳实践（请这样做）：

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="A descriptive alt text for the hero image"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Page Title</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalent to top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* This property mimics background-size: cover */
      z-index: -1; /* Places the image behind other content */
    }
    

此实现提供了相同的视觉效果，但使 LCP 图片在最早的时刻就可被发现，从而最大限度地减少其 Load Delay。

原因：客户端渲染和 JavaScript 注入

问题：使用客户端渲染（CSR）框架（如 React 或 Vue）的应用程序通常提供一个最小的 HTML 外壳。实际内容（包括 LCP <img> 标签）只有在下载、解析和执行大型框架包之后才由 JavaScript 插入 DOM。这个过程从根本上将 LCP 资源隐藏在预加载扫描器之外，造成高发现延迟。

解决方案：最有效的解决方案是将初始渲染从客户端移到服务器。

• 服务器端渲染（SSR）或静态站点生成（SSG）：SSR 或 SSG 等架构模式在服务器上生成完整的 HTML。浏览器收到包含 <img> 标签及其 src 属性的完整文档，使 LCP 资源可被预加载扫描器立即发现。这是任何性能关键页面所需的架构。
• 框架特定的优化：现代框架还提供内置优化。例如，Next.js <Image> 组件具有 priority 属性。将其设置为 true 会指示框架自动添加正确的 <link rel="preload"> 和 fetchpriority="high" 属性，确保图片被发现并以正确的优先级获取。

原因：在 LCP 图片上使用 loading="lazy"

问题：这是一个常见且影响很大的错误。loading="lazy" 属性是对浏览器的直接指令，延迟获取图片直到它接近视口。虽然这是首屏以下图片的正确优化，但将其应用于首屏 LCP 元素是适得其反的。浏览器的预加载扫描器被设计为忽略带有 loading="lazy" 的图片，这保证了延迟发现和高 Resource Load Delay。

解决方案：解决方案需要细心。

• 从 LCP 图片中移除 loading="lazy"：任何可能成为 LCP 元素的图片都不能有 loading="lazy" 属性。浏览器的默认行为是 loading="eager"，这是关键首屏内容的正确设置。完全省略 loading 属性具有相同的效果。
• 审计和配置第三方工具：你还必须审计第三方工具。许多 CMS 平台（如 WordPress）和各种图片优化插件会自动对所有图片应用懒加载。必须配置这些工具以将 LCP 图片排除在此行为之外。这通常涉及为页面上的前一两张图片创建排除规则。

原因：次优的 HTML 结构和大型文档

问题：预加载扫描器从上到下处理 HTML 文档。如果非关键但占用大量带宽的资源（如标题图标或聊天小部件脚本）在 <body> 中的位置高于 LCP 元素，它们会先被发现并排队下载。这会消耗初始网络带宽，并可能延迟 LCP 资源的下载。大型 HTML 文档也可能是一个问题；如果 LCP 元素不在浏览器接收到的第一个数据块中（约 14KB），其发现会被至少一个网络往返延迟。

解决方案：优化 HTML 中内容的结构和优先级。

• 重新排列 HTML：尽可能确保 LCP 元素的 <img> 标签或文本块尽早出现在 <body> 标签内。
• 降低非关键图片的优先级：对于必须出现在 HTML 源码较早位置的非必要图片（如标题中的图标），应用 loading="lazy"。这告诉预加载扫描器跳过它们，为 LCP 元素保留下载队列。
• 延迟非必要脚本：分析、广告或社交媒体小部件的脚本很少对初始渲染至关重要。将其 <script> 标签移到 <body> 末尾或使用 defer 属性。这可以防止它们阻塞解析器或与 LCP 资源争夺网络带宽。

使用资源提示进行高级优先级控制

一旦 LCP 资源在 HTML 中可被发现，你可以使用资源提示来给浏览器更明确的获取指令。这些提示提供了对发现和优先级的精细控制。

使用 <link rel="preload"> 强制提前发现

<link rel="preload"> 不是提示；它是指令。它强制浏览器以高优先级下载资源，即使主解析器尚未发现它。将其放在 HTML 的 <head> 中是修复字体、CSS 背景图片或位于 DOM 深处的 LCP 图片等资源延迟发现问题的最直接方式。

机制

当 preload 链接放置在 HTML 文档的 <head> 中时，预加载扫描器会识别它并立即将指定资源排队下载。这对于通过外部样式表中的 @font-face 加载的字体、CSS background-image LCP（尽管使用 <img> 标签更可取），或位于复杂 DOM 结构深处的 LCP 图片来说是理想的。[3]

响应式预加载

预加载响应式图片时需要一个关键的实现细节。为确保浏览器为用户的视口预加载正确大小的图片并避免浪费性的双重下载，<link rel="preload"> 标签必须包含与相应 <img> 标签上的属性完全匹配的 imagesrcset 和 imagesizes 属性。[4]

响应式预加载示例：

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="A descriptive alt text"
     fetchpriority="high"
     width="1200" height="675">
    

潜在陷阱

预加载解决了获取时机（Load Delay 和 Load Duration）但不解决*绘制时机*。如果在预加载的图片到达时主线程被繁重的 JavaScript 或渲染阻塞 CSS 所阻塞，图片仍然需要等待渲染，这可能会将瓶颈从 Load Delay 转移到 Element Render Delay。[5, 6]

使用 fetchpriority="high" 微调：赢得带宽竞争

fetchpriority 属性是一个提示，用于表示资源下载的相对重要性。它允许你影响资源在浏览器下载队列中的优先级。[7]

preload 与 fetchpriority

这两个提示服务于不同但互补的目的。preload 影响资源何时被发现并添加到队列。fetchpriority 影响资源进入队列后的优先级级别。

LCP 最佳实践

对于 LCP 图片，最优策略是将两者结合使用。首先，通过将 <img> 标签放在 HTML 的早期位置或使用 preload 来确保提前发现。其次，直接在 <img> 标签（以及 preload 链接，如果使用的话）上添加 fetchpriority="high"。这种组合确保资源不仅被提早发现，而且被赋予最高优先级以赢得与其他资源（如样式表或字体）的网络带宽竞争。[3, 1, 7]

示例：

<img src="lcp-image.jpg" fetchpriority="high" alt="A critical hero image">

经过验证的影响

在一个涉及 Google Flights 的案例研究中，向 LCP 背景图片添加 fetchpriority="high" 对于将 LCP 时间从 2.6 秒改善到 1.9 秒起到了关键作用，改善了 700 毫秒。[8]

优化第三方连接：preconnect 和 dns-prefetch

问题

如果你的 LCP 资源托管在第三方域上（例如图片 CDN 或 Google Fonts 等字体提供商），浏览器必须与该域建立新的网络连接。此过程涉及 DNS 查找、TCP 握手和 TLS 协商，所有这些都必须在资源的第一个字节可以下载之前完成。对于跨域资源，这个连接建立时间直接导致了 Resource Load Delay。[9, 2, 10, 11]

解决方案

• preconnect：此提示指示浏览器提前在后台执行指定第三方源的完整连接设置（DNS、TCP 和 TLS）。当实际请求资源时，连接已经就绪，消除了设置延迟。这非常有效，建议用于提供 LCP 资源的一两个最关键的第三方域。[2]
• dns-prefetch：这是一个更轻量级的提示，仅执行域的 DNS 查找。它节省的时间不如 preconnect，但具有更广泛的浏览器支持，作为回退或用于不太关键的第三方域非常有用。[2, 12]

实现最佳实践

为确保最大兼容性，请同时提供这两种提示。如果支持，浏览器将使用 preconnect，否则回退到 dns-prefetch。crossorigin 属性对于使用 CORS 获取的资源（如字体）至关重要。

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>    

表格：LCP 优化的资源提示比较

为防止误用并阐明这些强大提示的不同角色，下表提供了比较摘要。

整体和面向未来的策略

除了有针对性的提示之外，更广泛的架构决策和新兴的 Web 平台特性可以为 Resource Load Delay 提供整体且强大的解决方案。

现代 CDN 的作用

内容分发网络（CDN）是 Web 性能的基础技术，它间接但显著地减少了 Resource Load Delay，尤其是对于 LCP 资源。

• 减少连接开销：通过在全球服务器网络中分发资源，CDN 将内容放在地理上更靠近用户的位置。这固有地减少了 DNS 查找、TCP 握手和 TLS 协商所需的往返时间（RTT），这些都是连接建立时间的组成部分。[13, 14, 15]对于托管在 CDN 上的 LCP 图片，这直接减少了其 Load Delay。
• 图片 CDN：专门的图片 CDN 提供双重优势。它们提供标准 CDN 的就近优势，同时还自动化许多减少 Resource Load Duration 的复杂优化，例如即时图片调整大小、压缩以及转换为 AVIF 和 WebP 等现代格式。[9, 1]
• 高级协议：许多现代 CDN 利用更优的网络协议，如使用 QUIC 代替 TCP 的 HTTP/3。HTTP/3 减少了连接建立时间并缓解了队头阻塞，从而整体上实现更快、更高效的资源交付。[16]

使用 Speculation Rules 彻底消除延迟

Speculation Rules API 是一项前沿的 Web 平台特性，有可能完全消除后续导航的 LCP 延迟。

机制

此 API 允许开发人员以声明方式通知浏览器用户接下来可能导航到哪些 URL。根据这些规则，浏览器可以选择在用户点击链接之前就在隐藏的后台标签页中预渲染目标页面。[3, 1, 16]

对 LCP 的影响

当用户点击预渲染页面的链接时，导航几乎是即时的。页面已经在后台完全加载和渲染。对于此导航，从用户的角度来看，TTFB、Resource Load Delay、Resource Load Duration 和 Element Render Delay 实际上都被降低到接近零。[3, 1, 16]

示例使用场景

在电子商务分类页面上，Speculation Rules 可用于预渲染列表中前几个商品的产品详情页面。当用户点击其中一个产品时，页面立即显示，提供无缝且极快的体验。

案例研究综合：从理论到实践

这些优化策略的有效性不仅仅是理论上的；它通过真实世界测试和场景的数据得到了证明。

• 案例 1：预加载的变革性力量：DebugBear 在一个具有高 Load Delay 的页面上进行的实验提供了一个引人注目的例子。LCP 图片隐藏在请求链中，导致 Resource Load Delay 占总 LCP 时间的惊人 75%。通过实施一个 <link rel="preload"> 提示使图片可以提早被发现，Resource Load Delay 被降低到仅占 LCP 时间的 2%。[17]这展示了一个简单的架构修复如何解决一个巨大的性能瓶颈。
• 案例 2：真实世界的 loading="lazy" 反模式：一位开发者在 Stack Overflow 上报告了桌面端 LCP 出现令人困惑的 1,430 毫秒 Load Delay，尽管网络速度很快。原因被追溯到一个图片优化插件，它通过将 src 属性替换为透明占位 SVG 来错误地对 LCP 图片应用懒加载。最终解决方案是禁用此 LCP 元素的该行为，使其能够被积极发现和加载。[18]这说明了第三方工具如何无意中引入严重的 Load Delay。
• 案例 3：fetchpriority 性能提升：Google Flights 案例研究为显式优先级的影响提供了明确证据。通过简单地将 fetchpriority="high" 添加到页面的 LCP 背景图片，LCP 分数改善了 700 毫秒，从 2.6 秒降至 1.9 秒。[8]这表明，即使资源已可被发现，向浏览器表明其高重要性仍然是赢得网络带宽竞争的关键步骤。

Chrome DevTools 中的网络检查： 使用 Ctrl + Shift + I 快捷键打开 Chrome 的开发者工具，然后选择"Network"选项卡并重新加载页面。查看加载顺序。你的 LCP 资源应该是最先排队下载的项目之一。如果它落后于其他元素，则存在 Resource Load Delay 问题。下面是一个未优化 Resource Load Delay 的网站示例。

利用 Real User Monitoring (RUM) 数据： Real User Monitoring 工具通常会记录 LCP 归因数据。通过 RUM，你可以可视化 LCP 子部分的分解（按时间或按页面），让你清楚了解整个网站或每个页面的 LCP 元素的 Load Delay。 下面的示例显示了全局 LCP 分解以及相应的 Load Delay。

如何改善 Load Delay

Resource Load Delay 发生在资源的下载顺序和时机不是最优的时候。实质上有两种简单的方法来修复它：优先化 LCP 资源或降低非 LCP 资源的优先级。让我们探讨一些常见模式：

LCP 提示：了解预加载扫描器： 现代浏览器使用一种称为预加载扫描器的机制，它快速扫描 HTML 并将资源排队下载。如果资源不能被预加载扫描器排队，它将不得不等待较慢的 DOM 解析器，从而导致延迟。确保你的 LCP 资源可被预加载扫描器发现可以在减少 Load Delay 方面产生重大差异。

1. 优化 HTML 结构

浏览器（或预加载扫描器）从上到下处理你的 HTML，按出现顺序排队资源。这意味着 LCP 资源在 HTML 中出现的位置越高，它就越早被排入队列。要优化这一点，请从 HTML 顶部移除或延迟不需要的资源：

• 懒加载不重要或隐藏的图片：有时图片（例如用于语言特定版本的国旗或菜单中的图片）出现在网站 HTML 的最顶部。这些图片远没有 LCP 元素重要。通过懒加载这些图片，预加载扫描器会跳过它们，在加载过程中稍后排队。
  
• 将不重要的脚本移到页面底部：将对初始加载绝对不重要的脚本移到页面底部，以防止它们延迟关键资源。例如聊天小部件。在互联网的历史上，从来没有人需要在页面可见之前就开始聊天！

2. 避免使用背景图片。

背景图片对预加载扫描器不可见，这意味着它们总是会被更慢的 DOM 解析器排队。为了避免这种延迟，请改用常规的 <img> 标签，结合 CSS 属性 object-fit: cover 来模拟背景图片的外观。这样，预加载扫描器就可以立即检测并排队该图片。

3. 使用 Fetch Priority

在你的 LCP 元素上添加 fetchpriority="high" 属性，向浏览器提示它应该从一开始就优先处理此资源。通常，图片以默认的低或中优先级加载。在布局阶段，浏览器会将可见元素升级为高优先级。通过设置 fetchpriority="high" ，下载立即以高优先级开始，确保更快的 LCP。 

Fetchpriority 通常比预加载侵入性更小（也不那么有效），因为它设置的是元素的相对优先级（在这种情况下，图片相对比其他图片更重要），但它不会使其比样式表或非阻塞脚本更重要

<img src="hero-image.jpg" alt="Hero Image" fetchpriority="high">

4. 实施预加载

预加载改变了预加载扫描器排队文件的顺序。将 <link rel="preload"> 标签放在页面的 head 中 以指示浏览器尽早获取关键资源，例如 LCP 图片。 预加载可用于预加载在 HTML 中稍后引用的资源（因此排队较晚），甚至预加载尚未在 HTML 中引用的资源（如某些轮播图）。为了最大化效果，建议将预加载放在样式表之后、脚本之前的页面头部 

<link rel="preload" as="image" href="hero-image.jpg">

5. 优化样式

样式表通常在 LCP 资源之前排队，这是有充分理由的。没有样式表，浏览器将不知道页面的外观，无法开始渲染阶段。然而，过大的 CSS 体积和过多的样式表数量会与 LCP 资源争夺早期带宽。

6. 实施高效的懒加载

loading 属性可以是一把双刃剑。对你的 LCP 资源使用 loading="eager"（或简单地省略该属性，因为"eager"是浏览器默认值），同时对屏幕外的图片应用 loading="lazy"。

• 积极加载 LCP 元素：如果 LCP 元素被懒加载，它将不会被预加载扫描器排队，加载时间会大大推迟，对性能产生负面影响。
• 懒加载视口中的图片：对于在可视视口中但不是 LCP 资源的图片，使用 loading="lazy" 将它们排队到稍后下载。这减少了与 LCP 资源的带宽竞争。
• 避免懒加载屏幕外图片：不在可视视口中的图片根本不会触发下载，完全消除了带宽竞争。

7. 浏览器缓存

浏览器缓存允许你跳过对已存储在用户设备本地的资源的网络请求。虽然它不会加速首次页面浏览，但会改善后续页面浏览和回访用户的加载时间。以下是浏览器缓存如何帮助解决 Resource Load Delay：

• 缓存竞争资源：虽然缓存 LCP 资源本身是一个很好的策略，但浏览器缓存通过存储可能与 LCP 资源竞争或延迟 LCP 资源的网络资源（如脚本、样式表和图片）来改善 LCP Resource Load Delay。
  
• 减少服务器负载：缓存减少了发送到服务器的请求数量，这可以通过释放带宽和减少服务器 CPU 周期来改善其他资源的性能。
  

8. 使用 Speculation Rules

Speculation Rules 使浏览器能够根据预测的用户导航来预取或预渲染网页。预取有效地消除了 LCP 的 Time to First Byte 子部分，对 Resource Load Delay 没有影响。预渲染在隐藏标签页中渲染下一个页面并下载所有页面资源。 这消除了 LCP 元素的所有 Load Delay，如以下预渲染页面的 LCP 分解示例所示。

9. 避免客户端渲染