Use a performance test to identify what delays a real user task. A Lighthouse score describes one measured run; it is not a search ranking, a promise of conversions or a permanent property of the site. Start with the SafeNet speed checker or PageSpeed Insights.
Lab Scores and Real-user Data Answer Different Questions
Lighthouse simulates a page load under stated device and network conditions. Its Performance, Accessibility, Best Practices and SEO categories highlight specific automated checks. A score of 100 does not establish complete accessibility, security or search readiness.
Real-user data describes observed visits when enough eligible data exists. Core Web Vitals are LCP, INP and CLS; FCP, TTFB and lab TBT are useful diagnostics but are not additional Core Web Vitals. Lab TBT is not the same measurement as field INP. Web Vitals definitions.
| Core Web Vital | Good threshold | What to inspect |
|---|---|---|
| LCP | At most 2.5 seconds | Delivery of the largest visible content element |
| INP | At most 200 milliseconds | Responsiveness to user interactions |
| CLS | At most 0.1 | Unexpected visual movement |
Assess these thresholds at the 75th percentile of visits, with mobile and desktop separated. Good Core Web Vitals support page experience but do not guarantee a top search position. Google's Core Web Vitals guidance.
Run a Reproducible Test
- Record the exact URL, release, time, tool/version and mobile or desktop setting.
- Test a page that represents the important customer journey, not only a simplified homepage.
- Repeat under the same conditions and retain all runs; compare the median rather than selecting the best score.
- Inspect LCP, blocking work, layout shifts and the request list to locate the actual delay.
- Test keyboard navigation, forms and staff contact paths after an optimisation.
- Compare available field data separately. If it is absent, report that limitation instead of labelling lab results as real-user evidence.
What to Fix First
Oversized images, unnecessary client JavaScript, render-blocking assets, slow responses and third-party scripts can affect many platforms. Check the evidence before attributing a slow page to WordPress or promising that Next.js will solve it. Define an asset budget and preserve important content and working enquiry routes.
For this SafeNet website, the implementation work includes pre-rendered pages, compressed assets, appropriately sized images and deferral of selected offscreen interactions. These are techniques to test, not a universal sub-second loading promise. The Recharge implementation case study documents a separate delivered website; it does not claim a measured score or business uplift for that client.
Set Acceptance Criteria with Your Developer
Specify representative URLs, test conditions, the number of runs, an agreed performance target and functional checks before work starts. Recheck the published release because hosting, content and third-party services can change the result. See website scope and packages to discuss a measured improvement plan.
