Skip to content

Engineering

Fixing Largest Contentful Paint without guessing

Stop pasting random image-CDN snippets from memory. Confirm the primary content loading signal on the cited page, change the real LCP element path, and verify with the same evidence trail.

· by Jonas Reed

Fixing Largest Contentful Paint without guessing

Guessing a global "compress all images" pass from a random gist is how you "fix" LCP on the homepage and break an article template's gallery quality. The loading signal for primary page content is a concrete observation on a concrete URL. Your fix should start there.

SlaySlop's Largest Contentful Paint check "Reviews the loading signal for the primary page content." Fixing without guessing means reproducing that signal on a host you control, changing the real cause, and verifying the same evidence goes quiet.

Outcome you want

After the fix, the cited public pages no longer show the primary-content loading problem that triggered the finding. A follow-up scan no longer flags the same LCP evidence on those routes. CLS and Interaction readiness still get their own triage—you did not "fix Performance" by shrinking one PNG and ignoring shift or input delay.

Boundaries before you edit

Read-only scanner. You change your own templates, media, CDN rules, or edge config. Permission required on anything you scan. Not a pentest. Not a license to hammer third-party origins. LCP is one Performance row beside CLS ("Checks for visual instability during page load").

Do not strip required consent UI illegally to chase a metric. Do not pretend a CDN purge alone changed hero bytes.

Loading diagram.

Happy path: reproduce, fix, verify

  1. Copy the affected URL from the finding evidence.
  2. Cold-load it in a clean browser. Note which element looks like primary content.
  3. Confirm bytes, format, dimensions, and whether the element was discoverable early in the document.
  4. Change the cause: responsive images, modern formats, preload only when appropriate, reduce competing late discovers, fix server TTFB if the document itself is late.
  5. Deploy to the same host family the scan used.
  6. Rescan with permission and confirm the LCP evidence quieted. Check CLS and Interaction readiness so you did not trade one problem for another.
bash
# Permissioned: confirm you are fixing the same host the report cited
curl -sI "https://www.example.com/campaign" | awk 'NR==1 || tolower($0) ~ /^(server|cache|cf-ray|content-type|content-length)/ {print}'
text
fix_log:
  check: Largest Contentful Paint
  definition: "Reviews the loading signal for the primary page content."
  url:
  lcp_element:
  change:
  rescan_date:
  cls_interaction_reviewed: yes|no

Choosing a fix that matches the cause

If the document is slow, fix origin or cache first. If the hero bytes are huge, fix media. If the LCP element is a late-discovered image without dimensions in the initial HTML, fix markup discoverability. Matching the fix to the cause sounds obvious. It is still where most guessing dies.

I keep a short personal rule: one cause per commit when I can. Mixing a hero recompress with a redesign of the pricing table makes the rescan harder to interpret.

Pitfalls

Fixing only on staging with different media than production. Fixing by deleting the hero and calling the metric improved. Fixing the ticket title without a before/after note. Collapsing CLS into the same commit message without measuring it.

After it goes quiet

Update the portal note with the rescan date. Leave CLS and Interaction readiness as their own checkboxes. Tell the client what changed in one sentence. Then stop touching the page unless a new finding appears.

Aftercare

CDN caches lie cheerfully. After deploy, confirm the cited URL serves the new hero bytes, then rescan. If marketing still has a tag-manager module waiting to reinject the old campaign still, kill that module in the same change set.

I still admit the habit: I curl headers once for comfort, then I open a real browser and watch the primary content. Headers are not the check. The paint is.

Choosing the fix layer deliberately

Media weight, render-blocking CSS, and failed assets are not interchangeable. If the hero is the late element, fix the hero path. If a stylesheet blocks paint of a text headline that is primary content, fix the stylesheet strategy. Mechanisms first. Blame later.

html
<!-- Prefer explicit dimensions + modern delivery for media that owns LCP -->
<img
  src="/hero.avif"
  width="1200"
  height="675"
  alt="Product hero"
  fetchpriority="high"
/>

Illustrative markup only. Your stack may use a picture element or a CDN image API. The point is deliberate primary-content delivery—not a random compression knob.

Documentation culture is part of the fix

If the runbook still says "upload the full-resolution brand still to every campaign," the late paint will return. Change the runbook in the same window as the media fix. Process that survives launch week is a checklist, not a hero engineer who remembers which asset was sketchy.

Related next step

If Network failures accompany the late paint, fix Failed requests with the same reproduce-and-rescan discipline. Soft product mention only when it helps: SlaySlop's page evidence is a better start than a gist you half remember.