WordPress Site Slow? 5 Causes and How to Fix Each

A WordPress site slow enough to lose visitors almost always has one of five problems: slow hosting, oversized images, a heavy theme with too many plugins, no page caching, or a cluttered database. Measure first so you know which one you have, then fix them in that order, because hosting and images usually decide whether the rest is worth doing.

I’m Zain Saeed, a WordPress and Shopify developer. I’ve shipped 120+ projects over 8+ years and won Fiverr’s Millionaire Award for $1M+ in orders. Speed fixes are some of the most common jobs I get, and the same five problems come up on most of them.

Short answer, what to check first:

• Server response time (TTFB): if the server is slow to send the first byte, nothing else will make the site feel fast.
• Image weight: a single full-size photo in the hero section can be bigger than the rest of the page combined.
• Theme and plugins: every plugin that loads CSS and JavaScript on every page adds work for the browser.
• Page caching: without it, WordPress rebuilds the same page with PHP and database queries for every visitor.
• Database: old revisions, expired transients and large autoloaded options slow down the admin and uncached pages.

How to measure before you change anything

Run your homepage and one important inner page (a service page or product page) through PageSpeed Insights. Look at the field data at the top first, because that is what real visitors experienced. Google’s Core Web Vitals guidance sets the “good” targets as Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) of 200 milliseconds or less, and Cumulative Layout Shift (CLS) of 0.1 or less, measured at the 75th percentile of page loads.

Also check Time to First Byte. Google’s TTFB article calls 0.8 seconds or less good and more than 1.8 seconds poor. You can get a rough number from any terminal:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://yourdomain.com/

Run it a few times. If the first request is slow and later ones are fast, caching is working but the server is slow when the cache is empty. If every request is slow, start with hosting.

Which fix to do first

What you see	Likely cause	Start with
High TTFB on every request	Hosting or old PHP	PHP update, then hosting
Poor LCP, fine TTFB	Images	Resize, convert, check the hero image
Poor INP	Scripts from plugins, theme or third parties	Plugin and script audit
Fast for repeat visits, slow for first	Cache or slow server on cache misses	Caching setup, then hosting
Slow admin and search	Database	Revisions, transients, autoload

Change one thing at a time and measure again. Field data in PageSpeed Insights comes from real visitors and changes slowly, so use the lab numbers to confirm each step and check the field data again a few weeks later.

1. Slow hosting

Symptom: TTFB is high on every request, the site stalls when traffic rises or a backup runs, and the admin is slow even when nobody else is on the site.

Cause: The WordPress optimization handbook says plainly that your hardware has a large effect on performance: processor, memory and storage all matter. Budget shared plans put many sites on one server and limit how much CPU each one can use, so your site waits in line. Old software is the other common cause. WordPress’s requirements page recommends PHP 8.3 or greater and MySQL 8.0 or MariaDB 10.11 or greater, and many older hosting accounts still run versions well below that.

Fix:

• Update PHP in your hosting panel after testing on a staging copy. This is often the cheapest speed fix there is.
• Check that OPcache is on. The handbook lists PHP accelerators like OPcache as a standard server optimization.
• Move to better hosting if TTFB stays poor after that. A managed WordPress host or a small VPS with a control panel both work. Pick a data center close to most of your visitors.

2. Oversized images

Symptom: PageSpeed Insights flags “Properly size images” or “Serve images in next-gen formats”, and LCP is over 2.5 seconds on mobile. The LCP element is usually the hero image.

Cause: Photos uploaded straight from a phone or stock site are often several thousand pixels wide and several megabytes, then shown in a container a fraction of that size. The browser still downloads the whole file.

Fix:

• Resize before upload or set a maximum width. 1920px is enough for full-width images on most sites.
• Convert to WebP or AVIF. WordPress 6.5 added AVIF support, but it depends on your server’s image library. Check Tools > Site Health > Info > Media Handling to see which formats your server supports. An image optimization plugin can bulk-convert the existing library.
• Do not lazy-load the hero image. WordPress adds loading="lazy" to images that have width and height attributes, and it tries to skip the first images on the page. Some themes and plugins override this and lazy-load the LCP image anyway, which delays it. Check the hero image’s HTML and make sure it has no loading="lazy".

3. A heavy theme and too many plugins

Symptom: “Reduce unused JavaScript” and “Reduce unused CSS” list a long run of files. Pages load slider, gallery or form scripts on pages that have no slider, gallery or form. INP is poor because the browser is busy running scripts when the visitor taps something.

Cause: Multipurpose themes ship every feature and often load the assets for all of them on every page. Each plugin you add may also load its own files sitewide. The WordPress handbook’s first recommendation here is simple: deactivate and delete plugins you do not need.

Fix:

• Audit plugins. List what each one does. Remove duplicates (two SEO plugins, two form plugins) and anything unused.
• Find the slow ones. The free Query Monitor plugin shows which plugins add database queries and scripts to a page.
• Stop assets loading where they are not used. An asset manager plugin can unload a form plugin’s scripts on every page except the contact page.
• Review third-party scripts. Chat widgets, tag managers, heatmaps and ad pixels are frequent causes of poor INP. Keep only the ones someone actually uses.
• Consider a lighter theme if the theme itself is the problem. I explain what to look for in how to choose the right WordPress theme.

4. No page caching or CDN

Symptom: Every page view is as slow as the first one. TTFB is high for all visitors, and the server struggles during traffic spikes.

Cause: WordPress builds each page with PHP and database queries. The handbook notes that without caching, performance can grind to a halt as more requests come in, and that a caching plugin serving pages as static files can make fairly static pages much faster.

Fix:

• Use one page cache. If your host runs LiteSpeed, use its LiteSpeed Cache plugin. Many managed hosts have caching built in, so check before adding a plugin. On other servers, use a single caching plugin. Two caching plugins at once cause more problems than they solve.
• Add a CDN for images, CSS and JavaScript so visitors far from your server get files from a nearby location. Cloudflare’s free plan is a common starting point.
• Exclude dynamic pages such as cart, checkout and account pages on WooCommerce stores.

A caching plugin is not the only way to get good scores. I cover a different approach in how to reach 90+ PageSpeed on WordPress without a speed plugin.

5. A cluttered database

Symptom: The admin is slow, saving a post takes several seconds, and search, filter and archive pages are slow even when the rest of the site is cached.

Cause: Years of post revisions, expired transients, data left behind by deleted plugins and large autoloaded options. The WordPress handbook warns that too many autoloaded options can slow down your site, because they load on every request. WooCommerce stores can also build up large session and order tables.

Fix: Take a full backup first. Then limit revisions in wp-config.php, delete expired transients and look at your largest autoloaded options:

# In wp-config.php: keep at most 5 revisions per post
define( 'WP_POST_REVISIONS', 5 );

# Delete expired transients
wp transient delete --expired

# List the 20 largest autoloaded options
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload IN ('yes','on') ORDER BY size DESC LIMIT 20;"

If a large autoloaded option belongs to a plugin you deleted, it can usually go. If it belongs to an active plugin, leave it and check that plugin’s settings instead. When you are not sure, do not delete it.

Frequently asked questions

Why is my WordPress site slow only on mobile?

Phones have slower processors and often slower connections, so heavy images and JavaScript hurt more there. PageSpeed Insights tests mobile with a throttled device, which is why mobile scores are usually lower than desktop.

Will a caching plugin fix a slow WordPress site?

It helps with server response time, but it does not shrink images or remove unused scripts. If LCP or INP is the problem, caching alone will not fix it.

How many plugins is too many?

There is no fixed number. One poorly built plugin that loads scripts on every page can do more harm than ten small ones. Judge plugins by what they load and query, not by how many you have.

Should I change hosting first?

Only if TTFB is poor after you update PHP and set up caching. If TTFB is good and the site is still slow, the problem is on the page itself: images, theme or scripts.

Can I fix WordPress speed myself?

Updating PHP, resizing images and removing unused plugins are fine to do yourself on a staging copy. Database cleanup and unloading scripts can break things, so get help if you are not comfortable with backups and testing.

If you would rather have someone do this for you, I handle WordPress speed optimization as a fixed-price job. If you want a fixed-price quote for your WordPress or Shopify project, send me a short brief and I’ll tell you what it will take.