Why Website Speed Matters and Simple Ways to Improve It
Why a fast website matters for visitors and search, plus practical steps to speed yours up.
July 26, 2026 11:26
Site speed advice is usually either too vague to act on or too technical to attempt. This is the version for someone who runs a small site and wants to know which things are worth doing.
The measurements that matter
Google's Core Web Vitals reduced site speed to three measurements. They are worth knowing by name because every testing tool reports them.
Largest Contentful Paint (LCP) measures how long until the biggest visible element, usually a hero image or a headline block, has rendered. The threshold for "good" is 2.5 seconds or less. This is the one most small sites fail, and the cause is almost always an oversized image.
Interaction to Next Paint (INP) measures how quickly the page responds when someone taps or clicks. Good is 200 milliseconds or less. INP replaced the older First Input Delay metric in March 2024, so any guide still discussing FID predates that change.
Cumulative Layout Shift (CLS) measures how much the page jumps around while loading. Good is 0.1 or less. This is the one that makes people tap the wrong thing because an advert loaded and pushed the button down.
Where the weight actually is
On a typical small website, the page weight breaks down in a predictable order, and so does the opportunity.
Images are almost always the biggest problem, and usually by a wide margin. The classic case is a photograph straight from a phone camera, several thousand pixels wide and several megabytes, displayed in a slot 800 pixels across. The browser downloads all of it and throws most of it away.
Three fixes, in order of impact: resize images to roughly the largest size they will actually be displayed at; save them as WebP or AVIF rather than JPEG or PNG, which typically cuts the file size by a quarter to a half at the same visual quality; and add loading="lazy" to images below the fold so they are not fetched until needed. The first of those alone frequently halves a page's weight.
Third-party scripts are the second biggest problem and the most overlooked. Analytics, chat widgets, consent banners, social embeds, font loaders and advertising tags each add requests, and each is a connection to a server you do not control. A single chat widget can add several hundred kilobytes and block rendering while it loads.
The useful exercise is to list every third-party script on your site and justify each one. Most sites are carrying at least one that was added for a trial years ago and never removed.
Web fonts are third. Each weight and style is a separate file. A site loading four weights of two families is downloading eight font files to render text that would have looked fine in two. Adding font-display: swap also stops text being invisible while fonts load.
Things worth doing that take ten minutes
- Turn on compression. Gzip or Brotli on HTML, CSS and JavaScript is a server setting, usually a single toggle, and typically cuts those files by around seventy percent.
- Set cache headers so returning visitors are not re-downloading your logo every visit.
- Specify image dimensions in the HTML. This costs nothing and fixes most layout shift, because the browser reserves the right amount of space before the image arrives.
- Check your hosting. If the server takes 800 milliseconds to send the first byte, no amount of front-end work will rescue the page. Shared hosting at the cheapest tier is frequently the actual bottleneck.
A caveat about scores
Testing tools give a score out of 100, and chasing that number is a trap. The score is a synthetic lab measurement on a simulated slow device, and the last twenty points are disproportionately hard to win. What Google actually uses for ranking is field data from real visitors, which is reported separately in Search Console.
Speed is also a modest ranking factor rather than a decisive one, and Google has been explicit that it is used as a tiebreaker between pages of comparable relevance. A fast page about the wrong thing still loses to a slow page about the right thing. Fix speed because visitors leave slow sites, which is the real cost, and treat the ranking benefit as a bonus.
