Guides debugging and optimizing Largest Contentful Paint (LCP) using Chrome DevTools MCP tools. Use this skill whenever the user asks about LCP performance, slow page loads, Core Web Vitals optimization, or wants to understand why their page's main content takes too long to appear. Also use when the user mentions "largest contentful paint", "page load speed", "CWV", or wants to improve how fast their hero image or main content renders.
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.
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.
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.
Follow these steps in order. Each step builds on the previous one.
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.
Use performance_analyze_insight to drill into LCP-specific insights. Look for these insight names in the trace results:
Call performance_analyze_insight with the insight set ID and the insight name from the trace results.
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).
Use list_network_requests to see when the LCP resource loaded relative to other resources:
list_network_requests filtered by resourceTypes: ["Image", "Font"] (adjust based on Step 3).get_network_request with the LCP resource's request ID for full details.Key Checks:
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.
After identifying the bottleneck subpart, apply these prioritized fixes.
The most common bottleneck. The LCP resource should start loading immediately.
data-src usage, or loading="lazy".<img> with src. Never lazy-load the LCP image.<link rel="preload" fetchpriority="high"> if the image isn't discoverable in HTML.fetchpriority="high" to the LCP <img> tag.The element should render immediately after loading.
<head>, or main thread blocking.Make the resource smaller or faster to deliver.
srcset).Cache-Control headers.font-display: swap if LCP is text blocked by a web font.The HTML document itself takes too long to arrive.
performance_start_trace with reload: true) and compare the new subpart breakdown. The bottleneck should shrink.emulate to test under constraints:
emulate with networkConditions: "Fast 3G" and cpuThrottlingRate: 4.