Why Is My Business Website Slow? Four Causes and How to Tell Them Apart

Why is my business website slow? Four causes cover almost every case, and you can work out which one you have in about ten minutes without paying anybody. Three Google numbers decide it: the page should appear within 2.5 seconds, the server should start answering in under 0.8 seconds, and the layout should not shift by more than 0.1. What matters is that the four cost wildly different amounts to fix — two of them are Rp0, one of them means a new monthly bill. Every figure here was checked on 6 October 2026.

The trouble is that from where you sit, all four feel identical. The site feels heavy, and that is all you know. The repairs have almost nothing in common, so guessing wrong means paying to fix a problem you do not have.

Measure first, guess later

Open Google PageSpeed Insights, paste your address, run it in mobile mode. Free, no account. The big coloured score at the top is not what you came for — it is a simulation, and it moves by several points if you simply run it again. The three lines underneath are the useful part, because those come from visits by real people.

Google treats a page as passing when 75% of real visits meet all three numbers. One test from an office laptop on good fibre proves nothing at all. Use mobile mode.

Why is my business website slow: four causes, four price tags

Match your test results against the table. The rows read from the symptom you can see yourself, not from the jargon.

The expensive cause: a hosting queue that is already full

This is the one that gets misdiagnosed most often. The owner sees a long blank screen, then tells somebody to compress the images — except the images had not even been requested yet. If your TTFB is above 1.8 seconds, the problem happens before the page starts being sent, and no amount of image work can reach it.

On shared hosting there is a number almost nobody reads, and it is the one that decides this: entry process. It caps how many requests your account may process at the same time. That is not a visitor limit — it is the length of the queue. Rumahweb gives 10 on its cheapest plan, 15 on the next, then 20. While the queue has room everything feels normal. Once it fills, the next visitor waits, and they have no idea why.

List prices run Rp25,000 per month for the smallest, then Rp50,000, Rp90,000 and Rp140,000. Storage is not the real difference: the Rp25,000 plan comes with 512 MB of RAM and a 20% daily CPU allowance, while Rp50,000 brings 1 GB and 40%. If your site crawls every Monday morning and behaves itself the rest of the week, that is a queue symptom rather than bad code — and moving up one tier costs far less than hiring somebody to take the theme apart.

Images: the cheapest fix, and the one most often skipped

The numbers below were measured on one ordinary photo today rather than quoted from anywhere. At its original 3000 pixels it weighed 686 KB. Resized to 1600 pixels and saved again as JPEG at quality 80, it came to 247 KB. The same 1600-pixel image as WebP at the same quality: 63 KB. On a phone screen your eye cannot separate the three, but the last one arrives about eleven times faster.

Scale that to a homepage carrying six such photos and you go from roughly 4 MB down to under 400 KB. Nothing else on this list returns that much for that little effort. Three steps.

1. Resize before uploading, not after. There is no point uploading a 3000-pixel photo into a slot that is 800 pixels wide. Most cases are finished at this step alone.
2. Save as WebP. Every browser still in real use supports it. If whoever manages your site says it is not possible, that is usually about the plugin they chose, not about browsers.
3. Put a width and height on every image. This also closes the fourth cause outright: the page stops jumping, because the space was reserved before the picture arrived.

Third-party scripts nobody noticed piling up

The third cause is almost always sediment from several years. An advertising pixel from a campaign that ended long ago, two analytics tools measuring the same thing, a chat bubble, a map, fonts pulled from three different places. Each one is small. Added together, your page now waits on a dozen servers belonging to other people before its own buttons will work.

Do not rip them all out at once, though. Open the network request list in your browser, sort by slowest, and go down it asking one question: is anyone actually reading this data? When nobody can name the person who looks at it, you have found the first thing to remove.

If the site is still heavy after all three, what is usually left is the structure itself — a theme bought years ago, then layered with plugins that fight each other. At that point rebuilding often costs less than patching forever, and a web development team in Sidoarjo or a ready-made website package starts to make arithmetic sense.

The order that usually turns out to be right

In our experience the sequence barely changes: images first, then unused scripts, then hosting. The first two are free and frequently enough on their own. Only if your TTFB is still above 0.8 seconds after both does a monthly bill belong in the conversation.

Something sellers rarely say out loud: speed is not a job you finish. Six months from now somebody adds a background video to the homepage, or uploads a 20 MB PDF catalogue, and the numbers drift back to where they started. What keeps a site fast is not one big optimisation project but one person who checks it regularly.

Measure before you spend. If you have the numbers in hand but are unsure which one to chase first, an IT consultant in Sidoarjo can read the results with you before the decision gets made.