The Specific Things That Make a Small Business Site Slow

What “fast” actually means in numbers

Speed stopped being a matter of opinion when Google published Core Web Vitals. Three measurements matter. Largest Contentful Paint is how long until the biggest thing on screen, usually your hero image or headline, has drawn; the target is 2.5 seconds or better. Interaction to Next Paint is how long the page takes to respond when someone taps something, and the target is 200 milliseconds. Cumulative Layout Shift measures how much the content jumps around while loading, and should stay under 0.1.

Two details about those numbers get missed. First, they are assessed at the 75th percentile of real visits, so a site that is quick for three quarters of people and awful for the rest fails. Second, the measurement that counts is field data from actual visitors on actual phones, not the score you get from a testing tool on a desktop connection. Your site feels fine to you because you are testing it on a fast laptop, on your own broadband, with the page already cached in your browser.

Your customer is on a two-year-old Android phone with a weak signal outside a supermarket. That is the machine your site has to be fast on.

Photographs are almost always the problem

If a small business site is slow, start with the images. A modern phone camera produces a file of several megabytes at 4000 pixels wide. The slot it appears in on your website might be 800 pixels wide on a laptop and 380 on a phone. Upload the original and the browser downloads every one of those bytes, decodes the whole image in memory, then throws away most of the detail to draw it small. On a mobile connection that single file can take longer to arrive than everything else on the page combined.

The fix is unglamorous and entirely mechanical. Resize each image to the largest size it will ever be displayed at, generate several widths so a phone can fetch a small one, serve them in WebP or AVIF rather than JPEG, and set explicit width and height attributes so the browser reserves the right space and nothing jumps when the picture lands. That last point is what most layout shift comes down to: text that has already drawn gets shoved down the page when an image finally appears above it, and the reader loses their place at the exact moment they were starting to read.

Also worth checking: how many images load before anyone scrolls. A gallery of twenty photographs at the bottom of the home page should not be downloading while the visitor is still reading the headline. Lazy loading everything below the fold is a one-attribute change with a large effect, but the hero image should never be lazy loaded, because that is the one the browser needs immediately.

Fonts that hold the page hostage

Web fonts are the second most common cause and the least understood. A browser that meets a stylesheet referencing a custom font will, by default, hold off painting any text in that font until the file has downloaded. Point the stylesheet at a third-party font host and the browser first has to resolve a new domain, open a fresh connection, negotiate TLS, fetch a CSS file, discover the font URLs inside it, then fetch those. Every one of those steps is a round trip, and round trips on mobile networks are where the seconds go.

Self-hosting the font files from your own domain removes most of that. Subsetting them to the characters you actually need, usually Latin, cuts the file size further. Preloading the one or two weights used above the fold tells the browser to start fetching immediately rather than waiting to discover them. And setting font-display: swap means text draws in a fallback font straight away and switches when the real one arrives, which looks slightly untidy for a moment and is far better than a blank page.

The deeper question is how many fonts you need. Two families at two weights each is four files. Most small business sites would lose nothing by using one family at two weights, or by using the fonts already on the visitor’s device and shipping none at all.

Third-party scripts, and the ones nobody remembers adding

Every tag you add to a site is a promise that someone else’s server will be quick today. A typical accumulation looks like this: an analytics script, a remarketing pixel, a live chat widget, a cookie consent banner, a reviews badge, a font host, and a booking embed. Each one opens a connection to a different domain. Several of them load further scripts of their own once they arrive. The chat widget in particular tends to be the single heaviest thing on a small business site, and on many of them it is used twice a month.

This is where the cost is genuinely hidden, because a script that arrives late does not just delay the page, it competes for the phone’s processor. Parsing and running JavaScript is the work that makes a cheap Android device feel broken: the page looks finished, the visitor taps a menu, and nothing happens for half a second because the main thread is busy with someone else’s tracking code.

Audit what you have with a clear head. For each tag, ask who reads its output and when they last acted on it. A marketing pixel for a campaign that ended in 2024 is pure cost. If a widget genuinely earns its place, load it after the page is interactive, or on a click, rather than in the head. The irony worth naming is that consent banners, which exist to protect the visitor, are frequently the slowest and most layout-shifting element on the page.

Page builders that ship a bundle to draw a paragraph

A lot of small business sites are built on a stack where every page load involves a database query, a theme, a page builder plugin, half a dozen other plugins, and a JavaScript framework rendering content that was never going to change. The visible result is a home page that ships a 400 kilobyte stylesheet, most of it for blocks the site does not use, plus scripts to animate things nobody asked to be animated.

The alternative is to do that work once, at build time, and send the browser finished HTML. This site is built that way: Astro with static output, so a page arrives as HTML and CSS with no framework to boot up before the text appears. That is not a claim of virtue, it is a claim about arithmetic. Nothing you send is faster than something you send. Our post on what an agent builds and what a human still decides covers how the rest of that build works.

If you are on a builder and staying there, the honest wins are still available: strip unused plugins, turn off animation libraries, enable proper caching so pages are not rebuilt for every visitor, and resist the temptation to solve a slow site by adding an optimisation plugin on top of the seven you already have.

Where the bytes come from

Distance costs time, and nothing you do to a page can beat physics. A request from Newcastle to a server in Virginia takes roughly 80 to 100 milliseconds each way before the server has done anything at all, and a first connection needs several of those round trips for DNS, TCP and TLS. Serve the same file from a network with a point of presence near the visitor and that overhead largely disappears.

Static files on a CDN are the simplest version of this. This site sits on Cloudflare Pages, so the HTML is cached at the edge and the first byte arrives quickly wherever the reader happens to be. Shared hosting on a single box in one data centre is where a lot of small business sites still live, and it is a defensible choice for a shop that only serves one town, but it puts a floor under how fast the site can ever be.

Check the cheap wins too. Compression should be on, and it should be Brotli rather than gzip where available. Cache headers on images, fonts and stylesheets should be long, with filenames that change when the content does. HTTP/2 or HTTP/3 should be in use so a page can fetch many small files over one connection instead of queuing them.

How to find out which of these is yours

Start with field data, not a lab score. The Chrome User Experience Report shows what real Chrome users experienced on your site, and PageSpeed Insights surfaces it above the lab score if your site has enough traffic to qualify. If it does not, run the lab test but throttle it to a slow 4G connection and a mid-range mobile CPU, because an unthrottled desktop test will tell you everything is fine.

Then open the network panel in your browser’s developer tools, tick “disable cache”, reload, and sort by size. The top three rows are usually your entire problem. Sort by time instead and you will see which requests are waiting on someone else’s server. Look at what loads before the first paint, and ask of each item whether the page could have drawn without it.

Finally, measure the same page again after each change rather than making six at once. Speed work goes wrong when nobody knows which of the six things helped, and one of them quietly broke the contact form.

What the delay actually costs

The research on this is consistent even if the exact numbers vary by industry: conversion rate falls as load time rises, and the steepest part of that curve is in the first few seconds. For a business whose site exists to produce phone calls and form submissions, a visitor who leaves before the page paints is indistinguishable from a visitor who never arrived, except that you may have paid for the click.

There is a search dimension too. Core Web Vitals are a ranking signal, modest next to relevance and links, but real. A slow site also wastes crawl budget, which matters more once you have a few hundred pages. And answer engines that summarise pages have to fetch them first; a page that times out is a page that does not get quoted.

Mostly, though, it is about what speed signals. A page that appears instantly reads as competence before a single sentence is judged. If you want to talk about a site that is slow and you are not sure why, send us a message and describe what you have got.