How to Speed Up a WordPress Website: A Practical Guide That Works

Introduction

Short answer: To speed up a WordPress website, measure first with PageSpeed Insights, then fix hosting and PHP, enable one page cache, optimise images, and remove unused plugins. Aim for Google’s Core Web Vitals thresholds: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1.

A slow WordPress website costs you money in a way that is easy to miss, because nobody emails you to say they left. A visitor taps a link, waits, waits a little longer, and quietly goes back to Google to try the next result. Google notices. Your customers notice. You see only a bounce rate that creeps up and an enquiry form that stays quiet, and it is tempting to blame the design, the copy or the market. Often the real problem is simpler: the site is too slow, and every other improvement you make sits on top of that slowness.

The good news is that most slow WordPress sites are slow for boring, fixable reasons. An underpowered host. No page cache. Oversized images. Forty plugins, each loading its own stylesheet on every page. Fix those four, and most sites pass Google’s Core Web Vitals without touching a line of code. This guide shows you how, in the order that gives you the biggest improvement for the least effort. It is practical on purpose: each section says what to do, where to click, and how to tell whether it worked.

One warning first. Do not try to fix speed by stacking optimisation plugins on top of each other. Two caching plugins will fight. Three image plugins will slow the very thing they are meant to speed up. The method here is the opposite: measure first, fix one thing at a time, re-test, and keep only what provably helps. Work through it in order, and a site that felt hopeless on Monday can feel like a different website by Friday.

Key takeaways

• Measure first: use PageSpeed Insights field data from real visits over the previous 28 days, test the homepage, one service page and one blog post on mobile, run each test three times and take the median, and write the numbers down.
• Fix the foundation: hosting and PHP set the ceiling, and moving from budget shared hosting to managed WordPress hosting commonly drops TTFB from around 800 milliseconds to under 200 milliseconds.
• Enable one page cache only: install one caching plugin, not two, and do not stack optimisation plugins, because two caching plugins will fight and three image plugins will slow the site.
• Get images under control: serve WebP, which typically cuts file size by roughly a quarter to a third, set explicit width and height attributes on images, and use lazy loading.
• Audit plugins, use a CDN and clean the database: remove unused plugins and themes, use a CDN for international visitors, limit post revisions, disable pingbacks, and keep core, themes and plugins updated in a monthly routine.

Measure First: Know What “Slow” Actually Means

Before you change anything, get a baseline. Run your homepage through PageSpeed Insights, and note the field data — the section headed “Discover what your real users are experiencing” — not just the lab score. Field data comes from real visitors over the previous 28 days, and it is what Google’s Core Web Vitals report is based on. The lab score is a single simulated test: useful for diagnosis, misleading as a goal.

The three numbers that matter are Google’s Core Web Vitals thresholds, measured at the 75th percentile of real visits: Largest Contentful Paint (LCP) at or under 2.5 seconds, which is how quickly the main content appears; Interaction to Next Paint (INP) at or under 200 milliseconds, which is how quickly the page responds when someone taps or clicks; and Cumulative Layout Shift (CLS) at or under 0.1, which is whether things jump around while the page loads. Note that INP replaced First Input Delay as a Core Web Vital in March 2024, so older guides that still talk about FID are out of date.

Test the pages that actually receive traffic — usually the homepage, one service page and one blog post — and test on a mobile connection, not just office wifi on a desktop. A homepage that loads in 1.2 seconds means little if your best-converting landing page takes six. Run each test three times and take the median, because single runs vary enough to send you chasing problems that are not there. Write the numbers down. Every fix below should be judged against them.

Fix the Foundation: Hosting and PHP

Hosting is the ceiling everything else runs into, and it is the part people least want to hear about, because it costs money and cannot be fixed with a plugin. Server response time, often reported as Time to First Byte (TTFB), is the floor under every other metric. If your server takes 900 milliseconds to return the first byte of HTML, no amount of image compression brings your load time under a second. It is arithmetic.

Cheap shared hosting packs hundreds of sites onto one machine, and your site competes for resources with strangers. When a site moves from budget shared hosting to decent managed WordPress hosting, TTFB commonly drops from around 800 milliseconds to under 200, and every subsequent fix builds on that. You do not need the most expensive plan on the market. You need a host whose servers are not overloaded, who keeps PHP current, and who offers server-level caching that actually works.

Check your PHP version in your hosting panel or under Tools, then Site Health in WordPress. Sites still running PHP 7.4 are leaving significant performance on the table compared with PHP 8.2 or newer, and the upgrade is usually free from your host. Before upgrading, check that your theme and plugins support the newer version — most maintained ones do — and take a backup first. Also confirm that OPcache is enabled, that your database runs MySQL 8 or MariaDB 10.6 or newer, and that your server uses HTTP/2 or HTTP/3. These are hosting-panel settings, not code changes, and together they decide how fast WordPress can answer before a single plugin is involved.

If your TTFB is consistently over 600 milliseconds on an uncached page, the host, the PHP version or the database is the bottleneck. Fix that first. Everything else in this guide is polishing a foundation that, right now, may not be level. If you would rather not wrestle with hosting panels and PHP versions yourself, this is exactly the kind of work our WordPress development services cover: the server, the theme and the plugins treated as one system, not three separate problems.

Turn On Page Caching

Without a cache, WordPress runs PHP and database queries for every single visit. A page cache stores the finished HTML and serves it directly, which is usually the single biggest improvement to server response time on a content site. It is also the easiest win in this guide.

Install one caching plugin — one, not two — and configure it. A well-known free option generates static HTML files for browsers to store for returning visitors, and most managed hosts provide server-level caching that does the same job without a plugin at all. If your host provides caching, use that and do not add a plugin on top. Whichever route you take, clear the cache after you make changes, or you will stare at the old version of a page and conclude, wrongly, that your fix did nothing.

Caching has limits worth understanding. It helps visitors who see the same page. It helps logged-out visitors most. A membership site, an online shop with a cart, or a learning platform where most visitors are logged in will benefit less, because each visitor sees something different. Those sites need the other fixes in this guide — and often object caching or a persistent cache for database queries — more than they need page caching alone. Set expectations accordingly, and do not let a caching plugin’s marketing promise what your site type cannot deliver.

Get Images Under Control

On most sites, images account for more of the page weight than everything else combined. Someone uploaded a 4,000-pixel photograph straight from a phone into a slot that displays at 600 pixels, and every visitor downloads the full file. Three fixes, in the right order, solve most of it.

First, serve modern formats. WebP typically cuts file size by roughly a quarter to a third against JPEG at equivalent quality, and AVIF goes further still. WordPress has generated WebP versions on upload since version 6.1 and supports AVIF since 6.5, and plugins can convert your existing media library. Second, resize before you compress. Compression on an oversized image treats the symptom; getting the dimensions right first treats the cause. A hero image that displays at 1,200 pixels wide should not be uploaded at 2,400. Third, lazy-load below the fold, but never the hero. Lazy loading your largest, first-visible image actively delays the very metric you are trying to improve, and it is an extremely common mistake. Modern WordPress handles this sensibly by default — it does not lazy-load the first image and marks the likely largest image to load first — so if your theme or a plugin overrides that behaviour, you are undoing a measurable gain.

Always set explicit width and height attributes on images. Without them the browser cannot reserve space, the layout shifts as images arrive, and your CLS score suffers. And compress images before uploading them, not only after: tools that compress on your computer take seconds, and they stop the oversized original from ever reaching your media library. A guide to speeding up WordPress from Liquid Web puts image optimisation first among its high-impact, beginner-friendly tips, alongside caching and a CDN, for exactly this reason — images are the largest content element on most pages, so they deserve more attention than any other asset. You can read its full list of 33 tips in this guide to speeding up a WordPress site.

Cut the JavaScript and Plugin Weight

Plugins are WordPress’s greatest strength and its most common cause of slowness. Each plugin can add stylesheets, scripts and database queries, and many load their assets on every page whether the page uses them or not. A contact-form plugin loading on your homepage, a slider loading on a blog post, a review widget loading on a checkout page: each one adds weight for no benefit on that page.

Start with an audit. List every active plugin and ask, for each one: what does it do, is it still used, and is there another active plugin that already does the same job? Delete the unused ones — deactivating is not enough, because deactivated plugins still need security updates — and delete unused themes too. Then look at what remains with a plugin that shows which assets load on each page, or ask a developer to check. The goal is not a magic number of plugins. A site can run thirty light, well-built plugins and be fast, or five heavy ones and be slow. The goal is that everything loading on a page earns its place on that page.

Two specific habits help. First, keep WordPress core, themes and plugins updated. Updates routinely include performance improvements as well as security fixes, and running old versions is a common hidden cause of slowness. Second, be careful with page builders and sliders. A heavy page builder loading scripts on every page, and a slider with five full-size images on a homepage, are two of the most common causes of a slow homepage in real audits. If your homepage uses a slider, consider whether one strong image and a clear headline would serve visitors better. It usually would, and it will almost certainly load faster.

Use a CDN, Especially for International Visitors

A Content Delivery Network is a global network of servers that stores copies of your website’s static files — images, stylesheets, JavaScript — and serves them from the server closest to each visitor. If your business serves customers in the US, the UK and Germany from a server in one country, visitors in the other two wait longer for every file. A CDN removes most of that distance penalty, and for an international audience it is one of the highest-impact changes you can make.

Many hosts bundle a CDN, and several standalone services offer a free tier that is enough for a small business site. Setup usually means changing your DNS settings or using a plugin provided by the CDN, and your host can usually confirm the right method for their platform. As with caching, use one CDN, test after enabling it, and check that dynamic pages — your cart, your enquiry form, logged-in areas — are excluded from caching, so visitors never see someone else’s content or a stale form. A CDN is not a substitute for fixing a slow server, but once the server is sound, it is the cheapest way to make a site feel fast everywhere you sell.

Clean the Database and Limit the Bloat

After a few years, a WordPress database accumulates thousands of post revisions, trashed items, expired transients, spam comments and orphaned data left behind by deleted plugins. None of it is visible on the front of the site. All of it makes the database slower to query, and on a busy site that slowness shows up in every page load.

Clean it carefully. Limit post revisions going forward, so WordPress does not store dozens of copies of every page — a small setting in your configuration file, or a setting in a reputable optimisation plugin, is enough. Empty the trash, delete spam comments, and remove expired transients. Then optimise the database tables, which reclaims the overhead left by deleted rows. Take a backup before any database work, and do it outside busy hours. Database cleaning is maintenance, not a one-off fix: schedule it every few months, or use a plugin that does it on a schedule and logs what it removed, so you can see that it is working and nothing important disappeared.

Disable pingbacks and trackbacks while you are in the settings. These are notifications of links to your content from other blogs, they create unnecessary server load, and almost nobody reads them any more. You will find the setting under Settings, then Discussion: uncheck the box for allowing link notifications from other blogs on new posts. It is a small win, but it is free, it takes ten seconds, and small wins add up.

Fix the Remaining Details That Move the Metrics

With the big fixes done, a handful of smaller settings are worth checking, because they are the difference between a site that is fast in general and a site that passes Core Web Vitals on the pages that matter.

Minify and combine CSS, JavaScript and HTML where your caching or optimisation plugin offers it — shrinking files and reducing the number of requests — but test after enabling each option, because aggressive combining can break a theme. Defer non-essential JavaScript so the browser loads the visible content first and runs the rest afterwards. Preload the font files your pages actually use, and remove font weights and styles you never display; web fonts are a surprisingly common cause of a slow largest content paint, because the headline text cannot render until its font arrives. Reduce redirects: each redirect adds a round trip, so a chain of two or three old redirects before a page loads is pure wasted time. And fix broken links, which waste crawl time and send visitors to dead ends.

Check your largest contentful paint element specifically. In PageSpeed Insights, the report names the element that counted as the LCP on each page. If it is a hero image, that image’s size, format and loading priority are your next job. If it is a headline, the font is your next job. If it is a slider or a video, the slider or video is your next job. Fixing the named element, rather than optimising in general, is how you turn a good score into a passing one.

Speed Work Compared: What to Do First

Use this table to prioritise. Start at the top and work down; do not start at the bottom because it looks easier.

Jetpack’s guide to speeding up WordPress reaches a similar order of work — a one-click optimisation plugin or caching plugin first, then image sizes, then plugin and hosting clean-up — and it stresses the same rule this guide does: stick to one caching plugin at a time to avoid conflicts. Its 19 methods are worth reading alongside this guide in this how to speed up WordPress guide.

Keep It Fast: Maintenance That Prevents Relapse

Speed is not a project you finish. It is a condition you maintain, because every new plugin, larger hero image or marketing script added through a tag manager can undo months of work in an afternoon. Set up Search Console’s Core Web Vitals report and look at it monthly. Re-test your key pages after any theme change, plugin installation or redesign, and compare with the baseline numbers you wrote down at the start. If a number moves, you will know which change caused it, while the change is still fresh enough to reverse.

Build a short routine into your month: update core, themes and plugins; check that no new plugin is loading assets on pages that do not need it; compress any images uploaded since the last check; empty spam and trash; and glance at the Core Web Vitals report for any page that slipped from Good to Needs Improvement. Fifteen minutes a month prevents the slow drift that turns a fast site into a slow one without anyone noticing the day it happened. For a business site, that routine is worth treating as seriously as bookkeeping. It protects the same thing: revenue you would otherwise lose quietly.

If maintenance is the part that never happens — because running the business comes first, as it should — that is a sensible reason to hand the work over. Our web development services include ongoing WordPress care where speed, updates and monitoring are handled as one routine, and our SEO services depend on that foundation, because a fast site is what lets good content and good links do their work.

Frequently Asked Questions

What is a good loading time for a WordPress website?

Aim for the Core Web Vitals thresholds rather than a single stopwatch number: largest contentful paint at or under 2.5 seconds, interaction to next paint at or under 200 milliseconds, and cumulative layout shift at or under 0.1, measured from real visitors. A site that meets those three on mobile, on its busiest pages, will feel fast to almost everyone who visits it, and that is the standard Google uses in its own reports.

Will a caching plugin alone fix a slow WordPress site?

Sometimes, if the only problem is that no cache exists. Often, no: caching cannot fix an overloaded host, oversized images, or a theme loading heavy scripts on every page. Think of caching as the first and cheapest fix, not the only fix. Measure after enabling it, and if the numbers are still poor, work through hosting, images and plugins in the order in this guide.

Does the number of plugins slow down WordPress?

Not directly. What matters is what each plugin loads and how well it is built. Thirty light plugins can be faster than five heavy ones. Audit what loads on each page, remove what is unused or duplicated, and judge plugins by the weight they add to real pages — not by the count on your plugins screen.

How often should I optimise my WordPress database?

For most small business sites, every two to three months is enough, with revision limits set so the database does not refill with copies in between. Busy shops and sites with frequent publishing may need monthly cleaning. Always back up before database work, and use a reputable tool that logs what it removed.

Is managed WordPress hosting worth it for speed?

For most business sites, yes, if the alternative is budget shared hosting. Managed hosting usually brings current PHP, server-level caching, a CDN and support staff who understand WordPress, and the difference in server response time is often the largest single improvement available. Compare hosts on TTFB and support quality, not on headline price alone — the cheapest host that keeps your site slow is the most expensive one in lost sales.

Should I hire a developer to speed up my WordPress site?

Hire help when you have worked through the beginner fixes and the site is still slow, when the problem is in the theme or the server, or when you simply do not have the hours. A good developer will measure first, explain what they changed, and show you before-and-after numbers. Be wary of anyone who promises a specific score without looking at the site, or who wants to install a bundle of plugins and call it optimisation.

Conclusion: Fast Is a System, Not a Plugin

Learning how to speed up a WordPress website comes down to a short, ordered list: measure with field data, fix the hosting and PHP version, turn on page caching, get images under control, cut the plugin and script weight, serve static files from a CDN, clean the database, and then fix the specific element that is still holding back your largest contentful paint. On many sites the first three steps make the largest difference. On the rest, the remaining steps are what turn a faster site into a passing one.

Start today with the measurement, because you cannot improve what you have not recorded. Then work the list one fix at a time, re-testing after each change so you know what actually helped. Your visitors will feel the difference before your reports show it — and your reports will show it soon enough.

If you would like a specialist to run this process on your site — measuring first, fixing hosting, theme and plugin problems in the right order, and leaving you with before-and-after numbers you can check yourself — contact Links Optimizer Pro for a conversation about your WordPress site, starting with our WordPress development services.