
Debug Optimize Lcp
Diagnose which element is your LCP and why load time is slow using Chrome DevTools–aligned heuristics before you ship.
Overview
debug-optimize-lcp is an agent skill for the Ship phase that explains LCP element types, size rules, and Chromium heuristics so solo builders can debug and optimize largest-contentful paint.
Install
npx skills add https://github.com/chromedevtools/chrome-devtools-mcp --skill debug-optimize-lcpWhat is this skill?
- Explains which DOM types count as LCP candidates (img, svg image, video poster, background-image, text blocks)
- Documents Chromium heuristics that exclude non-contentful nodes (opacity 0, full-viewport covers, placeholders)
- Clarifies how visible vs intrinsic image size and text bounding boxes affect reported LCP element size
- Frames LCP as time-to-largest-content render for breakdown-driven optimization
- Pairs with browser/DevTools workflows for solo builders shipping marketing or app landing pages
Adoption & trust: 958 installs on skills.sh; 43.1k GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+200% hot-view momentum).
What problem does it solve?
You see a poor LCP score but cannot tell which element the browser chose or why it was sized or excluded incorrectly.
Who is it for?
Indie builders tuning marketing pages, dashboards with heavy heroes, or storefronts before launch when Core Web Vitals block ship confidence.
Skip if: Teams that only need generic lighthouse tips without element-level LCP theory, or native mobile apps where web LCP rules do not apply.
When should I use this skill?
LCP is failing thresholds, Lighthouse flags largest contentful paint, or you are tracing render with Chrome DevTools MCP and need element eligibility context.
What do I get? / Deliverables
You can map DevTools LCP breakdown to concrete DOM candidates and sizing rules, then target the hero image, text block, or background that actually drives the metric.
- Prioritized list of likely LCP elements
- Hypotheses tied to exclusion heuristics and size rules
Recommended Skills
Journey fit
Largest Contentful Paint is a launch-readiness and shipping gate metric; this skill belongs on the perf shelf where solo builders fix Core Web Vitals before release. Subphase perf covers measurable render and load bottlenecks; LCP element rules and size heuristics are exactly what you tune in that pass.
How it compares
Use for LCP semantics and element eligibility—not as a substitute for a full CDN or image pipeline integration skill.
Common Questions / FAQ
Who is debug-optimize-lcp for?
Solo and indie builders shipping web apps or sites who use agent-assisted debugging and need to understand what counts as the LCP element and how its size is computed.
When should I use debug-optimize-lcp?
Use it in Ship (perf) when Field or Lab LCP regresses; during Launch (SEO) when page experience matters; and in Build (frontend) when you design hero sections that will become the LCP candidate.
Is debug-optimize-lcp safe to install?
Treat it as documentation-style procedural knowledge; review the Security Audits panel on this Prism page and your org policy before pulling skills from any marketplace.
SKILL.md
READMESKILL.md - Debug Optimize Lcp
# Elements and Size for LCP ## What Elements are Considered? The types of elements considered for Largest Contentful Paint (LCP) are: - **`<img>` elements**: The first frame presentation time is used for animated content like GIFs. - **`<image>` elements** inside an `<svg>` element. - **`<video>` elements**: The poster image load time or first frame presentation time, whichever is earlier. - **Background images**: Elements with a background image loaded using `url()`. - **Block-level elements**: Containing text nodes or other inline-level text element children. ## Heuristics to Exclude Non-Contentful Elements Chromium-based browsers use heuristics to exclude: - Elements with **opacity of 0**. - Elements that **cover the full viewport** (likely background). - **Placeholder images** or low-entropy images. ## How is an Element's Size Determined? - **Visible Area**: Typically the size visible within the viewport. Extending outside, clipped, or overflow portions don't count. - **Image Elements**: Either the visible size or the intrinsic size, whichever is smaller. - **Text Elements**: The smallest rectangle containing all text nodes. - **Exclusions**: Margin, padding, and borders are not considered toward the size. - **Containment**: Every text node belongs to its closest block-level ancestor element. # Largest Contentful Paint (LCP) Breakdown LCP measures the time from when the user initiates loading the page until the largest image or text block is rendered within the viewport. To provide a good user experience, sites should strive to have an LCP of 2.5 seconds or less for at least 75% of page visits. ## The Four Subparts of LCP Every page's LCP consists of these four subcategories. There's no gap or overlap between them, and they add up to the full LCP time. | LCP subpart | % of LCP (Optimal) | Description | | ----------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Time to First Byte (TTFB)** | ~40% | The time from when the user initiates loading the page until the browser receives the first byte of the HTML document response. | | **Resource load delay** | <10% | The time between TTFB and when the browser starts loading the LCP resource. If the LCP element doesn't require a resource load (e.g., system font text), this time is 0. | | **Resource load duration** | ~40% | The duration of time it takes to load the LCP resource itself. If the LCP element doesn't require a resource load, this time is 0. | | **Element render delay** | <10% | The time between when the LCP resource finishes loading and the LCP element rendering fully. | ## Why the Breakdown Matters Optimizing for LCP requires identifying which of these subparts is the bottleneck: - **Large delta between TTFB and FCP**: Indicates the browser needs to download a lot of render-blocking assets or complete a lot of work (e.g., client-side rendering). - **Large delta between FCP and LCP**: Indicates the LCP resource is not immediately available for the browser to prioritize or the browser is completing other work before it can display the LCP content. - **Large resource load delay**: Indicates the resource is not discoverable early or is deprioritized. - **Large element render delay**: Indicates rendering is blocked by stylesheets, scripts, or long tasks. # LCP Debugging Snippets Use these JavaScript snippets with the `evaluate_script` tool to extract deep insights from the page. ## 1. Identify L