Diagnose website speed with both field and lab evidence, test representative templates and journeys, identify the largest systemic causes, set performance budgets and verify improvements in production. A single homepage score is not a performance strategy.
Key takeaways
- Use field data when available and lab data for diagnosis.
- Test multiple templates, devices and connection conditions.
- Control images, JavaScript, fonts and third-party scripts.
- Prevent regression with budgets and monitoring.
Who this is for: Marketing and engineering teams investigating a slow website or preparing performance requirements.
Measure the right experience
Core Web Vitals currently focus on loading, interaction responsiveness and visual stability. Use them as important user-experience signals, not the only definition of quality.
| Signal | What it represents | Typical investigation |
|---|---|---|
| LCP | Loading of the largest important element | Server response, render blocking, hero media |
| INP | Responsiveness to user interaction | Long tasks, JavaScript and main-thread work |
| CLS | Unexpected layout movement | Missing dimensions, late content and fonts |
Test representative pages
Create a test set across page types and traffic importance.
- Homepage
- Primary service page
- Article/resource
- Case study
- Search/filter experience
- Product/category/checkout where applicable
- Form or booking journey
- Authenticated workflow where applicable
High-impact checks
Look for systemic patterns before micro-optimizing.
- 1Resize, compress and responsively serve images.
- 2Remove or defer unused and non-critical JavaScript.
- 3Audit third-party tags by owner and business value.
- 4Optimize font families, weights and loading behavior.
- 5Cache stable assets and reduce server delay.
- 6Reserve dimensions for media and dynamic components.
- 7Render important content without requiring avoidable client work.
Responsive image example
Use framework image tooling or an equivalent responsive strategy so devices do not download unnecessarily large assets.
<Image
src={heroImage}
alt="Team reviewing a website prototype"
sizes="(max-width: 768px) 100vw, 1200px"
priority
/>
Keep improvements from regressing
Set template-level budgets, monitor real-user data, document third-party ownership and include performance in acceptance criteria. Re-test after marketing tags, redesigns and CMS component changes.
How to use this guide with your team
Performance discussions should connect measurements to real experiences. Explain which visitor, template, device and journey is affected rather than treating one laboratory score as the whole website.
Prioritize systemic causes such as media policy, component architecture and uncontrolled third-party scripts. These improvements protect many pages and future publishing work at once.
Share before-and-after evidence with non-technical stakeholders in plain language: what became faster or more stable, why it mattered and how regression will be prevented.
Practical next steps
Use the following actions as a short working session. Record decisions, owners and unresolved questions so the article becomes an implementation aid rather than passive reading.
- 1Test representative templates and devices.
- 2Combine field evidence with diagnostic lab tests.
- 3Fix systemic causes before minor scores.
- 4Explain impact in user and business terms.
- 5Add budgets and monitoring to prevent regression.
Frequently asked questions
Is a 100 performance score required?
No. Use scores diagnostically and focus on real user experience, business-critical journeys and sustainable improvements.
Why do lab and field results differ?
Lab tests use controlled conditions; field data reflects real users, devices, networks and interactions over time.
Sources and further reading
Last reviewed: September 1, 2026
