Page speed is how quickly a page loads and becomes usable. That second half matters: a page can paint something on screen almost instantly and still be useless for several more seconds while fonts swap, layout shifts and scripts block every tap. What visitors experience as “fast” is the whole sequence from request to working page, which is why a single speed score rarely describes it well.
Speed is worth fixing for two separate reasons, and they are not equally weighted. It is a modest ranking signal. It is a large conversion factor. Businesses that pursue it purely for SEO usually under-invest, because the money is in the second reason.
How it is actually measured
Google’s Core Web Vitals are the metrics that matter, and each captures a different failure:
Largest Contentful Paint (LCP) is when the main content becomes visible. Usually the hero image or headline.
Interaction to Next Paint (INP) is how quickly the page responds when someone taps or clicks. This is the one that makes a page feel broken rather than merely slow.
Cumulative Layout Shift (CLS) is how much the layout jumps around while loading. The reason people tap the wrong thing.
The distinction that trips most people up is lab data versus field data. Lab tools such as Lighthouse and PageSpeed Insights simulate one load on a throttled connection and give you a score out of 100. Field data, the Chrome User Experience Report, records what real visitors on real devices and networks actually experienced over the preceding 28 days.
Google uses field data. A green Lighthouse score with failing field metrics means your real visitors are having a worse time than your test did, usually because they are on older phones and worse connections than your laptop. Chase the field numbers; treat the lab score as a diagnostic tool for finding causes, not as the target.
Why it matters commercially
Slow pages lose people before they see anything. The effect compounds through the funnel: fewer visitors reach the page, fewer of those who arrive stay, and fewer of those who stay complete a form or a checkout. On mobile, where connections are worse and patience is shorter, the gap widens.
This is why speed work is best justified against conversion rather than rankings. A faster checkout does not need a ranking argument to pay for itself, and neither does a service page that stops shedding a share of its arrivals. The ranking benefit is real, and it is the smaller half.
There is also a newer angle: systems that fetch pages to answer questions operate under time limits, so a slow page is less likely to be read and cited, a point we cover in why AI and LLMs prefer fast websites.
What actually makes sites slow
In rough order of how often it is the real culprit:
Images. Almost always the largest thing on the page. Oversized dimensions, uncompressed files, and formats from a decade ago. Serving a 3000-pixel photograph into a 600-pixel slot is the single most common waste on the web.
Too much JavaScript. Scripts must be downloaded, parsed and executed before the page responds, which is why INP suffers. Third-party tags are frequent offenders: analytics, chat widgets, heatmaps, ad pixels, each added for a good reason and never removed.
Render-blocking CSS. Stylesheets the browser must fetch and process before showing anything.
Slow server response. Underpowered hosting, uncached pages, heavy database queries. Everything else waits on this, which is why it is worth checking first even though it is rarely the most interesting answer.
Too many plugins and page builder overhead. Each adds its own stylesheets and scripts, usually loaded sitewide whether the page needs them or not. See page builder.
Fonts. Several weights of a custom family, loaded from a third party, blocking text from rendering.
Missing dimensions on images and ads, which causes the layout shift that ruins CLS.
What to do, in order of return
1. Fix the images. Correct dimensions, modern formats such as WebP or AVIF, sensible compression, and lazy loading for everything below the fold. Critically, do not lazy load the hero image, which is usually the LCP element: deferring it is one of the most common self-inflicted LCP problems.
2. Sort out hosting and caching. Page caching, object caching, and a host that is not the bottleneck. This is foundational and no amount of front-end tuning compensates for it.
3. Audit third-party scripts. List every tag, identify who uses the data, and remove what nobody does. This is usually the fastest meaningful win on an established site and it costs nothing.
4. Reduce and defer JavaScript. Load what the page needs, when it needs it.
5. Handle CSS properly. Inline what is needed for the visible area, defer the rest, and remove unused rules.
6. Add a CDN where the audience is geographically spread.
7. Minify and compress, covered under minification. Worth doing, smaller in effect than the steps above, and frequently attempted first because it sounds technical.
Where plugins stop helping
Optimization plugins do real work: caching, deferring scripts, removing unused CSS, serving modern image formats. On a bloated site they can transform the numbers.
What they cannot do is remove code the site depends on. A theme that loads eight stylesheets and a page builder that wraps every element in six containers sets a floor the plugin cannot break through. Past a point, the remaining gains require changing what the site is made of rather than compressing what it already sends, which is the argument for a custom theme on sites where performance is commercially significant.
A related caution: aggressive optimization settings can break things subtly. Deferring the wrong script, removing CSS a rarely-visited template needed, or combining files that conflict. Test forms, checkouts and interactive elements after any change, not just the homepage.
Measuring honestly
PageSpeed Insights shows both field and lab data for a URL. Read the field section first.
The Core Web Vitals report in Search Console shows field data across the whole site, grouped by URL pattern, which identifies the templates with problems rather than individual pages.
Chrome DevTools for diagnosis: what is blocking, what is heavy, what the LCP element actually is.
Test the pages that matter. Homepages get tested and service pages, product pages and checkouts earn the money. They are frequently the slower ones.
Test on a real phone on mobile data. Nothing resets expectations faster.
Where this fits
Our page speed optimization services target the field metrics Google actually measures rather than lab scores, and we prioritize by what will change the numbers for real visitors on real devices. If your site tests well but feels slow, or the score is fine while conversions are not, book a discovery call.
