Skip to content

Engineering

Common Lighthouse Performance mistakes that still ship

Shipping with a homepage-only lab score, ignored CLS siblings, and production tags staging never had still happens—Performance audit mistakes that confuse a glance with a check.

· by Jonas Reed

Common Lighthouse Performance mistakes that still ship

Curious mechanism question first: what did the browser actually measure on which pages? Not what a slide said about "fast." Not what staging looked like with marketing tags disabled. The mistakes that still ship treat Performance audit like a vibe.

SlaySlop's definition: Performance audit "Runs browser-based performance checks on key pages." Browser-based. Key pages. The failures below drop one of those constraints.

Outcome if you catch these early

Key pages get a real-browser performance pass. LCP, CLS, and Interaction readiness stay labeled as siblings. Production parity is written down. Uptime is not asked to impersonate performance.

Boundaries

Read-only. Permissioned. Not a pentest. Not a CDN configuration service. Performance audit lives under Performance with Largest Contentful Paint, Cumulative Layout Shift, and Interaction readiness. Inventory of feelings is not a substitute for those signals.

Loading diagram.

Mistake 1: one URL stands in for the site

Product flow runs quality audits on discovered pages and attaches findings to routes. Measuring / once leaves campaign landers, bloated article templates, and checkout steps unchecked. Linked pages discovery often reveals the gap.

bash
# Permissioned: list what you claim is "key" before launch
printf '%s\n' \
  "https://staging.example.com/" \
  "https://staging.example.com/pricing" \
  "https://staging.example.com/blog/some-heavy-post"

Mistake 2: headers-only "performance" review

bash
curl -sI "https://staging.example.com/" | sed -n '1,20p'

Useful for TLS and caching headers. Useless as a substitute for browser-based performance checks. Runtime cost and layout behavior need a real browser—the Performance and accessibility product says that outright.

Mistake 3: collapsing LCP and CLS into one score argument

LCP "Reviews the loading signal for the primary page content." CLS "Checks for visual instability during page load." Fixing image compression may help LCP and do nothing for a late font that shoves text. Separate tickets beat abstract score theater.

text
mistake: score_collapse
symptom: "we improved Lighthouse so CLS is fine"
fix: read sibling findings by name; verify on the same route

Mistake 4: staging without third parties, production with the full set

The release adds pixels, chat widgets, and A/B scripts. Staging stayed clean. Performance audit on production reopens. Re-check the hostname you hand the client.

Mistake 5: treating uptime green as user-speed green

Monitoring answers availability. Performance audit answers browser-based checks on key pages. A 200 with a five-second main-thread block still ships pain.

Mistake 6: ignoring Interaction readiness

Interaction readiness "Reviews browser signals related to responsive interaction." A pretty paint with a dead click target for seconds is still a handoff failure. Do not let first-paint pride hide it.

Mistake 7: optimizing micro-CSS while the hero video autoplays unmuted bandwidth

Product priority: start with the worst. Slow, inaccessible, or unstable experiences first. Cosmetic cleanup later. I still see PRs that shave a unused rule while a 12 MB hero ships.

Loading diagram.

Mistake 8: no permission, "just checking" a prospect's site

Read-only does not mean permissionless. Acceptable Use still applies.

Lab notebook addendum

When I reproduce a "mystery slow" report, I write three lines before I touch code: route, device width, and whether third parties were allowed. That alone prevents half the mistaken fixes. Performance audit findings without those lines turn into debates about whose laptop was kinder.

bash
# Permissioned cold-check reminder
UA_NOTES="mobile_width=390 third_parties=on"
echo "$UA_NOTES https://staging.example.com/pricing"

Also keep Domain insights out of the wrong argument. DNS and mail configuration explain delivery and infrastructure context; they do not replace browser-based performance checks on key pages. Different products, different sentences on the incident doc.

Depth notes

Interaction readiness deserves a explicit QA note on conversion pages. A button that paints early and responds late still fails the "how it feels" test agencies get graded on. Pair it with Performance audit rather than treating it as optional garnish.

Related next step

If you want browser performance checks beside accessibility on the same routes, SlaySlop runs that pass after render and keeps evidence on each finding.