Website speed is not one number. A page can deliver its first byte quickly and still take too long to show useful content. It can look complete and still react slowly to a click. It can load quickly while shifting the button a visitor was about to press.
The current Core Web Vitals
Google's Core Web Vitals focus on loading, responsiveness, and visual stability. For a good experience, the current thresholds are Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less.
- Largest Contentful Paint (LCP): how quickly the main content becomes visible. Good target: 2.5 seconds or less.
- Interaction to Next Paint (INP): how promptly the page responds to user interaction. Good target: 200 milliseconds or less.
- Cumulative Layout Shift (CLS): how much visible content moves unexpectedly. Good target: 0.1 or less.
Core Web Vitals are assessed at the 75th percentile of real page visits, segmented across mobile and desktop where applicable. That field data matters because one lab run cannot represent every device, connection, page, or visitor.
What about server response time?
Time to First Byte is a useful diagnostic metric because slow server response can delay everything that follows. It is not a complete measure of site speed, and one universal threshold is not a substitute for investigating the page. Caching, geography, application work, hosting, and third-party dependencies can all affect it.
Test representative pages
Start with pages that matter to the business: the homepage, key service or product pages, important landing pages, and any form or transaction flow. Test both mobile and desktop. A fast homepage does not compensate for a slow checkout or unusable contact form.
Useful diagnostic tools
- Google PageSpeed Insights for field data where available and a repeatable lab test.
- Chrome DevTools and the Core Web Vitals tooling for tracing page behavior.
- WebPageTest for testing locations, devices, connection profiles, and detailed loading waterfalls.
Fix the cause, not just the score
Common causes include oversized media, render-blocking resources, excessive client-side code, slow third-party scripts, unstable dimensions, and work that blocks interaction. Prioritize changes that improve important visitor tasks and can be maintained after the initial optimization.
When performance becomes a maintenance problem
Performance changes as a website changes. Plugins accumulate, third-party scripts get added, image sizes grow, old experiments remain installed, and content and integrations evolve. That makes performance a strong Website Care topic rather than just a one-time optimization task.
A useful performance program does not end with a launch score. It keeps important pages observable as the website evolves.
