Speed Up Your WordPress Website Using These Simple Techniques

QUICK GUIDE – If your WordPress website is slow, don’t start installing random optimisation plugins. Test several important pages first, identify the actual bottlenecks and then work through hosting, caching, images, plugins, JavaScript, CSS, fonts and third-party scripts. Make one group of changes at a time, clear your caches and test again.

Pro Tips – Quick WordPress Speed Wins That Make a Real Difference!

• Test Before Making Changes – Use PageSpeed Insights to identify the actual problems before installing plugins or changing settings.
• Check Your Hosting First – A slow server can limit performance regardless of how well the rest of your WordPress website is optimised.
• Enable Page Caching – Serve cached versions of pages to reduce PHP processing and database requests.
• Compress Large Images – Resize and optimise images before they add unnecessary megabytes to your pages.
• Use WebP or AVIF – Modern image formats can significantly reduce file sizes without sacrificing noticeable image quality.
• Don’t Lazy-Load Above-the-Fold Images – Prioritise important hero and LCP images so visitors see them as quickly as possible.
• Remove Unnecessary Plugins – Keep only the plugins you genuinely need and investigate any that add excessive scripts or database queries.
• Reduce Third-Party Scripts – Review chat widgets, tracking codes, videos, maps and other external resources that may be slowing pages down.
• Optimise JavaScript Carefully – Delay non-essential scripts and remove unused code rather than blindly combining every JavaScript file.
• Monitor Core Web Vitals – Keep an eye on LCP, INP and CLS to understand how your website performs for real visitors.

A slow WordPress website can cost you enquiries, sales and organic traffic before somebody has even had a proper chance to look at what your business offers.

As a freelance SEO and web developer, WordPress performance is something I deal with regularly. I work on websites using different hosting platforms, themes, plugins and page builders, but the same performance problems tend to appear again and again.

Sometimes the hosting is slow. Sometimes somebody has uploaded enormous images directly from a phone. On other websites, I find several optimisation plugins all trying to do the same job, unnecessary JavaScript loading across every page or third-party scripts slowing down an otherwise perfectly good WordPress installation.

The good news is that you don’t normally need to rebuild an entire website to make it noticeably faster.

This guide explains how I approach WordPress speed optimisation, what I look at first and which changes are usually worth prioritising.

By the end of this guide, you will know how to:

• Test your WordPress website properly.
• Understand LCP, INP and CLS.
• Identify whether your hosting is slowing the website down.
• Configure page and browser caching.
• Optimise images without damaging quality.
• Find plugins that are affecting performance.
• Reduce unnecessary JavaScript and CSS.
• Optimise fonts and third-party scripts.
• Improve WordPress database performance.
• Prioritise the changes most likely to make a difference.

Why Does WordPress Website Speed Matter?

When somebody contacts me about a slow website, PageSpeed Insights is often one of the first things they mention.

They have run a test, seen a red or orange score and naturally assume something is wrong.

PageSpeed scores are useful, but I don’t optimise websites simply to turn a number green.

The real objective is to improve the experience for the people actually using the website.

A faster WordPress site can provide:

• A better experience for visitors.
• Faster navigation between pages.
• Lower abandonment on mobile devices.
• Better ecommerce conversion opportunities.
• Faster form and checkout interactions.
• Improved Core Web Vitals.
• A better overall page experience.

I’ve seen website owners become completely focused on reaching 100/100 in PageSpeed Insights.

I don’t think that should be the goal.

I’d much rather have a properly functioning business website scoring in the 90s than a stripped-back website scoring 100 that has lost useful features customers actually need.

Test Your WordPress Website Before Changing Anything

Before I change anything on a client website, I establish a baseline.

Otherwise, there is no reliable way to tell whether my work actually improved the site.

One of the first tools I use is Google PageSpeed Insights.

I don’t just test the homepage.

Depending on the website, I might also check:

• A main service page.
• A blog post.
• A product page.
• A product category.
• A location landing page.
• The contact page.

This is important because different templates can have completely different performance problems.

I’ve worked on websites where the homepage performs well but product or service pages are considerably slower because they load additional plugins, scripts or widgets.

Understand Your Core Web Vitals

Modern website performance isn’t simply measured by asking how many seconds a page takes to finish loading.

The three Core Web Vitals I pay particular attention to are LCP, INP and CLS.

Largest Contentful Paint (LCP)

LCP measures how quickly the main visible content appears.

A good target is:

2.5 seconds or less.

On WordPress websites, I often find that the LCP element is:

• A hero image.
• A large banner.
• A prominent heading.
• A large content block near the top of the page.

Identifying the actual LCP element is important because there is little point optimising ten small images at the bottom of the page if a huge hero image is causing the real problem.

Interaction to Next Paint (INP)

INP measures how quickly the page responds after somebody interacts with it.

A good target is:

200 milliseconds or less.

When I see poor INP, I normally start investigating:

• JavaScript.
• Heavy plugins.
• Sliders.
• Product filters.
• Menus.
• Third-party functionality.

Cumulative Layout Shift (CLS)

CLS measures how much the page moves unexpectedly while it is loading.

A good target is:

0.1 or less.

You’ve probably experienced bad CLS yourself.

You go to click a button and, just before you press it, an image or banner appears above the button and shifts everything down.

That’s exactly the sort of problem CLS is designed to identify.

Don’t Confuse PageSpeed Scores With Real User Performance

One thing I explain to clients is that a PageSpeed Insights score is not the same thing as measuring every visitor to the website.

PageSpeed can contain both lab data and field data.

Lab data is generated under controlled simulated conditions and is useful for diagnosing performance problems.

Field data is based on real Chrome users where enough data is available.

Lighthouse scores can also fluctuate.

If I run a test and get 88, then run it again and receive 92, I’m not going to start changing the website because of four points.

I’m looking for repeatable problems.

Check Your WordPress Hosting

Hosting is one of the first technical areas I investigate.

There is little value spending hours shaving a few kilobytes from CSS files if the server takes a second or two just to start responding.

WordPress has to:

• Execute PHP.
• Communicate with the database.
• Process plugins.
• Load the theme.
• Generate the response.

If the server is slow, everything starts behind.

Things I look for include:

• Slow Time to First Byte.
• CPU throttling.
• Low memory limits.
• Overloaded shared hosting.
• Slow databases.
• Outdated server software.
• Lack of server-side caching.

That doesn’t mean I automatically recommend expensive managed hosting.

Some inexpensive hosting packages perform perfectly well.

The important thing is establishing whether hosting is genuinely the problem.

Keep WordPress, PHP, Themes and Plugins Updated

I regularly inherit websites that haven’t been properly maintained.

Sometimes WordPress itself is outdated.

Sometimes the site is running a very old version of PHP.

Other times there are dozens of plugin updates waiting.

That isn’t only a security issue.

Performance improvements are continuously introduced throughout the WordPress ecosystem.

I therefore check:

• WordPress core.
• PHP.
• The active theme.
• Plugins.
• Server compatibility.

I don’t recommend blindly clicking every update button on an important live website.

Take a backup first and use staging for major updates where possible.

Configure Page Caching Properly

Caching is still one of the biggest performance improvements available on many WordPress websites.

Without page caching, WordPress may need to execute PHP and query the database every time somebody requests a page.

With caching, a previously generated version of the page can be served considerably faster.

Caching solutions I commonly come across include:

• WP Rocket.
• LiteSpeed Cache.
• WP Super Cache.
• W3 Total Cache.
• WP-Optimize.

I don’t recommend one plugin blindly for every site.

The correct caching solution depends heavily on the hosting environment.

For example, if a website is hosted on LiteSpeed, LiteSpeed Cache can integrate directly with the server.

Managed WordPress hosts may already provide their own caching.

If they do, adding another caching layer may be unnecessary.

Don’t Install Several Performance Plugins

This is one of the most common mistakes I see.

A website might already have:

• A caching plugin.
• A JavaScript optimisation plugin.
• A database cleaner.
• An image optimiser.
• A generic speed booster.
• Cloudflare optimisation.

Then somebody installs another plugin because PageSpeed still isn’t green.

Eventually several systems are trying to alter the same CSS or JavaScript files.

That can result in:

• Broken menus.
• Broken sliders.
• Forms not submitting.
• Checkout problems.
• Visual layout issues.

My preference is to use the smallest number of optimisation tools required and understand what each one is doing.

Make Sure Browser Caching Is Working

Browser caching allows static resources to be stored temporarily on a visitor’s device.

This can include:

• Images.
• CSS.
• JavaScript.
• Fonts.
• Icons.

When that person moves to another page, some of those resources can be reused rather than downloaded again.

Most modern caching solutions, CDNs and hosting platforms can configure suitable browser cache headers.

I generally prefer that to copying old `.htaccess` rules from a random tutorial.

Check Your Image Sizes

Images are one of the first things I inspect on a slow WordPress website.

I’ve opened Media Libraries and found individual photographs weighing four, five or even ten megabytes.

Sometimes the image is only displayed at 800 pixels wide.

There is no reason for the visitor to download an enormous camera image only for their browser to shrink it.

I recommend:

• Resizing images appropriately.
• Compressing them.
• Using sensible dimensions.
• Choosing an appropriate file format.

For existing sites with hundreds or thousands of images, an image optimisation plugin can often save a considerable amount of page weight.

Use WebP or AVIF Where Appropriate

Modern image formats can significantly reduce file sizes.

WebP now has extremely broad browser support and is suitable for many WordPress websites.

AVIF can produce even smaller files in some situations.

Common WordPress optimisation tools include:

• ShortPixel.
• Imagify.
• Smush.
• EWWW Image Optimizer.
• Optimole.

Again, you don’t need all of them.

Choose one solution that suits your website.

Lazy-Load Images Below the Fold

Lazy loading prevents images further down the page from being downloaded immediately.

If somebody opens a long blog post containing 20 images, there is little reason to download the image near the bottom before the visitor gets anywhere near it.

WordPress already supports native lazy loading.

However, there is one very important exception.

Don’t Lazy-Load Your Main LCP Image

If the hero image at the top of the page is your LCP element, delaying it can make your Core Web Vitals worse.

This is why I don’t follow blanket advice such as:

“Lazy-load every image.”

A better approach is:

Lazy-load images that aren’t immediately needed and prioritise the ones visitors see first.

Make Sure Images Have Defined Dimensions

Image dimensions can affect CLS.

If the browser doesn’t know how much space an image requires, surrounding content can move when the image arrives.

WordPress normally handles Media Library images correctly, but problems can still be introduced by:

• Page builders.
• Custom templates.
• Sliders.
• Widgets.
• Custom HTML.

If PageSpeed reports images without explicit dimensions, investigate them.

Audit Your WordPress Plugins

Clients often ask me:

“How many plugins is too many?”

There is no magic number.

Twenty efficient plugins might perform perfectly well.

One badly coded plugin can cause serious performance problems by itself.

Plugins can add:

• Database queries.
• CSS.
• JavaScript.
• API calls.
• Scheduled tasks.
• AJAX requests.
• Third-party connections.

I also regularly find plugins that haven’t been used in years.

If something is no longer required, remove it.

Identify Which Plugins Are Actually Slow

I don’t randomly disable plugins because somebody read that “plugins slow WordPress down”.

I measure their impact.

Things I investigate include:

• Slow database queries.
• Repeated AJAX requests.
• Large JavaScript files.
• External API requests.
• Scripts loading unnecessarily across the website.
• WooCommerce processes.

Query Monitor can be extremely useful for investigating WordPress queries and PHP.

For frontend problems, I use tools such as PageSpeed Insights and Chrome DevTools.

Check Your WordPress Theme

Themes vary enormously.

Some are extremely lightweight.

Others include almost every feature imaginable.

A theme can introduce:

• Large stylesheets.
• JavaScript.
• Sliders.
• Animations.
• Icon libraries.
• Several font families.

I don’t automatically recommend rebuilding a client’s website because the theme isn’t the lightest available.

A rebuild can involve substantial time and expense.

I first look at whether unnecessary theme features can be disabled.

Optimise Your Page Builder

I work on plenty of websites using WPBakery, Elementor, Divi and similar page builders.

They can all produce good websites.

They can also be used badly.

I’ve seen pages containing:

• Rows inside rows inside rows.
• Unnecessary animations.
• Multiple sliders.
• Duplicate mobile and desktop sections.
• Widgets performing very simple tasks.

If I’m optimising a page-builder site, I look for unnecessary complexity before recommending a complete rebuild.

Minify CSS and JavaScript Carefully

Minification can still reduce file sizes.

However, I no longer recommend blindly combining every CSS and JavaScript file.

Modern HTTP/2 and HTTP/3 connections are considerably better at handling multiple files than older HTTP/1 connections.

I concentrate more on:

• Removing unnecessary code.
• Minifying where useful.
• Loading resources only where needed.
• Deferring suitable JavaScript.
• Delaying appropriate third-party scripts.

I always test carefully after JavaScript optimisation.

It’s one of the easiest areas in which to accidentally break website functionality.

Delay Non-Essential JavaScript

JavaScript can make a page feel slow even after the visible content has loaded.

The browser may still be busy processing scripts.

That can contribute to poor INP.

Common sources include:

• Live chat.
• Heatmaps.
• Tracking scripts.
• Video players.
• Popups.
• Social media widgets.
• Advertising.

If something doesn’t need to run immediately, I investigate whether it can load later.

Reduce Third-Party Scripts

Sometimes WordPress isn’t actually the biggest performance problem.

I regularly find websites loading numerous external services.

For example:

• Google Analytics.
• Google Tag Manager.
• Meta Pixel.
• YouTube.
• Google Maps.
• Review widgets.
• Live chat.
• Advertising platforms.

Some may be important.

But they don’t all necessarily need to load on every page.

Optimise YouTube Embeds

YouTube embeds can add a surprising amount of additional code.

On pages containing several videos, I may use a lightweight preview image and only load the full YouTube player when somebody clicks it.

That means visitors who never play the video aren’t forced to download everything required by the player.

Optimise Your Web Fonts

Fonts can quietly add considerable weight to a website.

I sometimes find sites loading:

• Several font families.
• Regular weights.
• Medium weights.
• Semi-bold weights.
• Bold weights.
• Italic versions.

I review:

• Whether every font family is required.
• Which weights are actually used.
• Whether WOFF2 is available.
• Whether local hosting makes sense.
• Whether any critical fonts should be preloaded.

I don’t preload everything.

Overusing preload can create a different performance problem.

Consider a CDN

I regularly work on websites using Cloudflare and other CDN services.

A CDN can serve cached resources through geographically distributed servers.

Potential benefits include:

• Faster static file delivery.
• Reduced bandwidth on your origin server.
• Additional caching.
• Security features.

A CDN isn’t a substitute for fixing a poorly configured WordPress website.

Think of it as another performance layer.

Check Brotli or GZIP Compression

HTML, CSS and JavaScript can be compressed before being transferred.

Modern platforms may use Brotli, while GZIP remains common.

In most cases I don’t manually configure this anymore.

Hosting platforms, CDNs and caching systems often handle it.

I check first rather than assuming it needs changing.

Consider Persistent Object Caching

Dynamic WordPress websites can benefit from persistent object caching.

Technologies include:

• Redis.
• Memcached.

I consider this more relevant for:

• WooCommerce stores.
• Membership websites.
• Large websites.
• Database-heavy applications.

A small brochure website with good page caching may see considerably less benefit.

Keep the WordPress Database Under Control

WordPress databases accumulate data.

That may include:

• Post revisions.
• Expired transients.
• Spam comments.
• Old plugin tables.
• Orphaned metadata.

Database housekeeping can help, but I don’t oversell it.

Removing a few revisions isn’t going to transform a genuinely slow website.

Database optimisation is most useful when there is an actual database problem.

Always back up the database before deleting or optimising data.

Check Autoloaded Options

This is a more technical issue, but it appears regularly enough to be worth checking.

Themes and plugins store data in the WordPress options table.

Some of that data loads automatically.

Large amounts of unnecessary autoloaded data can contribute to slower processing.

WordPress Site Health may warn about this.

If it does, find out which plugin or theme created the entries.

Don’t simply delete database options because they look large.

Stop Loading Features You Don’t Need

WordPress plugins sometimes load resources globally even though they’re only used on one or two pages.

Examples include:

• Contact form scripts on pages without forms.
• WooCommerce resources on non-shop pages.
• Unused block styles.
• External widgets.
• Embeds.

Each saving may be small.

Together, they can make a noticeable difference.

Optimise WooCommerce Separately

WooCommerce requires a slightly different approach because much of the website is dynamic.

I don’t blindly cache:

• The shopping basket.
• Checkout.
• Customer accounts.

Other WooCommerce areas I investigate include:

• Product database queries.
• Large variation counts.
• Payment scripts.
• Product filters.
• Site search.
• Large product imagery.
• Tracking scripts.

WooCommerce can still perform extremely well.

It just needs to be treated as an ecommerce application rather than a simple brochure website.

Remove Redirect Chains

Redirects are often essential for SEO.

Redirect chains are unnecessary.

Instead of:

Page A → Page B → Page C → Page D

I try to simplify the process to:

Page A → Page D

I also update internal links to point directly towards the final URL.

Test Mobile Performance

A website may feel lightning-fast on a powerful desktop connected to fibre broadband.

That doesn’t mean it is fast for everybody.

Potential customers could be using an older mobile phone on a weaker connection.

I pay particular attention to:

• Hero images.
• Mobile navigation.
• Popups.
• Cookie banners.
• Background videos.
• Sliders.
• JavaScript.

You need to optimise for your visitors, not your own computer.

How I Fix Poor CLS

If a website has poor Cumulative Layout Shift, I look for elements moving while the page loads.

Common causes include:

• Images without dimensions.
• Ads without reserved space.
• Cookie notices.
• Banners.
• Fonts.
• Embeds.
• Popups.

Where possible, I reserve the necessary space before those elements load.

How I Fix Poor LCP

The first thing I do is identify the actual LCP element.

If it is an image, I investigate:

• File size.
• Dimensions.
• File format.
• Lazy-loading.
• When the browser discovers it.
• Fetch priority.

If the LCP element is text, I look more closely at:

• Server response time.
• Render-blocking CSS.
• Fonts.
• JavaScript.

Identify the cause first.

How I Fix Poor INP

When INP is poor, JavaScript is usually high on my list of things to investigate.

I look for:

• Long JavaScript tasks.
• Heavy menus.
• Sliders.
• Product filters.
• Third-party scripts.
• Unnecessary frontend effects.

Reducing unnecessary JavaScript can make a website feel dramatically faster even if the total page loading time doesn’t change much.

My WordPress Speed Optimisation Checklist

When I carry out a general WordPress performance audit, this is the checklist I work through:

• Test several important pages.
• Review LCP, INP and CLS.
• Check server response times.
• Review the hosting environment.
• Check WordPress and PHP versions.
• Configure page caching.
• Check browser caching.
• Compress oversized images.
• Review image dimensions.
• Use WebP or AVIF where appropriate.
• Lazy-load below-the-fold images.
• Make sure the LCP image isn’t being unnecessarily delayed.
• Audit plugins.
• Identify slow plugins.
• Review unnecessary CSS.
• Review JavaScript execution.
• Reduce unnecessary third-party scripts.
• Optimise fonts.
• Check CDN configuration.
• Check Brotli or GZIP.
• Consider object caching where appropriate.
• Review database health.
• Investigate excessive autoloaded options.
• Reduce redirect chains.
• Test mobile performance.
• Retest everything after making changes.

What Should You Fix First?

Every website is different, but I normally work on the biggest potential wins before spending time on tiny optimisations.

My general priority is:

Hosting and server response

If the server is fundamentally slow, address that first.

Page caching

Correct caching can make an enormous difference.

Images

I’ve found individual images heavier than entire properly optimised pages.

Plugins and third-party scripts

Find out which resources are actually causing the problem.

JavaScript and CSS

Remove unnecessary code and improve how the remaining files load.

Fonts, database and smaller optimisations

Then move onto the finer details.

There is little value spending an hour saving 3KB from a stylesheet when your homepage contains a 5MB banner image.

Don’t Chase a Perfect PageSpeed Score

I like seeing good PageSpeed scores.

But I don’t sacrifice important website functionality simply to reach 100.

A WooCommerce store with analytics, payment systems, customer accounts and product filters naturally has more going on than a simple five-page website.

The questions I care about are:

Does the website feel fast?

Does it respond quickly?

Does the layout remain stable?

Are important pages passing Core Web Vitals?

Does everything still work properly after optimisation?

If the answer is yes, a score of 94 instead of 100 isn’t something I’m going to worry about.

WordPress Speed Optimisation Isn’t a One-Off Job

A website can be fast today and gradually become slower again.

New things get added.

Images are uploaded.

Plugins are installed.

Marketing platforms introduce tracking scripts.

New pages and widgets appear.

Themes and plugins change.

This is why I treat website performance as something worth reviewing periodically rather than a one-off exercise.

I particularly recommend retesting after:

• Major website changes.
• Installing new plugins.
• Changing hosting.
• Adding tracking platforms.
• Launching new ecommerce functionality.
• Changing themes or page builders.

My overall approach is straightforward:

Test first, identify the genuine bottleneck and fix that problem rather than blindly applying every WordPress speed tip you can find online.

That approach saves time, reduces the risk of breaking your website and normally produces much better results.