01 Sample report
not a client report
This is what $699 buys.
Below is a sample of the Speed Rescue handover, populated with the causes we most commonly find on slow WordPress sites, so you can judge the depth before you pay. It is a sample of the format, not a real client's report, and the numbers are a representative composite rather than one site's best case. Client reports are confidential.
Speed report: sample
- Fee
- $699 fixed
- Turnaround
- 1 week
- Causes shown
- 5 of a typical 6–12
- Format
- numbers, then causes
02 The numbers
Before and after, measured the same way.
PageSpeed Insights, mobile profile, same templates, same week. This table is the whole guarantee: if the after column is not better than the before column, the fee comes back.
| Metric | Before | After | What it is |
|---|---|---|---|
| LCP (mobile) | 7.4 s | 2.1 s | Largest Contentful Paint. Google calls anything over 2.5s poor. |
| TTFB | 92 ms | 88 ms | Time to first byte. Already fine before we started, and we did not pretend otherwise. |
| CLS | 0.31 | 0.02 | Layout shift. Over 0.1 is poor: this is the page jumping under a thumb. |
| Total page weight | 6.8 MB | 1.1 MB | What a phone on mobile data has to download before the page settles. |
| Blocking JavaScript | 18 files | 4 files | Scripts loading in the head, holding up the first paint. |
| PSI mobile score | 24 | 91 | The headline number. It is the least useful one here, and the one clients ask about first. |
Note the TTFB row. It barely moved, because it was already fine, which is the normal case. We report it anyway so you can see what we did not fix and did not need to.
03 The causes
Five causes, ranked by the time they cost.
Each one names what we found, the fix we shipped, and what that fix bought back. Real reports typically run 6 to 12.
Cause 01 · Images
The homepage hero was a 3800×2500 JPEG at 2.4 MB, served at full size to every phone and resized in the browser. Eleven more originals loaded below the fold with no lazy-loading. Images alone were 4.9 MB of the 6.8 MB page.
- Fix shipped Generated correct responsive sizes, converted to WebP with JPEG fallback, added lazy-loading below the fold and left the hero eager so the LCP element does not wait in a queue.
- Bought back 4.1 s off LCP
Cause 02 · Theme weight
The page builder enqueued its full CSS and JavaScript bundle on every page, including animation, carousel and form modules the site never used. 780 KB of CSS, of which the rendered pages needed roughly 60 KB.
- Fix shipped Disabled the unused builder modules, scoped the remaining assets to the templates that use them, and inlined the small amount of CSS the first screen actually needs.
- Bought back 1.2 s off LCP
Cause 03 · Plugin JavaScript
Fourteen plugins each loading their own scripts in the head: a slider, a chat widget, two analytics tags, a cookie banner, a popup builder and a booking form present on one page but loaded on all 40.
- Fix shipped Deferred everything not needed for the first paint, restricted the booking form assets to the booking page, and removed three plugins whose only job was something the theme already did.
- Bought back 0.9 s off LCP, 14 fewer requests
Cause 04 · Fonts
Six font files across three families, loaded from a third-party host with no preconnect and no font-display, so text was invisible for about 900ms while they downloaded.
- Fix shipped Self-hosted two families in two weights each, subset to Latin, with font-display: swap and a preload on the one used above the fold.
- Bought back 0.9 s to first text
Cause 05 · Layout shift
Images and ad slots had no reserved dimensions, and the cookie banner injected itself above the content after load. The page moved under the reader twice in the first three seconds.
- Fix shipped Set explicit width and height on every image, reserved space for the embeds, and moved the banner to an overlay that does not push the document.
- Bought back CLS 0.31 → 0.02
01 Cause 01 · Images
The homepage hero was a 3800×2500 JPEG at 2.4 MB, served at full size to every phone and resized in the browser. Eleven more originals loaded below the fold with no lazy-loading. Images alone were 4.9 MB of the 6.8 MB page.
- Fix shipped Generated correct responsive sizes, converted to WebP with JPEG fallback, added lazy-loading below the fold and left the hero eager so the LCP element does not wait in a queue.
- Bought back 4.1 s off LCP
02 Cause 02 · Theme weight
The page builder enqueued its full CSS and JavaScript bundle on every page, including animation, carousel and form modules the site never used. 780 KB of CSS, of which the rendered pages needed roughly 60 KB.
- Fix shipped Disabled the unused builder modules, scoped the remaining assets to the templates that use them, and inlined the small amount of CSS the first screen actually needs.
- Bought back 1.2 s off LCP
03 Cause 03 · Plugin JavaScript
Fourteen plugins each loading their own scripts in the head: a slider, a chat widget, two analytics tags, a cookie banner, a popup builder and a booking form present on one page but loaded on all 40.
- Fix shipped Deferred everything not needed for the first paint, restricted the booking form assets to the booking page, and removed three plugins whose only job was something the theme already did.
- Bought back 0.9 s off LCP, 14 fewer requests
04 Cause 04 · Fonts
Six font files across three families, loaded from a third-party host with no preconnect and no font-display, so text was invisible for about 900ms while they downloaded.
- Fix shipped Self-hosted two families in two weights each, subset to Latin, with font-display: swap and a preload on the one used above the fold.
- Bought back 0.9 s to first text
05 Cause 05 · Layout shift
Images and ad slots had no reserved dimensions, and the cookie banner injected itself above the content after load. The page moved under the reader twice in the first three seconds.
- Fix shipped Set explicit width and height on every image, reserved space for the embeds, and moved the banner to an overlay that does not push the document.
- Bought back CLS 0.31 → 0.02
04 The structure
What every report contains.
From Etherlabz, the rescue desk
Re What every Speed Rescue handover contains
The numbers open it, not close it
Before and after on the same templates with the same tool, at the top, where you can check the guarantee in ten seconds instead of reading eleven pages to find it.
Every change is listed
What we changed, in which file or setting, and why. Including the ones that turned out not to help. Your next developer should be able to read it and pick up where we left off.
A "we did not touch this" list
What we checked and left alone, so you know what you are not paying for and what is still on the table. Hosting usually lands here.
What will make it slow again
Sites get slow again when plugins pile back up and someone uploads a 4 MB photo. The last page is the short list of what to watch, which you can act on yourself or hand to a care plan.
Five causes shown here. Real reports typically run 6 to 12.
05 Next step
Get the real one.
The free triage comes first: send the URL, and within 24 hours you get the top 3 things slowing your site down. No payment, no call.
Entry: closing
The same format, filled in with what's actually slowing your site down.
Balance due one conversation
Now booking