No website is slow by accident.
That sounds like a reprimand and it is meant as the opposite. If slowness were random there would be nothing to do about it. It is not random. It is the accumulated weight of four or five decisions, each of which saved somebody an afternoon, and each of which your visitors now pay for on every single page load, forever.
Here is what they usually are, in rough order of how much they cost.
1. The theme
A commercial theme has to sell to everybody, which means it has to do everything. Portfolio layouts, a restaurant menu module, six header variants, a booking calendar, an events system, a slider with fourteen transitions. You use about four percent of it.
The other ninety-six percent does not sit quietly on the server. In most cases its CSS and JavaScript are loaded on every page of your site whether or not the page uses any of it, because working out which page needs what is harder than shipping all of it, and the theme author has no way of knowing what you built.
This is the largest single cost on most slow sites and it is also the most invisible, because it arrived before you did. Nobody chose to load a booking calendar on your contact page. It came in the box.
2. The page builder’s runtime
Page builders are not inherently slow, and I build with one. What makes them slow is how most of them are configured by default, which is to load their entire front-end runtime on every page, plus a stylesheet for every element type they support, plus an animation library, plus icon fonts for icons you are not using.
Some builders let you turn most of that off and load only what a page actually contains. Most installations never have it turned off, because the setting is buried and nothing visibly breaks when it is on.
The tell is a page with a heading, three paragraphs and one image that ships two hundred kilobytes of CSS. That is not your content. That is the toolbox arriving with it.
Every one of these was a choice to save an afternoon, made once, by somebody who was not going to be the one waiting for the page.
3. Fonts loaded from somebody else’s server
A font hosted on a third-party service costs you a DNS lookup and a TLS negotiation to one domain, which then returns a stylesheet that points at a second domain, requiring a second lookup and a second negotiation, before a single letterform has been requested. On a good connection that is a couple of hundred milliseconds. On a phone on one bar it is considerably worse, and it happens before any text can render in its real typeface.
There used to be a real argument for it: your visitor probably had the font cached already from some other site that used it. That argument is dead. Browsers partition their cache by site now, precisely to stop cross-site tracking, so a font fetched on one website is fetched again on yours. The shared-cache benefit has not existed for years and the advice recommending it is still everywhere.
Self-hosting the same font, subset to the characters you actually use, turns four network round trips into zero and is an hour of work once.
4. Images at the size they came off the camera
The most common and the easiest to fix. A photograph goes from a phone or a DSLR into the media library at four thousand pixels wide and three megabytes, and gets displayed in a box six hundred pixels across. The browser downloads all three megabytes and throws most of it away.
Multiply by eight images on a homepage and the page weighs more than most mobile data plans enjoy. Resize to the largest size actually displayed, export as WebP, and the same page is frequently a tenth of the weight with no visible difference.
Why caching hides this instead of fixing it
This is the part worth understanding, because it is where most performance work goes wrong and where a lot of money gets spent on nothing.
A caching plugin stores a finished copy of your page so the server does not have to build it from the database on every request. That genuinely helps one specific thing: the delay before the first byte arrives. If your host is slow, caching is a real improvement and you should have it.
What caching does not do is change what gets sent. The four hundred kilobytes of theme CSS is in the cached copy. So is the builder runtime, the font request, and the three megabyte photograph. The browser still downloads all of it, still parses all of it, and still blocks on all of it, and the phone still has to do the work of turning it into a page.
So the score improves a little, the site still feels sluggish to touch, and the conclusion everyone reaches is that they need better hosting. Sometimes that is true. Usually the host is fine and the problem is that four hundred kilobytes of CSS is four hundred kilobytes of CSS no matter how fast the machine that sent it was.
What fast is actually worth
Speed gets sold as a search ranking factor, and it is one, but a minor one. That is not the reason to care.
The reason to care is that the people you most want are the ones on the worst connections. In infrastructure contracting that is a foreman in a truck cab, a coordinator on hotel wifi, an applicant on a phone at the end of a shift with a plan that throttles after ten gigabytes. Those visitors do not report a slow site. They leave, and you never find out they were there.
If you want a number to hold your site to, the useful ones are the Core Web Vitals: largest contentful paint under two and a half seconds, interaction to next paint under two hundred milliseconds, cumulative layout shift under 0.1. Interaction to next paint is the one that catches the problem described above, because it measures whether the page responds when somebody touches it, which is exactly what all that unused JavaScript interferes with.
How to check yours in five minutes
- Run your homepage through PageSpeed Insights and ignore the score. Look at the field data at the top if there is any, because that is real visitors rather than a simulation.
- Look at total page weight. Under one megabyte is healthy for a content page. Over three, something structural is wrong.
- Open your browser’s developer tools, go to the network tab, reload, and sort by size. The four problems above will be the top four rows, by name.
- Check whether any request goes to a domain that is not yours. Fonts, icon libraries and analytics all show up here, and each one is a connection made before your page can finish.
- Then load the site on your phone on cellular, away from the office. That number is the only one your customers experience.
Most of this is fixable without a rebuild. Images and fonts are an afternoon. The builder settings are an hour if they exist in your builder. The theme is the one that usually is not fixable, because you cannot remove the parts of it you are not using without breaking the parts you are, which is the actual argument against buying one in the first place.
Building without a theme underneath is most of what I mean by website development as distinct from design, and it is why the sites I build ship the CSS for the page you are on rather than the CSS for every page anyone could ever build. There is a worked example of what that buys in the Central Plains Communications case study, where the constraint that set the whole budget was a foreman on one bar of signal.
