Why is my website so slow?

Here’s the frustrating part about a slow website: it almost never feels slow to you. You open it a dozen times a week. Your browser has it cached. You’re on home Wi-Fi or a wired office connection. It snaps right up.

Your customer is a different story. They’re on a phone, on cellular data, tapping your link for the first time — downloading everything fresh. That’s the load that matters, and it’s the one you rarely see.

The good news is that slowness is not a mystery. It comes from a short list of specific, measurable causes, and you can check every one of them yourself. Let’s walk through them.

What counts as “slow,” according to Google?

Before we diagnose, let’s set the bar with a neutral referee instead of a gut feeling.

Google’s own research found that 53% of mobile visitors abandon a page that takes longer than three seconds to load. More than half — gone before your headline, your offer, or your phone number ever appears.

Google also publishes a specific technical target through Core Web Vitals: a Largest Contentful Paint (LCP) under 2.5 seconds is considered “good.” LCP is roughly the moment the main content of your page becomes visible. If yours is sitting at five or six seconds on mobile, that’s not a matter of taste — it’s measurably outside the range Google treats as a healthy experience.

So the working definition for the rest of this guide: under 3 seconds on mobile is the line, under 2 is genuinely fast. Now let’s find what’s putting you over it.

Cause 1: Your images are far bigger than they need to be

This is the single most common cause, and the easiest to underestimate.

A modern phone camera produces photos that are four or five thousand pixels wide and several megabytes each. When those get dropped straight onto a website — a hero banner, a gallery of past jobs, a team photo — the visitor’s phone has to download every one at full size, even though it’s being shown in a space a few hundred pixels wide.

Stack a handful of those on one page and you can be asking a visitor to download 10, 15, even 20 megabytes before the page settles. On cellular data, that’s the difference between a one-second load and a ten-second one.

How to check it yourself: run your URL through Google PageSpeed Insights or the MachSites Grader. Look for flags like “properly size images,” “serve images in next-gen formats,” or “efficiently encode images.” If you see those, image weight is dragging you down. A properly built site serves each image at the exact size and format the device needs — often cutting image weight by 70% or more with no visible change in quality.

Cause 2: Too many plugins, apps, and third-party add-ons

Template platforms make it easy to bolt on features: a booking widget, a chat bubble, a reviews carousel, a pop-up tool, three analytics trackers, a social feed. Each one feels small. Each one usually loads its own bundle of scripts and stylesheets, often from someone else’s server.

By the time a page with twenty add-ons finishes loading, the visitor’s phone has fetched and run code from a dozen different sources — most of it before anything useful appears on screen. It’s death by a thousand small downloads.

How to check it yourself: in PageSpeed Insights, look at “Reduce the impact of third-party code” and the count of network requests. A lean page might make 20–40 requests; a bloated one can make 150+. If yours is high, every extra widget is a tax you’re paying on every single visit.

The fix isn’t always deleting features — it’s building them in efficiently instead of stacking third-party tools that each phone home separately.

Cause 3: Render-blocking scripts hold the page hostage

This one is more technical, but the concept is simple. Some scripts and stylesheets are “render-blocking” — the browser refuses to show the page until it has downloaded and processed them. So even if your content is ready, the visitor stares at a blank white screen while the browser works through a queue of scripts that don’t affect what they came to see.

Heavy page-builder frameworks are notorious for this. They ship large JavaScript bundles that must run before the page becomes interactive, which is why some template sites feel like they “hang” for a beat before snapping into place.

How to check it yourself: PageSpeed Insights flags this directly as “Eliminate render-blocking resources” and “Reduce unused JavaScript.” If those show large potential savings, scripts are getting in the way of your content. On a well-built site, the content paints first and the non-essential scripts load quietly afterward, so the visitor never waits on them.

Cause 4: Cheap shared hosting responds slowly

Even a lean page has to start somewhere: the visitor’s phone asks your server for the page, and the server has to answer. On budget shared hosting, your site may be sitting on a machine with hundreds of other websites, all competing for the same processor and memory. When the server is busy, your visitor waits — sometimes a full second or more — before a single byte comes back.

That initial delay is called Time to First Byte (TTFB), and it’s the foundation everything else is built on. A slow TTFB means the visitor is already behind before any image or script has even started.

How to check it yourself: tools like PageSpeed Insights and web.dev’s guidance call out slow server response times. If your TTFB is consistently high, the problem is partly where your site lives, not just how it’s built.

Cause 5: No CDN, so distance adds delay

If your website lives on a single server in one city, every visitor’s request has to travel to that city and back — even if they’re on the other side of the country. Physical distance adds real milliseconds, and they add up.

A CDN (Content Delivery Network) solves this by keeping copies of your site on servers around the world and serving each visitor from the one nearest them. The result is that a customer 2,000 miles away gets the same fast response as someone next door.

Most cheap hosting setups don’t include a proper CDN by default. Serving a site from a global edge network — the way sites built on Cloudflare’s infrastructure are — removes distance as a variable entirely.

Cause 6: The page is doing work it doesn’t need to

Sometimes the site is simply built to do too much on every load: fetching live data that rarely changes, running animations that recalculate constantly, loading fonts in ways that block text from appearing, or shifting the layout around as elements pop in (which also hurts your Core Web Vitals). None of these are visible as “features” to the owner — they’re just quiet overhead baked into how the template was assembled.

This is the category you can’t easily self-diagnose beyond the PageSpeed score, and it’s usually the clearest signal that the architecture of the site — not any one setting — is the thing holding it back.

The pattern: weight and architecture, not one setting

Notice the theme running through all six causes. Slowness isn’t usually one broken thing you can toggle off. It’s accumulated weight — heavy images, stacked plugins, blocking scripts — sitting on infrastructure that was never built for speed, all compounding on the one load you never see: a first-time visitor on a phone.

That’s also why speed can be the hardest problem to fix on a template site. You can compress a few images and remove a widget or two, but the render-blocking framework, the shared hosting, and the missing CDN are baked into how the whole thing was built. This is the same root cause behind a lot of quiet conversion problems, too — see why is my website not generating leads, where a slow load is usually the biggest single leak.

How to diagnose your own site in ten minutes

1. Get a neutral score. Grade your site or run it through PageSpeed Insights. Note the mobile load time against the 3-second line and the LCP against 2.5 seconds.
2. Read the “Opportunities.” Image sizing, render-blocking resources, unused JavaScript, and third-party code are the four flags that map directly to Causes 1–3 above.
3. Test on a real phone. Open your site on cellular data, not office Wi-Fi. That’s the experience your customers actually get.
4. Count the requests. In the PageSpeed report, a request count well over 100 usually means plugin and third-party bloat.
5. Check your host. A consistently slow Time to First Byte points at the hosting and the lack of a CDN.

Each of those maps to a real cause, and the neutral tools do the judging — you’re just reading the results.

If your load time is the thing dragging everything else down, that’s exactly what a rebuild on faster infrastructure is meant to solve: the same look and the same content, re-engineered to load in under a second and served from a global edge network, so the traffic you already pay for isn’t leaking out before the page appears. You can see what that costs on the pricing page — but start by getting your number. Check your speed at no cost and see where you stand against the 3-second line.