Practical guide · verified against the real thing
Why your website is slow: the real causes, not the guessed ones
In one line: Websites have exactly six speed problems, ranked by how often they're the culprit. Measure first, blame second — the fixes are different for each.
Slow websites get "fixed" in the wrong place constantly — people upgrade hosting when the problem is a 4MB hero image, or rip out a feature when the problem is a font. Site speed has a short list of real causes, and they're rankable by frequency. Measure first (Google's PageSpeed Insights or the browser's Lighthouse — free, thirty seconds), find your cause on this list, fix that one.
Cause one: images (the usual culprit)
Oversized images cause more slow sites than every other cause combined. A phone photo is 3-6MB; a webpage needs that same image at 100-300KB. The fixes are mechanical: resize to the display size, compress (modern formats like WebP/AVIF if your stack allows, JPEG at quality ~80 if not), and lazy-load everything below the fold. A site that does only this is usually transformed — it's the same disease as the full phone: nobody notices bytes piling up until performance is the symptom.
Cause two: the JavaScript habit
Every widget, tracker, animation library and framework ships code the visitor's phone must download and run before the page settles. Modern sites routinely ship megabytes of JavaScript to display a thousand words of text. The fixes: audit what's actually loaded (the Lighthouse report lists it), delete what isn't earning its place, and load the rest deferred. The brutal honest question — "would this page still work with this script deleted?" — usually has yes as the answer.
Cause three: third-party scripts
Analytics, chat widgets, ad networks, embedded social feeds, maps: each one is your page waiting on someone else's server, and a slow third party makes your page slow by association. The fixes: fewer embeds, loaded last (async), and the occasional brutal audit — the chat widget nobody uses is often worth more removed than its "engagement" is worth kept.
Cause four and five: caching and the server itself
Caching is the difference between rebuilding the page for every visitor and serving the finished one from memory — static-site generators and CDNs do this for free (it's why free static hosting is so fast); dynamic sites need it configured. The server's first response time — time-to-first-byte — is the one place hosting tier genuinely matters: an overloaded shared server adds half a second before your page even starts. TTFB is the measurement that tells you whether the slow site is the site or the host — which is the diagnosis most upgraded-hosting purchases should have started with.
Cause six: fonts
Web fonts block rendering while they load — a beautiful typeface from a slow server can hold your entire page hostage for seconds. Fix: host fonts locally, load them with font-display: swap (text shows immediately in a fallback), and carry two or three weights, not eight.
The discipline that beats guessing
Measure (PageSpeed Insights), read the biggest items in its report, fix exactly those, measure again. Three cycles of that beats any amount of performance folklore — and the site that emerges usually costs less to run than the slow one did, because the real fixes are subtractions (the same subtraction discipline hardened this site's own front end).
Sources: Google web.dev performance guidance (Core Web Vitals measurement methodology). Reviewed September 2026.
Sources
Next