A page speed optimization service should make important journeys faster for real visitors and prevent the same problems returning. A single high Lighthouse score is useful evidence, but it is not the whole result.
Start with field and lab evidence
Field data shows how real visitors experienced the site across devices and networks. Lab tests give repeatable diagnostics for a controlled page load.
Use both. Google’s Web Vitals guidance explains that Core Web Vitals are field metrics and that lab tools are useful for development and catching regressions.
The current Core Web Vitals are:
- Largest Contentful Paint for loading;
- Interaction to Next Paint for responsiveness;
- Cumulative Layout Shift for visual stability.
Review the 75th percentile and separate mobile from desktop where the data allows.
What the service should investigate
The diagnosis should cover representative home, service, article, product, collection, basket and checkout templates where relevant.
Common causes include:
- oversized or poorly delivered images and video;
- render-blocking CSS and scripts;
- heavy JavaScript and long main-thread tasks;
- slow server response or uncached work;
- third-party tags, chat, testing and consent tools;
- web fonts and late layout changes;
- plugin, app or extension overhead;
- code shipped site-wide for one small feature.
The bottleneck varies by template. Optimising one homepage screenshot does not fix a slow product journey.
A practical optimisation process
Establish the baseline
Record field data, repeatable lab tests, page weight, requests and important business events. Note test location, device, throttling and date.
Find the cause, not the symptom
Trace the LCP element, long tasks, layout shifts and network dependencies. Rank work by user impact and implementation risk.
Fix in controlled releases
Typical work may include resizing media, changing loading priority, removing unused code, deferring non-critical scripts, improving caching, reducing third-party work or rebuilding a heavy component.
Test after each meaningful change. This shows which intervention created the improvement and makes rollback safer.
Verify the whole journey
Check that forms, analytics, accessibility and commercial functions still work. A faster page that loses tracking or breaks a product option is not an improvement.
Add regression control
Set budgets for JavaScript, CSS, media, requests and key lab metrics. Monitor field data and include performance checks in release QA.
What you should receive
Expect:
- a baseline and test method;
- root-cause findings by template;
- a prioritised technical backlog;
- before-and-after evidence for each release;
- known trade-offs and remaining limits;
- regression budgets and ownership;
- a live readback after deployment.
Avoid guarantees based on one test run. Network, device, cache state and third parties all affect results.
What good performance evidence looks like
A useful performance report shows the baseline, the affected templates, the changes made and the result under the same test conditions. Removing technical debt at the source can outperform adding another layer of optimisation plugins, but your site needs its own measurements.
Performance still belongs inside the customer journey. Pair this work with UX audit services when the experience problem is broader than loading, or ask DreamWeb to diagnose the slow templates before buying a generic speed package.
Related reading: SEO audit services and Website maintenance plan.