Why speed affects both conversion and rankings
Speed is not a purely technical concern — it is a business one. A visitor who has to wait for a page to become usable is a visitor who is actively deciding whether to stay, and that decision happens well before they have seen anything about what you actually offer. A slow site quietly taxes every other page on it, no matter how good the design or copy is.
Speed also has a direct relationship with search visibility: page experience, including loading and interaction speed, is one of the signals search engines use when ranking pages of otherwise similar relevance and quality. A fast site does not guarantee good rankings on its own, but a slow one puts a ceiling on how well even excellent content can perform.
Core Web Vitals in plain language
Core Web Vitals are a small set of metrics that try to capture what "feels fast" actually means to a real visitor, rather than measuring speed in the abstract. Three matter most:
Three separate measures of the same thing: does this page feel fast and stable to use?
LCP (Largest Contentful Paint) measures how long it takes for the biggest visible element — usually a hero image or heading — to actually render. This is the metric closest to "how long did I wait for this page to look done." Large unoptimised images and slow servers are the most common causes of a poor LCP.
CLS (Cumulative Layout Shift) measures how much content unexpectedly moves around while a page is loading — the frustrating moment you go to tap something and an ad or image loads in above it, shifting everything down. It is usually caused by images or embeds that do not reserve space before they load.
INP (Interaction to Next Paint) measures how quickly the page responds after someone taps or clicks something — a laggy delay between tapping "add to cart" and seeing anything happen is exactly what this metric captures. Heavy, unoptimised JavaScript is the usual cause.
Image optimisation
Images are the single most common source of slow pages, and also the easiest to fix. A photo straight out of a modern camera or stock library is often many times larger than a page actually needs. Before uploading any image:
- Resize it to the actual dimensions it will display at — do not upload a 4000px-wide photo for a 600px-wide slot.
- Compress it using a modern format (WebP or AVIF where supported) rather than an uncompressed PNG or a high-quality JPEG.
- Add width and height attributes (or their CSS equivalent) so the browser reserves the right space before the image loads — this directly protects CLS.
- Lazy-load images that are below the fold, so the browser is not fetching everything at once on first load.
Hosting and caching
No amount of front-end optimisation compensates for genuinely slow hosting. A server that is under-resourced or geographically distant from most visitors adds delay before a page even starts rendering. Choosing hosting appropriate to the platform and expected traffic — and upgrading it as the site grows rather than after it has already become a problem — is a foundational, not optional, part of performance.
Caching stores a ready-to-serve version of a page so it does not need to be rebuilt from scratch on every visit, which can meaningfully cut load times, particularly for content-heavy or e-commerce sites. A content delivery network (CDN), which serves static files like images and stylesheets from a location physically closer to the visitor, compounds that improvement for visitors far from the primary server.
If you fix nothing else this month, fix images — resize and compress every image on the homepage and top landing pages. It is the highest-leverage speed change most sites can make in an afternoon.