Half the site briefs we receive begin the same way: "our website feels slow, and we think we need a new one". Sometimes they do. But slowness itself is rarely a mystery, and it is rarely the whole site's fault. When we run an audit, the same six causes come up in roughly the same order, and most of them can be fixed on the site you already have.
Speed is worth taking seriously before it is worth taking personally. Visitors give a page about three seconds before a meaningful share of them leave, and Google folds loading speed into rankings through its Core Web Vitals. A slow site loses people twice: once at the search result, once at the door.
The six usual culprits
1. Your images are too big
This is the cause in the majority of cases, so start here. A photo straight off a phone or a stock site is 4–10 MB. Displayed in a card on your homepage, it needs to be perhaps 150 KB, twenty to fifty times smaller, with no visible difference at that size. A hero section carrying three uncompressed photos can outweigh the rest of the website put together.
The fix: resize images to roughly the size they are displayed at, export them as WebP or AVIF rather than JPEG or PNG, and lazy-load anything below the first screen so it only downloads when the visitor scrolls towards it. Most modern platforms (Shopify, Webflow, Framer, WordPress with the right plugin) will do the format conversion for you. The resizing discipline is still on whoever uploads.
2. Too much JavaScript
Images make a page heavy; JavaScript makes it busy. Every script has to be downloaded, parsed and executed before parts of the page become usable, and on a mid-range phone that execution time is often the single biggest share of the wait. Sites built by stacking plugins, page-builder widgets and animation libraries accumulate scripts the way a drawer accumulates cables.
The fix: remove what you do not use: old plugins, sliders nobody scrolls, chat widgets nobody opens. What remains should load after the content, not before it. This one usually needs a developer for an afternoon, and it is an afternoon well spent.
3. Cheap hosting and no CDN
Before the browser can render anything it has to receive the first byte from your server. On oversold £3-a-month shared hosting, that alone can take over a second, before a single image, font or script has moved. And if your server is in London while your visitor is in Sydney, physics adds its own delay on every request.
The fix: decent hosting is tens of pounds a month, not hundreds. A content delivery network keeps copies of your site near your visitors, and Cloudflare's free tier is genuinely fine. This is the cheapest large improvement on this list.
4. Fonts loaded carelessly
Custom type is worth having; we would say that. But each weight is a file, and a site pulling eight weights across three families is downloading type it mostly never uses, while the visitor stares at invisible or shape-shifting text waiting for it.
The fix: two families, three or four weights in total, self-hosted in WOFF2, with font-display: swap so text is readable immediately in a fallback font and swaps when the real one arrives.
5. Third-party trackers and embeds
Analytics, ad pixels, heat maps, social embeds, review widgets, video players. Each is one line of code to add, so they accumulate silently, and each one phones another company's server before your page settles. We have audited pages where the marketing stack outweighed the actual content several times over.
The fix: list every third-party script and justify each one. Whatever survives should load after the page is interactive. An embedded YouTube video can be a thumbnail that only loads the player when clicked; that single change often saves more than a megabyte.
6. Nothing is cached
A returning visitor should not have to download your logo, fonts and stylesheets again. Without caching headers, every visit starts from zero, and your most interested people, the ones who came back, get the slowest experience.
The fix: configuration, not redesign. Long cache lifetimes on images, fonts, styles and scripts; short on the pages themselves. A CDN from point three largely handles this for you.
How to find out which one is yours
Run your homepage through Google's PageSpeed Insights; it is free and takes thirty seconds. Ignore the score wheel and read the list underneath. "Properly size images" is point one above. "Reduce unused JavaScript" is point two. "Reduce initial server response time" is point three. The report names your culprits in order; this article is the translation.
Watch one number in particular: Largest Contentful Paint, the moment the main image or headline appears. Under 2.5 seconds is good. Over four means people are leaving.
When it is time to rebuild
Everything above assumes the site is worth tuning. Sometimes it is not: a theme with a decade of accumulated plugins, a page builder generating markup nobody can untangle, a platform fighting you on every change. The honest signal is when the fixes stop sticking: every new page arrives heavy again because the system defaults to heavy. At that point speed is not a task, it is an architecture decision, and it belongs in the brief for the next site rather than the maintenance list of this one.
When we build, this is why our sites are light by default: system fonts or two self-hosted families, images processed at build time, as little JavaScript as the design genuinely needs. Fast is not a feature we add at the end. It is what is left when nothing unnecessary was added at all.
