What should a website speed-optimization job include?
Direct answer. A useful speed-optimization brief names five things: target pages, a baseline, permitted changes, functional checks and a before-and-after report. A single Lighthouse score is a diagnostic result, not a guarantee of customer experience or higher rankings.
Commissioning work now? Compare the Website speed optimization scope, or send the project details for a scope check.
Choose representative journeys before choosing a score
Name the pages that matter to the business: the main landing page, an important service or product page, and the enquiry or checkout journey. Explain the device and connection you care about and any reports you already have. “Make the whole website fast” leaves the test boundary unclear, especially when different templates and third-party tools are involved.
A fast homepage cannot prove that a product filter, account page or checkout works well. Likewise, a slow third-party payment handoff may need a different investigation from compressing an oversized banner. Ask the developer to separate the page they control from the connected services they can only measure or recommend changing.
Distinguish lab diagnostics from field experience
Chrome describes Lighthouse as an auditing tool covering areas including performance and accessibility. It can help identify a problem in a particular run; it does not simulate every visitor. Record the tested URL, device or configuration, date and relevant conditions so a before-and-after comparison means something.
Google’s Web Vitals guidance identifies loading, responsiveness and layout stability as separate concerns. Where field data is available, inspect that alongside lab diagnostics. Do not present a fresh lab run as a measured improvement for all real users, and do not claim that a technical score proves an increase in leads or sales.
| Line | Specify before work | Evidence after work |
|---|---|---|
| Target pages | Representative URLs and journeys | The same pages tested |
| Baseline | Test method and relevant conditions | Comparable reports retained |
| Permitted changes | Approvals and excluded costs | Actual changes explained |
| Functional checks | Forms, checkout and navigation at risk | Named journeys still work |
| Remaining work | Hosting or architecture constraints | Clear next decision, without a score guarantee |
Approve the changes that might affect the business
Images, caching, fonts, scripts, plugins, embeds and hosting can contribute different constraints. Require a short finding and proposed action for each important change. Replacing a plugin, changing image delivery or deferring a script can alter behaviour, so get approval when the change affects a business function.
Ask which backups and rollback steps are included. Keep hosting upgrades, paid CDN plans and a full theme rebuild visible as separate costs or decisions. If the site relies on an old page builder, an optimization pass may improve some problems without turning it into a different architecture. A refusal to guarantee a perfect score can be more honest than a fixed score promise with no exclusions.
Protect the working journeys while optimizing
Re-test the menu, search, contact form, checkout, login and other functions affected by the changes. Check the site at phone and desktop widths and inspect whether content jumps as assets load. An optimization is not accepted merely because a test page looks faster while an enquiry button has stopped working.
Include accessibility and motion needs in the review. Useful visible content should not depend on an animation or script that may fail. The acceptance record should list the actual pages and journeys checked, not a blanket assertion that every part of the site is now perfect.
Ask for a report that another developer can understand
A useful report links the comparable before and after runs, describes the changes, records functional tests and identifies remaining constraints. If hosting response time or a third-party script remains a bottleneck, name it and state what decision is required. Preserve the reports rather than comparing a remembered score with a new screenshot.
Example brief: “Audit these three page types, propose the changes, back up the affected files, implement the approved image/cache/script work, then rerun the same checks and verify our enquiry journey. Report hosting or redesign work separately.” Three pages is an illustrative project boundary, not a guarantee that every package includes that number.
Choose between optimization, repair and rebuilding
The current ZoopCoder speed-optimization service lists concrete implementation tasks and before/after reports, with hosting fees, a theme rebuild and guaranteed scores excluded. A single broken interaction may fit a bug-fix scope; a deeper platform change belongs in a separately assessed redesign or rebuild.
We publish this guide as a supplier of the work. Use the checklist to compare deliverables and evidence, including offers from other providers. The outcome to buy is a documented improvement within an agreed boundary, with the important business journey still working.
Questions before you commission the work
Can a supplier guarantee a Lighthouse score?
A score depends on the test conditions, hosting and third-party behaviour as well as the code. Ask for scoped work and comparable evidence rather than an unconditional score guarantee.
Does a better lab result prove more sales?
No. Technical performance and business conversion are different measurements. Review real customer and enquiry outcomes separately.
Should speed optimization include a theme rebuild?
Only when the quote explicitly includes it. A bounded optimization pass and a redesign or rebuild are different scopes.
Sources and scope
Primary documents checked 3 November 2026. The commissioning tables and sample briefs are editorial suggestions, not platform requirements or measured client outcomes. Live service pages govern the current price and included work.