WordPress Slow Site Speed Checklist: Find and Fix the Bottleneck

A slow WordPress site is almost never slow for one reason. Hosting, uncached PHP, oversized images, heavy plugins and a bloated database all add up. The trick is to measure first so that you fix the biggest cost, not the one that is easiest to tweak.

This checklist is ordered by how often each item turns out to be the real problem. Work from the top and re-measure after each change.

Step 0: Measure before changing anything

Pick three representative URLs: the home page, a typical post or product, and a heavy page such as the checkout or a page-builder landing page. Record these for each:

Time to First Byte (TTFB): how long the server takes to start answering. This isolates hosting, PHP and database speed from front-end weight.
Total page weight and number of requests.
Core Web Vitals: LCP, INP and CLS.

Use the वेबसाइट स्पीड टेस्ट for the timing breakdown, the पेज वेट एनालाइज़र to see which resources are heavy, and the Core Web Vitals checker for the metrics Google uses. A quick TTFB measurement from the command line:

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com/

Run it three times and ignore the first (cold cache). As a rule of thumb, a cached WordPress page should have a TTFB well under half a second; Google's own guidance for good TTFB is 800 ms or less. If TTFB is high, work on server-side items (hosting, caching, database). If TTFB is low but the page still loads slowly, the problem is front-end weight (images, scripts, fonts). The reduce TTFB guide goes deeper on the server side, and the Core Web Vitals guide explains the metrics.

Step 1: Hosting and PHP

If an uncached request takes more than a second just to start, the server is the bottleneck, and no front-end optimization will fix it.

Plan type. Cheap shared hosting with hundreds of sites per server is the most common cause of slow TTFB. A managed WordPress host or a small VPS gives more consistent performance. See VPS vs shared hosting reliability और choosing web hosting for uptime.
PHP version. Newer PHP releases are noticeably faster than old ones. Check which version you run (wp cli info or Tools, Site Health, Info) and move to a currently supported release after testing plugins on staging.
PHP-FPM and OPcache. OPcache should be enabled; without it PHP recompiles every file on every request. php -i | grep opcache.enable.
HTTP/2 or HTTP/3 and TLS. Check with the HTTP/2 and HTTP/3 checker. Use the Website Hosting Checker to confirm where your site really sits and whether the server is far from your audience.
Server location. Latency to a server on another continent adds hundreds of milliseconds per uncached request, which a CDN only partly hides.

Step 2: Page caching

WordPress builds each page with PHP and dozens of database queries. A page cache stores the finished HTML so that most visits skip all that work. It is the single biggest speed gain for most sites.

Use one caching plugin or the host's built-in cache, not several. Two caches fight each other.
Confirm it works by checking response headers with the HTTP Header Checker. Look for a cache header such as X-Cache, cf-cache-status or a plugin-specific header, and compare TTFB between the first and second request.
Exclude pages that must not be cached: cart, checkout, account pages, and anything with personal content. Logged-in users are usually bypassed by default.
Enable gzip or Brotli compression, and browser caching with long Cache-Control max-age values for static files. For nginx:

gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

location ~* \.(?:css|js|jpg|jpeg|png|gif|webp|avif|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Only use immutable for files whose names change when their content changes (most optimization plugins version file names with a query string or hash).

Add a persistent object cache (Redis or Memcached) if your host supports it. It speeds up logged-in and dynamic pages, such as WooCommerce and membership sites, which page caching cannot help. Install the matching WordPress object-cache drop-in and check it with wp redis status if you use the Redis plugin's WP-CLI commands.

Step 3: A CDN

A content delivery network serves images, CSS and JavaScript from locations near the visitor and can also cache full pages. Check whether you already have one with the CDN डिटेक्टर. If you add one, see CDN explained और Cloudflare cache rules and purge. Remember that a CDN does not fix a slow origin for uncached pages.

Step 4: Images

Images are the biggest part of most pages and the easiest to shrink.

Resize to the displayed size. A 4000 pixel photo shown at 800 pixels wastes bandwidth.
Use modern formats. WordPress core supports WebP uploads and generation, and since 6.5 supports AVIF uploads, depending on your server's image library. See image optimization with WebP and AVIF.
Compress: re-encode at quality around 75 to 85 for photos.
Lazy load below-the-fold images (WordPress does this by default with loading="lazy"), but do not lazy load the main hero image, since that delays your Largest Contentful Paint. WordPress core tries to skip lazy loading for the first content image, but check page-builder output.
Set width and height attributes to avoid layout shift.

Regenerate thumbnails in bulk after changing sizes, using WP-CLI if the regeneration command is installed (wp media regenerate --yes).

Step 5: Plugins, themes and third-party scripts

More plugins do not always mean slower, but some plugins load scripts and styles on every page, run heavy queries on each request, or call remote APIs.

List what is active: wp plugin list --status=active.
Profile with a query monitor plugin or WP-CLI's profile package to see slow hooks and queries: wp profile stage --all (requires installing wp package install wp-cli/profile-command).
Remove plugins you do not use. Deactivated plugins do not run, but outdated ones still pose a security risk.
Replace a plugin that loads 500 KB of assets on every page for a feature used on one page with a lighter option, or load its assets only where needed.
Page builders and bloated multipurpose themes often ship large CSS and JS. Compare against a lightweight theme on a test copy.
Third-party scripts (chat widgets, analytics, ad tags, social embeds, fonts) can dominate load time. The थर्ड-पार्टी स्क्रिप्ट चेकर lists them, and you can delay non-critical ones until user interaction.

Step 6: Database health

A years-old site accumulates data that slows queries.

wp db size --tables
wp transient delete --expired
wp post delete $(wp post list --post_type=revision --format=ids) --force
wp db optimize

Be careful with the revisions command: only run it with a backup, and limit future revisions in wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

Common database culprits:

Autoloaded options. Everything with autoload = yes loads on every request. Check the total size: wp db query "SELECT SUM(LENGTH(option_value))/1024 AS kb FROM $(wp db prefix)options WHERE autoload IN ('yes','on','auto-on','auto');". If the total is several megabytes, find the largest rows and see which plugin owns them. (WordPress 6.6 changed how autoload values are stored, so the values differ across versions; check both yes and the newer values as in the query.)
Expired transients and leftover plugin tables from software you removed.
Slow queries from a large wp_postmeta table, which grows quickly with WooCommerce and custom fields. Enabling the slow query log on a VPS identifies the offenders: slow_query_log = 1 and long_query_time = 1 in the MySQL config.

Step 7: Background work

WP-Cron runs scheduled tasks when visitors load pages, which can slow the unlucky request that triggers a heavy task. Moving it to a real system cron removes that cost. See WP-Cron explained and fixed. The Heartbeat API also makes admin AJAX calls every 15 to 60 seconds in the editor and dashboard, which loads the server if several editors are logged in; a plugin or snippet can limit its frequency.

Step 8: Re-measure and monitor

After each change, repeat the Step 0 measurements and keep a simple log of what you changed and the result. Rolling back a change that did not help is easier when you know which one it was.

Then keep an eye on it. Slowness often returns after a plugin update or traffic growth. An uptime monitor records response times, and a rising trend is an early warning. If the slowness is intermittent and you cannot find a pattern, see the general website slow diagnosis guide.

Quick checklist

Measure TTFB and page weight on three URLs.
Server slow? Upgrade PHP, plan or host.
Enable one page cache and verify cache headers.
Add a CDN for static files.
Compress, resize and convert images.
Remove or replace heavy plugins and scripts.
Clean the database and autoloaded options.
Move WP-Cron to a system cron.
Re-measure and set up monitoring.

अगले कदम

Test your site with the वेबसाइट स्पीड टेस्ट and the Core Web Vitals checker.
See what makes pages heavy with the पेज वेट एनालाइज़र.
Find slow external scripts with the थर्ड-पार्टी स्क्रिप्ट चेकर.
Read reduce time to first byte.
Watch response times with the uptime monitor.

सामान्य प्रश्न

What is a good load time for a WordPress site?

There is no single number, but for most sites a cached page that starts responding in under 800 ms and has a Largest Contentful Paint under 2.5 seconds is a sound target, in line with Google's published Core Web Vitals thresholds.

Do I need a caching plugin if my host has caching?

Often no. If the host provides server-level caching, adding a second page cache plugin can cause conflicts or stale pages. Use the host's cache and add a plugin only for extras such as file optimization, and test after each change.

How many plugins is too many?

The count matters less than what each plugin does. Ten well-built plugins can be lighter than one badly built plugin. Measure with a profiler, and disable suspects one at a time on a staging copy.

Why is my admin slow but the front end fast?

Page caching speeds up visitors but not logged-in users. A slow dashboard points to the server, object cache, heavy admin plugins, the Heartbeat API or a big database. Try an object cache first.

Will upgrading PHP make my site faster?

Usually yes, since newer PHP versions execute WordPress code more efficiently. Test on a staging copy first, because older plugins can break on new versions.

Get notified when this guide updates

Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.