When a Slow Website Is Not Your Host Fault
A photo straight out of a phone is often four megabytes. Put six of them on a homepage at full size and you have handed every visitor roughly twenty four megabytes of picture, on a page that displays each one in a box about the size of a business card. That is a slow website, and it will be a slow website on our servers, on a competitor's servers, and on the most expensive plan anyone will sell you. The bytes do not get lighter when they change address.
One photograph, one hundred times bigger than the space it fills
Open the file on your computer and look at the dimensions. A recent phone shoots something around 4032 pixels wide. Now look at where that photo actually lands on the page. In a three across grid on a phone screen, it is displayed about 400 pixels wide. Ten times narrower. Pixels are area, so the browser downloaded roughly one hundred times the image data it could use, decoded all of it, and threw the rest away.
Nothing about that is a hosting problem. The file is four megabytes because it left the camera as a four megabyte file, it got uploaded that way, and nothing in between resized it. The same photo saved at 800 pixels wide, which still looks sharp on a modern phone, typically comes in under 150 kilobytes. Same picture to the eye. Somewhere around one twenty fifth of the weight.
Do that to six photos and the homepage goes from about twenty four megabytes of imagery to about one. No plan change. No migration. No new invoice.
The browser downloaded one hundred times the image data it could use, then threw the rest away.
What a slow website is actually waiting on
Here is where the seconds go. The browser looks up the domain, opens a connection, and asks the server for the HTML. Lookup and handshake are tens of milliseconds. Then the server does its work and starts sending. On decent shared hosting, for a normal small business site, that is a couple hundred milliseconds. Call it a quarter of a second and be generous about it.
Everything after that is your content. Images, fonts, stylesheets, scripts, an embedded video player, the chat bubble, the review widget, two or three tracking tags. If the page needs nine megabytes of that, the arithmetic is not kind. Nine megabytes is seventy two megabits. On a 20 Mbps connection that is 3.6 seconds of pure transfer, and that assumes the server answered instantly and nothing else was using the network. Neither is true, so the real number is worse.
Some of that weight also blocks. The browser will not paint text until the stylesheet arrives, and it will often hold the words back while it waits on a font file. A chat widget shows up as one small line of code in your page and then goes and fetches its own bundle from somewhere else, on a connection your host has no say over at all.
If the server answered in a quarter of a second and the page needs nine megabytes, the server is not what you were waiting on.
Moving the same weight to a faster address
The usual advice at this point is to upgrade. Move off shared hosting, get a virtual server, pay several times what you were paying. Sometimes that is sound. Often it is a nine megabyte page arriving intact at a nicer address.
Say the move takes your server response from 400 milliseconds down to 120. That is a real improvement and worth having. It is also 0.28 seconds off a page that was taking six and a half. You spent four times the money to remove about four percent of the wait. The demo looked wonderful because the demo was an empty page, and on an empty page server time is the only thing there is to measure.
A content delivery network has the same shape of problem. It moves your bytes physically closer to the visitor, which matters if your customers are in Oregon and Ireland. If you run a roofing company and your customers are in Amherst, Cheektowaga and West Seneca, those bytes were already travelling a short distance. There are just far too many of them.
The part your host really does control
This is not an argument that hosting does not matter. It matters for a specific and fairly short list. How fast the server produces the HTML. Whether it is running a current version of PHP or something five years stale. Whether the database is sitting on a box shared with an unreasonable number of neighbours. Whether server side caching exists. Whether the connection is modern and encrypted properly. And whether the thing is up at all, which is a different complaint entirely. A 99.9 percent uptime figure sounds close to perfect until you multiply it out and get about 8.8 hours of a year with the doors locked.
So yes, there is a version of this where the host is the problem, and it is easy to spot. If the server takes two or three seconds to send back the very first byte, before a single image has even been requested, that is not your photos. That is the box your site lives on, and you should move.
But that is the honest scope of web hosting for small business. It owns the first half second and the reliability. It does not own the twenty four megabytes you put in the page, and no plan sold anywhere will.
WordPress makes weight very easy to add
Most of the slow sites we see are built on WordPress, and not because WordPress is bad. It is because WordPress makes adding weight a two click operation and removing it something nobody ever does. A slider plugin. A page builder. A form plugin that loads its stylesheet on all forty pages including the ones with no form. Three font families where one would do. A social feed. A popup. A cookie banner from a fourth company.
Every one of those is small on its own. Twelve of them are not small. A page builder theme commonly ships several hundred kilobytes of CSS and JavaScript before you have written a word of content, and each plugin adds its own on top. The site did not get slow on a particular Tuesday. It got slow one reasonable decision at a time, over three years, which is exactly why nobody suspects it.
We keep WordPress hosting explained as its own page because tuned hosting genuinely helps a WordPress site. It helps by caching and serving what you built more efficiently. It does not help by deleting what you added, and it cannot, because it has no idea which of those twelve plugins you actually use.
The site did not get slow on a particular Tuesday. It got slow one reasonable decision at a time.
The upgrade is easier to sell than the fix
There is a reason the advice tilts the way it does. Selling you a bigger plan is a checkout button and a recurring charge. Telling you that your photos are too big is an awkward five minutes at the counter followed by an hour of unglamorous work that bills once and never again.
There is a second reason, and it is the unwelcome one. Quite often the person who built the site is the one who put the twenty four megabytes in it, and when the client complains about speed, the host is a comfortable place to point. It is a third party who is not in the room.
None of this requires anyone to be dishonest. It only requires that the easy answer and the correct answer are different answers, and that only one of them has a price list.
Before you shop for a new plan, weigh the page. If the HTML comes back fast and the total is measured in megabytes, you have found the problem, and it moved into that house with you. A homepage like the one at the top of this post, with the six photos resized to the size they are actually displayed at, generally lands under two megabytes on the same server, on the same plan, at the same monthly price. Nothing was purchased. The page simply stopped carrying what it never needed to carry.
More from the blog
- What Unlimited Hosting Really Means
- The First Hour When Your Site Goes Down
- Why Your Business Email Goes to Spam
All posts are on the blog. For the step by step versions, see the domain and hosting guides.