The Short Answer: It’s Almost Never Just One Thing
Your website is slow because multiple small decisions have compounded into a significant performance problem. It might be your hosting, your images, your theme, your plugins, your third-party scripts, or the way your CMS was configured. Most likely, it’s several of these working together. The good news is that once you understand what’s actually causing the slowdown, most fixes are straightforward and the performance gains can be dramatic.
What we see on most mid-market sites is a pattern: the site was reasonably fast when it launched, then gradually slowed down as content was added, plugins were installed, marketing tags were layered on, and nobody was watching the performance impact of each change. By the time someone notices the problem, the site might be taking 5-8 seconds to load, bounce rates are climbing, and Google’s Core Web Vitals scores have turned red. The path to fixing it starts with understanding where the time is actually going.
How to Diagnose What’s Making Your Site Slow
Before you fix anything, you need to measure. Guessing at performance problems wastes time and money because you end up optimising things that don’t matter while ignoring the real bottlenecks.
Start with Google PageSpeed Insights (pagespeed.web.dev). Enter your homepage URL and your most important landing pages. This tool gives you two things: lab data, which is a simulated test of your page under controlled conditions, and field data, which is real performance data from actual Chrome users visiting your site over the past 28 days. Field data matters more because it reflects what your visitors actually experience, but lab data is useful for identifying specific issues.
Pay particular attention to the three Core Web Vitals metrics: Largest Contentful Paint (LCP), which measures how quickly the main content appears; Interaction to Next Paint (INP), which measures responsiveness when someone clicks or taps; and Cumulative Layout Shift (CLS), which measures visual stability. If any of these are in the red or amber zones, Google is telling you that your visitors are having a poor experience, and it’s likely affecting your search rankings too.
Beyond PageSpeed Insights, run your site through WebPageTest.org for a more detailed breakdown. This tool shows you a waterfall chart of every single request your page makes, in the order they happen. That waterfall is where you’ll spot the real culprits: oversized images, render-blocking scripts, slow server responses, and third-party resources that take longer than your own site to load.
The Most Common Reasons Websites Are Slow
After auditing hundreds of sites, we’ve found that the same handful of issues account for the vast majority of slowdowns. Here they are, roughly in order of how frequently we encounter them.
Cheap or Misconfigured Hosting
Your server response time sets the floor for how fast your site can possibly be. If your server takes 1.5 seconds just to start sending the page, nothing else you do will get your total load time under that. We regularly see mid-market B2B sites sitting on shared hosting plans that cost £10-20 per month, sharing resources with hundreds of other sites on the same server. During peak traffic, these servers slow to a crawl.
Check your Time to First Byte (TTFB) in WebPageTest or PageSpeed Insights. If it’s consistently above 600ms, your hosting is likely part of the problem. For a WordPress site serving UK and European visitors, a well-configured server should deliver TTFB under 300ms. For a static or headless site, under 100ms is realistic.
The fix isn’t necessarily expensive. Moving from a budget shared host to a quality managed hosting provider with proper server-level caching, HTTP/2 or HTTP/3 support, and a nearby data centre typically costs £30-100 per month for a mid-market site. That investment often delivers more measurable speed improvement than any amount of front-end optimisation.
Unoptimised Images
This is the single most common performance problem we find. Images frequently account for 60-80% of a page’s total weight, and most sites serve them at far larger dimensions and far lower compression than necessary.
Typical mistakes include uploading images straight from a camera or stock library at 4000×3000 pixels when they’re displayed at 800×600, using PNG format for photographs instead of JPEG or WebP, and failing to implement responsive images so that mobile users download the same enormous files as desktop users.
A single hero image uploaded as an uncompressed PNG can weigh 3-5MB. Convert that to WebP format at appropriate dimensions with sensible compression, and it drops to 80-150KB with no visible quality loss. Multiply that saving across every image on the page and you’ve often just cut your page weight by 70% or more.
The practical fix involves several layers. First, resize images to the maximum display size before uploading. Second, serve modern formats like WebP or AVIF, with JPEG fallbacks for older browsers. Third, implement responsive images using srcset attributes so the browser downloads only the size it needs. Fourth, lazy-load images below the fold so they don’t block the initial page render. Most modern CMS platforms support all of this either natively or through well-maintained plugins.
Too Many Plugins or Poorly Built Plugins
If you’re running WordPress, this one deserves close attention. It’s not the raw number of plugins that matters; it’s what those plugins do. We’ve seen sites with 40 lightweight plugins that run perfectly well, and sites with 12 plugins that grind to a halt because three of them load heavy JavaScript and CSS on every page regardless of whether they’re needed.
The worst offenders are typically page builders, social media feed widgets, chat tools, and “all-in-one” SEO or security plugins that bundle far more functionality than you actually use. Each plugin can add its own CSS files, JavaScript files, font requests, and database queries. When five or six plugins all do this, you end up with 15-20 extra HTTP requests and hundreds of kilobytes of code that the browser has to download, parse, and execute before your page becomes interactive.
The fix starts with an honest audit. Deactivate plugins one at a time and measure the impact on load speed. You’ll often find that two or three plugins are responsible for most of the slowdown. Replace them with lighter alternatives, or if the plugin’s functionality is only needed on specific pages, configure it to load only where it’s actually used. A skilled developer can do this with conditional loading in a few hours.
Render-Blocking JavaScript and CSS
When a browser starts loading your page, it reads the HTML from top to bottom. Every time it encounters a CSS file or JavaScript file in the head of the document, it stops rendering the page and waits for that file to download and process. This is called render blocking, and it’s one of the biggest contributors to slow LCP scores.
A typical WordPress site might load 6-10 CSS files and 8-12 JavaScript files, many of them added by themes and plugins you didn’t even realise were loading assets. The browser has to fetch all of them before it can paint anything meaningful on screen.
The solution involves a few techniques used together. Critical CSS extracts the styles needed to render the visible portion of the page and inlines them directly in the HTML, allowing the rest of the CSS to load asynchronously. JavaScript deferral moves non-essential scripts to load after the page has rendered, so they don’t block the initial paint. File concatenation and minification combine multiple small files into fewer requests and strip out unnecessary whitespace and comments. Done well, these changes can cut perceived load time in half.
Third-Party Scripts and Marketing Tags
This is the problem that creeps up on you. Your marketing team adds Google Analytics. Then Google Tag Manager. Then a Facebook pixel. Then a LinkedIn Insight Tag. Then Hotjar for heatmaps. Then a live chat widget. Then a cookie consent banner. Then an A/B testing tool. Each one seems harmless in isolation, but collectively they can add 1-3 seconds of load time and make your INP scores terrible because they compete for the browser’s main thread.
We recently audited a B2B SaaS company’s site that had 23 third-party scripts loading on every page. Their own site content loaded in under a second; the third-party scripts took another 4 seconds. Their Google Analytics showed an 8-second average page load time, and they’d been blaming their CMS and hosting when the real problem was entirely in their tag management.
The fix requires discipline. Audit every third-party script and ask whether it’s still being used and providing value. Remove anything that’s abandoned or redundant. For the scripts you keep, load them via Google Tag Manager with trigger conditions so they only fire on pages where they’re needed. Set chat widgets to load on interaction rather than on page load. Use the async or defer attributes on every script tag that will tolerate it. This alone can dramatically improve both LCP and INP.
No Caching Strategy
Caching means storing a pre-built version of your page so the server doesn’t have to rebuild it from scratch for every visitor. Without caching, a WordPress site runs dozens of PHP processes and database queries every time someone loads a page. With page caching enabled, that entire process is skipped and the server simply delivers a static HTML file, which is orders of magnitude faster.
There are several layers of caching that should be working together. Page caching stores the full HTML output. Object caching (using Redis or Memcached) stores database query results in memory. Browser caching sets headers telling the visitor’s browser to store static assets locally so they don’t need to be re-downloaded on subsequent page views. CDN caching distributes copies of your content across servers worldwide, so visitors get served from a location physically close to them.
If you’re running WordPress and don’t have a page caching plugin active, implementing one is likely the single fastest win available to you. The difference between a cached and uncached WordPress page is often 500ms-2 seconds of server response time.
Bloated Theme or Page Builder
Many WordPress themes ship with enormous CSS files and JavaScript libraries to support every possible design option, even if your site only uses a fraction of them. A premium theme might load 300-500KB of CSS, of which your specific pages use 30-50KB. The rest is dead weight.
Page builders compound this issue. They generate deeply nested HTML markup, inline styles, and their own JavaScript framework on top of whatever your theme already loads. A page that a developer could build in 20KB of clean HTML and CSS might weigh 200KB when built with a page builder. That difference matters, especially on mobile connections where bandwidth is constrained and CPU processing power is limited.
If you’re planning a redesign, this is the right time to evaluate whether your theme and page builder choices are compatible with your performance goals. Our team typically recommends choosing a lightweight theme framework and building only the components you actually need, rather than starting with an everything-included theme and trying to strip it back later. You can read more about this approach in our performance architecture guide, which covers how to make these structural decisions before they become expensive to reverse.
A Practical Fix-It Sequence
If you’re looking at multiple problems and wondering where to start, here’s the order we typically recommend for mid-market sites. This sequence is designed to deliver the biggest improvements first with the least risk of breaking anything.
- Measure your current baseline. Run PageSpeed Insights and WebPageTest on your five most important pages. Record the scores and key metrics so you can track improvement.
- Fix your hosting and caching. If TTFB is above 600ms, address server performance first. Enable page caching, object caching, and proper browser cache headers.
- Optimise images. Convert to WebP, resize to appropriate dimensions, implement lazy loading below the fold, and ensure responsive image markup is in place.
- Audit and remove unnecessary plugins and scripts. Strip out anything that’s not actively providing value. Defer or async-load everything that remains.
- Address render-blocking resources. Inline critical CSS, defer non-critical CSS and JavaScript, and minify all remaining assets.
- Implement a CDN. If your audience is geographically distributed, a CDN will significantly reduce latency for visitors far from your server.
- Re-measure and iterate. Test the same pages again. Compare to your baseline. Identify anything still underperforming and dig deeper into those specific issues.
Steps 1 through 3 typically deliver 60-70% of the total improvement on most sites. Don’t skip straight to the advanced optimisations before handling the fundamentals.
Why Speed Keeps Getting Worse After Launch
Even after you fix everything, performance degrades over time if nobody is watching it. This happens because websites are living systems. Content editors upload images without compressing them. Marketing installs new tracking scripts. A plugin auto-updates and introduces a performance regression. Someone adds a video embed that loads 2MB of JavaScript from YouTube on every page, not just the page with the video.
The sites that stay fast are the ones with performance budgets. A performance budget is a simple set of rules: the page weight must not exceed 1.5MB, the total number of requests must stay under 40, LCP must remain under 2.5 seconds, and so on. When someone proposes a change that would breach the budget, it triggers a conversation about whether the change is worth the trade-off and whether there’s a faster way to achieve the same goal.
In our projects, we set these budgets before design begins and build them into the monitoring that runs after launch. Automated tools like SpeedCurve or Calibre can test your pages on a schedule and alert you when metrics start drifting. This turns performance from a one-off fix into an ongoing practice, which is the only way to keep a site genuinely fast over months and years.
When Patching Isn’t Enough
Sometimes the honest answer is that your current site can’t be made fast enough without a more fundamental rebuild. This is usually the case when the slowness is baked into the architecture itself: a heavyweight page builder generating bloated markup on every page, a hosting platform with no caching layer, a CMS that makes database calls that can’t be optimised away, or a theme so deeply intertwined with the site’s content that replacing it would mean rebuilding every page anyway.
If you’ve worked through the fix-it sequence above and you’re still not hitting acceptable performance targets, the performance problem is likely structural. Patching a structurally slow site is like putting better tyres on a car with a failing engine. You’ll see marginal improvements, but you’ll never reach the level of performance that your competitors achieve with well-architected sites.
The key distinction is between sites that are slow because of accumulated neglect (which can almost always be fixed) and sites that are slow by design (which need to be rebuilt with performance as a foundational requirement, not an afterthought). Knowing which category your site falls into saves you from spending months optimising something that needs replacing.
What to Do Right Now
Open PageSpeed Insights, test your homepage and your top three landing pages, and write down the LCP, INP, and CLS numbers. Look at the opportunities and diagnostics sections for the specific issues flagged on your site. Cross-reference what you find with the common problems described above, and you’ll have a clear picture of where your time and budget should go first. Performance improvements of 40-60% are achievable on most mid-market sites within a few weeks of focused work, often without touching your site’s design or content at all. The speed is there to be found; you just have to know where to look.
