Skip to content
All articlesWordPress

Your WordPress site was fast when it launched. Here is what made it slow

Umar Farooq20 October 20269 min read

A professional services firm in Leeds asked me why their website had become so slow. At launch, two years earlier, it had loaded in under two seconds. On a mid-range phone on 4G it was now taking around nine, and their bounce rate on paid traffic had quietly climbed all year.

Nobody had done anything wrong. The marketing manager had added a popup tool. Someone else had installed a chat widget. A contractor had added a slider on the homepage. The SEO consultant had installed a second SEO plugin without removing the first. A tracking plugin went on for a campaign that ended fourteen months ago and was never removed. Thirty-eight active plugins, each one a reasonable decision at the time.

This is how almost every WordPress site gets slow. Not one catastrophic mistake, but twenty small ones compounding, with nobody whose job it is to notice.

Measure before you touch anything

Do not start installing optimisation plugins. That is how sites end up with three caching plugins fighting each other.

Run the homepage and one key landing page through PageSpeed Insights on the mobile setting, and look at two things. First, the field data at the top, which is real Chrome user data and is the only version Google uses for ranking signals. Second, the lab diagnostics below, which tell you what to fix.

The numbers that matter in 2026 are Largest Contentful Paint, which should be under 2.5 seconds, and Interaction to Next Paint, which should be under 200 milliseconds. INP is the one most WordPress sites now fail, and it is almost always caused by JavaScript from plugins blocking the main thread while the user is trying to tap something.

Then open the browser developer tools, go to the Network tab, and reload with the cache disabled. Sort by size. You will usually find the problem within thirty seconds.

The five things that are usually responsible

Images that were never resized. The most common single issue, and the easiest to fix. Someone uploads a 4,000-pixel photograph straight from a camera and WordPress displays it in a 600-pixel slot. Multiply by thirty across a page. Serve WebP, let WordPress generate responsive sizes, and lazy-load anything below the fold.

Plugins you are not using. Deactivating is not enough and neither, sometimes, is deleting: plugins frequently leave script tags, database tables and scheduled tasks behind. Go through the list honestly, remove what nobody can justify, and check the page source afterwards for orphaned scripts.

A page builder loading its entire library on every page. Elementor, Divi, WPBakery and the rest ship a large CSS and JavaScript bundle regardless of whether a page uses one widget or forty. Most offer settings to load assets conditionally or to disable unused features, and almost nobody turns them on.

Third-party scripts. Chat widgets, review badges, heatmap tools, booking embeds, and the tag manager container that has accumulated eleven tags over three years. Each one is a request to someone else's server, and your page waits. Audit the container, remove what is dead, and defer whatever does not need to run before the page is interactive.

Cheap shared hosting. At some point the server becomes the ceiling. If your time to first byte is over about 600 milliseconds and stays there after caching, no amount of front-end work will rescue you. Managed WordPress hosting costs more and solves this in an afternoon.

Fix it in this order

  1. Images: compress, resize, convert to WebP, lazy-load.
  2. Plugin audit: remove the dead, check the source for leftovers.
  3. One caching plugin, configured once. Page caching, minification, and a CDN if your audience is international.
  4. Page builder asset settings: load conditionally.
  5. Third-party scripts: delete or defer.
  6. Hosting: only after the first five, when you can prove the server is the bottleneck.

Do them one at a time and re-measure after each. If you change six things at once and the site gets faster, you have learned nothing about which change mattered, which means you cannot prevent the regression next time.

The part nobody budgets for

Speed is not a project, it is a maintenance habit. The Leeds site will be slow again in eighteen months if the same pattern continues, because the pattern is organisational, not technical.

What stops it: one person who approves plugin installations, a quarterly check of PageSpeed field data on the three pages that matter most, and a rule that any new third-party script has to replace something or justify its weight. That is maybe two hours a quarter, and it is the difference between a site that stays fast and one that needs rescuing every second year.

While you are in there, check security

The same neglect that makes a site slow makes it vulnerable. Outdated plugins are the most common WordPress attack vector by a wide margin. Turn on automatic updates for minor releases, remove abandoned plugins that have not been updated in over a year, enforce strong passwords with two-factor for admin accounts, and make sure backups run somewhere that is not the same server. None of that is sophisticated, and it is almost always what is missing.

What this is worth

The Leeds site went from about nine seconds to just under three on mobile after images, plugins and scripts were dealt with, before they spent anything on hosting. Their paid traffic bounce rate fell noticeably in the following month, which is the only reason any of this matters. Speed is not a score to improve, it is the tax every visitor pays before they see your offer.

If you are sending paid traffic to a site like this, the speed problem is also an advertising problem, because you are paying full price for visitors who leave before the page renders. I covered the same dynamic on the store side in why your Shopify store converts on desktop and dies on mobile.

If the site is due a rebuild rather than a rescue, choosing between Webflow, WordPress and a custom build is the decision to make first.

We handle this as part of our WordPress development and maintenance work. If you want to know what your site is costing you before committing to anything, the free growth audit includes a speed and technical review alongside the ad account.

Want this done on your account?

The free growth audit applies everything above to your own campaigns, and you get the findings in writing.