Why is page speed not the only thing to optimize for?

Wait… I meant a perfect CWV 100 score, didn’t I?

As I’ve said in my two previous articles on the real cost of a slow website and the teardown of auditing a slow WordPress site, it is possible to reach that goal. But it is also mostly pointless, because the web can start to look and feel naked and bare, as if it were made for robots instead of humans. More on that later.

What is the problem with optimizing for “page speed” and what the PSI score measures?

A better question might be how we, as humans, actually measure page speed. Time to first byte, total load time, Lighthouse score, CWV pass, and similar metrics are all useful, but they are still metrics. We often optimize them for machines and algorithms, hoping they will push us higher in search results and now into AI overviews when someone searches for something even remotely connected to the business a website represents.

The other misconception is treating PageSpeed Insights as the true “North Star” for user experience. Yes, it includes real-world user experience data as well as lab data, but come on… is it really necessary to chase perfection at the cost of built-in features that drive conversions, just to hit 100 / 100 instead of 95 / 100? Honestly, in terms of ranking, that difference usually makes no meaningful difference whatsoever.

In most cases, PageSpeed Insights’ most visible “North Star” is still lab data, which can vary depending on server response time, CPU behavior, and other testing conditions. That is why back-to-back tests can produce different scores, making those numbers a bit less reliable as a benchmark for performance or as a proxy for a ranking signal.

Lab data vs field data: why the gap matters for SEO

As mentioned earlier, lab data uses test runs in a controlled environment under artificial conditions. Field data comes from real Chrome users — thousands, if not millions, of actual page visits captured across the wide range of network conditions, device capabilities, and locations that make up your real audience. That data is stored in the Chrome User Experience Report (CrUX). These two data sources use completely different measurement methodologies, so they can tell very different stories about the same URL.

There are so many things to consider when it comes to ranking, and being obsessively focused on website performance is usually not what is required to outrank the competition.

Where Core Web Vitals do matter is when websites are competing with the same or similar content quality. Even then, they are not a standalone ranking lever.

Of course, every website should be reasonably fast, but only up to the point where further optimization still creates a real benefit.

Why a perfect 100 score can actually hurt your site?

You have to think about the actual users you are building the website for in the first place. Features such as live chat widgets, A/B testing tools, analytics tools, and similar additions may lower that ideal score, but they also help you understand and improve the website experience.

In other words, you are not flying blind. You have a radar to navigate by. Yes, it adds a little weight to the plane, but it also helps you reach your destination sooner and more safely.

How to read your actual performance data in Search Console and CrUX

Google Search Console’s Core Web Vitals report is probably the best place to start when you want to understand how Google sees your site’s real-world performance. It uses CrUX field data grouped by URL clusters and shows how those pages perform at the 75th percentile, which is the same type of data Google uses when evaluating Core Web Vitals. So, if a group of URLs is marked as “Poor” or “Needs improvement,” that is usually the signal worth paying attention to first. A strong Lighthouse score in PSI is still useful, but it does not really cancel out what Search Console is showing you from real users.

PageSpeed Insights also includes CrUX field data, although it is easy to miss because many people naturally jump straight to the lab score. For SEO purposes, the field data at the top of the PSI report is usually the more meaningful part. If Search Console is showing Core Web Vitals issues while the PSI lab score still looks healthy, it is not necessarily a mistake — it usually just means the lab test and real-user data are telling different stories. In that case, it is better to focus on the field data first. Also keep in mind that CrUX uses a rolling 28-day window and needs enough traffic to show results, so newer or lower-traffic URLs may simply display “not enough data,” meaning there is no reliable field signal for those pages yet.

A practical optimization hierarchy: what to work on first

We covered this in detail in a website audit teardown but in short, start with CWV report in Google Search Console. That is the most relevant source of truth for your website optimization status.

For LCP failures, audit in this order: TTFB, image format and size for the LCP element, and whether the LCP resource is preloaded. For INP failures, open Chrome DevTools Performance panel and profile actual interactions — long JavaScript tasks and heavy third-party script execution are the most common causes. For CLS failures, add explicit width and height attributes to all images and embeds, reserve space for ad slots with CSS min-height, and audit your font loading strategy for render-triggered reflows. Only after field data thresholds are met should you revisit lab score improvements — and only if those improvements reflect real changes to the user-facing page.

When the PageSpeed Insights score is still useful

The Opportunities and Diagnostics sections in PSI are more actionable than the score. They flag specific, fixable issues — unused JavaScript, unoptimized images, render-blocking resources — that frequently map to real LCP or INP problems in field data. Use the score directionally against your own previous results, not as an absolute target or a stakeholder-facing KPI. If someone asks why the score dropped from 87 to 79, the honest answer is: it probably doesn’t matter, as long as field CWV data is still passing thresholds.

In the end, the goal is not to make a website look perfect inside a testing tool. The goal is to make it fast enough, stable enough, and useful enough for real people to actually enjoy using it. If your Core Web Vitals are healthy and the page still supports the features your business needs, that is usually a much better win than chasing the last few points in a lab score.