How to Speed Up a WordPress Website: A Practical Step-by-Step Guide

Most WordPress speed guides start with plugins. But a cache plugin can’t fix a server that’s queueing requests, and compressing images won’t help if the connection hangs before anything loads.

This guide works from the bottom up: measure first, then fix the server, the connection, WordPress, and finally the page itself. Each step includes how to check it and how to fix it.

Step 1: Measure Before You Change Anything

Guessing wastes time. Doubling a server’s size or installing three cache plugins rarely helps if you don’t know where the delay is.

Time the page itself. On a Mac or Linux terminal:

curl -so /dev/null -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nSSL: %{time_appconnect}s\nWait: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://www.example.com

• Wait over 1 second: the server is slow to build the page.
• Wait under 0.5 seconds, but the site still feels slow: the problem is in the files the page loads, not the page itself.

Watch a real first visit. curl only fetches one file. Browsers load dozens at once, so some problems only show up there.

1. Open Chrome in an incognito window.
2. Open developer tools (Cmd + Option + I on Mac, F12 on Windows) and go to the Network tab.
3. Tick Disable cache, and make sure the filter is set to All.
4. Load the page and sort by the Time column.

Look for small files taking seconds, rows marked failed or pending, and 301 redirects.

Test when the site is “cold”. Many problems only appear on the first visit after a few quiet hours. Test then, not straight after you’ve been working on the site.

Run PageSpeed Insights for a list of specific issues, and to see how the page scores against Core Web Vitals. If it fails completely with ERR_TIMED_OUT, you have a connection problem (see Step 3), not a page problem.

Step 2: Check the Web Server

This is the most overlooked step, and it can be the biggest win.

Look for a request queue

If tiny files (1–5 KB) take 5, 10, 15, 20 seconds in neat steps, requests are waiting in a queue. The server only lets a few in at a time.

On Apache, check the mode and limits:

sudo apache2ctl -V | grep -i mpm
sudo grep -rn "MaxRequestWorkers\|KeepAliveTimeout" /etc/apache2/ | grep -v "#"

If you see prefork with a low MaxRequestWorkers (like 5), that’s your bottleneck. Some preconfigured server images, including Lightsail’s newer WordPress instance, ship this way to save memory.

Switch Apache to event mode with PHP-FPM

In prefork mode, every request, even a small image, takes up a heavy worker. In event mode, static files use lightweight threads and only PHP pages go to a separate PHP-FPM pool.

On Debian or Ubuntu with PHP 8.2 (swap in your PHP version, from php -v):

sudo apt update && sudo apt install -y php8.2-fpm
sudo a2dismod php8.2 mpm_prefork
sudo a2enmod mpm_event proxy_fcgi setenvif
sudo a2enconf php8.2-fpm
sudo systemctl enable --now php8.2-fpm
sudo apache2ctl configtest && sudo systemctl restart apache2

To undo it if anything breaks:

sudo a2dismod mpm_event proxy_fcgi && sudo a2disconf php8.2-fpm
sudo a2enmod mpm_prefork php8.2 && sudo systemctl restart apache2

If you’d rather stay on prefork, at least raise the limits. On a 1 GB server, 12 workers and a 2-second keep-alive is a safe starting point.

Match your PHP settings

PHP-FPM reads its own settings file (/etc/php/8.2/fpm/php.ini), not the one Apache used. Check for differences before you test:

grep -E "^(memory_limit|max_input_vars|post_max_size|upload_max_filesize)" /etc/php/8.2/apache2/php.ini /etc/php/8.2/fpm/php.ini
diff <(ls /etc/php/8.2/apache2/conf.d) <(ls /etc/php/8.2/fpm/conf.d)

Page builders like Elementor need more than PHP’s defaults. Sensible values:

memory_limit = 256M
post_max_size = 16M
max_input_vars = 3000
max_execution_time = 300

If a line starts with ;, it’s switched off. Remove the ; on the lines you change. Then restart:

sudo systemctl restart php8.2-fpm

Don’t upgrade the server until you’ve checked

If doubling the CPU and memory doesn’t help, the problem is a limit or a setting, not a lack of power. Keep an eye on memory with free -h. As long as “available” stays above about 150 MB, you’re fine.

Step 3: Check DNS and the Connection

Remove AAAA records you don’t need

If your DNS has AAAA (IPv6) records pointing at a server whose IPv6 address isn’t static, they can end up pointing nowhere after a resize or rebuild. Connections that try IPv6 hang until they time out, which looks like a random 30-second load.

If you’re behind Cloudflare’s proxy, you don’t need AAAA records to your server at all. Cloudflare serves IPv6 visitors itself and talks to your server over IPv4.

Use the right SSL setup with Cloudflare

• Set SSL/TLS to Full (strict). “Flexible” causes redirect loops on WordPress.
• Consider a free Cloudflare Origin Certificate on the server. It lasts 15 years and doesn’t depend on Let’s Encrypt renewals, which can break when a server is copied or resized.
• Turn on Always Use HTTPS so http:// visits go straight to HTTPS.

Pick one address and redirect the rest

Choose www or non-www and 301-redirect everything else to it: the other version, http://, and the bare IP. Every extra redirect is a wasted round trip, and two loading versions of the site is bad for SEO. If you’re mid-migration, our guide on moving a website without losing rankings covers redirects in more depth.

Step 4: Fix WordPress’s Background Work

Move WP-Cron to a real timer

WordPress runs its scheduled tasks (update checks, clean-ups) when a visitor loads a page. On a quiet site, the first visitor after a long gap waits for all of it.

Turn that off in wp-config.php:

define( 'DISABLE_WP_CRON', true );

Then run the tasks every 5 minutes from the server instead:

sudo apt install -y cron
sudo crontab -u www-data -e

Add:

*/5 * * * * cd /var/www/html && /usr/local/bin/wp cron event run --due-now >/dev/null 2>&1

Adjust the path to your WordPress folder, and check where wp is with which wp.

Let the server talk to itself directly

WordPress regularly calls its own address. Behind Cloudflare, those calls go out to the internet and back, and can get caught by bot protection. Point your domain at the server itself in /etc/hosts:

127.0.0.1 www.example.com example.com
::1 www.example.com example.com

Check it with getent hosts www.example.com. It should show 127.0.0.1 or ::1.

Remove plugins you don’t use

Every plugin adds code to each page load. Some, like Jetpack, also call outside servers regularly. If you only use one feature of a large plugin, look for a lighter alternative. While you’re in there, make sure what’s left is up to date — our guide on updating plugins safely covers doing that without breaking the site.

Step 5: Add Caching

Page caching

A page cache plugin saves a ready-made copy of each page, so WordPress doesn’t rebuild it for every visitor. Keep it simple:

• W3 Total Cache: turn on Page Cache (Disk: Enhanced) and Browser Cache. Leave Minify, Database Cache and Object Cache off. Minify often breaks Elementor layouts.
• WP Super Cache: a simpler option. Turn it on and keep the defaults.

If the plugin asks for FTP details or can’t write files, it needs permission. Add these to wp-config.php:

define( 'WP_CACHE', true );
define( 'FS_METHOD', 'direct' );

And give WordPress ownership of its content folder:

sudo chown -R www-data:www-data /var/www/html/wp-content

Cloudflare caching

Cloudflare caches images, CSS and JavaScript, but by default often only for 4 hours. After that, the next visitor waits while every file is fetched from your server again.

1. Go to Caching → Configuration and set Browser Cache TTL to 1 month or 1 year.
2. Go to Caching → Cache Rules and create a rule: if the URI path contains /wp-content/ or /wp-includes/, set Edge TTL to 1 month.

Updated files don’t get stuck, because WordPress adds version numbers to CSS and JS files (?ver=4.3.4). If you replace an image under the same name, use Purge Everything.

Check it works by running this twice. The second result should say HIT:

curl -sI https://www.example.com/wp-includes/js/jquery/jquery.min.js | grep -i cf-cache-status

Step 6: Make the Page Lighter

Elementor settings

In Elementor → Settings → Performance:

• CSS Print Method: External File
• Optimized Image Loading: Enable
• Optimized Gutenberg Loading: Enable
• Lazy Load Background Images: Enable
• Load Google Fonts Locally: Enable
• Element Cache: 1 week

In the Features tab, set Inline Font Icons and Optimized Markup to Active. Avoid experiments marked Alpha on a live site.

Then go to Elementor → Tools and click Clear Files & Data, so the changes take effect.

Images

• Resize images before uploading. Around 2000px wide is plenty for most layouts.
• Convert to WebP, either with a plugin like Converter for Media or before uploading.
• Check your logo. PageSpeed often flags a logo uploaded at 3–4 times the size it’s shown at.

Fonts

Fonts loaded from Google’s servers add an extra connection before text can appear. Loading them locally (see Elementor above) removes that step and helps with GDPR too, since visitor IP addresses are no longer sent to Google. If that’s a concern for your site, our GDPR compliance team can review how your site handles third-party services.

Step 7: Test Again

After each change, purge your caches (the plugin, then Cloudflare) and repeat Step 1:

• curl timings, direct to the server and through Cloudflare
• Chrome Network tab in incognito with cache disabled
• PageSpeed Insights
• A cold test after a few idle hours

Change one thing at a time where you can. That way you know what actually helped.

Quick Checklist

1. Measure: curl, Chrome Network tab, PageSpeed, cold test.
2. Check Apache mode and worker limits; switch to event + PHP-FPM.
3. Match PHP-FPM settings to what your site needs.
4. Remove unneeded AAAA records; use Full (strict) SSL.
5. Redirect everything to one address.
6. Move WP-Cron to a server cron job.
7. Point your domain to the server in /etc/hosts.
8. Remove unused plugins.
9. Add a simple page cache.
10. Extend Cloudflare cache times for static files.
11. Tune Elementor performance settings.
12. Resize and convert images; load fonts locally.
13. Test again, cold.

If your site is slow and you’d rather not spend an afternoon in the terminal, the hosting team at Matrix Internet tunes and manages WordPress servers for businesses across Ireland, and our technical support team keeps them that way. If the site isn’t slow but down, start with our guide on why websites go down instead.