Frontend LCP Tuning Workflow

Identify the largest contentful paint element and fix the specific blockers of resource load, render delay, and size.

advanced~65 minperformancefrontendweb

Objective

Improve largest contentful paint by fixing its specific contributing factors.

Environment

Lighthouse or a RUM tool
A staging page
Network throttling

Steps

1. Identify the LCP element

Determine which element is the largest contentful paint on key pages.

Expected state: The LCP element is known, not assumed.

2. Diagnose the delays

Separate time to first byte, resource load delay, and render delay.

Expected state: The dominant delay phase is known.

3. Fix the dominant factor

Optimise the image, preload it, or eliminate render-blocking work as the diagnosis indicates.

Expected state: The chosen fix targets the real delay.

4. Verify LCP improvement

Re-measure under the same throttling and confirm LCP improved.

Expected state: LCP improves with evidence.

Decision points

Optimise images or remove render-blocking?

Follow the diagnosis
Optimise images always

Fix whichever phase dominates; optimising the wrong phase does nothing.

Field or lab measurement?

Field for what users see, lab for diagnosis
Lab only

Use field data to prioritise and lab tools to diagnose.

Expected outcome

LCP improves because the specific dominant delay was fixed rather than randomly optimised.

Verification

Confirm LCP drops under the same conditions and the fix addresses the diagnosed phase.

Cleanup

Add a performance budget check to CI to prevent regression.

Overview

Improve largest contentful paint by fixing its specific contributing factors.

This workflow is reusable across teams and environments; adapt the commands to your tooling while keeping the sequence and checkpoints intact.

Environment and prerequisites

Lighthouse or a RUM tool
A staging page
Network throttling

Procedure

1. Identify the LCP element

Determine which element is the largest contentful paint on key pages.

Expected state: The LCP element is known, not assumed.

2. Diagnose the delays

Separate time to first byte, resource load delay, and render delay.

Expected state: The dominant delay phase is known.

3. Fix the dominant factor

Optimise the image, preload it, or eliminate render-blocking work as the diagnosis indicates.

Expected state: The chosen fix targets the real delay.

4. Verify LCP improvement

Re-measure under the same throttling and confirm LCP improved.

Expected state: LCP improves with evidence.

# identify the LCP element
npx lighthouse https://staging.example.com --only-audits=largest-contentful-paint-element --output=json

Verification

Confirm LCP drops under the same conditions and the fix addresses the diagnosed phase.

Decision points

Optimise images or remove render-blocking?

Follow the diagnosis
Optimise images always

Recommendation: Fix whichever phase dominates; optimising the wrong phase does nothing.

Field or lab measurement?

Field for what users see, lab for diagnosis
Lab only

Recommendation: Use field data to prioritise and lab tools to diagnose.

Common failures

Optimising the wrong phase wastes effort.
Lab-only data may miss real-user experience.
No budget lets LCP regress again.