Website speed optimization
Website speed optimization, measured before and after.
A slow site quietly taxes every visitor: they see a blank screen, they leave, and the ad spend or SEO that brought them is wasted. I find what is actually blocking the first paint, fix it in the code, and publish the before/after numbers: a dated Lighthouse mobile run, not a promise.
Fixed USD quote before code · 30-day warranty on the delivered scope
A dated baseline, first
Lighthouse mobile (150ms RTT / 1.6 Mbps / 4x CPU) plus your real-world scores, measured before anything changes. No baseline, no claim.
The blocking bytes, named
The specific cause (a phantom preload, an unsized hero, JavaScript gating the first paint, an oversized image) written in one page you keep even if you hire nobody.
Fixes shipped, not just listed
Reports that end in a to-do list are homework. The fix ships in code, on a branch, with the reasoning in the commit.
A re-run and the receipts
The same profile re-measured after the fix, both numbers published: including when the second number is less impressive than hoped.
The proof
74 → 97 · LCP 7.2s → 2.0s
Small Batch Brine storefront. Root cause: the layout preloaded a 768 KB image the page never rendered, queued ahead of the chunks that build the page.
Read the Small Batch Brine breakdown →75 → 88 · LCP 5.9s → 3.8s
Through Tenon storefront. Root cause: the hero was hidden until client JavaScript ran, so the page was fully downloaded and still blank for seconds.
Read the Through Tenon breakdown →Self-initiated concept builds, no client affiliation implied. Dated Lighthouse mobile runs, including the ones that score badly.
FAQ