Request a Website Audit 👈

How To Speed Up WordPress Sites (30 Tips): Ultimate Guide

If you buy something through a link on this page, I may earn an affiliate commission, at no extra cost to you.

How To Speed Up WordPress Sites
Learn how to speed up WordPress sites with these 30 optimisation tactics.

WordPress is the most popular content management system for building websites, but one common issue that many site owners and users face is slow loading times. A slow website can lead to a poor user experience and even affect your search engine rankings.

However, there are several steps you can take to speed up your WordPress site and improve its performance. From high-performance hosting to optimising images, there are many strategies you can implement to make WordPress faster.

Let me show you how to speed up WordPress to keep your visitors happy.

If you use WooCommerce, read this guide: 👉 How to Speed Up WooCommerce

Throughout this WordPress speed up guide, I use this website as a case study, showing and explaining what I've implemented for optimised performance.

1. Get Better WordPress Hosting

The first and most important part of speeding up WordPress is using a better hosting provider.

I personally use and recommend Click here to try them out for $1. 👈

For more recommendations, read this article about the best WordPress hosting for speed.

What does better WordPress hosting mean though? Here is my checklist for choosing a better hosting provider:

  • Server location: Make sure the server is located in your target audience’s country, ideally the same city.
  • Server Hardware: Opt for servers with NVME storage for higher throughput and faster response time.
  • Modern Protocols: They should support modern protocols like HTTP/2 and HTTP/3.
  • Compression: Opt for Brotl compression over GZIP.
  • Server Resources: Make sure you get enough server resources. e.g. CPU cores and RAM. Each server comes with a whopping 32 CPU cores and 128GB RAM, which is ~10x more than any other managed hosting provider for the same or similar price (that I’m currently aware of).
  • Object Caching: Make sure your host has object caching (e.g. Redis) to reduce WordPress database queries.
  • Content Delivery Network: Use a host that has a direct integration with Cloudflare Enterprise with full-page HTML edge caching.
  • Uptime: Make sure uptime is at least 99.9%.
  • Security: Use hosts that provide security at the DNS level, e.g. Cloudflare. It’s a bonus if your host has automated malware scanning and removal.
  • Support: I prefer hosting providers that offer 24/7 live chat support.

It’s worth noting that I think the majority of WordPress website owners should be using a managed WordPress hosting provider, like This way all of the above checklist items are configured and managed for you. However, if you are a developer or prefer to manage your own server, then I recommend trying one of these cloud/VPS control panels: GridPane (my favourite), RunCloud, ServerPilot or SpinupWP. You’ll also need to spin up your own server from an infrastructure provider like VULTR (my favourite), Digital Ocean, Linode, Google Cloud Platform, AWS (least favourite) etc.

Web Hosting Terminology:

CPU = Central Processing Unit

This is the brain of your WordPress website, which can only handle so many processes at once. If you have a dynamic website, e.g. WordPress, membership, etc, you will need significantly more processing power than a relatively static website with a simple contact form. And if you get lots of traffic, especially in sudden spikes at certain times of the day or year, you will need even more processing power.

More CPU cores mean more processing power to be able to run more processes at the same time. e.g. to run all of the plugins you have installed, make your theme settings work, run WordPress and all of its backend processes/events, and allow multiple customers/clients to log in, make purchases, etc. Essentially, any command that has to run from WordPress, your theme or any plugin requires CPU. If your WordPress website has too many processes to handle at the same time, it will create a queue of processes, which usually slows down your website, sometimes making it unusable and worst case crashing.

RAM = Random Access Memory

Your RAM is the temporary storage space that WordPress/Themes/Plugins use to store and process data from their many different processes. Without RAM, the CPU would have to get data directly from the hard disk every single time a process is executed, which is slow and inefficient. The more RAM you have, the more of those processes can be stored and executed from memory instead, resulting in significantly higher server performance.

In other words, your hard disk is where data is originally stored. And your RAM is like a little helper that temporarily stores data ready for the CPU to process. Without this little helper, your CPU and hard disk have to work much harder and much longer.

Simple, Fast, & Secure WordPress Hosting -
Try for $1
I earn a commission if you make a purchase, at no extra cost to you.

2. Use Cloudflare for DNS Management (Free)

This tactic won’t speed up your website a hell of a lot, but every millisecond counts!

Most WordPress website owners that I know, including those who are now clients, registered and purchased their domain name through GoDaddy or Namecheap. This is totally fine to do, but what is not fine is using these providers for DNS management. These providers and many others (see chart below) provide slower DNS lookup times (on average) compared to Cloudflare.

Cloudflare provides the fastest DNS lookup times, so if you want to speed up WordPress, one tactic is using Cloudflare for DNS management in order to reduce DNS lookup times.

Cloudflare’s average DNS lookup time over the last 30 days (as of 27/11/23) was ~12ms. In comparison, GoDaddy’s average lookup time was ~43ms.

DNS Performance Comparison of Popular DNS Providers
DNS Performance Comparison from DNSperf of Popular DNS Providers

Other benefits of using Cloudflare for DNS management are faster DNS propagation times that take minutes, not days (this can help prevent downtime during migrations), and it’s easier to use and manage, especially if you have multiple websites. The downside is that you have to manage it yourself. So if you need help changing your DNS, your current hosting provider won’t have direct access unless you add them as a user. They will most likely instruct you to change the DNS records though, instead of getting access to change it themselves.

Here is a step-by-step guide to adding a website to CloudFlare.

For pure DNS management, make sure the Proxy Status shows a grey cloud icon, not an orange cloud. If it’s orange, that means you are using the Cloudflare proxy/CDN. If you are going to use, they will set up CloudFlare Enterprise CDN, which is way better than the free CloudFlare CDN. Note that you should still set up Cloudflare for DNS management even if you use or any other host that has a Cloudflare integration. 


DNS = Domain Name Server. The DNS lookup time (aka response time or query speed) is the time it takes for a browser to find the IP address associated with a domain name. i.e. If you are trying to load the domain name, the Domain Name Server aka DNS needs to figure out what IP address is associated with the domain name so that it can then connect to the server.

Note that I also use CloudFlare to register domain names. You can’t register domain names yet, but you can register .com. Cloudflare is significantly cheaper than most registrars if not all of them. And if you are going to manage DNS with them, you may as well register your domain name with them too.

3. Use a Lightweight WordPress Theme

To speed up WordPress you should be using a performance-focused lightweight WordPress theme. Most WordPress themes are created with design options/features in mind, not fast load times. Generally, more design options mean more CSS and Javascript (bigger files and more of them), which means a heavier web page that can take longer to load. However, there are themes to strike a good balance between design options and being performant.

In my experience, you want to stay well clear of any theme sold on Themeforest. These usually always come with a million design options, most of which you don’t need, which results in huge bloat.

Instead, I recommend using one of the below WordPress themes:

  1. Generate Press: This is what I use for this website.
  2. Kadence: This has more design options but it is still lightweight. I use this for many client sites.
  3. Blocksy: I personally haven’t used this theme yet, but I’ve heard really good things about it. Very similar to Generate Press and Kadence.

All of the above themes are lightweight and use a block-based system that works with the default WordPress editor (Gutenberg), not heavy page builders like Divi, WP Bakery, Elementor, etc. However, you could still use one of the page builders, but I don’t recommend it if you want a faster WordPress website.

There are many benefits to using a lightweight theme, not just faster load times.

Key benefits of using a lightweight theme:

  • Faster load times
  • Reduced load on the server
  • Fewer conflicts with other plugins
  • Usually more secure due to optimised/streamlined code
  • Mobile-friendly design
Kadence WP | Free and Premium WordPress Themes & Plugins
Learn More
I earn a commission if you make a purchase, at no extra cost to you.

4. Don’t Use Heavy Page Builders Like Divi, WP Bakery, Elementor, etc.

If you want to speed up WordPress, I don’t recommend using heavy page builders like Divi, WP Bakery, Elementor, etc. Instead, you should be using a lightweight WordPress theme (see above) and a block-based page builder that works with the standard WordPress editor (aka Gutenberg editor). 

For example, this website uses Generate Press (theme) + Generate Blocks (block-based builder). Note that the Generate Blocks plugin should be installed along with the Generate Press theme.

Or you could use Kadence (theme) + Kadence Blocks (block-based builder). The Kadence Blocks plugin should be installed along with the Kadence theme.

Or simply just use the standard WordPress editor aka Gutenberg editor.

Note: If you want to continue using heavy page builders, you can try unloading/disabling scripts and CSS that you don’t use. Page builders are often jam-packed with design features you aren’t using, but still load on every page of your site. However, if you don’t know how a file is used, doing this can break styling and functionality.

Do this if you want to continue using page builders (this is the polishing a turd method):

  • Start by turning off the page builder settings you don’t need.
  • Then use Perfmatters Script Manager to disable files you don’t need.
  • Then make sure you follow the below section about delaying Javascript until user interaction.
  • And then make sure you follow the below section about removing unused CSS.

Make sure you test the above optimisations in a staging environment first.

5. Limit WordPress Plugins to Absolute Essential

It’s not necessarily true that fewer plugins equals a faster website. However, it is true that resource-intensive plugins can significantly slow down a website, especially if you are using cheap shared hosting or any hosting that doesn’t have enough server resources to run those plugins. Usually, they just make the website really slow for visitors and admin, but they can crash your website if all server resources get used up.

What are resource-intensive plugins? They are pretty much any plugin that does ongoing scanning or some kind of process in the backend that isn’t critical to the function of your WordPress site. e.g. Security plugins that do regular malware scans, backup plugins that take automatic backups, image optimisation plugins that optimise images using your own server instead of theirs, broken link checkers, etc.

But even if your plugins aren’t resource-intensive, they are still using some server resources. So, it is good practice to deactivate AND delete non-essential plugins.

Some benefits of using fewer plugins/extensions include:

  • Reduced conflict risk between all software including WordPress, theme and plugins
  • Reduced load on your server
  • Can make WordPress backend faster for admins
  • Can make WordPress frontend faster for visitors

Extra tip: Even after deleting a plugin, you should check your database’s wp_options table for autoloaded data. You’d be surprised at how many plugins you have that are still autoloading data, even after you’ve deleted the plugin.

6. Optimise Images and Video

One of the best ways to speed up WordPress is to optimise your images and videos (if you have them). Images and videos are often the biggest files present on a web page, so it pays to reduce their file size through optimisation and compression

How to optimise images for WordPress

  1. Aim to optimise each image under 100kb. First impressions count though, so don’t forget about the image quality. i.e. Try to optimise and reduce the size of your images as much as possible without making them look terrible. If 100kb makes them look blurry, try to get them under 200kb.
  2. Resize images before uploading to WordPress. e.g. 1920px wide for full-screen images, 1200px wide for featured images (required for Google Discover), and 600px to 2000px wide for product images (depending on your preference for speed or image quality). WordPress will automatically create smaller image sizes, e.g. 1024px (Large), 768px (Medium Large), 300px (Medium), and 150px wide (Thumbnail). If you are using WooCommerce, more image sizes will be created based on your settings, e.g. 600px wide for product images and 100px for gallery thumbnails.
  3. To fully optimise an image, reduce its width to the maximum screen width where it will be used. However, keep in mind that retina displays will show 2x the resolution. So your image might look fine on a standard desktop screen, but it could look a little blurry on a Macbook Pro with a retina display. For example, the maximum screen width where images can be displayed in this blog post is 860px wide. However, I have chosen to upload all images at 1200px wide instead so that they look better on retina displays (not perfect, but significantly better) and so that they comply with requirements from Google Discover. The images are heavier, but they are still lightweight under 100kb. Reducing the image weight by another 30% or so is not worth making images look blurry on retina displays and not complying with the requirements to appear on Google Discover.
  4. Use appropriate image formats. e.g. SVG for simple icons/logos, PNG for product images, transparent backgrounds, or any image that needs to be higher resolution (e.g. I use PNG for featured images with text overlay because it makes the text lines a little sharper), and usually JPG for the rest (although most images in this post are PNGs to make them slightly sharper).
  5. Compress and optimise images automatically using a plugin like Imagify OR use a free tool like Squoosh before uploading to WordPress. If you are serious about speed, optimise using Squoosh first to get images under 100 kB, then upload to WordPress and let Imagify take care of the rest.
  6. Create AVIF and WebP versions of all PNGs and JPGs using a tool like Imagify to make them even more compressible and lighter. Doing this is a great way to optimise PNGs where the usual weight difference compared to JPGs becomes negligible. For example, the featured image used on this page in PNG format is almost the exact same size as the same image exported and optimised as a JPG. The difference is that the PNG is slightly sharper. Win! However, I don’t recommend enabling WebP images with Imagify unless you are using the smart compression setting. I’ve found that lossless compression setting will actually make your WebP images bigger.
  7. Preload all images above the fold (i.e. any images that appear on the screen before you start scrolling) and lazy load the rest using a plugin like Perfmatters.
  8. Add missing image dimensions to prevent content layout shifts (CLS) using Perfmatters.

Image Size Difference WebP vs AVIF

Here is a screenshot showing how Imagify creates a WebP and AVIF version of PNGs (or JPGs) that I upload to the WordPress media library and the size difference between each image format.

Imagify serves the AVIF image format unless it’s not supported by the browser. In which case it serves the WebP format. And if that’s not supported (e.g. by old browsers), then the original PNG is shown.

Image Size Differences - PNG vs WEBP vs AVIF
Imagify - The Easiest Online Image Compressor And WebP Optimizer
Learn More
I earn a commission if you make a purchase, at no extra cost to you.

How to optimise videos

  1. If possible, don’t use videos above the fold (i.e. appearing on the screen before visitors start scrolling).
  2. If you have videos above the fold, i.e. on your product page, or any other page, it’s better to upload these videos directly to your WordPress website. If you embed them from a third-party platform like YouTube or Vimeo, your website will have to load a bunch of third-party scripts that slow page load.
  3. For videos above the fold that are going to be uploaded to WordPress, compress them first using a tool like HandBrake.
  4. For videos above the fold that are going to be uploaded to WordPress, try exporting them in WEBM format first to reduce size.
  5. If you have videos below the fold, i.e. that appear further down the page after visitors start scrolling, it’s best to host these on a third-party platform like YouTube or Vimeo and then embed them on your website but make sure to lazy load them, i.e. only load them once a visitor scrolls to it or near it. I recommend using Perfmatters to lazy load videos and iframes.

7. Use Caching

Caching is one of the best ways to speed up WordPress and reduce CPU load on your server. There are two categories of caching including server-side caching and client-side caching. I’ll explain each category below, the types of caching from each, and why each is important for your WordPress site.

Server-side caching

Server-side caching includes:

  • Bytecode Cache (OP Cache): Your Bytecode Cache is a caching layer that stores compiled PHP code so that WordPress doesn’t have to compile it again. This comes standard with WordPress though, so there is nothing for you to do here.
  • Object Cache: Your Object Cache is a caching layer that stores the results of database queries in memory so that WordPress doesn’t have to query the database again when it already knows the result. This is more important for WordPress websites that store information about users, e.g. that use WooCommerce, learning management systems like LearnDash, membership functionalities like MemberPress, etc. Opt for Redis Object Cache, ideally Redis Object Cache Pro. If you use cheap shared hosting or any hosting with low RAM limits, you probably shouldn’t use an object cache like Redis. Doing so might speed up backend processes but at the expense of using more memory, which might slow down or crash the rest of your site. This website has the free version of Redis Object Cache installed. If this site had an online course or membership registration, I would likely enable the pro version. Until then, the free version is fine.
  • Page Cache: Your Page Cache is a caching layer that stores a copy of each web page so that WordPress doesn’t have to create it again. This way the page is served from memory, which is much faster and easier on your server. Not all hosting providers have server-side page caching though. In these cases, you need to set up page caching through a plugin like WP Rocket. You should also consider how long you want pages to be cached. If your website doesn’t change often, you could set the cache lifespan to unlimited. If your website is more dynamic and/or things change often, you could set the cache lifespan to ~10 hours instead where the page cache gets rebuilt with the latest page changes every ~10 hours.
  • CDN Cache: Your CDN Cache is a caching layer by your content delivery network (CDN) that can store the full page (similar to page caching) or just static files like images, fonts, CSS, and Javascript at data centers closer to your visitors. This is especially important for WordPress websites with a global customer base. Imagine if your customers in the United States were browsing your website that has to load from Australia. As you can imagine it would take longer to load considering the data has to travel from Australia to the United States. A CDN like CloudFlare will automatically store a copy of every web page at 300+ data centers around the world. e.g. If you have a customer in Miami, CloudFlare has a data center in Miami, which is where the page would be stored and loaded from. I recommend using, which comes with CloudFlare Enterprise and full-page HTML edge caching.

Client-side caching includes:

  • Browser Caching: A browser cache is where a browser, e.g. Chrome, will store a copy of your web page in a folder on the browser. This way, the browser simply shows the website that a visitor was previously browsing instead of having to download it all from the server again. I recommend using a caching plugin like WP Rocket that automatically enables browser caching on activation.
WP Rocket Caching Plugin
Learn More
I earn a commission if you make a purchase, at no extra cost to you.

8. Use a Content Delivery Network (CDN) with Full-Page HTML Edge Caching

As you know, a CDN acts as a caching layer that stores the full page (similar to page caching) at data centers closer to your target audience. If you have a global or national audience, you would benefit greatly from using a CDN with full-page HTML edge caching to speed up your WordPress site. Even if you don’t, CDN providers with full page caching like CloudFlare and Fastly can still improve loading times, keep your WordPress site safe with a web application firewall (WAF), and reduce load on your server.

I recommend using which comes packaged with CloudFlare Enterprise and Argo Smart Routing. Click here to try it for $1. 👈 Or at least request a free migration so you can see how fast your website loads with their full page caching compared to your current website. As mentioned in the speed testing tools section, I recommend using Speed Vitals to test TTFB times around the globe. Test your current website and test the migrated version to compare.

If you can’t afford a managed WordPress hosting provider that comes with CloudFlare Enterprise for full-page edge caching, you have a couple of free options.

Free option #1 = Fastly CDN

Free option #2 = CloudFlare free account + Super Page Cache for Cloudflare plugin

I think Fastly is the best option because it comes with most, if not all features from CloudFlare Enterprise including security, for free, if you don’t exceed their monthly 500GB bandwidth limit. Just contact support to get set up for free and use their free plugin to integrate their CDN with your WordPress website.

Alternatively, you could use a free CloudFlare account (which you should already have set up to manage DNS) and install the Super Page Cache for Cloudflare plugin that tells Cloudflare to cache all, i.e. full page caching. Just make sure caching is disabled for your WordPress wp-admin backend.

Below is a tutorial about how to set up the Super Page Cache for the Cloudflare plugin.

Video guide about how to set up the Super Page Cache for Cloudflare plugin.

Cloudflare Free vs Pro vs Business vs Enterprise

Keep in mind that full page caching on Free, Pro or Business plan with Cloudflare won’t be as fast, at least not all the time, as Cloudflare Enterprise. This is because Cloudflare Enterprise uses a premium tier network, meaning your website gets priority to load from the nearest data center compared to users on lower Cloudflare plans.

For example, I’ve tested the Free and Pro plan for my own website, and I was shocked to see it loading from Singapore instead of Australia. Lower priority is one thing, but it’s actually more expensive for Cloudflare to load my website from Australia compared to Singapore, and because Free/Pro plans don’t get priority, they will load your website from a data center that doesn’t cost them as much. Something to keep in mind!

Cloudflare APO Addon

If you are going to use a free Cloudflare CDN + the Super Page Cache plugin, one way to speed things up is to use their Cloudflare Automatic Platform Optimization (APO) addon. This is a better way to do full-page caching using ‘Cloudflare Workers’ to cache dynamic content instead of using cache all rules (which can cause issues with some hosting providers that already have multiple layers of server-side caching). APO only costs $5/month!

With all that being said, the order in which I would try full-page caching options is:

  2. Fastly
  3. Cloudflare free + APO + Super Page Cache plugin
  4. Cloudflare free + Super Page Cache plugin
Simple, Fast, & Secure WordPress Hosting -
Try for $1
I earn a commission if you make a purchase, at no extra cost to you.

9. Optimise Javascript Loading

Delay javascript until user interaction

Another great way to speed up WordPress is to optimise Javascript loading by delaying Javascript from loading until user interaction. This is much better than letting it load before/with the rest of the page. The less Javascript loading before user interaction, the better.

To easily delay all Javascript from loading until user interaction, I recommend using a plugin called Perfmatters.

This website uses Perfmatters with the below settings enabled:

  • Defer Javascript
  • Delay Javascript > Delay All Scripts > Exclude Generate Press Blog, Mobile Menu & Offside Menu

Performance improvement results from delaying javascript until user interaction

Below you’ll find speed test results showing before and after delaying Javascript until user interaction.

Speed test configuration:

  • Speed Test Tool = Browser Stack Speed Lab
  • Page tested =
  • Location = Australia
  • Network/Internet Connection = 4G Slow (1.6 Mbps/768 Kbps 150ms RTT)
  • Real Device = Samsung Galaxy S10 Plus
  • Browser = Chrome Version 120
  • OS =  Android, v9.0
  • CPU/Memory Power = 602.5
  • Viewport = 412px x 722px
  • Browser Stack ran 5 tests showing results for each and the median result highlighted above
BEFORE Delaying Javascript
Browser Stack Speed Lab Test - Max Jacobs Home Page - Mobile - Without Delay Javascript
Here are the speed test results for this website’s home page BEFORE delaying Javascript.
AFTER Delaying Javascript
Browser Stack Speed Lab Test - Max Jacobs Home Page - Mobile - With Delay Javascript
Here are the speed test results for this website’s home page AFTER delaying Javascript.

As you can see from the above speed test results, delaying Javascript until user interaction can have a significant impact on page load times. The results are almost identical for other pages and posts too. Note the massive difference in time to interactive and total blocking time. And of course, it looks good to get 100/100. 👌

To further convince you to delay Javascript until user interaction, see the below table that shows the overall page weight (compressed) and HTTP requests before and after delaying Javascript.

PagePage Size BEFOREPage Size AFTERRequests BEFORERequests AFTER
Home384 kB49.5 kB3314
Blog Post500 kB165 kB5434

Table summary:

  • Home Page = ~87% reduction in page size and ~58% reduction in page requests
  • Blog Posts = ~67% reduction in page size and ~37% reduction in page requests

The delay all scripts feature successfully delayed a wide range of third-party software Google Tag Manager, Google Analytics, Get Lasso, Mailerlite, and social sharing for blog posts. So don’t worry too much if your website has lots of scripts making external requests. i.e. You don’t need to remove them to speed up your site. Instead, just delay them from loading until user interaction. Just make sure to test your website if delaying JS.

Minify javascript

Minifying JavaScript can reduce page weight. However, minifying can cause styling issues with some themes, so use this with caution. I personally don’t do this often, at least not at the application level, e.g. with a caching/optimisation plugin. Instead, I would enable this setting at the CDN level, e.g. with CloudFlare.

Perfmatters Settings > Assets > Javascript

Perfmatters Settings - Assets - Javascript - Max Jacobs
Here are the Perfmatters Javascript optimisation settings I use for

Disable javascript files

You can also disable Javascript files altogether if they aren’t needed on certain pages using the Perfmatters Script Manager feature.

I often disable entire plugins from loading, including their javascript files if they aren’t needed. e.g. Contact form plugins are only needed on pages that display the contact form, so the contact form plugin can be disabled from loading everywhere else.

Extra Tips

  • If you have forms embedded, use Javascript snippets instead of HTML code. This way you can easily delay the Javascript snippet (if your form is below the fold or a popup) using the Perfmatters delay javascript feature.

10. Optimise CSS

In addition to optimising Javascript, you should optimise your CSS to make WordPress faster.

Remove unused CSS

When your WordPress website loads pages and posts, there are often unused CSS and CSS files that load. So, another tweak to speed up WordPress is to remove unused CSS, which reduces HTTP requests and overall page weight. As you probably guessed, you can do this with Perfmatters. Is there anything this optimisation plugin can’t do? 💪

I always set the used CSS to print into a cacheable file so that it can be cached and so that it reduces the overall page weight and delays the original CSS (used and unused) from loading until user interaction (similar to delaying Javascript).

Please note the exclusions I have in place. If I don’t exclude these, certain styling and functionality ends up breaking. Your exclusions (if any) will likely be different to mine depending on your theme, plugins, etc. If you decide to remove unused CSS, make sure you check Perfmatter’s list of common exclusions.

Perfmatters Settings - Assets - CSS - Max Jacobs
Here are the Perfmatters CSS optimisation settings I use for

Performance improvement results from removing unused CSS

Below you’ll find speed test results showing before and after removing unused CSS.

Speed test configuration:

  • Speed Test Tool = Browser Stack Speed Lab
  • Page tested =
  • Location = Australia
  • Network/Internet Connection = 4G Slow (1.6 Mbps/768 Kbps 150ms RTT)
  • Real Device = Samsung Galaxy S10 Plus
  • Browser = Chrome Version 120
  • OS =  Android, v9.0
  • CPU/Memory Power = 597.5
  • Viewport = 412px x 722px
  • Browser Stack ran 5 tests showing results for each and the median result highlighted above
BEFORE Removing Unused CSS
Browser Stack Speed Lab Test - Max Jacobs Home Page - Mobile - Before Removing Unused CSS 2
Here are the speed test results for home page BEFORE removing unused CSS.
AFTER Removing Unused CSS
Browser Stack Speed Lab Test - Max Jacobs Home Page - Mobile - After Removing Unused CSS 2
Here are the speed test results for home page AFTER removing unused CSS.

As you can see from the above Browser Stack tests, the core web vital metrics didn’t change much, but they did still improve for Speed Index, Largest Contentful Paint, Time to Interactive and Total Blocking Time. However, these minor improvements would be within the margin of error. i.e. these differences are expected between tests with the same configuration.

Here are the page weights and request improvements from removing unused CSS for this website.

PagePage Size BEFOREPage Size AFTERRequests BEFORERequests AFTER
Home67.8 kB49.5 kB1714
Blog Post187 kB165 kB4134

Table summary:

  • Home Page = ~27% reduction in page weight and ~18% reduction in HTTP requests
  • Blog Posts = ~12% reduction in page weight and ~17% reduction in HTTP requests

As you can see from the above, the reduction in HTTP requests and page weight is significantly less than optimising Javascript. But still, improvements that I think are worth implementing on your own WordPress site.

Keep in mind that the website being tested is already optimised. i.e. it doesn’t use a bloated theme or page builder with millions of design features and CSS files that load for no good reason. This technique will provide the biggest improvements to websites with heavy page builders and themes with many unneeded design features that load on every page.

Note that you should always test these delaying tactics in a staging environment. If something goes wrong, your live website is safe. If something does go wrong, you’ll need to figure out which Javascript or CSS file needs to be excluded from the delay feature. If you can’t figure it out, Perfmatters support is always happy to help.

Disable CSS files

You can also disable CSS files using the Perfmatters script manager. This should be done with caution though. Instead of disabling individual CSS files, I usually disable entire plugins if they aren’t needed on certain pages. For example, this site uses Novashare (a lightweight social sharing plugin) on posts. I don’t use this anywhere else, so I’ve disabled this everywhere except for posts.

Don’t go overboard with this tactic. More often than not, plugins are needed on pages you didn’t realise.

Implementing this tactic helped save another 2 requests on the home page and reduced page weight by ~19%. No improvements were made to blog posts though. But keep in mind that this website is already optimised. If your website uses a bloated theme or a wide range of plugins, disabling plugins on pages that don’t need them could provide drastic speed improvements.

11. Optimise Fonts

Optimising your fonts is another great way to make WordPress faster.

First, you need to decide whether to use custom fonts, e.g. for better branding or use system fonts to maximise website speed.

Use system fonts

This is what this website uses. This tactic will give you the biggest speed improvement in terms of font load times. This is because your website will load the fonts that already exist on your visitor’s device. If the font already exists, your website doesn’t need to load any new fonts. System fonts can be enabled with a single click using Perfmatters.


  • Faster load times
  • Visitors are already used to seeing the same font on their device


  • Using system fonts means you aren’t using custom fonts for branding.

Interesting fact: I’ve noticed that Shopify now makes you use system fonts for their checkout pages. This is because they know that fast loading times are crucial to making sales!

Host fonts locally

If you prefer to use custom fonts for branding (which is what most WordPress site owners do), I recommend hosting your fonts locally (from your own server) instead of loading them externally, e.g. from Google servers.

Hosting fonts locally can be enabled with a single click using Perfmatters.

Note that if you use cheap shared hosting, hosting fonts locally might not help that much. It might even slow your website down because your hosting provider is so slow. But you want a faster WordPress site right? So this won’t be you because you won’t be using cheap shared hosting.

Preload fonts

If you are using custom fonts (hopefully hosting them locally), I recommend preloading them, which tells a browser that they should be loaded before non-preloaded files. Basically, anything that loads above the fold, i.e. in the device/screen before scrolling, should be preloaded. This would include fonts, your logo, the header image, etc.

Note that system fonts can’t be preloaded because they already load from your visitor’s device. It’s like the ultimate preload. So I’m not preloading any fonts for this website, but I’ll show you my preload settings anyway.

Perfmatters Settings for Optimising Fonts
Here are the Perfmatters font optimisation options. I have ‘Disable Google Font’s toggled on.

12. Optimise Database

If your WordPress site is brand new, especially if it’s built using a performance-focused theme and plugins, this step probably won’t help speed things up that much, if at all, but it will set the stage for an optimised database going forward.

If your WordPress site has been around for a while, (e.g. years), or if your website has gone through multiple revamps or lots of plugin trial and error, OR if it was built using a bloated theme (e.g. from Themeforest), then the below optimisations will likely help speed up your WordPress backend for admins and the frontend for visitors. Although, it’s usually the backend that benefits the most.

Here are some ways to optimise your WordPress database.

Clean up wp_options table and autoloaded data

For bloated websites, this can be the most important step to optimise your WordPress database.

Your wp_options table essentially stores the backend settings for WordPress, your theme, plugins, widgets, etc. Each of these settings or ‘options’ can be set to autoload, which loads the settings on every single page load. And because they get loaded everywhere, it’s important to know how much data is being autoloaded and from which plugins. You’ll even find options that are autoloading data from deleted plugins! 😳 

Here are the basic steps to cleaning up your wp_options table:

  • Check autoload data size and list of contributing plugins/options.
  • If your autoload data size is below 1MB, you don’t need to take any critical action. Of course, you can still reduce the database size, but you might not see noticeable speed improvements. But if you are like me, you’ll probably try to reduce it anyway so that you can sleep at night knowing your database is optimised. 😅 FYI, the autoload data size for this website is ~90KB, well under the 1MB threshold.
  • Reduce the autoload data size by removing unneeded plugins that were contributing to autoloaded data. Or you can replace current plugins with ones that don’t add unnecessary autoload data.
  • From your phpMyAdmin, scan all rows of your wp_options table to find the names (sometimes just acronyms) of plugins that you no longer use. Check the boxes for each of them and then select Drop to delete the rows (and their autoloaded data) from your database.

IMPORTANT NOTE: Make sure you take a full backup before making changes to your database. Sometimes it’s tricky to figure out if a certain option belongs to an active plugin or not. The last thing you want is to delete options from a plugin that you are using. You might need to copy-paste the option_name into Google to help figure out what plugin it belongs to. If you aren’t sure, it’s always better to leave it as is. Only delete options when you are certain they belong to a deleted plugin.

How to check wp_options autoloaded data size and contributing rows

So, there are two ways to check your wp_options autoloaded data.

The first is to log into phpMyAdmin and run the below SQL command. Just replace wp_ with your database name. This will output the autoload size and top 30 contributing options/plugins from largest to smallest.

SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes' UNION SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes' UNION (SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 30)

For more information, read this guide from Kinsta.

The second option is using a plugin like Autoload Checker. Note that I’ve only ever used this plugin once, for this article. It does work, and it’s free, and it’s easier than running an SQL command. Just make sure to delete it when you are done. The below screenshot using the Autoload Checker plugin shows the total autoload size and list of top plugin options that are contributing.

Database Autoload Size - Max Jacobs
Screenshot from Autoload Checker plugin showing database autoload size and plugin options contributing to autoload size for

Remove tables from plugins that no longer exist

As you now know, deleting plugins doesn’t always delete all of its settings from your database. Sometimes the actual database tables for a deleted plugin are leftover. If you aren’t going to use the plugin again, it’s best to delete all associated database tables.

You can either sign into your phpMyAdmin to find and delete tables from deleted plugins. Or you can temporarily use a plugin like WP-Optimize that has a database optimisation feature that automatically checks if a plugin is being used or not. If not, the plugin will give you the option of deleting the table.

Delete old posts/page revisions

Deleting old posts/page revisions is a good way to clean up your database. Not because it will speed things up, but because it will reduce your database size leaving more room on your server.

Limit the number of revisions stored

Once you’ve deleted old revisions, you can prevent post revisions from piling up in your database by limiting the number of revisions stored when editing posts and pages. Perfmatters has a nice option to disable or limit your post revisions. I usually set the limit to 5 revisions. It’s not often that you’ll need to go back more than 5 revisions when editing a page/post. But you can set this to whatever makes sense for you.

Delete expired transients

Another way to clean up your database is to delete expired transients. Transients are temporary options stored by WordPress, themes and plugins. I recommend using Perfmatters to scan and remove expired transients.

You can also remove the below using Perfmatters:

  • Post revisions
  • Post auto drafts
  • Trashed posts
  • Spam comments
  • Trashed comments
  • All transients

13. Remove Slow & Resource-Intensive Plugins

If a plugin makes lots of queries to your database or needs lots of CPU processing power to work, it can slow down your WordPress website. This is especially the case if you use cheap/shared hosting with low server resource limits.

So, one good way to speed up WordPress is to remove resource-intensive plugins.

What are resource-intensive plugins? They are usually a plugin that has lots of ongoing processes, scans, etc, or ones that have dynamic functionality, e.g. language plugins.

General tips:

  • Don’t use plugins that unnecessarily display analytics inside your WordPress Dashboard when you can easily check them from a third-party website/platform. e.g. Google Analytics. Just sign into your Google Analytics account instead. If you absolutely must use certain plugins, make sure to disable their analytics features.
  • Don’t use plugins that run continuous scans of your website. You can still use them if you really need to, but only use them once, then remove them. e.g. Broken link scans using Broken Link Checker, malware scans using WordFence, etc. 
  • Some plugins and themes come packed with a gazillion design options, features and settings that are automatically enabled. You can make a plugin less resource-intensive by disabling or turning off all of the settings and features you don’t need.

How to find slow resource-intensive plugins

Start by installing the Query Monitor plugin for WordPress to help find plugins that are slow, making way too many database queries, causing PHP errors, etc. If a plugin is causing issues, remove it or replace it.

Follow these basic steps to use Query Monitor:

  1. Install Query Monitor
  2. Investigate all Notices (if any)
  3. Investigate all Deprecated warnings (if any)
  4. Investigate all Slow Query warnings (if any)
  5. Disable all caching layers (e.g. I disabled object cache and page cache)
  6. Go to Database Queries > Queries by Component tab
  7. Sort the list of plugins by time from slowest to fastest
  8. Investigate any plugin that has a query time longer than 0.05 seconds
  9. Investigate any plugin that has a query time significantly longer than other plugin query times
  10. You can dig deeper into slow queries by clicking the Queries by Caller and Database Queries tabs

Note: It’s important to disable caching, especially object caching, before checking queries by component. This will give you a true indication of any slow queries. If you have object caching enabled, most queries won’t show up once they are cached. e.g. when loading the same blog post with object caching enabled, the only plugins that load are Get Lasso and Novashare.

Below is a screenshot showing steps #6 and #7.

How To Check Slow Database Queries - Blog Post - Max Jacobs
Here I’m using Query Monitor and the Database ‘Queries by Component’ tab to check database query time (in seconds) for each plugin after loading one of my blog posts with object caching disabled.

To learn more about using Query Monitor to optimise your database, read this guide.

Next, you could take it a step further by using a tool like New Relic for application performance monitoring (APM). Most managed hosting providers should support this. e.g. All of the best WordPress hosting providers have the option to enable New Relic APM. Alternatively, you could use New Relic directly using New Relic’s WordPress Quickstart.

Once you’ve found slow plugins and performance bottlenecks, either remove or replace the plugins with performance-focused alternatives.

14. Don’t Use Image Sliders or Animations

Image sliders look great, but they can negatively impact speed and performance for pages that use them and also negatively impact the speed of your WordPress site overall because of the scripts loading sitewide, especially if done by image slider plugins.

General tips:

  • Don’t use image sliders if you don’t have to.
  • Don’t use animations if you don’t have to.
  • If you want to use an image slider, use the slider widget that comes with the Kadence theme.
  • If you don’t use Kadence or another performance-focused theme with a slider, and instead use an image slider plugin, don’t use Revolution Slider. Try Meta Slider instead. There are other image slider plugins, but this is the best one I’ve found that doesn’t cause as many performance issues. It also causes fewer conflicts with optimisation plugins.
  • If you use an image slider, limit animations. I personally prefer websites without fancy animations. If you are scrolling quickly or on a slow internet connection, animations can make a website feel slow with lots of lag, and sometimes that page feels broken because the animation takes ages to finish.
  • If you use an image slider, make sure you are compressing and optimising your images. Having a slider with many high-resolution images significantly increases page weight and load time, especially for slower internet connections.
  • If you use an image slider above the fold with a background video on autoplay, it’s best to upload the video directly aka self-hosted, instead of loading it from YouTube, Vimeo, etc. If you load from an external site, you’ll have a bunch of third-party scripts loading too. Just make sure to minimise the video length and compress its size. Refer to the image and video optimisation section above.

15. Optimise WordPress Heartbeat API

The WordPress Heartbeat API is used to sync data between your server and the browser. For example, it’s used by WordPress to create auto drafts/revisions while editing pages and posts, display real-time stats on your WordPress dashboard (e.g. recent sales), dashboard notifications, lock a post if another user is working on it, etc. Your dashboard is updated every 15 seconds and auto saves are done every 60 seconds.

It uses AJAX requests to sync and update, which require CPU processing time. This is fine if your server has high CPU limits, but it can cause issues with cheap shared hosting that typically has low CPU resource limits.

General tips for optimising WordPress Heartbeat API:

  • Only allow Heartbeat to run when editing posts and pages. No need to run it on the frontend or backend when you don’t need it.
  • Increase Heartbeat frequency from 15 seconds to 60 seconds.
  • Disable or increase the autosave interval from 60 seconds to 2 minutes or more.

You can easily optimise the WordPress Heartbeat API using Perfmatters.

Perfmatters Settings for WordPress Heartbeat Control
Here are the Perfmatters WordPress Heartbeat settings I use for

16. Increase WordPress Memory Limit to Minimum 256MB

Your WordPress memory limit is there to limit the amount of memory any script can use. Your plugins, theme and WordPress need memory to function though, so it’s very important to give them enough memory to work at maximum performance. However, the limit is there for a reason, to limit over usage.

So, when your WordPress website is slow, plugins aren’t working, or you are seeing errors about exhausting memory, it could be because your WordPress Memory limit is too low OR you have software (usually plugins) using up all available memory.

General tips about WordPress memory limit:

  • Set WordPress Memory Limit (wp_memory_limit) to at least 256MB for scripts on the front end.
  • Set the WordPress Max Memory Limit (wp_max_memory_limit) even higher than 256MB if you want a faster WordPress backend. This website is set to 1GB. Most hosts set this to be the same as wp_memory_limit.
  • If you aren’t sure how to increase your memory limit, ask your hosting provider.
  • If you want to get your hands dirty, you can set the memory limit via wp-config, .htaccess or php.ini.

17. Use Latest PHP Version

By using the latest PHP version, your WordPress site will be able to handle more requests per second. For example, Kinsta showed that WordPress with PHP version 8.1 is ~47% faster than 8.0.

However, you should keep in mind that not all themes and plugins are compatible with the latest PHP versions. So make sure you test everything if upgrading to the latest PHP version.

General tips:

  • Use the latest PHP version available on your server.
  • Try to use the latest supported PHP version. As of 30/5/24, PHP 8.2 is the latest supported version. However, PHP 8.1 is still getting security updates, so this is ok to use too.
  • If the latest PHP version causes issues, e.g. if your theme or plugins aren’t compatible, then use the previous PHP version.

18. Use Gzip or Brotl Compression

If your files aren’t being compressed by your server using either Gzip or Brotl, you are missing out on some serious speed gains.

Here are the recommended compression methods:

  • Gzip: This is the most popular
  • Brotl: This is the latest and greatest method

This website uses Brotl compression.

Use this test to see what compression method your website uses.

19. Use a Server-Side Cron Job Instead of wp-cron to Significantly Reduce Server Load

The WordPress cron system is what WordPress uses to schedule various tasks that happen in the background. e.g. checking for WordPress, theme, and plugin updates, publishing scheduled posts, and allowing plugins to also perform their own scheduled tasks.

However, the WordPress cron system aka wp-cron gets triggered on every page load. And every time this gets triggered, your server uses CPU. This isn’t a big issue if your WordPress site doesn’t get much traffic or if you have high CPU limits. But if you do have lots of visitors, wp-cron events get triggered all the time, which can put unnecessary load on your server and slow everything down.

So, instead of using the default wp-cron system, it’s better to trigger the cron events from your server at specific intervals. e.g. once every 5 minutes.

Either ask your host to do this, or add the below cron rule yourself. Just replace my domain name with your own.

*/5 * * * * wget -q -O - >/dev/null 2>&1

Here are the steps to use a server-side cron job instead of wp_cron:

  1. Add the above server-side cron job to run once every 5 minutes.
  2. Disable wp_cron from your wp-config file.
  3. Monitor cron events using the WP Control plugin to make sure cron events are still firing.

Note: If you aren’t sure how to do the above, talk to your hosting provider. If your hosting provider can’t easily add a server-side cron and disable wp_cron, then move to a better hosting provider.

20. Use Performance-Focused Plugins

Try to use plugins that are performance focused including those that are:

  • Lightweight
  • Not crammed with unnecessary features
  • Ad free
  • Not CPU intensive

Knowing the above doesn’t make it much easier to find performance-focused plugins though. So, below I’ll share some performance-focused plugins that I’ve found for a few different use cases where the majority of plugins available are bloated and/or CPU-intensive.

21. Consider .Htaccess vs Redirection Plugins for 301 Redirects

There are two main ways to add 301 redirects.

  • From your server (e.g. .htaccess file)
  • From a redirection plugin

The first is from your server, e.g. from your .htaccess file if using Apache or NGINX rewrite rules if using NGINX. Your server can process a redirect rule faster from a .htaccess file than PHP processes happening inside WordPress such as SQL database queries from the redirection plugin and WordPress core, so it’s usually best to add your 301 redirects at the server level. However, your server has to process your .htaccess file before loading each page. This is fine if it’s a few hundred redirects, but once you have a few thousand, you might begin to see your Time To First Byte (TTFB) negatively impacted due to the additional server overhead. i.e. if a .htaccess file has 10,000 redirects, the server has to check them all before loading each page. If you have this many redirects, you should consider if they need to be there.

The other redirect option is using a redirection plugin where all redirects are set inside WordPress and saved to the database. It’s much easier to set up for most WordPress admins. As mentioned above, your server can process a single redirection faster than a redirection plugin can process one. However, redirection plugins store redirections in the database, which don’t add server overhead, meaning they don’t negatively impact your TTFB. However more database queries require more server resources to process, i.e. more CPU/IO processing, so it’s possible they could slow down your site if your server can’t handle the additional database queries.

As you can see from above, there are pros and cons to using .htaccess vs redirection plugins. If you have less than 1000 redirects, it probably doesn’t matter which option you choose. But if you have significantly more redirects, it’s worth considering both options. If you have a cheap server with low resource limits, you might be better off using .htaccess for redirects to prevent database queries. If you have a strong server with high resource limits, the redirection plugin method might actually be best to prevent server overhead, but only if you have a ridiculous amount of redirects.

Note that this website uses .htaccess for 301 redirects.

22. Use an SMTP Provider

Following on from above, another way to reduce the load on your server is to use an SMTP provider to send transactional emails (e.g. order confirmations) instead of using the default PHP mailer function. You should already have this set up though to improve email deliverability.

The best WordPress hosting providers should have SMTP enabled as standard. Other good hosts like Cloudways still have an SMTP add-on, e.g. Elastic Mail, but you’ll need to configure it to work with your WordPress website using a plugin like WP Mail SMTP.

If your hosting provider does not include SMTP nor has an SMTP add-on, you’ll need to use a third-party provider. I’ve had a good experience using Brevo, which is free for up to 300 emails per day. Once you’ve created an account with Brevo, you can use WP Mail SMTP to help configure it to your WordPress website.

23. Reduce Blog Posts Displayed on Category Pages

Do you have 100s or 1000’s of blog posts listed on each category page? If so, you could speed up the page load of these pages by reducing the number of blog posts per page. i.e. instead of listing 1000s of articles, list 20-30 instead. The fewer blog posts per page, the quicker it will load. 

However, user experience is not just page load time, but how easy it is to browse your blog articles. So don’t reduce your blog or category archive pages into too many subpages that make it harder for visitors to browse. 

24. Remove Bloat with Disable Bloat for WordPress Plugin

One tactic to boost the speed of your WordPress backend is to remove bloat using a plugin called Disable Bloat for WordPress & WooCommerce. It will help you disable a wide range of WordPress admin options you might not need.

Below you’ll find my settings for the free version of the Disable Bloat plugin. The free version is a little limited though.

Admin panel optimization:

  • Hide update notice for non-admin users

Site Performance:

  • Load comments script only when needed
  • Prevent auto-linking URLs in comments

WordPress Core:

  • Disable themes auto-updates
  • Disable plugins auto-updates

Third-party plugins bloat:

  • Remove Jetpack installation notice

25. Block Bad Bots

It’s a good idea to block bad bots to prevent unnecessary load on your server. According to CloudFlare, about 40% of internet traffic is bot traffic and a significant portion of that is malicious bots aka bad bots. Good bots are bots that help our site, like Google’s web crawler aka Google Bot that crawls your pages and indexes them on Google. Bad bots are bots hindering your site, e.g. stealing your content, scraping your email addresses to add to databases for spamming, click fraud, brute force login attempts, other hacks, credit card fraud, messing up your analytics, DDOS attacks, etc. 

The best way to block bad bots while keeping your WordPress website super fast is by using CloudFlare Enterprise, which comes free with hosting.

Note that I don’t recommend using the free CloudFlare plan. It will help block some bad bots, but it might slow down your website, especially if your website is already quite optimised. For example, if you are in Australia, it might load your website from Singapore instead because it’s cheaper for CloudFlare to load it from there. Speed isn’t the priority on the free or cheaper CloudFlare plans.

If you don’t use Cloudflare Enterprise, there are some other options:

26. Add Search Function

If your WordPress website has 100s or 1000s of pages and posts, having a simple search bar could help reduce the load on your server by reducing needless page loads.

i.e. Visitors might be able to find a blog post from the search bar, instead of clicking through endless pages in an annoying search that results in them clicking back to Google and going to a competitor website with a better user experience.

27. Paginate User Comments & Reviews

If you have 100s or 1000s of comments, it can help to speed up page loads by paginating the comments. e.g. dividing the comments section up into multiple pages each containing 30 reviews. Otherwise, you’ll have potentially 1000s of comments slowing down each page load.

28. Optimise WordPress Settings

To fine-tune WordPress, I recommend optimising your settings and general setup.

Here are the settings that I normally use:

  • Settings > Discussion > Disable ‘Attempt to notify any blogs linked to from the post’
  • Settings > Discussion > Disable ‘Allow link notifications from other blogs (pingbacks and trackbacks) on new posts’
  • If your website doesn’t have blog comments or blog authors, you can go to Settings > Discussion > Disable ‘Show Avatars’. 
  • I also like to manually approve comments so they don’t get out of control. You can do this from Settings > Discussion > Enable ‘Comment must be manually approved’
  • Remove unneeded themes and plugins
  • To help prevent brute force login attempts, 429 too many request errors, etc, I like to create a custom login URL, e.g. instead of (or /wp-admin). Note that you won’t need to do this if you are using or another hosting provider that comes packages with CloudFlare for security. Cloudflare will do a better job protecting your login page.

29. Keep WordPress, Theme, & Plugins Updated

To maintain optimal performance, it’s important to keep WordPress, your theme, and plugins up to date. What does up-to-date mean? It means you are using the latest and greatest version. In most cases, this is a good thing. Many plugins come out with performance-focused updates and security updates.

However, be careful with less-known plugins or plugins that have recently been purchased by someone else. Oftentimes these plugins get loaded with unnecessary settings, features, ads, etc, that might slow down your website.

Note that keeping WordPress, theme and plugins updated is also essential to WordPress security.

Updating tips:

  • I like to run updates once per month. If you run updates more frequently, you run the risk of conflicts between software that isn’t compatible. Quality plugins are of course tested to be compatible with WordPress, but there is no guarantee they will be compatible with your theme or other plugins. It’s common for an update to be released that causes a conflict with at least one theme or plugin out there, which requires another minor update to be compatible. But the update only happens if someone raises a support ticket with the theme/plugin developer to fix the issue, which can take a while. So it’s usually safer to wait a couple of weeks after an update is released before updating it on your own website. This way you are less likely to deal with the headache of a broken site.
  • Don’t update plugins that aren’t compatible with the latest version of WordPress. If it says ‘Compatible with WordPress: Unknown’, you can still update it, but make sure you test everything in a staging environment first.
  • It’s best to run software updates in a staging environment. If everything is working fine, then you can either push live or run the updates again for the live site.
  • Always take a backup before running software updates, even if it’s the staging site. It’s much easier to restore a website backup than fix a broken website by checking server error logs, finding the software culprit, disabling it, reinstalling the previous version, etc. The same goes for staging sites. You could just delete the staging site and create another, but I find it easier and quicker to restore a backup of the staging site if something breaks.
  • I prefer to run updates manually instead of relying on automated tools. Some hosts do this with visual regression testing aka VRT testing (e.g. Cloudways), but they don’t usually test functionality, which is more important. e.g. If you let plugins get updated automatically, and even if you are using VRT testing, you won’t know if visitors are having problems with the site, not getting email notifications, etc, until it’s too late and you’ve likely lost them as a client/customer. It’s better to test the functionality yourself after manually updating so that you know for sure everything is working properly.
  • After running software updates, test your contact forms and click through all of the key pages on your website to make sure everything is working. e.g. check the home page, shop page, category page, blog post, contact page, etc. 

30. Use Perfmatters for Remaining Optimisations

As you already know, I highly recommend using Perfmatters for a range of optimisations including:

  • Disabling many unused WordPress features to reduce bloat, e.g. Dashicons, XML-RPC, JQuery Migrate, etc.
  • Custom login URLs for sites not using Cloudflare to protect the WordPress admin login page.
  • Adding useful code snippets to the header, body and footer of each page. e.g. tracking scripts, email marketing popups, etc.
  • Optimising javascript (mostly delaying javascript until user interaction)
  • Optimising CSS (mostly removing unused CSS)
  • Disabling plugins and files on pages they aren’t needed using Script Manager
  • Optimising fonts (I prefer system fonts, but at least host fonts locally)
  • Optimising images (mostly lazy loading images and embedded videos)
  • Preloading files (mostly images and videos about the fold, but also custom fonts, audio files and a wide range of other file types)
  • Database optimisation (I do this once a month)

If you aren’t sure about a specific setting, or it causes a problem with your site, I recommend reaching out to Brett and Brian from Perfmatters. They are really good guys that provide great support. They are usually happy to configure the plugin for you too.

How to Speed Up WordPress Backend/Admin/Database

Below you’ll find the most important tips from above that will help speed up WordPress backend, admin area, and database queries.

Critical optimisations include:

  • Use better WordPress hosting with a focus on server location, NVME storage, plenty of CPU cores and RAM, and object caching. Note that object caching is especially important if you run an online store, online course, or membership site.
  • Upgrade your object caching from Redis Object Cache to Object Cache Pro.
  • Limit plugins to those essential to run your WordPress site.
  • Remove resource-intensive plugins. Use performance-focused alternatives instead.
  • Don’t use heavy page builders like Elementor, WP Bakery, Divi, etc. Your page/post editing area will be much faster if you use the default WordPress editor + a block-based builder like Generate Blocks, or Kadence Blocks.
  • Optimise your database by removing tables and autoload options from deleted plugins.
  • Remove bloat from WordPress admin using Perfmatters and Disable Bloat.
  • Use the latest PHP version available (make sure it’s compatible with your theme and plugins though).
  • Increase the WordPress Memory Limit (wp_memory_limit) to at least 256MB and the WordPress Max Memory Limit (wp_max_memory_limit) to the same or higher. The Max WordPress Memory Limit is what controls memory allocation for everything in the backend. So if you want a faster WordPress backend, make sure you increase the WordPress Max Memory Limit.
  • Make sure other PHP settings like max_input_vars, max_input_time, and max_execution_time are high enough. has set the PHP limits for my WooCommerce site ( to 100000, 600 seconds, and 600 seconds respectively. In comparison, this WordPress website is set to 100000, 30 seconds, and 60 seconds respectively.

How to Speed Up WordPress Form Submissions

There are a few things you can do to speed up WordPress form submissions. Some of them are similar to the above, but others are specific to submitting a contact form.

Critical optimisations include:

  • Use better hosting with a server location close to your target audience, NVME storage, plenty of CPU cores and RAM, and object caching.
  • Use Object Cache Pro instead of the standard Redis Object Cache.
  • Limit plugins to those essential to run your WordPress site.
  • Use a lightweight theme.
  • Use Perfmatters Script Manager to disable all plugins and files not needed, especially on pages that have forms.
  • Optimise your database by removing tables and autoload options from deleted plugins.
  • Remove bloat from WordPress admin using Perfmatters and Disable Bloat.
  • Use the latest PHP version available.
  • Use MariaDB instead of MySQL for your database.
  • Increase the WordPress Memory Limit (wp_memory_limit) to at least 256MB.
  • Make sure other PHP settings like max_input_vars, max_input_time, and max_execution_time are high enough. Again, this site is set to 100000, 30 seconds, and 60 seconds respectively.

How to Speed Up WordPress Import

Slow import processes are usually due to low resource limits set by your hosting provider.

Here are the steps you can take to speed up WordPress imports:

  • Use a better hosting provider with higher resource limits, e.g. CPU and RAM.
  • Increase your WordPress Max Memory Limit aka wp_max_memory_limit. e.g. 512MB. Note that this is different from wp_memory_limit and is the limit for memory allocated to scripts running in the backend. e.g. imports.
  • Increase maximum execution time aka max_execution_time. e.g. 600 seconds.
  • Increase maximum input time aka max_input_time. e.g. 600 seconds.
  • Increase maximum input variables aka max_input_vars. e.g. 100000.
  • Increase maximum upload file size aka upload_max_filesize. Make this larger than the file you are importing.
  • Increase maximum post size aka max_post_size. Make this larger than the file you are importing.

Just make sure you have enough server resources and high enough PHP limits to handle the import. If not, it will be slow or not work at all.

Measuring WordPress Site Speed 

When learning how to speed up WordPress, it’s important to know how to measure website speed so that you can benchmark and gauge improvements when you do start doing speed optimisation.

Measuring WordPress website speed can be done with several tools, each offering unique insights into performance.

Free Website Speed Test Tools

Here are the website speed test tools that I recommend using.

For an explanation of each tool, read this guide about free website speed test tools.

How to Measure WordPress Website Speed

Here are some steps you can follow to get a good measurement of WordPress website speed.

  1. Use Google PageSpeed Insights to check for real user data and/or simulated core web vital metrics.
  2. Use WebPageTest or Browser Stack’s SpeedLab to run tests using a real device from their location, ideally, a device that your ideal customer or client is likely to use. This is the closest you’ll get to a controlled test with real user data.
  3. If you have a global audience, use the Speed Vitals TTFB test to see how quickly your server responds to visitors in different countries. This will help you figure out whether you need a Content Delivery Network (CDN), need to use a better CDN or need to fine-tune your current CDN provider.
  4. Investigate the recommendations given by each speed testing tool.
  5. Follow the above guide about how to speed up WordPress sites.

Wrapping Up

I hope some of this 15,000-word guide about speeding up WordPress was helpful. 😅

You should now know why fast load times are important for WordPress sites, how fast your WordPress site should be, how to test website speed, and how to speed up WordPress.

If you have any questions, please leave a comment below.

Need help speeding up your WordPress site?

Check out this WordPress Speed Optimisation Service.

You might also like these articles:

Max Jacobs - Author -
Max Jacobs

My name is Max Jacobs and I’m a Web Designer, SEO and Marketing Consultant based out of Geelong, Australia. Visit my about page.

Recommendations are based on my experience building, optimising and maintaining WordPress websites over the last 7 years. However, I don't claim to be an expert or pretend that I know everything. The more I learn, the more I realise how much I don't know. 😅 I'll update these articles as I continue to learn though!

Leave a comment