How SlaySlop checks Lighthouse Performance

I still reach for the Network waterfall first when a page feels late. That habit is fine for a single URL. SlaySlop's Performance audit packages browser-based performance checks on key pages so the result sits next to the rest of the scan instead of a folder of screenshots named final-FINAL.

Published definition: Performance audit "Runs browser-based performance checks on key pages." I will not invent proprietary scoring math the glossary does not state. I will describe the observation point the product pages do state.

Outcome the check is for

You get findings when browser-based performance checks on key pages show problems worth ranking, each linked to the page where it was observed. The outcome is triage fuel for builders, not a claim that every geography and device class was sampled.

Performance siblings stay separate. LCP reviews the loading signal for primary content. CLS checks visual instability during page load. Interaction readiness reviews browser signals related to responsive interaction. Performance audit is the wider browser performance pass on those key pages.

Boundaries

Read-only. Public pages. Permission required. SlaySlop does not edit your bundler config. This is not a pentest and not a synthetic multi-region load test. Private dashboards behind auth the scan never entered will not appear.

A static curl is the wrong observer for this signal. Runtime, layout, and script cost show up after the browser works. The Performance and accessibility product flow starts with "Render key pages": the site opens in a real browser so runtime and layout behavior can be measured.

Happy path: how the signal is observed

Published workflow on the Performance and accessibility product page:

1. Render key pages in a real browser.
2. Run quality audits (performance, accessibility, and best-practice checks) on discovered pages.
3. Attach findings to routes so each issue stays linked to the page where it was observed.
4. Start with the worst: slow, inaccessible, or unstable experiences before cosmetic cleanup.

Performance audit participates in that performance pass. Evidence stays with the finding and the affected page.

When I reproduce locally, I mirror the same idea:

# Permissioned host
printf '%s\n' "https://staging.example.com/pricing"
curl -sI "https://staging.example.com/pricing" | awk 'NR<=12 {print}'

Then open the URL in a browser, wait for network quiet, and inspect the Performance and Network panels. Headers never substitute for that step.

check: Performance audit
observer: real browser on key pages
siblings: LCP, CLS, Interaction readiness
product: Performance and accessibility

Pitfalls when reading the check

Treating one homepage run as the whole site. Ignoring production third parties that staging strips out. Mixing up uptime success with browser performance. Collapsing LCP or CLS into "the Lighthouse number" so the wrong team gets the ticket.

Evidence I expect beside a finding

Product framing repeats that every finding comes with the evidence that triggered it, and that findings attach to routes. For Performance audit that should be enough to open the page and see the same class of problem: long main-thread tasks, late primary content, heavy payloads, or related browser performance signals the audit surfaced.

# Permissioned local notes after opening the finding URL
# DevTools → Network: sort by transferred size
# DevTools → Performance: record a cold load on the same page
printf '%s
' "finding_route=https://staging.example.com/pricing"

If I cannot name the route, I do not trust the conversation yet. If I can name the route but only stared at headers, I also do not trust it. The check's observer is the browser on key pages.

How this sits next to accessibility in one run

The same product run executes accessibility audits on discovered pages. That shared render is convenience, not synonym. Accessibility audit "Runs automated accessibility checks in a rendered browser page." Different findings, same route context. I like that for triage meetings: one URL, two columns, no scavenger hunt across tools.

Related next step

If you want the performance pass beside accessibility on the same routes, use the shared product surface. SlaySlop keeps both sets of findings in one route context after render.