Why Is My WordPress Website Slow and How Do I Fix It?

A slow WordPress website is nearly always the result of a small number of fixable problems, most often the hosting, the PHP version, heavy plugins or themes, oversized images and missing caching. WordPress itself is rarely the cause and the right fix depends on measuring first and then working through the problems in order of impact. Priority Pixels provides WordPress development for UK businesses, with performance and Core Web Vitals work part of every build we deliver.

Speed matters for more than patience. Google says good Core Web Vitals align with what its core ranking systems seek to reward and a sluggish page makes every enquiry form, product page and service page harder to reach.

The Most Common Reasons a WordPress Website Is Slow

If you are asking why your WordPress site is slow, the answer usually sits in one or more of the areas below. Most slow websites have two or three of these problems at once and they tend to compound each other.

• Shared or undersized hosting that is slow to respond to every request.
• An outdated PHP version running on the server.
• Plugins that load scripts and database queries on every page.
• Multipurpose themes and page builders carrying code you never use.
• Large, uncompressed images in older formats.
• No page caching or object caching in place.
• A database bloated with revisions, transients and autoloaded options.
• Third party scripts such as chat widgets, embeds and tracking tags.
• No content delivery network for visitors further from the server.

Server response time sets the floor for everything else, so there is little point compressing images on a website whose server takes over a second to start replying. Fix the foundations first and the smaller gains become far easier to measure.

How to Measure WordPress Speed Before Changing Anything

Start with Google PageSpeed Insights, which reports how real visitors experience the page alongside a simulated lab test. Measuring first stops you spending hours fixing problems that are not there.

The two types of data answer different questions. Google’s documentation on PageSpeed Insights explains that field data comes from the Chrome User Experience Report and covers the previous 28 days. Lab data is generated by Lighthouse in a controlled environment and is more useful for debugging. Lower traffic pages often have no field data at all, so treat the lab score as a guide to where the problems are rather than a verdict on the website.

The field data is reported against the Core Web Vitals. According to web.dev’s Web Vitals guidance, a good experience means Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads. Older guides still mention First Input Delay, but Google confirmed that INP replaced FID in the Core Web Vitals in March 2024.

LCP

Largest Contentful Paint measures how long the main image or block of text takes to appear. Slow hosting, large hero images and render blocking files are the usual causes.

INP

Interaction to Next Paint measures how quickly the page responds when someone clicks, taps or types. Heavy JavaScript from themes, plugins and third party scripts is the main culprit.

CLS

Cumulative Layout Shift measures how much the page jumps around as it loads. Images without dimensions, late loading fonts and injected banners cause most of it.

TTFB

Time to First Byte measures how long the server takes to start sending the page. It is not one of the Core Web Vitals, but a slow TTFB drags every other metric down with it.

For WordPress specific detail, the free Query Monitor plugin shows database queries, PHP errors, enqueued scripts and HTTP API calls for each page, which makes it easy to see which plugin is doing the heavy lifting. The Network and Performance panels in Chrome DevTools fill in the rest. Our guide to WordPress Core Web Vitals optimisation goes further into fixing each metric.

Hosting, PHP and Server Response Time

Hosting is the foundation of WordPress speed, so a slow server response is the first thing to rule out. On shared hosting your website competes with many others for the same processor, memory and database resources and a busy neighbour can slow you down at the worst possible moment.

Time to First Byte is the clearest signal of a hosting problem. Google’s guidance on TTFB suggests most websites should aim for 0.8 seconds or less and values above 1.8 seconds are rated poor. If your TTFB is consistently high on uncached pages, image compression and minification will not close the gap. Server location plays a part too, so a UK audience is better served by a UK data centre. Our article on how your host affects page load times covers the hosting side in more depth.

The PHP version on the server matters just as much as the hardware. WordPress.org currently recommends PHP 8.3 or greater and newer PHP releases run WordPress faster than older ones. Many websites still run older versions as nobody has tested the upgrade.

You can check every branch on the official PHP supported versions page. Our guide to WordPress PHP version compatibility sets out how to upgrade without breaking older plugins.

Plugins, Themes and Page Builders

Plugin quality matters far more than plugin count. One badly written plugin can slow a website down more than twenty well built ones and the problem usually comes from code that runs on pages where it is not needed.

Typical offenders load their stylesheets and JavaScript on every page when they only do something useful on one, run database queries on every request or call external APIs that hold up the page. Removing plugins that duplicate each other, such as two form plugins or several social sharing tools, is one of the quickest wins available.

Themes cause similar problems at a larger scale. Multipurpose themes ship with sliders, animation libraries, icon sets and layouts for dozens of demo designs and that code still loads on a simple business website that uses a fraction of it. Page builders add another layer of markup, inline styles and front end scripts over the theme. Priority Pixels builds WordPress themes from scratch without page builders or templates for this reason, so every line of code on the page serves a purpose for that website.

Images, Lazy Loading and the LCP Image

Oversized images are the most common quick win on a slow WordPress website. A photo straight from a modern phone or camera can be several megabytes and serving it into a content area a few hundred pixels wide wastes bandwidth on every visit.

Resize images to the largest size they will display at, compress them and use a modern format. WordPress has supported WebP since version 5.8 and the core team’s announcement notes that WebP images are around 30% smaller on average than JPEG or PNG equivalents. WordPress creates multiple image sizes and srcset markup automatically, but some themes bypass it and serve the full size file to every device.

Lazy loading needs a light touch. WordPress adds native lazy loading to images by default and since version 6.3 core adds fetchpriority to the image most likely to be the LCP element. Themes and optimisation plugins that force lazy loading onto the hero image undo that work and push LCP back, so the main image above the fold should load straight away.

Caching and Database Bloat

Caching stops WordPress rebuilding every page from scratch for every visitor and it is usually the single biggest improvement available. Without it, each request runs PHP, queries the database and assembles the HTML before anything reaches the browser.

The WordPress Advanced Administration Handbook describes caching as the fastest way to improve performance and covers three layers. Page caching stores finished HTML, browser caching tells returning visitors to reuse files they already have and object caching keeps the results of database queries in memory using tools such as Redis or Memcached. Getting the configuration wrong causes its own problems, particularly on WooCommerce stores and membership websites where logged in users and baskets need fresh content.

The database slows things down more gradually. Years of post revisions, expired transients, spam comments and settings left behind by deleted plugins all add weight and autoloaded options are loaded on every single request. The handbook’s optimisation guide lists database tuning and autoloaded options among the areas to review. Our WordPress database optimisation guide explains how to clean up safely and a full backup should always come first.

Third Party Scripts and Content Delivery Networks

External scripts slow WordPress down more than most website owners expect, as their speed depends on servers you do not control. Analytics tags, chat widgets, video embeds, review badges and advertising pixels each add requests and JavaScript that compete with your own content.

Filter the Network panel in Chrome DevTools by third party domains and you will often find tracking code for tools the business stopped using years ago. Google’s guide to loading third party JavaScript efficiently notes that some embeds can still block the page if their servers respond slowly, even with async or defer applied. Remove what you do not need, then delay the rest until a visitor interacts with the page where the tool allows it.

A content delivery network serves images, stylesheets and scripts from locations closer to each visitor. That matters most for organisations with international audiences and a CDN takes load off the origin server during traffic spikes too.

Which Fixes to Make First

Fix the problems with the biggest effect on server response and page weight first, then move on to the finer detail. The table below pairs each cause with its fix and shows whether it usually needs a developer.

Retest after each change rather than making them all at once. If a score drops or a page breaks, you will know exactly which change caused it.

What Needs a WordPress Developer

Image compression, plugin housekeeping and removing old tracking tags are jobs most content teams can handle. Changes to the server, the theme code or the database carry more risk and are better left to a developer.

That includes PHP upgrades, object caching, render blocking CSS and JavaScript, plugins that run slow queries and themes that need rebuilding rather than patching. A developer will test each change on a staging copy before it reaches the live website. Our WordPress support covers security monitoring, plugin updates and performance work for organisations that want that resource on hand without hiring in house.

Where hosting is the root cause, our managed WordPress hosting sizes each server after auditing the existing setup and runs a CDN with caching at server level. A website built without page builders on a well configured server rarely needs heavy optimisation plugins added to it.

Keeping Your WordPress Website Fast

WordPress performance needs regular maintenance, as every new plugin, script and image adds weight over time. A website that was fast at launch can be slow two years later without a single dramatic change.

Check the Core Web Vitals report in Google Search Console each month and keep uptime and response time monitoring in place so slowdowns show up quickly. Review your plugins every quarter, keep WordPress core, themes and plugins up to date and test significant updates on staging first. New plugins and tracking tags should be checked for performance before they go live.

Across B2B, healthcare and public sector websites, the ones that stay fast are the ones where someone owns performance as part of routine maintenance. Treating speed as an ongoing responsibility, rather than a one off project, is what keeps a WordPress website quick for visitors and in good standing with search engines.