Speed Up a Slow WordPress Site: A Practical Checklist

If your WordPress site takes five-plus seconds to load, you're not just annoying visitors - you're losing them. Google's own research says most people abandon a page that takes longer than three seconds, and slow sites also rank worse. The good news: on shared or VPS hosting, a slow WordPress site almost always comes down to a short list of fixable causes. Here's how to actually find and fix yours.

Symptom: What "Slow" Really Looks Like

Before you touch anything, get a baseline. "Slow" is subjective, but load time isn't. Run your homepage and one inner page through PageSpeed Insights and GTmetrix, and note three numbers: Time to First Byte (TTFB), Largest Contentful Paint (LCP), and total page size. If TTFB alone is over 600ms, the problem is server-side - PHP, database, or hosting resources. If TTFB is fine but LCP is high, the problem is front-end - images, fonts, render-blocking scripts.

Common Causes of a Slow WordPress Site

1. No caching layer

Every uncached request means WordPress rebuilds the page from scratch - PHP runs, the database gets queried, and the theme renders. On a busy site, that's the single biggest performance killer. If you don't have a page cache plugin active, this is almost certainly your top issue.

2. Bloated or conflicting plugins

Fifteen plugins isn't automatically a problem, but plugins that hook into init, wp_head, or run database queries on every page load add up fast. Old, abandoned plugins are especially common offenders because they were never optimized for current PHP versions.

3. Unoptimized images

A 4MB PNG hero image straight from a phone camera is one of the most common speed problems we see. Large, uncompressed, non-lazy-loaded images inflate LCP more than almost anything else on the page.

4. Database bloat

Post revisions, spam comments, expired transients, and orphaned metadata pile up quietly for years. A `wp_options` table with tens of thousands of autoloaded rows will slow down every single page request, even cached ones during cache misses.

5. Old PHP version or no opcache

PHP 8.1+ is significantly faster than PHP 7.x for typical WordPress workloads, and OPcache alone can cut execution time noticeably by caching compiled PHP bytecode between requests.

6. Hosting plan doesn't match the traffic

Shared hosting has finite CPU and memory per account. If your site is consistently near its resource limits, no amount of plugin tuning will fully fix it - you need more headroom, not more configuration.

The Fix: A Practical Speed Checklist

Step 1 - Turn on real caching

Install a caching plugin (WP Rocket, W3 Total Cache, or LiteSpeed Cache if your host runs LiteSpeed) and enable page caching plus browser caching. On Getwebup's LiteSpeed-based plans, LiteSpeed Cache is free and integrates directly with the server, which beats a PHP-only caching plugin.

Step 2 - Compress and lazy-load images

Run existing media through an optimizer (ShortPixel, Imagify, or the built-in tools in most caching plugins) and enable lazy loading for anything below the fold. Convert large hero images to WebP where your theme supports it - the file size drop is often 60-80% with no visible quality loss.

Step 3 - Clean the database

Use a plugin like WP-Optimize or run it manually via phpMyAdmin in cPanel:

DELETE FROM wp_posts WHERE post_type = 'revision';
DELETE FROM wp_options WHERE option_name LIKE '_transient_%';
OPTIMIZE TABLE wp_options, wp_posts, wp_postmeta;

Always take a backup before running direct SQL - see our cPanel backup guide first.

Step 4 - Upgrade PHP and enable OPcache

In cPanel, go to Software > MultiPHP Manager and set your domain to PHP 8.1 or newer, provided your theme and plugins support it (check plugin changelogs first). Then confirm OPcache is enabled under MultiPHP INI Editor - most Getwebup plans have it on by default.

Step 5 - Deactivate what you don't use

Deactivated plugins still take up disk space but stop executing code on every request. Go through your plugin list and remove anything you haven't used in the last six months - each one you cut is fewer database queries and fewer hooks firing per page load.

Step 6 - Add a CDN

A CDN (Cloudflare's free tier is a solid starting point) caches static assets - images, CSS, JS - at edge locations close to your visitors, which cuts latency dramatically for users far from your server's data center.

When Configuration Isn't Enough

If you've done all of the above and TTFB is still consistently over 500ms under normal traffic, the bottleneck is resources, not configuration. That usually shows up as high CPU or memory usage in cPanel's Resource Usage panel during traffic spikes. At that point, moving from shared hosting to a VPS - where you're not sharing CPU cycles with other accounts - is the real fix, not another plugin.

Prevention: Keep It Fast Going Forward

• Test new plugins on a staging site before installing on production - a single badly-coded plugin can undo everything above.
• Schedule a monthly database cleanup instead of letting revisions and transients pile up for a year.
• Compress images before uploading rather than relying entirely on a plugin to fix it after the fact.
• Recheck your PageSpeed score after any major plugin or theme update - regressions creep in silently.
• Keep an eye on cPanel resource usage graphs so you catch a creeping traffic increase before it becomes a crisis.

A slow WordPress site is rarely one big problem - it's usually four or five small ones stacked on top of each other. Work through the checklist above in order, measure after each step, and you'll generally see the biggest jump right after enabling caching and fixing images - often before you touch anything else.