Most speed guides list 30 tips without telling you which ones actually move the needle. This one is organized by impact — highest-ROI fixes first, marginal gains at the end. Each technique includes a realistic improvement estimate so you know what to expect before you start.
Before You Optimize: Measure First
Optimization without measurement is guesswork. Before changing anything, capture your baseline.
How to Check Your Current Speed
Go to PageSpeed Insights and run your homepage URL on the Mobile tab. Record four numbers: the Lighthouse Performance Score, LCP (Largest Contentful Paint), TBT (Total Blocking Time), and CLS (Cumulative Layout Shift). Also run your top 3 pages by traffic — performance can vary significantly between pages depending on images, scripts, and layout.
For a more detailed waterfall view showing exactly which files are blocking your page load, use WebPageTest. Run from a US server on a simulated 4G connection. The waterfall chart shows each HTTP request as a bar — long bars on render-blocking resources (JavaScript, CSS) are the priority targets.
What Metrics to Focus On
The Lighthouse Performance Score is a composite — useful as a headline but not enough detail to diagnose. Focus on the individual metrics:
- LCP: How long until the main content appears. Under 2.5s is “Good.” Most Lighthouse points come from LCP improvements.
- TBT: Total Blocking Time — how long JavaScript blocks the browser from responding. High TBT causes poor INP (Interaction to Next Paint).
- CLS: Cumulative Layout Shift — visual instability. Usually caused by images without declared dimensions or late-loading fonts.
Record your numbers before touching anything. You need a baseline to know if changes are working.
Tier 1: High-Impact Fixes (Do These First)
These techniques consistently produce the largest Lighthouse score improvements. Start here regardless of your site’s current state.
Switch to a Faster Hosting Provider
Hosting is the foundation. Time to First Byte (TTFB) — how quickly the server responds to a request — is Google’s threshold for server performance: under 800ms is acceptable, under 200ms is good. Shared hosting typically returns TTFB of 400–800ms. Managed WordPress hosting (Kinsta, WP Engine, Flywheel) returns TTFB of 80–200ms — a 3–5x improvement before you change a single plugin or setting.
No frontend optimization can compensate for slow server response. If your TTFB is above 600ms, switch hosting before optimizing anything else. Expected improvement: 15–30 Lighthouse points and 0.5–2 second LCP reduction.
Enable a Caching Plugin — and Configure It Properly
Installing WP Rocket and enabling page caching, browser caching, and GZIP compression will improve your Lighthouse score by 15–25 points for most WordPress sites. The critical setting most users miss: enable “Combine JavaScript files” and “Defer JavaScript loading” — this reduces TBT significantly. Also: disable caching for logged-in users and cart/checkout pages on WooCommerce sites, or you’ll serve stale content to customers.
W3 Total Cache is a free alternative. It achieves similar results with more configuration effort. WP Super Cache is simpler but less configurable. If you’re using Cloudflare (covered below), configure the cache plugin to work with Cloudflare’s caching layer — double-caching can cause issues if not configured correctly.
Expected improvement: 15–25 Lighthouse points, 0.5–1.5s LCP reduction.
Serve Images in WebP Format and Compress Before Upload
A 2MB JPEG hero image compressed to WebP at equivalent visual quality becomes approximately 500–700KB. Run every uploaded image through ShortPixel or Imagify (both have WordPress plugins), set compression to “Lossy,” and enable WebP conversion. Apply bulk optimization to your existing media library — most sites have years of unoptimized images sitting in the uploads folder.
Serving images in WebP reduces page weight by 25–34% compared to JPEG at equivalent quality (Google Developers data). For image-heavy sites — portfolios, e-commerce, services with photos — this single change reduces page weight by 40–60%.
Expected improvement: 5–15 Lighthouse points, 0.3–1.5s LCP reduction on image-heavy pages.
Enable Lazy Loading for Images Below the Fold
Lazy loading defers image loading until the user scrolls toward them. WordPress has built-in lazy loading since version 5.5 (the loading="lazy" HTML attribute). For the hero image or the first visible image on the page, do NOT use lazy loading — that delays LCP. All images below the fold should load lazily.
Lazy loading reduces initial page payload by 30–60% on image-heavy pages (HTTP Archive data). It’s one of the highest-ROI changes per unit of effort.
Expected improvement: 3–10 Lighthouse points, 0.3–1s LCP reduction depending on image count.
Use a CDN
A Content Delivery Network serves your static files (images, CSS, JavaScript) from servers geographically close to each visitor. For US visitors on a US-hosted site, the benefit is modest on static files but meaningful for global visitors. Cloudflare’s free tier reduces average TTFB by 30–70% depending on geographic distance from your origin server.
Cloudflare free tier: configure your DNS to proxy through Cloudflare, enable “Auto Minify” for HTML, CSS, and JavaScript, and enable “Rocket Loader” (test this — it can conflict with some plugins). The free tier is sufficient for most small business sites. The Pro tier ($20/month) adds image optimization and better analytics.
Expected improvement: 5–20 Lighthouse points depending on visitor geography, 0.2–0.8s TTFB improvement.
Tier 2: High-ROI, Requires More Work
These techniques produce meaningful improvements but require more configuration time or development knowledge.
Eliminate Render-Blocking JavaScript
Render-blocking JavaScript is code that the browser must download and execute before it can display any page content. It’s the primary cause of high TBT and poor LCP. In WP Rocket, enable “Defer JavaScript execution” and “Delay JavaScript execution” for non-critical scripts. Test thoroughly — deferred JavaScript can break plugins that expect to run immediately.
For developers: manually add defer or async attributes to script tags that don’t need to run synchronously. The difference between defer and async: defer runs scripts in order after HTML parsing; async runs them as soon as they’re downloaded. For most site scripts, defer is correct.
A render-blocking external script (like Google Tag Manager misconfigured with synchronous loading) can add 300–600ms to TBT alone. Identify render-blocking resources in the PageSpeed Insights “Opportunities” section.
Expected improvement: 10–25 Lighthouse points, 0.3–0.8s TBT reduction.
Minify and Combine CSS and JavaScript
Minification removes whitespace, comments, and unnecessary characters from CSS and JS files — reducing file size by 15–30%. Combination merges multiple CSS files into one and multiple JS files into one — reducing HTTP requests. Both WP Rocket and W3 Total Cache do this through plugin settings.
Be cautious with CSS combination on complex sites — it can break styling if files are combined in the wrong order. Test on staging before deploying to production.
Expected improvement: 3–8 Lighthouse points, 2–10 HTTP request reduction.
Optimize Your Database
WordPress accumulates database overhead over time: post revisions (WordPress saves a new revision on every save), transients (temporary cached data that expires but isn’t always cleaned up), spam comment records, and orphaned metadata. A bloated database increases query time and slows TTFB.
Use WP-Optimize or Advanced Database Cleaner to remove post revisions (keep the last 3–5), delete expired transients, remove spam comments, and clean up orphaned metadata. Run database optimization quarterly, not once.
Expected improvement: 1–5 Lighthouse points, 50–200ms TTFB reduction.
Update PHP to the Latest Stable Version
PHP 8.2+ is 2–3x faster than PHP 7.4 for WordPress operations (PHP Benchmarks data). Most managed WordPress hosts run PHP 8.1 or 8.2 by default. Check your current PHP version in WordPress (Tools > Site Health > Info > Server). If you’re on PHP 7.4 or below, update immediately — you’re leaving significant performance on the table and running an unsupported version with known security vulnerabilities.
Expected improvement: 3–10 Lighthouse points, 100–400ms TTFB and server processing time reduction.
Remove Unused Plugins
Every active WordPress plugin — even one that doesn’t display anything on the front end — runs PHP code on every page load. A plugin that adds admin functionality still loads its PHP files during the WordPress bootstrapping process. Each plugin you deactivate and delete typically saves 10–50ms of server processing time.
Audit your active plugins list: deactivate anything that isn’t actively used, test the site, then delete the deactivated plugins. Common candidates for removal: SEO plugins you’re not using, backup plugins you’ve replaced, slider plugins, contact form plugins you’ve swapped out, and demo content import plugins.
Expected improvement: 1–5 Lighthouse points per removed plugin, variable TBT reduction.
Tier 3: Marginal Gains (Worth Doing, Not Worth Starting Here)
These improvements are real but small. Do them after Tier 1 and Tier 2 are complete.
Use System Fonts or Preload Web Fonts
Google Fonts and custom font files add 100–300ms of load time and can cause CLS (text reflow when the font loads). Option 1: use system fonts (Arial, Georgia, system-ui) — zero font load time, CLS eliminated. Option 2: self-host Google Fonts (use the “google-webfonts-helper” tool to download and self-host) and add <link rel="preload"> tags for font files. Option 2 eliminates the Google Fonts DNS lookup delay.
Reduce External Script Load
Every third-party script — Google Tag Manager, Facebook Pixel, HubSpot, Hotjar, chat widgets, affiliate tracking — loads asynchronously but still consumes browser resources and increases TBT. Audit every script tag on your page. For each one: what business decision depends on this data? If the answer is unclear or the tool hasn’t been reviewed in 6 months, remove it. Unused tracking scripts are invisible performance costs.
Enable HTTP/2
HTTP/2 allows multiple files to load in parallel over a single connection, reducing the overhead of multiple HTTP requests. Most modern managed WordPress hosts enable HTTP/2 by default. Check: in Chrome DevTools, go to the Network tab, right-click the column headers, and enable the “Protocol” column. Files served over HTTP/2 show “h2.” If your files show “http/1.1,” contact your host or switch to a host that supports HTTP/2.
The Optimization Ceiling: What You Can’t Fix
This section matters more than any specific technique.
Page Builder Structural Overhead
If your site runs Elementor, Divi, WPBakery, or another page builder, there is a performance floor below which optimization cannot go. Elementor’s core JavaScript runtime — approximately 300–400KB of JS that initializes on every page — cannot be removed through plugins or configuration. WP Rocket’s “Load JavaScript Deferred” option can delay it, but it still loads. CSS purging tools (Elementor’s built-in “Improved Asset Loading,” or WP Rocket’s CSS purge) can reduce the CSS payload significantly, but the JS floor remains.
With full Tier 1 and Tier 2 optimization, most Elementor sites reach Lighthouse mobile scores of 55–72. Hand-coded WordPress sites start at 82–90 before any optimization layer.
When a Rebuild Is More Efficient Than Continued Optimization
The threshold: if your Lighthouse mobile score is below 50 after completing Tier 1 and Tier 2 optimization, and your site is actively competing for organic search traffic, a rebuild is more efficient than continued optimization. Each point above 70 on a page builder site requires increasingly complex configuration with diminishing returns. A hand-coded rebuild eliminates the floor problem and reaches 90+ as a baseline.
Pages with a Lighthouse performance score above 90 have a 1.9x higher conversion rate than pages scoring below 50 (Google Think). That gap compounds over every visitor your site receives. For a business generating 1,000 monthly visitors, the conversion rate difference between a Lighthouse 45 and a Lighthouse 92 is measurable in leads per month.
For the technical comparison of what produces those score differences at the architectural level, read our hand-coded vs page builder performance breakdown. To understand what the speed metrics mean for your Google rankings specifically, see our Core Web Vitals business impact guide.
How to Know Which Side of the Line You’re On
Run Tier 1 optimization fully. Re-test. If your Lighthouse mobile score is below 50 — or your LCP is above 3.5s after caching, CDN, WebP images, and render-blocking JS deferral — you are at or near the optimization ceiling for your build method. At that point, optimization is diminishing returns. A rebuild is the more efficient path.
Verify Your Results
After completing Tier 1 changes, re-run PageSpeed Insights on both your homepage and your highest-traffic page. Compare the new scores against your baseline. A successful Tier 1 implementation should produce:
- Lighthouse mobile score improvement of 20–40 points
- LCP reduction of 0.5–2 seconds
- TBT reduction of 100–400ms
If improvements are smaller than expected, check that caching is active (visit the page in an incognito window — first visit tests uncached, second visit tests cached), confirm WebP images are being served (right-click an image in Chrome, “Copy image URL,” check if it ends in .webp), and verify the CDN is routing traffic (use WebPageTest from a location distant from your server).
Frequently Asked Questions
Why is my WordPress website slow even with a caching plugin?
Caching improves performance for repeat visitors but doesn’t fix the root cause of slowness. If your site is slow on the first visit (uncached), the problem is usually: slow hosting (high TTFB), unoptimized images (large file sizes), or render-blocking JavaScript (from a page builder or third-party scripts). Measure your TTFB first — if it’s above 600ms, hosting is the primary issue and caching won’t solve it.
What is a good WordPress page speed score?
90 or above on Google Lighthouse mobile is “Good.” 50–89 is “Needs Improvement.” Below 50 is “Poor.” For Core Web Vitals field data: LCP under 2.5s, CLS under 0.1, INP under 200ms. Most optimized custom WordPress sites reach 88–98 on mobile. Most optimized page builder sites reach 55–75 on mobile. The target is 90+.
Does my hosting affect my WordPress speed?
Yes, significantly. Shared hosting typically returns TTFB of 400–800ms. Managed WordPress hosting (Kinsta, WP Engine) returns TTFB of 80–200ms — a 3–5x improvement. TTFB is the foundation everything else is built on. A slow host limits how much frontend optimization can improve your scores. If your TTFB is above 600ms, hosting is priority one before any other optimization.
How much does a CDN improve WordPress performance?
For visitors in the same country as your server: 10–30% TTFB improvement from edge caching. For international visitors: 30–70% TTFB improvement from geographic proximity. Cloudflare’s free tier is sufficient for most small business sites. The practical Lighthouse improvement from adding a CDN is 5–15 points, varying by visitor geography and content type.
What is the fastest WordPress caching plugin?
WP Rocket is the most consistently recommended — it combines page caching, browser caching, file minification, JavaScript deferral, and image lazy loading in a single, well-maintained plugin. It costs $59/year. W3 Total Cache is free and comparably powerful but requires more configuration. LiteSpeed Cache is the best option if your host uses LiteSpeed servers (many shared hosts do). For WooCommerce specifically, WP Rocket handles cart and checkout exclusions correctly out of the box.
Can I speed up a WordPress site built with Elementor?
Yes, partially. Tier 1 optimization (hosting upgrade, WP Rocket, WebP images, CDN) typically brings an Elementor site from Lighthouse 30–45 to 55–72 on mobile. Enabling Elementor Pro’s “Improved Asset Loading” and combining it with WP Rocket’s CSS purge can push to 65–75 in favorable conditions. The structural floor — approximately 150–200KB of Elementor JavaScript that cannot be removed — sets the ceiling. For sites targeting 90+ on mobile, a hand-coded rebuild is the only path.
At what Lighthouse score should I consider rebuilding my WordPress site?
Below 50 on mobile after completing Tier 1 and Tier 2 optimization is the rebuild signal. At that score, the remaining gap to 90+ requires eliminating architectural overhead (page builder runtime JavaScript) that optimization plugins cannot remove. The ROI on continued optimization below Lighthouse 50 is low compared to the ROI of a hand-coded rebuild that starts at 82–90 before any optimization is applied.
If Tier 1 optimization has moved your score as far as it’s going and you’re still below 70 on mobile, the remaining gap is architectural. A hand-coded WordPress site eliminates the structural overhead that caching and CDN can’t touch. Run a diagnostic first at honest.designodin.com to confirm where your scores stand — then see our fixed-price packages if a rebuild is the right next step.