debug-optimize-lcp

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

What is LCP and why it matters

什么是LCP及其重要性

Largest Contentful Paint (LCP) measures how quickly a page's main content becomes visible. It's the time from navigation start until the largest image or text block renders in the viewport.

Good: 2.5 seconds or less
Needs improvement: 2.5–4.0 seconds
Poor: greater than 4.0 seconds

LCP is a Core Web Vital that directly affects user experience and search ranking. On 73% of mobile pages, the LCP element is an image.

Largest Contentful Paint（LCP）用于衡量页面主内容变为可见的速度，即从开始导航到视口中最大的图片或文本块完成渲染的时间。

良好：2.5秒及以内
需要改进：2.5–4.0秒
较差：超过4.0秒

LCP是Core Web Vitals的一项指标，直接影响用户体验和搜索排名。在73%的移动端页面中，LCP元素是图片。

LCP Subparts Breakdown

LCP子阶段细分

Every page's LCP breaks down into four sequential subparts with no gaps or overlaps. Understanding which subpart is the bottleneck is the key to effective optimization.

Subpart	Ideal % of LCP	What it measures
Time to First Byte (TTFB)	~40%	Navigation start → first byte of HTML received
Resource load delay	<10%	TTFB → browser starts loading the LCP resource
Resource load duration	~40%	Time to download the LCP resource
Element render delay	<10%	LCP resource downloaded → LCP element rendered

The "delay" subparts should be as close to zero as possible. If either delay subpart is large relative to the total LCP, that's the first place to optimize.

Common Pitfall: Optimizing one subpart (like compressing an image to reduce load duration) without checking others. If render delay is the real bottleneck, a smaller image won't help — the saved time just shifts to render delay.

每个页面的LCP都可细分为四个连续且无重叠的子阶段。找出哪个子阶段是瓶颈，是有效优化的关键。

子阶段	LCP的理想占比	衡量内容
Time to First Byte (TTFB)	~40%	从开始导航到接收到HTML的第一个字节的时间
资源加载延迟	<10%	从TTFB到浏览器开始加载LCP资源的时间
资源加载时长	~40%	下载LCP资源所需的时间
元素渲染延迟	<10%	从LCP资源下载完成到LCP元素渲染完成的时间

“延迟”类子阶段应尽可能接近零。如果任一延迟子阶段占总LCP的比例过大，那就是首先需要优化的地方。

常见误区：仅优化某一个子阶段（比如压缩图片以缩短加载时长）而不检查其他子阶段。如果渲染延迟才是真正的瓶颈，缩小图片尺寸并无帮助——节省的时间只会转移到渲染延迟上。

Debugging Workflow

调试流程

Follow these steps in order. Each step builds on the previous one.

按顺序执行以下步骤，每一步都基于上一步的结果。

Step 1: Record a Performance Trace

步骤1：记录性能追踪

Navigate to the page, then record a trace with reload to capture the full page load including LCP:

```
navigate_page
```
to the target URL.

performance_start_trace

with

reload: true

and

autoStop: true

The trace results will include LCP timing and available insight sets. Note the insight set IDs from the output — you'll need them in the next step.

导航至目标页面，然后记录包含重新加载的追踪信息，以捕获包括LCP在内的完整页面加载过程：

调用
```
navigate_page
```
访问目标URL。

调用

performance_start_trace

，设置

reload: true

和

autoStop: true

。

追踪结果将包含LCP计时和可用的洞察集。记录输出中的洞察集ID——下一步会用到。

Step 2: Analyze LCP Insights

步骤2：分析LCP洞察信息

Use

performance_analyze_insight

to drill into LCP-specific insights. Look for these insight names in the trace results:

LCPBreakdown — Shows the four LCP subparts with timing for each.
DocumentLatency — Server response time issues affecting TTFB.
RenderBlocking — Resources blocking the LCP element from rendering.
LCPDiscovery — Whether the LCP resource was discoverable early.

Call

performance_analyze_insight

with the insight name and the insight set ID from the trace results.

使用

performance_analyze_insight

深入分析LCP相关的洞察信息。在追踪结果中查找以下洞察名称：

LCPBreakdown — 显示四个LCP子阶段及其各自的计时。
DocumentLatency — 影响TTFB的服务器响应时间问题。
RenderBlocking — 阻止LCP元素渲染的资源。
LCPDiscovery — LCP资源是否可被提前发现。

传入洞察名称和追踪结果中的洞察集ID，调用

performance_analyze_insight

。

Step 3: Identify the LCP Element

步骤3：识别LCP元素

Use

evaluate_script

with the "Identify LCP Element" snippet found in references/lcp-snippets.md to reveal the LCP element's tag, resource URL, and raw timing data.

The

url

field tells you what resource to look for in the network waterfall. If

url

is empty, the LCP element is text-based (no resource to load).

使用

evaluate_script

并结合references/lcp-snippets.md中的**“识别LCP元素”代码片段**，查看LCP元素的标签、资源URL和原始计时数据。

url

字段会告诉你在网络瀑布图中需要查找的资源。如果

url

为空，则LCP元素是纯文本（无需加载资源）。

Step 4: Check the Network Waterfall

步骤4：检查网络瀑布图

Use

list_network_requests

to see when the LCP resource loaded relative to other resources:

Call

list_network_requests

filtered by

resourceTypes: ["Image", "Font"]

(adjust based on Step 3).

Then use
```
get_network_request
```
with the LCP resource's request ID for full details.

Key Checks:

Start Time: Compare against the HTML document and the first resource. If the LCP resource starts much later than the first resource, there's resource load delay to eliminate.
Duration: A large resource load duration suggests the file is too big or the server is slow.

使用

list_network_requests

查看LCP资源相对于其他资源的加载时间：

调用
```
list_network_requests
```
，并按
```
resourceTypes: ["Image", "Font"]
```
过滤（可根据步骤3的结果调整）。
然后使用LCP资源的请求ID调用
```
get_network_request
```
以获取完整详情。

关键检查点：

开始时间：与HTML文档和第一个资源的开始时间对比。如果LCP资源的开始时间远晚于第一个资源，说明存在需要消除的资源加载延迟。
时长：资源加载时长大，说明文件过大或服务器速度慢。

Step 5: Inspect HTML for Common Issues

步骤5：检查HTML中的常见问题

Use

evaluate_script

with the "Audit Common Issues" snippet found in references/lcp-snippets.md to check for lazy-loaded images in the viewport, missing fetchpriority, and render-blocking scripts.

使用

evaluate_script

并结合references/lcp-snippets.md中的**“常见问题审计”代码片段**，检查视口中的懒加载图片、缺失的fetchpriority，以及阻塞渲染的脚本。

Optimization Strategies

优化策略

After identifying the bottleneck subpart, apply these prioritized fixes.

确定瓶颈子阶段后，按优先级应用以下修复方案。

1. Eliminate Resource Load Delay (target: <10%)

1. 消除资源加载延迟（目标：<10%）

The most common bottleneck. The LCP resource should start loading immediately.

Root Cause: LCP image loaded via JS/CSS,
```
data-src
```
usage, or
```
loading="lazy"
```
.
Fix: Use standard
```
<img>
```
with
```
src
```
. Never lazy-load the LCP image.
Fix: Add
```
<link rel="preload" fetchpriority="high">
```
if the image isn't discoverable in HTML.
Fix: Add
```
fetchpriority="high"
```
to the LCP
```
<img>
```
tag.

这是最常见的瓶颈。LCP资源应立即开始加载。

根本原因：LCP图片通过JS/CSS加载、使用
```
data-src
```
或
```
loading="lazy"
```
。
修复方案：使用标准
```
<img>
```
标签并设置
```
src
```
。切勿对LCP图片使用懒加载。
修复方案：如果图片无法在HTML中被提前发现，添加
```
<link rel="preload" fetchpriority="high">
```
。
修复方案：为LCP
```
<img>
```
标签添加
```
fetchpriority="high"
```
。

2. Eliminate Element Render Delay (target: <10%)

2. 消除元素渲染延迟（目标：<10%）

The element should render immediately after loading.

Root Cause: Large stylesheets, synchronous scripts in
```
<head>
```
, or main thread blocking.
Fix: Inline critical CSS, defer non-critical CSS/JS.
Fix: Break up long tasks blocking the main thread.
Fix: Use Server-Side Rendering (SSR) so the element exists in initial HTML.

元素应在加载完成后立即渲染。

根本原因：大型样式表、
```
<head>
```
中的同步脚本，或主线程阻塞。
修复方案：内联关键CSS，延迟加载非关键CSS/JS。
修复方案：拆分阻塞主线程的长任务。
修复方案：使用Server-Side Rendering（SSR），使元素在初始HTML中就已存在。

3. Reduce Resource Load Duration (target: ~40%)

3. 缩短资源加载时长（目标：~40%）

Make the resource smaller or faster to deliver.

Fix: Use modern formats (WebP, AVIF) and responsive images (
```
srcset
```
).
Fix: Serve from a CDN.
Fix: Set
```
Cache-Control
```
headers.
Fix: Use
```
font-display: swap
```
if LCP is text blocked by a web font.

减小资源大小或加快交付速度。

修复方案：使用现代格式（WebP、AVIF）和响应式图片（
```
srcset
```
）。
修复方案：通过CDN提供资源。
修复方案：设置
```
Cache-Control
```
头。
修复方案：如果LCP文本被网络字体阻塞，使用
```
font-display: swap
```
。

4. Reduce TTFB (target: ~40%)

4. 缩短TTFB（目标：~40%）

The HTML document itself takes too long to arrive.

Fix: Minimize redirects and optimize server response time.
Fix: Cache HTML at the edge (CDN).
Fix: Ensure pages are eligible for back/forward cache (bfcache).

HTML文档本身的到达时间过长。

修复方案：最小化重定向并优化服务器响应时间。
修复方案：在边缘节点（CDN）缓存HTML。
修复方案：确保页面符合前后向缓存（bfcache）的条件。

Verifying Fixes & Emulation

验证修复与模拟测试

Verification: Re-run the trace (
```
performance_start_trace
```
with
```
reload: true
```
) and compare the new subpart breakdown. The bottleneck should shrink.
Emulation: Lab measurements differ from real-world experience. Use
```
emulate
```
to test under constraints:
- ```
emulate
```
  with
```
networkConditions: "Fast 3G"
```
  and
```
cpuThrottlingRate: 4
```
  .
- This surfaces issues visible only on slower connections/devices.

验证：重新运行追踪（设置
```
reload: true
```
调用
```
performance_start_trace
```
），并对比新的子阶段细分结果。瓶颈占比应有所缩小。
模拟：实验室测量结果与真实体验存在差异。使用
```
emulate
```
在受限条件下测试：
- 调用
```
emulate
```
  并设置
```
networkConditions: "Fast 3G"
```
  和
```
cpuThrottlingRate: 4
```
  。
- 这会暴露仅在较慢网络/设备上才会出现的问题。",