Why is my website so slow: the fixable problems slowing your site down

A slow website loses you visitors, conversions, and search rankings. Most slow sites run into the same issues, and you can usually fix them without rebuilding from scratch.

The fixes range from quick server tweaks to bigger decisions on how you build and host your site. Oversized images and missing compression are cheap to sort out. Tougher problems, like how your site handles JavaScript, take more work and budget, so teams put them off even though the payoff grows over time.

This guide lists the technical reasons sites drag, in the order we see them most often during client audits. You'll get the real cause and what to do about each one.

1) Unoptimised hero images (5000×3000 JPEGs served at full size)

The hero image at the top of your homepage is probably a 5MB file that could be 200KB. We see this on about 70% of sites with speed issues.

Hero images average 1 to 2 MB on most sites, making them the biggest thing most visitors download. A 5000×3000 pixel JPEG saved at max quality looks sharp zoomed in, but nobody browses at 5000 pixels wide. Most screens are closer to 1920 pixels, and phones are much smaller.

If you upload a 15-megapixel photo straight from the photographer, your server sends the entire file to every visitor. Their browser downloads it, decodes it, and scales it down just to fit the actual layout. That burns bandwidth and processor time for no good reason.

Images make up about half the average web page's weight, and a single hero image can outweigh the rest of the site. We rebuilt a property developer's homepage last year and shrunk their hero image from 4.2MB to 180KB. Load time dropped from 8.3 seconds to 2.1 seconds on 4G.

The fix has three steps. First, resize the image to match how it's actually displayed. Then compress it using modern formats like WebP. Finally, serve different sizes to different devices.

You can also preload critical images and set fetch priority so they load sooner. Most content management systems handle this if you set them up right. If yours doesn't, it's worth sorting out separately.

2) Excessive third-party scripts (analytics, chat widgets, ad tags)

Most sites load between 15 and 30 external scripts from different services. Each one adds a bit more drag.

Third-party scripts are bits of code from outside sources. They add things like Google Analytics, Facebook pixels, chat boxes, ad networks, and social buttons. Most sites pick these up over time, one after another.

The problem is, these scripts fight for bandwidth and processing power. Your browser has to grab them, read them, and run them before the page can finish loading. Some scripts even load more scripts, and those load more still.

We audited a property site last year and found 23 third-party scripts loading on every page. Dropping eight unused ones cut page load time by 1.8 seconds. The marketing team didn't realise half of them were still running.

Chat widgets are especially heavy. They often load entire apps just to show a button. Some analytics tools fire multiple times on the same page.

The fix starts with an audit. List every script your site loads. Ask if you actually use the feature or data. Managing third-party scripts means choosing what stays and what goes.

You can also delay non-essential scripts until after the page loads. For example, load your chat widget after someone's been on the page for five seconds. They won't notice, and your initial load time drops.

3) Render-blocking CSS and large CSS frameworks loaded site-wide

CSS files block your page from showing anything until the browser has downloaded and processed them. CSS is a render-blocking resource because browsers prevent a flash of unstyled content by waiting to display anything.

The issue gets worse if you load an entire framework like Bootstrap or Foundation on every page. Visitors end up downloading 150KB of CSS rules for features they'll never use on a simple blog post.

We audited a property site that loaded the full Tailwind CSS bundle on every listing page. Each visitor pulled down 280KB of CSS before seeing a single property photo. After extracting only the classes in use and inlining critical styles, we got that down to 18KB. Page speed improved by 1.8 seconds on mobile.

The fix is to identify which styles are actually needed for above-the-fold content, then eliminate render-blocking requests for the rest. Inline critical CSS in the HTML head and defer the rest until after the first paint.

Most teams stick with the easy route of dropping in a CDN link and moving on. The alternative takes build tools, critical CSS extraction, and maintenance as your design changes. That costs more upfront.

The payoff comes in the numbers. First Contentful Paint drops by seconds. Bounce rates fall because visitors see styled content sooner. For mobile, render-blocking resources often cause headaches for both users and search engines.

4) Heavy JavaScript bundles from single-page-app frameworks

Single-page applications built with React, Vue, or Angular ship hundreds of kilobytes of JavaScript before users see anything. That JavaScript has to download, parse, and run before the page becomes interactive.

On a slow 3G connection, the size of your bundle can mean 5.7 seconds versus 7 seconds just for the download. Then the browser still needs to process all that code.

We rebuilt the Household Cavalry Museum site without a JavaScript framework. The old React version shipped 312KB of compressed JavaScript. The new site uses 8KB for progressive enhancements. Page speed jumped from 42 to 94 on mobile, and the museum saw a 47% increase in ticket sales within three months.

Most teams pick a framework by default, without checking if they need it. You end up with polyfills, icon libraries, and CSS-in-JS solutions that each add weight. It adds up quickly.

The fix is either aggressive optimisation or questioning if you need a framework at all. Code-splitting loads only what's needed for each page. Tree-shaking removes unused code from your bundles.

For brochure sites and content-heavy projects, server-rendered HTML with minimal JavaScript usually runs faster and is easier to maintain. Users on slower devices and patchy connections notice the difference right away.

5) No browser caching or short cache lifetimes on static assets

Your images, stylesheets, JavaScript files, and fonts rarely change. Most stay the same for weeks or months. If you haven't set proper cache headers, every visitor downloads them fresh every time.

Google expects static assets to have a cache expiry of at least 30 days. Many sites have no cache headers, or they're set to expire after a few hours. One client came to us with all their assets expiring after 60 seconds, so returning visitors saw no speed boost at all.

When browsers cache static resources properly, someone going from your pricing page to your contact page doesn't re-download your logo, stylesheet, or fonts. The browser already has them. For the Household Cavalry Museum site, proper caching cut repeat page load times by about 40%.

The fix is to set Cache-Control headers on your server. On Apache or Nginx, this lives in your server config. On WordPress, caching plugins handle it. The change itself takes about ten minutes.

The trick is versioning. If you cache assets for a year, you need a way to change the filename or add a version number when you update a file. Otherwise, visitors keep seeing the old version. Most modern build tools and WordPress themes handle this for you.

6) Slow origin server response, high TTFB from cheap shared hosting

Your server has to process each request before sending anything back to the browser. That delay is Time to First Byte, or TTFB. Google says it should stay under 200 milliseconds.

Shared hosting usually delivers TTFB over 800ms. That’s four times slower than the target, and nothing appears on screen until it’s done.

Resource sharing is the culprit. Your site sits on a server with dozens or even hundreds of others. If another site gets a traffic spike or runs something heavy, your site slows too. You share CPU, memory, and disk access with strangers running who-knows-what.

We moved a property client from a £4/month shared plan to managed hosting with LiteSpeed and built-in caching. TTFB dropped from 920ms to 180ms. Page load times sped up by 2.3 seconds. Their mobile search rankings started climbing in about three weeks.

High TTFB often comes from slow hosting, inefficient code, long database queries, or missing cache. On shared hosting, the hosting is almost always the main issue.

Caching can help. If you’re stuck on shared hosting for now, enable server-side caching. Some hosts offer LiteSpeed with LSCache, which beats standard Apache setups.

The real fix is moving to hosting with dedicated resources. Managed WordPress hosting, VPS, or cloud hosting all give you more control and steadier performance. The price jumps to £15 to £50 per month. That’s a leap from shared hosting, but the speed difference is obvious straight away.

7) No CDN for global visitors, large geographic latency

Your website loads in under a second when you test it from your office. Then someone from Singapore emails to say the homepage took nine seconds.

You check from Sydney. Same story.

Distance is the problem. If your server’s in London and someone visits from Asia, the data travels thousands of miles. Every roundtrip between browser and server adds delay.

Testing from different global locations usually shows the scale of it. A site that loads in 800 milliseconds locally might take six or seven seconds from the other side of the world.

A Content Delivery Network copies your files to servers worldwide. When someone visits, they get files from the closest server. The distance shrinks, so the wait does too.

There’s more at stake than just slow page loads. Search engines factor in speed from different locations. If your site’s fast in the UK but slow in Asia, you’ll struggle to rank there.

E-commerce clients see this when their conversion rate drops for international traffic. Visitors abandon pages that crawl. Users worldwide deal with higher latency and longer waits if the server’s far away.

CDNs aren’t pricey for most sites. Basic plans start at around £10 a month. If your site’s built sensibly, setup takes a few hours.

8) Uncompressed assets, no Gzip or Brotli enabled on server

Your web server sends files to browsers every time someone visits. If those files aren’t compressed, you’re sending way more data than needed.

Most servers can compress files before sending them. The main methods are Gzip and Brotli. Brotli and Gzip both have about 40% adoption, with Brotli a bit ahead.

When a browser requests your site, it tells the server what compression methods it supports using the Accept-Encoding header. The server picks a supported method and sends compressed files with a Content-Encoding header showing which one it used.

Brotli usually compresses better than Gzip, so files are smaller. Chrome supports Brotli, while older browsers fall back to Gzip. Some servers decompress Brotli and re-compress as Gzip for browsers that don’t understand Brotli.

You’ll spot the problem when you run a site audit or test your compression settings. Your HTML, CSS, and JavaScript are sent full size. A 500KB stylesheet stays 500KB instead of maybe 100KB compressed.

Cloudflare supports Brotli, Gzip, or no compression when pulling content from your origin. If you use a CDN or managed host, check if compression is already switched on in your settings.

9) Too many HTTP requests from uncombined assets and fonts

Each file your website loads means a separate HTTP request. The browser asks the server for every CSS file, JavaScript file, font, and image.

Most browsers allow about six parallel requests at once. If your page needs 80 files to render, that’s at least 13 round trips before anything shows up.

Web fonts are the main culprit here. A site loads four weights of one typeface and three of another. That’s seven font files before a single word appears. Add in lots of CSS, JavaScript libraries, and icon sets as separate SVGs, and you can end up with 100+ requests for one page.

The fix is simple. Combine CSS into one or two files. Do the same for JavaScript. Only load the font weights you actually use.

One client’s homepage had 143 requests. We combined their CSS, switched to a variable font that loaded as a single file, and inlined critical styles. Requests dropped to 34. First contentful paint sped up by 2.1 seconds.

Reducing HTTP requests matters even more on mobile, where latency’s higher. Each request adds overhead that stacks up fast.

You can check your request count in Chrome DevTools under Network. If you’re over 50, it’s time to tidy up.

10) Unoptimised web fonts, multiple weights and character sets

Web fonts look great, but they slow things down. Every font file your browser downloads adds to load time.

This gets worse when designers specify lots of weights and styles. A setup might include regular, bold, italic, and bold italic for two typefaces. That’s eight font files before anything’s rendered. Each one needs a request, download, and render.

Many teams load full character sets when they just need basic Latin. A full Google Font might include Cyrillic, Greek, and Vietnamese you’ll never use. Variable fonts can shrink file sizes by packing multiple weights into one file.

Font files can also trigger layout shifts. Text renders in a fallback font first, then jumps when the web font loads. This messes with your Core Web Vitals and makes the page feel jumpy.

We saw this with a property client loading four weights of two custom fonts. The fonts alone added 400ms to mobile load time. We cut it to two weights of one typeface and subset the character range. Load time dropped by 280ms.

Poorly optimised fonts slow pages and create visual instability, especially on mobile. Audit what you’re actually using, subset character ranges, and use modern formats like WOFF2. Most sites do fine with two weights of one typeface if you keep it tight.

Underlying causes and long-term fixes

Server response time and technical debt build up the kind of slow performance you can’t fix with image compression alone.

Why server response times matter more than you think

Your server’s response time is how long it takes before anything starts loading. Users see a blank screen until then.

If your server takes 2 seconds to respond, that’s 2 seconds before any image, font, or text starts to appear. Only after that does the rest of the page load.

Shared hosting plans struggle when traffic jumps or the database gets big. A server that handles 500 visitors per day can fall apart at 5,000. The slowdown is longer response times, so every visitor waits longer no matter their internet speed or device.

Upgrading to better hosting usually costs £30 to £200 per month, depending on your traffic and technical needs. That’s the visible cost teams push back on, even though slow websites frustrate users and lose business.

Technical debt from years of legacy plugin bloat

WordPress sites pick up plugins over the years. Each seemed like a good idea at the time.

The membership plugin from 2019 still loads its JavaScript on every page. You only need it on the login page.

The popup builder you tested for two weeks never got fully removed. The old page builder still loads CSS files because uninstalling it left things behind.

Some sites end up running 40 or more plugins. Unoptimised code and excessive scripts stack up, creating hundreds of HTTP requests per page.

Every request adds time. The site gets slower, bit by bit.

Sorting this out means figuring out which plugins you actually need. Some features work better with lighter alternatives.

Someone has to know the codebase well enough not to break things. It's unglamorous, slow work—10 to 20 hours for a typical site.

How slow sites impact real users and revenue

If your site lags by a second, conversions drop by 7%. Users leave if it feels slow.

We've seen what happens when you fix it, and the difference is obvious.

What we learned from Southampton Athletic Club's mobile signups

Southampton Athletic Club wanted members to sign up online instead of showing up at the track with cash. The old site crawled on mobile, and forms timed out halfway through.

We rebuilt the site with performance at the top of the list. Page weight dropped from 4.2MB to under 800KB.

Forms loaded in less than two seconds on a 3G connection. Mobile signups jumped from 12% of new memberships to 68% in three months.

The club stopped losing people halfway through the form. Session times grew because people could actually browse fixture lists and training schedules without waiting for images.

The committee tracked a 40% increase in membership enquiries in the first six months. Faster pages meant more people finished what they started.

Case study: Purpose Homes tripled organic leads after prioritising page speed

Purpose Homes ran a property development site that ranked well but struggled to convert. Google Search Console showed plenty of impressions, but bounce rate hovered at 73%.

Website speed matters for SEO and conversions, and their site took over six seconds to load on mobile. That’s a long wait when you’re just trying to see a few photos.

We cut JavaScript bundles and finally lazy-loaded images the right way. Then we moved everything to faster hosting.

Load time dropped to 1.8 seconds. Core Web Vitals went from failing all three metrics to passing across the board.

Organic traffic climbed by 34% over four months. More people started filling in contact forms and asking for brochures.

A one-second delay can reduce conversions by 7%. Purpose Homes had been losing five seconds, so the difference felt huge on their end.