Answer in 60 seconds
A slow website may be a front-end problem, a server bottleneck, an unreliable integration, a bad release or a recovery process nobody has tested.
Do not approve a rebuild from one PageSpeed score. First separate three questions:
- Performance: are real users waiting too long on a critical journey?
- Reliability: are pages, forms, payments or logins failing intermittently?
- Recovery: can your team detect the failure, return to a known-good state and prove that data is intact?
Use field evidence where it exists, repeated lab tests for diagnosis and telemetry for errors. Stabilise outages and recovery before cosmetic optimisation. Then fix the smallest measured bottleneck.
No public benchmark can tell you how much revenue your site is losing. Your journeys, traffic, errors and commercial data must establish the consequence.
In this guide
- 1. Decide whether the problem is speed, reliability or measurement
- 2. Read PageSpeed and Core Web Vitals without chasing one score
- 3. Trace the first material bottleneck
- 4. Stabilise recovery and releases before polishing
- 5. Choose tune, stabilise, investigate, rebuild or stop
1. Decide whether the problem is speed, reliability or measurement
“The site is slow” is a symptom, not yet a technical brief.
A performance problem is usually repeatable: a meaningful element appears late, the interface responds slowly or content moves while the user is trying to act.
A reliability problem is intermittent. A form disappears, checkout times out or an update breaks a template. The team is afraid to deploy because recovery is uncertain.
A measurement problem begins with an unqualified complaint or a single lab test being treated as proof of what every visitor experiences.
Start with one business-critical journey: enquiry, checkout, login, booking or publishing. Record the device, page, delay or failure, time and completion state. If you cannot name the journey, do not start with site-wide optimisation.
2. Read PageSpeed and Core Web Vitals without chasing one score
Google’s PageSpeed Insights presents two evidence types. Field data comes from eligible real Chrome users over a trailing 28-day period. Lab data runs Lighthouse in a simulated environment and is useful for diagnosis. They can disagree without either being “wrong” (Google PageSpeed Insights).
A page may lack enough eligible field samples, so PageSpeed may show origin-level data - or none. A green lab score does not prove good real-user experience.
Google’s current Core Web Vitals cover loading, interactivity and visual stability:
- Largest Contentful Paint: 2.5 seconds or less;
- Interaction to Next Paint: 200 milliseconds or less;
- Cumulative Layout Shift: 0.1 or less;
Assessment uses the 75th percentile and should be segmented across mobile and desktop (web.dev). These are technical thresholds, not revenue targets.
In May 2026, the Chrome UX Report covered 18,445,974 eligible origins; 55.9% passed all three Core Web Vitals. This global, origin-level dataset cannot estimate one site’s loss or IZZY-market prevalence (Chrome UX Report).
3. Trace the first material bottleneck
Do not optimise the homepage because it is the easiest page to test. Follow the journey that matters.
| Observed signal | First question | Likely workstream |
|---|---|---|
| Slow field LCP across one template | Is the delay server-side, rendering-related or the main asset? | measured performance repair |
| Good lab result, poor field experience | Which devices, networks, regions or third parties differ? | real-user monitoring and segmentation |
| Fast pages with timeouts or errors | Which service, database or integration fails? | reliability investigation |
| Failures start after releases | What changed, what was tested and how is rollback authorised? | release-control repair |
| Only one inconsistent test looks poor | Can the symptom be reproduced across runs and conditions? | measure before changing |
| Conversion fell but the journey is technically stable | Is the first break actually offer, trust, form or follow-up? | conversion diagnosis |
Inspect browser requests, JavaScript, server response, database queries, APIs and third parties. Segment by device, template, geography and release where relevant.
The 2024 Web Almanac found materially different mobile and desktop results. It remains a dated global sample, not a client diagnosis (HTTP Archive).
4. Stabilise recovery and releases before polishing
If the site is intermittently failing, the first job is not image compression. Establish:
- critical-journey monitoring and error evidence;
- the last known-good release;
- a restoration test and recovery route;
- a dependency and version inventory;
- release checks and rollback authority.
In Uptime Institute’s 2025 report, 80% of 97 data-centre operators believed better management, processes or configuration could have prevented their most recent impactful downtime incident. This small, self-reported, data-centre-heavy signal is not a website outage rate, but it supports looking beyond hosting hardware (Uptime Institute).
The UK NCSC recommends inventorying dependencies and controlling how versions enter the system (NCSC). An older package does not prove compromise; version ownership must still be visible.
NIST places secure release and vulnerability response across the software lifecycle (SSDF); its configuration guidance adds controlled baselines and monitoring (SP 800-128 update). Both require tailoring.
5. Choose tune, stabilise, investigate, rebuild or stop
Use the evidence to choose the smallest justified action:
| Decision | Use it when | Do not proceed when |
|---|---|---|
| Tune performance | Field or repeatable lab evidence isolates a bottleneck and the journey is otherwise stable | The work is based only on a generic checklist |
| Stabilise reliability | Errors, outages, release regressions or untested recovery create the larger risk | An active incident requires specialist containment |
| Investigate | Field, lab and telemetry disagree or coverage is insufficient | A stakeholder wants a predetermined fix |
| Rebuild or replatform | The platform is a demonstrated constraint and parity, migration and recovery can be tested | “The score is low” is the whole business case |
| Stop | No material journey, consequence or repeatable symptom has been established | More activity is being used as a substitute for evidence |
A performance review should name the bottleneck, controlled change, test, guardrail and recovery route.
Conclusion: the next sensible move
A slow website does not automatically need a new platform. A fragile website does not become reliable because Lighthouse reaches 100.
Start with the critical journey. Separate field from lab evidence, and speed from errors, releases and recovery. Stabilise first; then make one controlled change and verify it against the same evidence.
Bring us the symptom. We’ll give you an honest read.
Bring one critical journey and the evidence you already have. In 30 minutes, IZZY can scope whether the first step is measurement, a bounded performance repair, reliability stabilisation or no engagement yet. We will not promise a speed, uptime, ranking or revenue result from a call.
Frequently asked questions
Google describes 90 or above as a good Lighthouse lab score, but warns that good lab data does not guarantee good real-user experience.
No. A failed assessment means eligible field data did not meet all three thresholds. If the data is insufficient, no field verdict should be inferred. Neither result identifies the cause or proves lost revenue.
Performance is how quickly a journey responds. Reliability is whether it works consistently and recovers from failure. A site can be fast but unreliable.
Not before isolating the cause. Consider rebuilding only when the platform is a demonstrated constraint and migration continuity can be tested.
Bring the affected journey, recent complaints, PageSpeed or real-user data, uptime and error history, recent releases, dependency inventory, hosting or CDN information, and evidence that backup, restore or rollback works.
Research and source status checked 16 July 2026. This article provides general performance and reliability decision guidance. It is not an incident-response service, penetration test, security certification or client-specific architecture recommendation.