Shopify site speed optimization scope template
Performance work is scoping-sensitive because "make it faster" isn't a deliverable.
A good scope defines:
- what you'll measure
- what you'll change
- what you won't touch
- how you'll verify improvements
Without those boundaries, performance engagements drift into open-ended optimisation work where the client expects a perfect Lighthouse score and your team has no definition of done.
Who this is for
This template is for agencies doing site speed work on Shopify stores and teams scoping performance sprints with defined targets. If you've ever finished a performance engagement with the client asking "but why isn't it 100?", the scope needed clearer boundaries from the start.
Copy/paste: performance optimisation scope sections (checklist)
- Baseline & access (theme repo access if needed) — Record current Core Web Vitals and page-load metrics across key templates before any changes are made.
- Measurement plan (what tools, what pages) — Define which tools you'll use (Lighthouse, WebPageTest, CrUX) and which pages represent the measurement set.
- Performance budget (if applicable) — Set target thresholds for LCP, CLS, and INP that the engagement is working towards.
- Quick wins (images, scripts, third-party apps) — Identify and implement low-effort improvements such as image compression, lazy loading, and removing unused scripts.
- Theme-level work (sections, assets, Liquid) — Refactor Liquid templates, reduce render-blocking assets, and optimise section architecture where measurable gains are possible.
- App stack review (remove/replace/disable) — Audit installed apps for performance impact and recommend removal, replacement, or configuration changes.
- QA plan (regressions) — Test all changes against functional requirements to confirm that speed improvements have not broken store behaviour.
- Rollout plan — Define how changes are deployed (staged vs all-at-once) and what rollback steps exist if regressions are found in production.
- Reporting — Deliver before-and-after metrics for the agreed measurement set, with notes on what changed and what further opportunities remain.
- Assumptions/exclusions (e.g., no guaranteed scores) — State clearly that Lighthouse scores are not guaranteed, and that third-party scripts outside your control may limit achievable gains.
Variables (inputs) that change the scope
- Theme complexity
- App/third-party scripts
- Markets/languages
- Number of templates to optimise
Common scoping mistakes
- No baseline measurement before starting. Without a recorded starting point, you cannot demonstrate improvement. Baseline metrics should be captured and agreed with the client before any work begins.
- Scope defined as "make it faster" without specific targets. A scope needs measurable targets (e.g., LCP under 2.5s on collection pages) so both sides know when the work is complete.
- Third-party scripts not flagged as out-of-scope when they should be. Client-installed tracking pixels, chat widgets, and marketing tools often account for the majority of performance issues. If you're not authorised to remove them, the scope must say so explicitly.
How RuleDox helps
- Rules-based assembly — RuleDox uses inputs like theme complexity, app count, and template volume to assemble the right scope sections inside Google Docs, so nothing is missed and nothing is over-promised.
- Exclusion language included automatically — Caveats around guaranteed scores and third-party script limitations appear in the document when the inputs indicate they're relevant.
- Consistent structure across the team — Every performance scope your agency produces follows the same format, making it easier to estimate, deliver, and compare engagements.