Tutorial · performance · Published 2026-08-15 · 3 min read
A 30 minute web performance audit
Run a 30 minute performance audit: field and lab measures, the waterfall, image and JavaScript audits, third-party check, then a performance budget.
What 30 minutes buys
A 30-minute scripted audit turns a vague "the site feels slow" into a numbered list of fixes. This tutorial runs in 30 minutes and yields field data, a lab score, a waterfall, and a short budget. Run it on the page that matters: the homepage or the first money page for a campaign.
Stage 1: Field data (5 minutes)
Open PageSpeed Insights for the URL and note the field numbers: real LCP, INP, and CLS from PageSpeed Insights, plus the baseline lab score; these 5 numbers are the before state. Record them in a table before touching any code.
| Metric | Value | Status |
|---|---|---|
| LCP | 3.2s | Needs improvement |
| INP | 180ms | Good |
| CLS | 0.02 | Good |
| Lab performance | 62 | - |
Stage 2: The lab score and waterfall (10 minutes)
Run Lighthouse from the same URL in an incognito window. Note the top three opportunities by size: each comes with an estimated saving, and together they are the roadmap. Then open DevTools, Network, and reload. Sort by size and by time. The pattern is almost always one of:
- A giant hero image that dwarfs the rest of the page.
- A long TTFB on the HTML request.
- A third-party domain that slides the timeline (chat, analytics, or a provider).
- A render-blocking stylesheet from a plugin the page does not need.
Stage 3: Images (5 minutes)
Now the audit narrows to the two weight champs. Use the same Lighthouse report. If the hero image transfers more than 200 KB, resize it to the render size and recompress (the image optimisation guide gives exact commands). Check it is served in a modern format and that width and height are present so the layout does not shift. A properly sized hero is the single most repeatable LCP win.
Stage 4: JavaScript and third-party (5 minutes)
Look at the script tier. Which scripts run at page load, and do the page's interactions need them? A defer or async attribute on a heavy non-critical script moves it out of the critical path (the render-blocking resources reference covers the choice). Note the third-party list and its total weight across the audit report, then decide which are truly required on this page. The rule: a remarketing pixel plus a chat widget plus analytics is already a meaningful runtime tax, and the heavy site page shows how much of the main thread they take.
Stage 5: Set out the budget (5 minutes)
Turn the findings into a budget, a threshold to hold during builds. The exact numbers vary by stack, but a sample:
| Item | Budget |
|---|---|
| LCP target | 2.5s field / 4.0s lab ceiling |
| Hero image | under 200 KB |
| Render-blocking bytes | 0 |
| Third-party scripts | 3 max, under 300 KB |
| Total page weight | under 1.5 MB |
A budget only works when a build gate enforces it, with the actuals measured: the same Lighthouse run each commit, and a CI check that fails on a regression.
What comes next
Copy the audited findings into a fix list ordered by size, then run the audit again after shipping each change. The LCP optimisation route shows the element-focused follow-on when LCP stays stubborn. The 30-minute version here is the repeatable loop: it turns a vague slowness complaint into decisions a developer can execute in a day.