A slow page can involve the server, application, images, scripts or an external service. Start with the affected customer journey and a repeatable measurement, then agree the work that addresses the observed problem.
Measure the affected journey, then separate server response, delivery and browser work to identify what needs attention.
- Server response
- Delivery
- Browser workload
Look at the whole page
Hosting and application
Review server response, resource pressure, database work, background tasks and the routes that need a fresh application response.
What the browser receives
Review image sizes, fonts, styles, scripts and third-party requests. A larger server alone does not make an oversized image smaller.
Separate a test run from visitor experience
A lab test uses defined device and network settings. Field data comes from actual visits, whose devices, connections and behaviour vary. Compare like with like and record where each result came from. Google's explanation of lab and field measurements covers why they can disagree.
Core Web Vitals describe loading (LCP), interaction responsiveness (INP) and visual stability (CLS). They measure different aspects of the experience; an uptime percentage or server-response average is not a substitute. See the Web Vitals reference.
Record a usable baseline
- Choose representative pages. Include the landing page and the slow form, search, product or logged-in route.
- Record the test conditions. Save the URL, date, tool, device/network setting and whether the visit was cached or signed in.
- Inspect the bottleneck. Distinguish slow initial response from heavy downloads, script work or an external request.
- Change one scoped area. Review the result under comparable conditions and repeat the important functional checks.
Cache according to the page's job
The published hosting stack includes server caching, edge delivery and Redis capability where applicable. Cache configuration depends on the platform and route. Review sessions, personalised content, cart and checkout behaviour with the application before changing a rule.
Record how a content update is invalidated and test both a fresh visit and a repeat visit. For a store, read the checkout-aware hosting guidance. For application services, review the Laravel operating scope.
Separate hosting care from optimisation projects
Routine server care follows the hosting agreement. Application profiling, database redesign, theme changes, script removal and custom development can require additional work. The care guide explains the boundary. Confirm the task and quote before treating a performance review as an included rebuild.
Performance questions
Do you guarantee a PageSpeed score?
No fixed score, load time or ranking is promised here. Outcomes depend on the application, page content, integrations and test conditions.
Should I upgrade the server first?
Use measurements to decide whether capacity is the constraint. Review CPU, memory, application behaviour and browser work rather than choosing a tier from one symptom.
Why do two tests show different results?
Device, network, location, cache state and page activity can differ. Save the conditions and compare repeatable runs; retain field data separately.
Related guides
Discuss a website performance review
Tell us the public site URL, platform and the work you need. We will confirm the scope and responsibilities before quoting.
Ask about your site