Why Website Speed Matters (And What Actually Makes Sites Slow)
Speed is not a vanity metric - it decides whether people wait. Here is what Core Web Vitals measure, what genuinely causes slow pages, and which fixes are worth doing first.
Website speed is one of the few technical topics where the business case is immediate. A slow site loses people before anything else you have built gets a chance to work. The headline, the design, the carefully written service page - none of it matters if the visitor left during the load.
What makes this frustrating is that speed problems are usually caused by a handful of specific, fixable things. The trouble is that the reporting tools produce a wall of warnings that make it hard to tell which ones matter.
What Google actually measures
Core Web Vitals are three metrics. Understanding what each one represents makes the reports far easier to act on.
Largest Contentful Paint (LCP) measures how long until the main content appears - usually the hero image or headline. This is the closest proxy for “how long did the page feel like it took”. Under 2.5 seconds is the target.
Interaction to Next Paint (INP) measures responsiveness: when someone taps something, how long before the page visibly reacts. High INP usually means too much JavaScript competing for the main thread. Under 200 milliseconds is the target.
Cumulative Layout Shift (CLS) measures how much the page jumps around while loading. This is the metric behind the universal experience of trying to tap a link and hitting an ad because the layout moved. Under 0.1 is the target.
These are ranking signals, but the ranking effect is modest and frequently overstated. The real reason to care is behavioural: people leave slow sites, and they especially leave slow sites on phones.
The actual causes, roughly in order
In practice, most slow sites are slow for one of these reasons.
Images that were never optimised
The single most common cause. Someone uploads a photograph straight from a camera or a stock library, the CMS displays it at 600 pixels wide, and the browser downloads all 4MB anyway.
The fix is unglamorous: resize images to the dimensions they are actually displayed at, serve modern formats like WebP or AVIF, provide multiple sizes so phones do not download desktop images, and lazy-load anything below the fold. This alone resolves a large share of speed problems.
Render-blocking resources
The browser cannot show the page until it has processed the CSS, and sometimes JavaScript, in the document head. Every blocking file adds a round trip before anything appears.
Fonts are a frequent offender. A webfont loaded without a fallback strategy leaves text invisible until it downloads.
Too much JavaScript
This is the deepest problem and the hardest to fix retroactively.
If a site is built so that the browser downloads a JavaScript bundle, executes it, and only then assembles the page, you have put a computer’s worth of work between the visitor and the content. On a fast laptop it is imperceptible. On a mid-range phone it is seconds.
This also affects search engines, which have to render the page to see the content. It usually works, but it is a dependency you do not need.
The alternative is server-rendered HTML: the content exists in the document when it arrives, and JavaScript only handles the parts that genuinely need interactivity. This is the default we build to, and it is why our own website development work targets minimal client-side JavaScript.
Third-party scripts
Chat widgets, analytics, heatmaps, A/B testing tools, embedded videos, social feeds. Each one is a request to someone else’s server, and you do not control how fast they respond.
Most sites accumulate several nobody remembers adding. Auditing them periodically is worth doing - we regularly find scripts for tools the client stopped using years ago.
Layout shift from unsized media
If an image has no dimensions in the markup, the browser does not know how much space to reserve. The text renders, then the image loads and shoves everything down.
The fix is to always specify width and height, or an aspect ratio. It costs nothing and eliminates most CLS problems.
What to fix first
If you have a report full of warnings, this is a reasonable priority order:
- Images. Highest impact per hour of work, almost always.
- Unsized media. Trivial to fix, immediately improves CLS.
- Third-party scripts. Remove what is unused, defer what is not critical.
- Fonts. Preload the ones you need, set a sensible fallback.
- JavaScript volume. Highest impact but usually requires architectural change.
The first three can often be done in a day and will move most sites meaningfully.
Measure the right thing
There are two kinds of performance data and they answer different questions.
Lab data - Lighthouse, PageSpeed Insights - runs a simulated test. It is repeatable and good for diagnosing what is wrong. It is not what your visitors experience.
Field data - the Chrome User Experience Report, or your own monitoring - is aggregated from real visits on real devices. It is what Google uses for the ranking signal, and it is the number that reflects reality.
A site can score well in the lab and poorly in the field, usually because real visitors are on slower devices than the test assumes. Where the two disagree, trust the field data.
Also: test the pages that matter. Most performance testing happens on the homepage, while most organic traffic lands on interior pages built from different templates.
Where speed stops being the problem
It is worth being honest about the limits. Speed is a floor, not a ceiling. Getting from eight seconds to two will change your numbers. Getting from 1.4 seconds to 1.1 will not.
Once a site loads quickly, further optimisation has diminishing returns, and the constraint moves to whether the page says something worth reading. We have seen plenty of very fast websites that convert badly because the content does not explain the offer.
Fix speed because it is a prerequisite. Then go and fix the harder thing.
If your site feels slow and you are not sure why, send us the URL - we will tell you what is causing it and what is worth fixing first. Performance work is part of how we approach both website development and SEO.