Anatomy of a website Speed Sprint: how I ship a week of performance work

I sell a fixed week of performance work. On my pricing page the offer is four lines: Speed Sprint, $1,500 to $3,500, 5 to 7 days, for existing sites that feel slow, clunky on mobile, or weak at turning visits into calls. This post is the anatomy of that week, written for a different reader than my last two: freelancers and agencies who might run the same engagement. Every phase, in order, including what did not work. Why a sprint shape at all Open-ended optimization retainers drift: there is always another plugin to audit, the work expands to fill the month, and the client cannot say what they bought. A fixed 5-to-7-day window forces triage: take the changes that move the score most, ship them in a fixed order, stop when the window closes. The scope is fixed too: audit, cleanup across scripts, media, and the render path, mobile layout and CTA fixes, basic on-page and technical cleanup, a before-and-after report, and a short post-launch support window. That list is the contract. It fits in a week because it has to. Day 0: scaffold, then the fan-out No sprint starts from a blank folder. A scaffold script copies a client template into a per-client workspace with baseline/ and handover/ directories and a scope file full of bracketed fill-in tokens. Every token, client name, production URL, hero element ID, is resolved before any code work happens. Then the fan-out: five reconnaissance tasks, launched in parallel on day 0, before anything is touched. Host recon. What cache stack is really running, read from the response headers; the cache methodology follows from it. Sitemap enumeration. Pull the sitemap index, list every service URL, quick-burst each page, so weak pages surface on day 0, not in the final report. The baseline burst. A spaced series of 50 or more mobile PageSpeed runs, one per minute, locking the before numbers. It runs in the background for hours. LCP discovery. Pin the exact hero element and hero image on the homepage and the top service pages. The carry-over scan. Capture pre-existing gaps, broken tel and mailto links, missing H1s, overlong titles, marked out of scope so nothing old reads as a regression later. The baseline lock is the discipline that holds it all together: nothing gets optimized before it gets measured. The rule was burned in, from the post-mortem of a sprint that stretched to 14 days against its 5-to-7-day shape, where each of those five gaps cost 6 to 22 hours on its own. In parallel on day 0, the five tasks take about 30 minutes. Baseline discipline A Lighthouse mobile run is a lab measurement: a simulated phone on a simulated network. It is honest about relative change and noisy about absolute truth. Single runs swing a few points for no reason, so I never quote one. The Renue Hawaii sprint closed on medians: 10 runs per page at the final gate, and across the full-sitemap gate, 5 cache-busted runs per page on all 33 pages. Two of the 165 runs came back under 70, both traced to contention on Google's own testing workers. That is what a lab floor looks like; you disclose it instead of hiding it. The deliverable is the before-and-after report, not the score. If you want the zero-setup version of the baseline step, my free grader does a single-run read in under a minute, no signup: grader.peakspire.ca The work, in triage order Lighthouse weights the mobile score: total blocking time 30 percent, largest contentful paint 25, cumulative layout shift 25, first contentful paint 10, speed index 10. That weighting is the triage ladder, and the buckets run down it. Scripts and the render path go first, because blocking time carries the most weight. Install Query Monitor, write down every enqueued handle, and ask of each one who needs it. Analytics plugins are the usual find, 20 to 50KB of synchronous JavaScript, replaced with a small loader that fires when the browser goes idle. jQuery and jQuery Migrate leave if nothing on the front end depends on them. Core bloat follows: block library CSS on themes that do not use blocks, emoji scripts. Media is next. The LCP image gets an explicit preload, eager loading, and fetchpriority high. Everything below the fold goes lazy, and every image gets explicit width and height. On Renue, the About page hero was lazy-loaded, low priority, and unpreloaded, all at once. Fixing that one image moved the page from 75 to 96 and its hero paint from 6.4 seconds to 2.23. Fonts I will not re-litigate here. I covered them in the first post of this series, a census of 97 Ottawa sites where they hid at the end of the waterfall. Same fixes inside a sprint: self-host, preload, font-display swap. As of this week you do not have to hand-roll them: the pattern is now a free plugin, live in the official WordPress plugin directory. It preloads locally hosted WOFF2 files, capped at four, adds font-display swap to @font-face rules missing a descriptor, and optionally removes external Google Fonts requests and the dashicons stylesheet for logged-out visitors. All of it is front-end output, so it sits on top of whatever caching layer the sprint just tuned instead of fighting it: https://wordpress.org/plugins/peakspire-font-loading/ Mobile layout and CTA fixes are the CLS bucket. Explicit dimensions on images, fixed heights on trust badges CSS shrinks, and page-builder entrance animations stripped server-side so content paints on the first frame it can. On Renue that meant removing Elementor's animation classes at the PHP layer. On-page and technical cleanup is last and deliberately small. The carry-over scan already documented the gaps; fix the cheap ones, leave the rest named and out of scope. Done across a whole site, the Renue sprint ended with 88 CSS sheets collapsed to one desktop file plus 4 mobile files, CLS at 0.000 under a real mobile user agent, and all 33 sitemap pages clearing a 90+ mobile gate. The design never moved: 10 of 10 screenshot checks held the pixel diff between 0.00 and 0.03 percent. One habit from that stack I will keep forever: verify on the wire by fetching the rendered HTML, because the server logs proved unreliable. Trust the wire, not the log. Handover and the support window The handover report carries a before-and-after table for every page and all five metrics, every dequeued script with a reason, and every trade-off named plainly: system fonts on mobile, a deferred chat widget, whatever the client will notice in a week. Caches get purged, and a functional smoke test confirms forms still submit, analytics still fire, navigation still works. I guarantee no score, ever. Lab scores decay quietly after redesigns and plugin additions, so instead of a guarantee the short support window is a re-verification: run the pages again, find what slipped, fix it once. A re-run beats a promise because it produces evidence instead of hope. What I would do differently The honest misses first. Rankings and lead counts did not move, or if they did I cannot say so: the engagement measured and fixed speed, and those outcomes were not instrumented. Anyone quoting a ranking jump from a speed fix alone is quoting something they did not measure. Desktop also finished 31 of 33 on Renue, and both desktop misses traced to Google's testing workers, not to the site. Two process misses shaped the current playbook. I optimized the homepage first and discovered late that four service pages still sat at 78; that surprise is why sitemap enumeration now runs on day 0. And I once preloaded a hero image that was already inlined base64 into the HTML, a pure duplicate download; that one is why LCP discovery is its own task. If you run sprints against other people's WordPress sites, the shape is yours to copy. Lock the baseline before you touch anything, triage by scoring weight, and put the misses in the report. For agencies and freelancers: I may open a small pilot teaching the Speed Sprint method as a service offering. Nothing committed yet; I am reading interest first. If that is you, tell me: info@peakspire.ca (subject line: sprint pilot).