Scenario · The bigger jobs
This site needs to be faster
Usually raised internally — a performance pass on a site nobody has complained about yet.
A slow site is usually raised proactively rather than reported, which changes the job: there's no complaint to reproduce, so it starts with measuring the real page rather than guessing at a cause. This measures actual load performance, ranks exactly which script, image or plugin is costing what, and takes the free wins — image weight — first, since that's the one fix with no risk of breaking anything else; every other change gets made and re-measured one at a time on purpose, so if something breaks, it's obvious which change did it.
What to ask for
See it work
A real run of Performance (Core Web Vitals):
Performance (Core Web Vitals) · performance-core-web-vitals — https://toolkit-tests.pages.dev/perf/slow-lcp.html
PageSpeed Insights (mobile + desktop) …
FAIL — https://toolkit-tests.pages.dev/perf/slow-lcp.html (psi, lighthouse 13.4.1)
mobile score 57 LCP:poor INP:— CLS:good
desktop score 59 LCP:poor INP:— CLS:good
playbook: local fallback
report: ./out/performance-core-web-vitals-performance-core-web-vitals.html
json: ./out/perf.json
text: ./out/performance-core-web-vitals-performance-core-web-vitals.txtThe captured report, exactly as a run hands it to a client —open the full report ↗
Seen in the wild
Closed as complete. 79 of 105 images oversized.
Ticket #12642closed
Selfie gallery — add the new cases
What the audit pulled back
| Images on the page | 105 |
|---|---|
| Larger than shown | 79 |
| Worst single case | 800px into 226px |
| Lazy-loaded | none |
| Verdict | REVIEW |
The tool names the fix in its own output — the image optimizer handles all 79 in one pass.
The cases were uploaded correctly and the page looks right. What nobody could see by looking is that the entire gallery loads at full weight, up front, on every visit — including on a phone, on mobile data, in a waiting room.
This category looks like an inbound complaint and mostly is not: it is proactive work we raise ourselves. That changes the procedure — there is no reported symptom to reproduce, so the job starts with measurement rather than triage, and it ends with a decision about what to remove.
- Measure the real page, not a synthetic one. Run the performance check for the pages that matter — home, the top service pages, whatever ranks. Lab numbers on their own mislead; where real user data exists, pull the field series so you are looking at what visitors actually experience over time rather than one run from one location.
- Rank the causes before touching anything. The fix pipeline turns a performance report into ordered, file-level findings: which script, which stylesheet, which image, how many bytes each is costing, and whether the call is remove, defer, or optimise. A performance ticket worked without this becomes an afternoon of guessing.
- Take the free wins first — images. Image weight is usually the largest single line and the only one with no behavioural risk: converting and resizing changes nothing about how the site works. Audit the page’s image weight, then optimise the offenders locally.
- Look at what the site is carrying. The plugin and theme audit finds abandoned and outdated plugins, which are both a security matter and frequently a performance one. On a Divi build, the Divi audit reports the inline-CSS weight that is the classic cause on those sites.
- [manual] Remove or defer, one change at a time, re-measuring after each. This is where the judgement is: a plugin that costs 400ms may be running something the client depends on, and the only way to know is to ask rather than to delete and wait for the complaint.
- Re-measure and record the delta. Same pages, same tool, before and after. A performance pass with no recorded starting point cannot be shown to have worked, which is how this work stops being funded.
Why “one change at a time” is in the procedure
Batching six optimisations and re-measuring once tells you the total moved and nothing about which change did it — or which one broke the booking widget. On a site you do not own, attribution matters more than throughput.
What this does not cover
The fixes that require a developer. It measures, ranks and tells you which asset or plugin is costing what; converting that into a faster site means deleting things, and deciding what a client can live without is a conversation rather than a check. Server-side and host-level causes are largely outside it too — it reads what the page delivers, not what the origin is doing to produce it.