Section 1
Why a sprint beats "someday"
Performance work stalls because it's unbounded, "make the site faster" has no clear start, scope, or end, so it never begins. A sprint solves this by bounding the work: a defined week, specific daily tasks, measurable before-and-after, and a finish line. This converts an intimidating open-ended project into a series of concrete, achievable steps, and because most high-impact speed fixes are non-technical (image optimization, script discipline, configuration), a focused founder can do most of it themselves in a week. The sprint also creates momentum: measurable daily progress (watch your PageSpeed score climb) sustains the effort. So the one-week sprint isn't a stripped-down version of performance work; it's the focused version that actually gets done, capturing the high-impact fixes that deliver most of the speed gain. The principle: bound performance work into a focused, measurable one-week sprint, and the speed work that never happens finally does. (This applies the performance research cited across this library.) "I'll improve site speed someday" is how slow sites stay slow forever, the project is unbounded, so it never starts. A one-week sprint with daily tasks and a measurable finish turns "someday" into "done by Friday." Most of the high-impact work isn't even technical. Bound it, and it happens.
Section 2
The one-week performance sprint
Day 1, Measure and baseline. Run PageSpeed Insights (mobile) on your key pages. Record your scores, Core Web Vitals (LCP, INP, CLS), and the top opportunities it flags. This is your baseline and your target list, you'll measure against it all week. Day 2, Optimize images (the biggest win). Images are 60–70% of page weight, so this is the highest-impact day. Compress every image, convert to modern formats (WebP/AVIF), size them correctly, and enable lazy loading. This alone often delivers the bulk of the gain. Day 3, Tame the scripts. Audit your third-party scripts (analytics, chat, pixels, embeds). Cut the ones you don't use, and defer the heavy ones so they load after the page is interactive. This attacks INP, the most-failed Core Web Vital. Day 4, Fix layout shift and the hero. Address CLS (specify image/media dimensions, reserve space for ads/embeds) and your LCP (optimize the hero image, prioritize its loading). These hit two of the three Core Web Vitals. Day 5, Check hosting and configuration. Verify you're on adequate (ideally fast, green) hosting, enable caching and a CDN if available, and check any platform performance settings. These are configuration wins that don't require code. Day 6, Re-measure and target the gaps. Re-run PageSpeed and compare to your baseline. Identify any remaining high-impact issues, and either fix them or note which need a developer. Day 7, Verify on real devices and lock it in. Test on a real phone over cellular, confirm the experience is genuinely faster, and document what you did (and any developer follow-ups). Celebrate the measurable improvement.
Section 3
The one-week sprint, in one view
The takeaway: website performance stalls because it feels like an unbounded technical project, but a focused one-week sprint, measure, optimize images, tame scripts, fix layout shift and the hero, check hosting, re-measure, verify, turns "someday" into "done by Friday." Most of the high-impact work (images, scripts, configuration) requires no developer, and the daily structure creates the momentum that sustains it. By the end of the week, a slow service site is meaningfully faster, with a measurable before-and-after to prove it, and since speed drives conversion and revenue, that week of focused effort pays off directly. Stop deferring performance as a vague project; sprint it. (The sprint structure synthesizes the performance research established across this library.)
Section 4
Execute This With AI
Step 1, Inputs. Run PageSpeed Insights (mobile) for your baseline, and note your platform and biggest assets. Step 2, Run the prompt: You are a performance coach running me through a ONE-WEEK speed sprint to take my slow site to meaningfully faster, most of it without a developer. The plan: Day 1 measure/baseline, Day 2 optimize images (biggest win, 60–70% of weight), Day 3 tame scripts (fixes INP), Day 4 fix CLS + hero/LCP, Day 5 hosting/config, Day 6 re-measure, Day 7 real-device test. My baseline PageSpeed (mobile): [scores + flagged opportunities]. My platform: [X]. My biggest assets: [DESCRIBE]. Do four things: 1. Turn the 7-day plan into specific daily tasks for MY site and platform. 2. Tell me which tasks I can do myself vs. need a developer. 3. Give me the target improvement to aim for by Day 7. 4. Tell me exactly what to re-measure each day to track momentum. Make it a concrete, achievable week, not a vague project. Step 3, Daily check. Each day: "Here's my updated PageSpeed after today's task: [X]. Did it improve as expected, and what's tomorrow's priority?" Tools and expected output. Any frontier chat model, plus PageSpeed Insights (daily measurement), your builder's settings, and a real phone for Day 7. Expect a tailored daily plan, an effort split, a target, and daily measurement guidance. The QA discipline: measure every day and verify on a real device at the end, the sprint works because progress is measurable, so track your PageSpeed daily and confirm the final result on an actual phone over cellular, not just the simulated test. The model structures the sprint; your daily measurements and real-device test prove the speed gain is real. Website speed feels like a vague, never-ending technical project, which is exactly why slow sites stay slow, the work is unbounded, so it never starts. A focused one-week sprint fixes that: measure and baseline, optimize images, tame scripts, fix layout shift and the hero, check hosting, re-measure, and verify on a real device. Most of the high-impact work needs no developer, and the daily structure creates the momentum to finish. By Friday, your slow site is meaningfully faster, with a measurable before-and-after, and since speed drives conversion, that focused week pays off directly. Don't defer performance as a someday project. Sprint it, and be done by the weekend.
Section 5
Keep reading
Keep reading in the Performance & Core Web Vitals cluster and across the library: [Core Web Vitals in the INP Era: What Changed and Why It Matters](/blog/core-web-vitals-in-the-inp-era-what-changed-and-why-it-matters), [Cumulative Layout Shift: The Jumpy Page That Quietly Loses Trust](/blog/cumulative-layout-shift-the-jumpy-page-that-quietly-loses-trust), [The Performance Budget: A Founder's Tool for Briefing Developers](/blog/the-performance-budget-a-founders-tool-for-briefing-developers). Also relevant: [Speed-to-Lead: Why Page Speed and Reply Speed Are the Same Conversion Lever](/blog/speed-to-lead-why-page-speed-and-reply-speed-are-the-same-conversion-lever), [The Service-Business Website Priority Stack: What to Fix First When Everything Needs Work](/blog/the-service-business-website-priority-stack-what-to-fix-first-when-everything-needs-work), [Core Web Vitals in Business Terms: What a Slow Website Costs You](/blog/core-web-vitals-in-business-terms-what-a-slow-website-costs-you).