Why Your Website Is Slow (And What to Actually Do About It)

The median web page in 2025 weighed 2.86MB on desktop and made 77 HTTP requests to load, according to the HTTP Archive. That's up 7.3% from the year before, and the trend hasn't reversed. If your site feels sluggish, you're in large company, but that's not a reason to accept it.

We audit slow websites constantly. The causes are almost always the same five or six things, and most of them can be fixed in a weekend. The hard part isn't knowing what to do. It's knowing what to fix first.

Why Speed Actually Matters (In Hard Numbers)

Before we get into the causes, here's why this is worth your time. Sites that load in one second have a 7% bounce rate. Sites that take three seconds sit at 11%. At five seconds, 38% of visitors leave before they see anything. Every additional second of load time between zero and five seconds reduces conversion rates by roughly 4.4%.

That's not theory. Those are measured outcomes across thousands of sites.

Google factors speed into search rankings through Core Web Vitals. Your Largest Contentful Paint needs to come in under 2.5 seconds, your Interaction to Next Paint under 200 milliseconds, and your Cumulative Layout Shift under 0.1 to pass. Sites that hit all three thresholds see measurably better visibility in search results. Sites that fail them get quietly pushed down.

And here's the part most business owners miss: 82% of consumers say slow page speeds affect their purchasing decisions. A slow website doesn't just hurt your search ranking. It actively drives away people who were ready to spend money.

A one-second improvement in load time can increase mobile conversions by 3%. That single second might be worth more to your business than your last three months of social media posts combined.

The Actual Causes, Ranked by How Often We See Them

We've grouped these from most common to least common. If you're guessing where your problem is, start at the top.

1. Uncompressed and oversized images

This is the number one offender. Not sometimes. Almost always.

The typical culprit: a 4000x3000 JPEG uploaded directly from a camera or stock photo site, weighing 3-5MB, displayed at 800 pixels wide in a content area. The browser downloads the full file, then scales it down for display. Your visitor's phone just downloaded a poster-sized image to show a thumbnail.

We audited a Calgary professional services firm last fall whose homepage loaded 14MB of images. Your homepage is often the heaviest page on your site and the one visitors judge first—we break down what makes a homepage actually work in a separate guide. Fourteen megabytes. The hero image alone was 4.2MB. After converting everything to WebP and sizing images to their actual display dimensions, the page dropped to 1.1MB. Load time went from 7.8 seconds to 2.1 seconds. No other changes.

What to do about it:

Convert your images to WebP format. WebP files are 25-34% smaller than equivalent JPEGs with no visible quality loss. If your audience includes very modern browsers, AVIF format saves even more, roughly 50% over JPEG. The free tool Squoosh (squoosh.app) lets you convert and compress images one at a time in your browser. For batch processing, tools like ShortPixel or Imagify handle entire media libraries.

Resize images to their actual display size. If an image displays at 800 pixels wide, don't upload a 3000-pixel-wide file. Export at 1600 pixels wide (2x for retina screens) and call it done.

Add width and height attributes to every <img> tag. This tells the browser how much space to reserve before the image loads, preventing the layout from jumping around as images appear. That fixes Cumulative Layout Shift problems at the same time.

Use loading="lazy" on every image below the fold. This tells the browser not to download images the visitor can't see yet. Your above-the-fold hero image should not be lazy-loaded, but everything else should be.

2. Render-blocking CSS and JavaScript

Your browser can't show anything to the visitor until it has downloaded and processed all the CSS and synchronous JavaScript in the <head> of your page. Every stylesheet and script file in the <head> that doesn't have a defer or async attribute blocks rendering entirely.

On a typical WordPress site with a page builder like Elementor or Divi, the <head> might reference six to ten separate stylesheets and three to five JavaScript files. The browser has to download, parse, and execute every single one before it paints a pixel. On a mobile connection, that can add two to four seconds of blank screen before the visitor sees anything at all.

What to do about it:

Move non-critical CSS out of the <head> and load it asynchronously. Critical CSS (the styles needed to render what's visible on first load) should stay inline or in the <head>. Everything else can wait. Plugins like WP Rocket and Autoptimize handle this for WordPress sites, though they don't always get it right without manual configuration.

Add defer to every <script> tag that doesn't need to run immediately. The defer attribute tells the browser to download the script in the background and execute it after the page has finished parsing. This alone can shave one to three seconds off your load time if you have multiple scripts blocking the page.

Audit your scripts. Do you actually need all of them? We regularly find live chat widgets, analytics scripts, A/B testing tools, and social media embeds all loading in the <head> on every page. A live chat widget that loads 400KB of JavaScript on your blog post that gets 12 visits a month is wasted bandwidth.

3. Too many plugins (WordPress-specific, but the principle applies everywhere)

The average WordPress site runs 20-30 active plugins. Some of the sites we audit have 45 or more. Each plugin can add its own CSS and JavaScript files, its own database queries, and its own HTTP requests. Even plugins that aren't doing anything visible on a given page still load their assets globally unless they're coded to conditionally load.

But here's our strong opinion on this: the number of plugins matters less than the quality. We've seen WordPress sites running 35 well-coded plugins that load in under two seconds. And we've seen sites with eight terrible plugins that take nine seconds. Five poorly written plugins can do more damage than 30 good ones.

The worst offenders are usually "all-in-one" plugins that try to do everything: SEO, caching, image compression, security, and performance monitoring in a single bloated package. They load code for features you're not even using. Slider plugins are another common performance drain. Revolution Slider, for example, loads its entire JavaScript library on every page whether that page has a slider or not.

What to do about it:

Deactivate plugins you're not using. Then delete them. Deactivated plugins still sit in your file system and still represent a security risk, even if they're not loading on the front end.

For the plugins you keep, check whether they load assets globally. Query Monitor (a free WordPress plugin, ironically) shows you exactly which scripts and styles load on each page and which plugin is responsible. If a contact form plugin loads its CSS and JavaScript on your About page, something's wrong.

Replace bloated plugins with lighter alternatives. If you're using a 2MB slider plugin to display a single hero image, you don't need a slider. You need an <img> tag.

4. Cheap hosting with slow server response times

This is the cause people jump to first and fix last. We get it. "Just upgrade your hosting" sounds like an easy answer. But hosting is a real factor, and we're tired of watching businesses waste money on $4/month hosting plans that sabotage everything else they've done right.

Your server's Time to First Byte (TTFB) measures how long it takes the server to start sending data back to the browser after it receives a request. Google considers under 800ms acceptable for TTFB, but on good hosting you should be under 400ms. On a $4/month shared hosting plan where your site shares a server with 500 other sites, TTFB can hit 1.5 to 2 seconds before the browser even begins downloading your page.

Premium hosts outperform cheap shared hosting by 300-700ms on dynamic pages. For a WordPress site that runs PHP and queries a database on every request, that difference is massive. We've written in detail about what cheap hosting actually costs you and why it's almost never the bargain it looks like.

The honest truth: if you've compressed your images, deferred your scripts, and removed the bloat, and your site is still slow, the hosting is probably your bottleneck. On the other hand, upgrading to $50/month hosting won't fix a 14MB homepage. Fix the page first. Then see if the hosting is still the problem.

What to do about it:

Test your TTFB. Open Chrome DevTools (F12), go to the Network tab, reload the page, click the first document request, and look at "Waiting (TTFB)" in the timing breakdown. If it's consistently over 600ms, your server is slow.

If you're on shared hosting and your TTFB is poor, consider managed WordPress hosting from providers like Cloudways, Kinsta, or SiteGround's GrowBig plan. The jump from $4/month to $25-40/month often cuts load times in half, and the reduction in headaches is worth far more than the dollar difference.

Make sure your hosting runs a current version of PHP. PHP 8.2 and 8.3 are dramatically faster than PHP 7.4 for WordPress sites. Many shared hosts still default to older PHP versions. Switching this in cPanel takes two minutes and costs nothing.

5. No caching and no CDN

If your server generates every page from scratch for every visitor, you're wasting processing power on work that's already been done. A blog post that hasn't changed in six months doesn't need to run 40 database queries every time someone reads it.

Server-side caching stores the fully rendered HTML page so the next visitor gets the pre-built version instead of waiting for the server to assemble it again. On a WordPress site, this can reduce server response time by 80% or more for cached pages.

A content delivery network (CDN) takes this further by serving your static files (images, CSS, JavaScript) from servers physically closer to your visitors. If your hosting is in Toronto and a visitor in Calgary requests your site, a CDN serves the static assets from a Calgary or Vancouver edge server instead of making the request travel across the country.

What to do about it:

Set up a CDN. Cloudflare's free tier is genuinely good and takes about 15 minutes to configure. It caches static assets, provides DDoS protection, and often improves TTFB on its own.

Install a caching plugin if you're on WordPress. WP Super Cache is free and simple. WP Rocket is paid but handles caching, script deferral, and lazy loading in one plugin that doesn't bloat the way most "all-in-one" tools do. Avoid stacking multiple caching plugins. Two caching plugins fighting each other is worse than no caching at all.

How to Test Your Site Right Now

You don't need to guess. These tools are free and take less than five minutes.

PageSpeed Insights (pagespeed.web.dev) gives you both lab data (a simulated test) and field data (real user measurements). The field data is what Google uses for rankings. Run it on mobile. That's where most of your visitors are, and that's where slow sites suffer the most.

GTmetrix (gtmetrix.com) provides a waterfall chart that shows exactly what loaded, in what order, and how long each resource took. The waterfall is the single most useful diagnostic tool for slow sites. You can see at a glance whether your problem is images, scripts, fonts, or server response time.

Both tools will give you a prioritised list of what to fix. Start with the red items and work your way down. Don't try to fix everything at once. The first three fixes almost always account for 80% of the improvement.

The Quick Wins That Actually Work

After auditing hundreds of sites, here's what we'd do if we had one afternoon to make a slow site faster.

First hour: run every image through Squoosh or ShortPixel. Convert to WebP, resize to display dimensions, aim for under 200KB per image. This fixes the single biggest problem on most sites.

Second hour: defer non-critical JavaScript. Add loading="lazy" to below-the-fold images. Remove any plugins or scripts you're not actively using.

Third hour: test TTFB. If it's over 600ms, enable server-side caching. If caching doesn't bring it under 400ms, your hosting is the bottleneck and no amount of front-end work will fully fix it.

That afternoon of work regularly turns a PageSpeed score of 30-40 into a score of 75-90. We've seen it happen on dozens of client sites. The fixes aren't complicated. They just need to be done in the right order.

If your site needs more than an afternoon and you want someone to handle it properly, that's what our performance and speed work is for.

Sources

1. HTTP Archive — Page Weight Report 2025: https://httparchive.org/reports/page-weight
2. HTTP Archive — 2025 Web Almanac, Page Weight Chapter: https://almanac.httparchive.org/en/2025/page-weight
3. web.dev — Understanding the Critical Rendering Path: https://web.dev/learn/performance/understanding-the-critical-path
4. web.dev — Optimize Largest Contentful Paint: https://web.dev/articles/optimize-lcp
5. Google Search Central — Core Web Vitals and Search: https://developers.google.com/search/docs/appearance/core-web-vitals
6. Chrome for Developers — Render-Blocking Requests: https://developer.chrome.com/docs/performance/insights/render-blocking
7. Smashing Magazine — Using Modern Image Formats (AVIF and WebP): https://www.smashingmagazine.com/2021/09/modern-image-formats-avif-webp/
8. Kinsta — How to Reduce TTFB: https://kinsta.com/blog/ttfb/