There is a conversation I have had enough times to predict it. A business owner says their site feels slow. Their designer says it scores fine on their laptop. Their developer says the score is misleading. Everyone is a bit right, nothing changes, and the site stays slow for another two years.
The reason it stalls is that the three people are measuring different things and none of them is measuring the thing that matters, which is what happens to a real customer on a real phone on a real connection.
What slow actually costs
Two effects, and the second one is bigger than most people think.
Conversion. Every major study on this points the same direction: as load time rises, conversion falls, and it falls hardest in the first few seconds. The specific percentages get quoted with more confidence than they deserve, because they vary enormously by sector and device, but the direction has never been in dispute. On mobile the effect is sharper, because the person is more likely to be distracted, on a worse connection, and one thumb away from leaving.
Search. Google uses Core Web Vitals as a ranking signal. It is a modest signal, and anyone telling you speed alone will fix your rankings is overselling. But it is a tiebreaker in competitive results, and more importantly it correlates heavily with the things that are not tiebreakers. A site that renders slowly usually renders badly, gets crawled less thoroughly, and has a worse experience underneath.
And then the effect nobody measures. A slow site reads as an unserious business. Nobody fills in a survey saying “the largest contentful paint was 4.2 seconds so I did not trust them”. They just feel that something is off and they call the other company. If you sell anything on the basis of competence, your site is the first evidence anyone has, and it is being judged before a single word is read.
The three numbers, in plain language
Google’s Core Web Vitals sound technical and are not.
Largest Contentful Paint. How long until the biggest thing on screen, usually the hero image or headline, actually appears. Target is under 2.5 seconds. This is the closest thing to “how long did it feel like it took”.
Interaction to Next Paint. When somebody taps something, how long before the page visibly responds. Target is under 200 milliseconds. This is the one that makes a site feel broken rather than slow, and it is almost always caused by too much JavaScript competing for the main thread.
Cumulative Layout Shift. How much the page jumps around while it loads. Target is under 0.1. This is the one where you go to tap a button and an advert loads above it and you tap the advert instead. Everyone has experienced it. Almost nobody knows it has a name.
Measure them on real data, not a lab test. Google’s own Search Console gives you field data from actual Chrome users on your site, which is worth more than any score generated on your own machine. Your laptop on office wifi is not the audience.
Why it is slow, in the order I usually find it
After a lot of audits, the causes are remarkably consistent.
Images that nobody resized
The most common cause by a distance. A 4000 pixel photograph straight off a camera or a stock site, displayed in a 600 pixel slot, downloaded in full. Four megabytes to show something that needed a hundred and fifty kilobytes.
The fix is well understood and cheap: correct dimensions, modern formats like WebP or AVIF, explicit width and height attributes so the space is reserved before the image arrives, and lazy loading for anything below the fold. This one change fixes both LCP and a good chunk of CLS on most sites, and it does not require a rebuild.
Too many third-party scripts
Count them. Analytics, a tag manager, a chat widget, a heatmap tool, two ad pixels, a cookie banner, a review widget, a font service, a booking embed. Each one was added by somebody with a reasonable justification, and each one loads code from a server you do not control, on a schedule you cannot predict.
The chat widget is usually the single worst offender. It is often the largest script on the page, it frequently loads before anything else, and on a lot of small business sites it produces a handful of conversations a month. That is a real trade and it is worth making deliberately rather than by default.
The exercise: list every third-party script, name the person who owns the decision to keep it, and state what it produces. Anything that fails either test comes off. Then delay the rest until after the page is interactive.
A page builder doing too much
A large amount of the small business web runs on WordPress with a theme and a page builder, and the combination is convenient in exactly the way that produces slow sites. You get a general-purpose layout engine shipping CSS and JavaScript for every feature the builder supports, whether your page uses them or not, plus a plugin stack where each addition loads its assets on every page.
This is not an argument against WordPress. It is an argument for knowing what your setup costs you. If you are on that stack, a competent developer can usually cut the payload substantially by dequeuing assets on pages that do not use them, and it is a much smaller project than a rebuild.
Fonts that block the text
Custom web fonts are the reason a page sits blank for a moment with no text at all. The fix is to self-host rather than call a font service, preload the one or two faces that appear above the fold, use font-display: swap so text renders immediately in a fallback, and choose a fallback that is close enough in metrics that the swap does not shove the layout around.
Hosting that is cheap for a reason
Shared hosting with a slow time to first byte puts a fixed tax on every page before a single byte of your content moves. If your server takes 800 milliseconds to start responding, you have already spent a third of your budget doing nothing. This is usually the cheapest problem to fix, because it is a monthly bill rather than a project.
Everything rendered in the browser
If your site is a JavaScript application that fetches its own content after loading, the visitor waits for the framework, then the data, then the render. For an application that is a reasonable trade. For a marketing site whose content changes weekly, it is paying an application cost for a brochure. Server rendering or static generation removes the entire category, and modern tooling makes it the default rather than an optimisation.
What to do, in order of payback
- Get field data. Search Console, Core Web Vitals report. Fifteen minutes, and it tells you whether you have a problem and on which pages.
- Fix the images. Highest impact per hour of work, on almost every site.
- Audit the third-party scripts. Remove what nobody owns. Defer the rest.
- Fix the fonts. Self-host, preload, swap.
- Check time to first byte. If it is over half a second consistently, the host is the project.
- Then, and only then, argue about the framework. Rebuilds are expensive and this list usually gets you most of the way without one.
The order matters because most sites do not need the expensive answer. I have taken sites from four seconds to under two without touching the stack, purely by doing the first four.
Setting a budget and keeping it
The reason speed regresses is that nobody owns it. A site gets optimised, then over eighteen months somebody adds a video background, somebody adds a pixel, somebody uploads a hero image straight from the camera, and it is slow again.
The fix is to write down a performance budget and treat it as a requirement rather than an aspiration. For this site the budget is under 1.8 seconds LCP and under 100KB of JavaScript, which is stated publicly in the footer partly as a claim and partly as a commitment. Pick your own numbers, put them in writing, and check them monthly. It takes ten minutes and it is the difference between a fast site and a site that was fast once.
The part your designer is right about
None of this is an argument for a plain site. A beautiful, distinctive, memorable website that loads in 1.5 seconds is entirely achievable, and the constraint tends to improve the design rather than damage it. Most of what makes a page slow is not the good design decisions, it is the accumulated stuff nobody removed.
Speed is not the opposite of craft. It is part of it.