Website Speed: What Actually Slows Sites Down

The Wrong Place to Look First

When a website feels slow, the instinct is usually to blame the server — "we need better hosting." Sometimes that's true. Far more often, the real cause is sitting in plain sight: oversized images, a pile of third-party scripts, and render-blocking code that has nothing to do with server hardware at all. We've covered the business cost of this in why slow websites kill sales — this post is about where the time actually goes.

The Biggest Offender: Images

Images are, by a wide margin, the most common reason a page is slow. A photo taken on a modern phone camera can be several megabytes. Dropped straight into a website without any processing, that single image can take longer to download than the rest of the entire page combined.

What actually helps:

• Compression — reducing file size without a visible quality loss, often shrinking an image by 60-90% before anyone notices a difference.
• Modern formats — formats like WebP or AVIF produce smaller files than traditional JPEG or PNG at equivalent quality.
• Responsive sizing — serving a phone-sized image to phones instead of forcing it to download the same 4000-pixel-wide file meant for a desktop monitor.
• Lazy loading — not loading images below the fold until the visitor actually scrolls near them, so the initial page load isn't waiting on photos nobody's seen yet.

Frameworks like Next.js handle a lot of this automatically through built-in image optimization, which is one reason framework choice does matter — just not because of raw server speed.

Third-Party Scripts: Death by a Thousand Cuts

Every chat widget, analytics tool, ad pixel, font loader, review widget, and marketing tag you add to a site is a separate script that has to be downloaded and run in the visitor's browser. Individually, each one might feel harmless. Stacked up — and it's common for a business site to be running eight or ten of these by the time sales, marketing, and support have each added their own tool — they add real, measurable delay.

Each script can also block the browser from doing other work while it loads and executes, depending on how it's included. A chat widget that adds a full second to page load might generate a handful of extra conversations, but if it's also costing you visitors who bounce before the page finishes loading, that trade isn't obviously a win.

The fix isn't "remove everything" — it's auditing what's actually earning its keep, loading non-critical scripts after the main content rather than blocking on them, and removing tools nobody's actually looking at the data from.

Render-Blocking Code

Some CSS and JavaScript has to be downloaded and processed before the browser can show anything at all. This is called render-blocking, and it's why a page can sit on a blank white screen for a moment even on a fast connection. Common causes include large CSS files loaded in full for a page that only needs a fraction of those styles, and JavaScript placed in a way that halts page rendering until it finishes running.

Well-built sites split code so only what's needed for the visible part of the page loads first, deferring the rest until after the page is usable — a technique often called code splitting.

Where Server and Hosting Actually Matter

None of this means hosting is irrelevant — it just isn't usually the primary bottleneck. Server choice matters most in these specific ways:

• Physical distance — a server far from your visitors adds real, if usually modest, delay. A content delivery network solves this by caching content on servers close to wherever the visitor is.
• Database performance — on a dynamic site, slow or inefficient database queries can genuinely bottleneck a page, especially under real traffic load.
• Shared hosting congestion — budget shared hosting means your site's resources are competing with other, unrelated websites on the same machine, which can cause inconsistent slowdowns.

If your images are optimized, your scripts are trimmed down, and your page is still slow, hosting and server-side performance are worth investigating. Just don't start there.

Fonts, Redirects, and Other Quiet Costs

A few smaller but real contributors:

• Web fonts loaded from external services add a network request and can cause visible text flashing while they load, if not handled carefully.
• Redirect chains — a URL that redirects to another URL that redirects again — add a full round trip to the server for each hop before the final page even starts loading.
• Unminified code — CSS and JavaScript files shipped with all their original spacing, comments, and formatting intact are larger than they need to be; minification strips that out for production.

How to Actually Check Your Own Site

Tools like Google PageSpeed Insights or Lighthouse (built into Chrome's developer tools) will scan a page and point directly at what's slowing it down — usually ranked by impact. It's often a short list: two or three oversized images, one blocking script, and a font loading strategy that could be improved. Fixing the top few items on that list typically does more for your load time than any hosting upgrade would.

For the metrics Google actually uses to judge whether these fixes matter for your search rankings, see our breakdown of Core Web Vitals.