Why Is My Website So Slow? Causes, Fixes, and What It Costs You

There is no single load-time number that separates fast from slow, because a page loads in stages: something appears, the main content appears, and the page starts responding to taps. Google measures those stages with 3 metrics it calls Core Web Vitals. They sound more complicated than they are.

As of July 2026, Google’s Core Web Vitals bar is: main content visible within 2.5 seconds, a reaction to taps under 200 milliseconds, and a layout shift score under 0.1. Clear all 3 on a phone and your site is fast enough; visitors will not experience it as slow, and shaving further milliseconds will not change anyone’s behavior.

Miss the bar and the page degrades in ways visitors can name. Past 2.5 seconds on cellular data, the site reads as broken: a white screen, a spinner, a logo with nothing under it. A page that paints but ignores taps feels frozen, so people tap harder, then leave. And a layout that keeps shifting produces the most rage-inducing failure of all: you aim for the menu, the page jumps, and you tap something else.

Customers, not milliseconds. The trouble is that the cost never announces itself. Nobody emails you to say the page took too long. A broken checkout at least produces a complaint; a slow homepage produces silence, because the people it loses press back before they know who you are. From your side, a slow month and a slow website look identical.

The time budget is smaller than most owners assume. According to Nielsen Norman Group research, most visitors leave within 10–20 seconds unless the page communicates value in the first 10. A site that spends 4 of those seconds on a blank screen has spent nearly half its budget saying nothing, and the headline that finally appears now has to beat the irritation it created. Slow load is also 1 of the 7 patterns behind why visitors leave a website in seconds, and it is the only one that costs you before a single word is read.

If you buy traffic, the cost stops being abstract. An ad click is billed whether or not your page ever painted, so every visitor who abandons a loading screen is spend with no chance of return. The honest accounting is qualitative: each extra second filters out a share of the people who clicked, and it filters hardest among first-time visitors on phones, exactly the people who have not yet decided you are worth waiting for.

Slowness also colors everything that loads after it. Nielsen Norman Group’s work on trustworthy design finds that visitors form credibility judgments quickly, from small signals. On a slow page, the first signal anyone receives is the wait. Visitors read a laggy page the way they read a messy storefront: as a preview of how you run the rest of the business. The judgment is unfair, instant, and preventable, because the page that keeps people waiting is also the page introducing you.

You do not need an account, a developer, or any technical vocabulary. Google runs a free test that does the diagnosis for you.

1. 1Run the free test. Open PageSpeed Insights, Google’s own speed test, paste your homepage address, and press Analyze. The result takes about 30 seconds.
2. 2Read the mobile result first. It is the default tab for a reason: phones are where most of your visitors are and where slow sites fail hardest. A site that passes on mobile passes everywhere.
3. 3Check the 3 vitals, not the score. Find the LCP, INP, and CLS readings and compare them to the bars in the table above. They tell you what a visitor feels; the big colored number is only a summary of lab conditions.
4. 4Screenshot the opportunities list. Below the score, the report lists what to change, ordered by estimated savings. That screenshot is your to-do list, or the exact thing to send whoever runs your site.

In rough order of how often they turn out to be the answer. For each: how to tell it is your case, and the fix, or the exact thing to ask your developer.

1. Oversized images

How to tell:this is the most common cause by a wide margin. A photo comes off a phone camera at 3–6MB, gets uploaded as-is, and the browser downloads all of it to display a small rectangle. The speed test flags it as “properly size images” or “serve images in next-gen formats,” and the symptom is a page whose text appears long before its pictures. The fix: resize images to roughly the size they display at and compress them before uploading; free compressors typically cut photos by more than half with no visible difference. Start with the hero image, because it is usually the largest thing on the page and the first thing measured.

2. Too many scripts and widgets

How to tell:chat bubbles, analytics tags, social feeds, popup tools, review badges: each one is code your visitor downloads and runs before the page settles. The page paints, then freezes to taps, which is exactly the INP failure. The test calls it “reduce unused JavaScript.” The fix: remove every widget you do not actively use, keep 1 analytics tool, and ask your developer to load the rest after the page becomes interactive. Widgets accumulate like drawer clutter; most sites can lose half of theirs and nobody notices anything except the speed.

3. Cheap shared hosting

How to tell:on entry-level shared hosting, your site queues behind hundreds of others on the same machine, and the wait shows up before a single image loads. The test flags “reduce initial server response time,” and even your simplest pages feel sluggish. The fix: this is the 1 cause money solves directly. Ask your developer whether your server regularly takes more than 600 milliseconds to start responding; if yes, a hosting upgrade is worth more than any amount of image compression. If your response time is fine, do not let anyone sell you hosting as the fix.

4. No caching

How to tell:caching lets the server hand out a saved copy of the page instead of rebuilding it for every visitor, and lets browsers keep files they already downloaded. The giveaway is that a repeat visit feels exactly as slow as the first, and the test flags “serve static assets with an efficient cache policy.” The fix: on WordPress, install 1 reputable caching plugin. On hosted builders like Wix, Squarespace, and Shopify, the platform handles it, so you can cross this cause off. Elsewhere, ask your developer to enable page caching and browser caching headers, which is routine, low-risk work.

5. Bloated themes and page builders

How to tell: a multipurpose theme advertising 200 demo layouts ships code for every one of them, and drag-and-drop builders add their own layer on top. The symptom is a site that stays slow even with small images and few widgets, while the test flags large amounts of unused CSS and JavaScript. The fix: do not swap themes on a live site casually; that is redesign-grade work. First delete unused plugins, sliders, and demo sections, which claws back measurable weight. Then, when a redesign does happen, make a lightweight theme a requirement instead of a hope.

6. Font loading

How to tell: every custom font family, in every weight, is a file that must arrive before your text renders the way you intended. The symptoms are text that appears late, visibly swaps from one typeface to another, or shifts the layout as it lands, which also damages your CLS reading. The fix: use 2 font families at most, load only the weights you actually use, and ask your developer to set font-display: swap so text shows immediately in a fallback font. Typography earns its cost on screen; 5 families in 4 weights each is a speed bill for a distinction nobody sees.

7. Redirect chains

How to tell:a visitor types the old address, is forwarded to the secure version, then to the www version, then to the final page. Each hop is a full round trip before loading even begins, and phones on cellular pay the most for it. Watch your address bar change several times, or look for “avoid multiple page redirects” in the test. Chains usually accumulate after a domain change or site migration. The fix: ask your developer to point every redirect directly at the final address in 1 hop. It is an afternoon of cleanup, and links from old marketing emails and directories get faster with it.

8. Unoptimized video

How to tell:an autoplaying background video is routinely 10–20MB, which makes it more than a hundred images worth of download sitting in your first screen. Worse is video hosted on your own server, which streams badly and taxes the same machine serving your pages. If your hero has motion in it and your LCP reading is far past the bar, this is your cause. The fix: replace hero video with a strong still image, or at minimum host video on a streaming service, embed it below the first screen, and never autoplay on mobile. One good photograph almost always communicates more per megabyte.

Every platform has 1 fix that pays off more often than the rest. Start there before touching anything else.

Whatever your platform, make 1 change at a time and re-run the test after each. Otherwise you will not know which fix worked, and the next person to touch the site will not either.

More often than the speed industry admits. Speed decides whether people wait for your page. It says nothing about what happens once they see it: whether the headline says what you do, whether a stranger finds a reason to trust you, whether the next step is obvious. A fast website that does not convince anyone simply fails faster.

So if your test comes back green and business is still quiet, stop optimizing milliseconds. The problem lives somewhere else: your design, SEO, copy, trust signals, or conversion path. The full website conversion audit guide walks that whole picture in order, and technical SEO audit basics covers the crawl-and-index layer that speed is only one part of.

The fastest way to find out where speed ranks among your problems is to check everything at once: run a free website preview and speed is one of the checks, scored next to the things it usually hides behind.