How to Speed Up Your WordPress Website: 10 Proven Techniques

Most slow WordPress sites are slow for boring reasons: an underpowered host, no page cache, oversized images, and forty plugins each loading a stylesheet on every page. Fix those four and you will pass Core Web Vitals on most sites without touching a line of code. The ten techniques below are ordered by impact per hour of effort, based on the performance audits we run on community and WooCommerce sites, and they reflect what WordPress core itself now does for you after the 6.8 and 6.9 releases.

Before you change anything, get a baseline. Run the page through PageSpeed Insights and note the field data (the “Discover what your real users are experiencing” section), not just the lab score. Google’s thresholds are 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint and 0.1 for Cumulative Layout Shift, measured at the 75th percentile of real visits. Those three numbers are what you are trying to move.

1. Fix the hosting before the plugins

Time to First Byte is the floor under every other metric. If your server takes 1.2 seconds to start sending HTML, no caching plugin will get LCP under 2.5 seconds on mobile. Check TTFB in the PageSpeed report or with curl -o /dev/null -s -w "%{time_starttransfer}\n" https://yoursite.com/. Anything consistently over 600 ms on an uncached page means the host, PHP version or database is the bottleneck.

Concrete things to check in your hosting panel: PHP 8.2 or newer (PHP 8.x is roughly 2x faster than 7.4 on WordPress benchmarks), OPcache enabled, MySQL 8 or MariaDB 10.6+, and HTTP/2 or HTTP/3 on the web server. Shared hosting at $3 a month can run a brochure site fine. It cannot run BuddyPress with 5,000 members or a WooCommerce store with 2,000 products. For those, a managed WordPress host or a properly configured VPS is not optional.

2. Add a page cache (and know when it does not help)

A page cache stores the finished HTML so repeat requests skip PHP and MySQL entirely. It is the single biggest win for anonymous traffic. Options, in rough order of how often we recommend them:

Plugin	Cost	Best fit
LiteSpeed Cache	Free	Any host running LiteSpeed or OpenLiteSpeed; server-level cache, very fast
WP Rocket	$59/year for one site	Apache/Nginx hosts where you want caching plus asset optimisation in one place
Host-level cache (Kinsta, WP Engine, Cloudways, SiteGround)	Included	Use it and skip the plugin layer unless you need specific features
Cloudflare APO	$5/month	Global audience; caches full HTML at the edge

Now the caveat that matters for our readers. Page caching only serves logged-out visitors. A BuddyPress or BuddyBoss community where 80 percent of page views come from logged-in members gets almost nothing from it, and the same is true of a LearnDash site where students are always signed in. For those sites, techniques 3, 6 and 7 matter far more than the cache plugin.

3. Install a persistent object cache

WordPress caches database query results in memory for the length of one request and then throws them away. A persistent object cache (Redis or Memcached) keeps them between requests. On logged-in-heavy sites this is the cache that actually helps, because BuddyPress activity streams, member queries and LearnDash progress lookups are all expensive and repeated.

Site Health (Tools → Site Health) has flagged a missing persistent object cache since WordPress 6.1, so check there first. Most managed hosts offer Redis as a toggle. On your own server, install Redis, then the free Redis Object Cache plugin, and click Enable Object Cache under Settings → Redis. We have seen admin dashboards on large BuddyPress sites go from 3 seconds to under 1 second from this change alone.

4. Get images under control

Images are the LCP element on most pages, so they deserve more attention than any other asset. The checklist:

1. Serve WebP or AVIF. WordPress has generated WebP on upload since 6.1 and supports AVIF since 6.5 (April 2024). Plugins like ShortPixel, Imagify or EWWW convert the existing library and handle the fallback.
2. Size images to the container. A 2400 px hero image in a 1200 px slot is wasted bytes. Check the “Properly size images” audit in PageSpeed.
3. Do not lazy-load the hero. WordPress 6.9 (December 2025) stopped adding loading="lazy" to the first image and adds fetchpriority="high" to the likely LCP image automatically. If you override this in a theme or plugin, you are undoing a measurable LCP gain.
4. Always output width and height attributes so the browser reserves space. This is where most CLS problems come from. 6.9 also added them to the Video block for the same reason.

For user-generated content (BuddyPress avatars, cover images, media in activity posts) set upload size limits and make sure the image plugin processes those directories too; several only watch the standard uploads folder by year and month.

5. Turn on a CDN

A CDN serves static files from a server near the visitor. Cloudflare’s free plan is enough for most sites and also gives you HTTP/3, Brotli compression and a basic WAF. Point your DNS at Cloudflare, set the SSL mode to Full (strict), and enable Auto Minify and Brotli under Speed. If most of your audience is in one country and your server is already there, the gain is smaller, but the security benefits alone justify it.

6. Cut the plugin and asset weight

Plugin count matters less than what each plugin loads. A contact form plugin that enqueues its CSS and JavaScript on every page, when the form only appears on one, is the classic offender. Two ways to deal with it:

• Audit with Query Monitor. This free plugin lists every script and style on a page with the plugin responsible. Look for anything loading where it is not used.
• Unload conditionally. Perfmatters ($24.95/year) and Asset CleanUp let you disable specific assets per page or post type without writing code. We covered the latter in our Asset CleanUp review.

WordPress 6.9 helps here on classic themes by loading block styles on demand instead of one large block-library stylesheet, which cut CSS by around 45 percent on simple pages in core’s testing. It also dequeues scripts and styles for blocks that are present but hidden. If a plugin breaks because of this, the opt-out is add_filter( 'should_load_separate_core_block_assets', '__return_false' );, but try to fix the plugin first.

7. Clean the database and the autoloaded options

Every WordPress request loads all options marked autoload = yes from the wp_options table. Plugins that were deleted years ago often leave hundreds of kilobytes behind. Check the total with:

SELECT SUM(LENGTH(option_value)) / 1024 AS autoload_kb
FROM wp_options WHERE autoload IN ('yes', 'on');

Under 800 KB is fine. Over 1 MB and you should find the largest rows (ORDER BY LENGTH(option_value) DESC LIMIT 20) and either delete orphaned ones or set them to not autoload. WP-CLI makes this painless: wp option list --autoload=on --fields=option_name,size_bytes --format=table. Also clear post revisions, expired transients and spam comments; WP-Optimize or Advanced Database Cleaner handles that on a schedule.

BuddyPress sites have an extra job: the activity and notifications tables grow fast. Pruning read notifications older than a year and archiving very old activity keeps those queries quick. Our performance optimisation service does this routinely on community sites where the activity table has passed a few million rows.

8. Use the performance features already in WordPress core

The Core Performance Team has shipped several features since 2025 that most site owners have never switched on.

Speculative loading (6.8, April 2025)

WordPress now outputs Speculation Rules that tell Chromium browsers to prefetch a page the moment a visitor starts clicking a link. The default is “prefetch” with “conservative” eagerness, applied to logged-out visitors on sites with pretty permalinks. You can make it more aggressive with a filter:

add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
    if ( is_array( $config ) ) {
        $config['mode']      = 'prerender';
        $config['eagerness'] = 'moderate';
    }
    return $config;
} );

Test before going to prerender on a WooCommerce site; prerendering “add to cart” links can have side effects. Use wp_speculation_rules_href_exclude_paths to leave those out.

Script priorities (6.9)

wp_enqueue_script() accepts a fetchpriority argument, and script modules can now load in the footer. Interactivity API scripts default to low priority. Theme and plugin authors should set 'fetchpriority' => 'low' on anything not needed for first paint.

Plugins from the Performance Team

The Performance Lab plugin on WordPress.org bundles experiments that later land in core, including Enhanced Responsive Images, Image Prioritizer and Embed Optimizer. They are stable enough for production and are a cheap way to get next year’s core improvements now.

9. Pick a theme that does not fight you

A theme that loads a 400 KB icon font, three slider libraries and jQuery UI on the homepage cannot be fixed with a cache plugin. When you choose one, test the demo in PageSpeed before buying. For community sites we build BuddyX with this in mind: no page builder dependency, assets loaded only where BuddyPress needs them, and the logged-in pages kept light because those are the pages members actually see. Whatever theme you use, check that it declares theme.json support so 6.9’s on-demand block styles and stylesheet minification kick in.

10. Measure, then keep measuring

Lab scores drift. A new plugin, a larger hero image or a marketing script added through Google Tag Manager can undo months of work in an afternoon. Set up Search Console’s Core Web Vitals report and look at it monthly. For INP specifically, the Web Vitals Chrome extension shows which interaction is slow on a real page; on WordPress it is usually a third-party chat widget or an oversized mega-menu script, not WordPress itself.

If you want to go further than a monthly glance, the free Web Vitals library can send field data to your analytics, and tools like DebugBear or SpeedCurve track every metric over time.

FAQ

Which one change helps the most?

For a logged-out content site: page caching. For a community or LMS with mostly logged-in users: a persistent object cache plus better hosting. For a store: image optimisation and cutting third-party scripts on product pages.

Do I need both a caching plugin and Cloudflare?

They do different jobs. The plugin caches HTML on your server; Cloudflare caches static assets (and, with APO, HTML) at the edge. Using both is normal. Using two caching plugins is not.

Is a perfect PageSpeed score worth chasing?

No. Passing Core Web Vitals in field data is what affects rankings and what visitors feel. A 100 lab score on a site that fails INP for real users is the wrong target.

Will speed work break my site?

Aggressive JavaScript deferral and CSS minification sometimes do. Make every change on staging, test the checkout, login, activity posting and any forms, then deploy. Keep a backup before enabling any “delay JavaScript” option.

Where to start

Run PageSpeed Insights, write down TTFB, LCP, INP and CLS from the field data, then work down the list above in order. Most sites see the biggest jump after steps 1 through 4, which is a day’s work. If your numbers are still red after that, the cause is usually specific to your plugin stack, and that is the point where an audit with Query Monitor, or an outside pair of eyes, pays for itself. The Make WordPress Core 6.9 performance field guide is worth reading if you maintain your own theme or plugins.