WordPress Speed Optimization: 11 Safe, Free Fixes

WordPress speed optimization doesn’t start with buying another plugin. It starts with finding the bottleneck. Give me 45 minutes with a slow site and I’ll check page caching, image weight, server response, database queries, and front-end assets before I change a single setting.

One WordPress site loaded in roughly eight seconds before I worked on it. It came in under one second after the fixes, but I didn’t get there by pasting every performance snippet I could find. The biggest gains came from fixing one measured problem, testing again, and stopping when the next change added risk without a visible benefit. Free fixes can get an ordinary blog most of the way there. Paid tools mostly save time.

Quick answer: Test the uncached page first, install one page-cache solution, and resize and compress images. Then add Cloudflare Free, use PHP 8.3 or newer with OPcache, and unload assets only after proving they aren’t needed. Don’t remove query strings, disable Heartbeat, or dequeue Gutenberg styles site-wide.

WordPress Speed Optimization Checklist

The safest WordPress speed optimization process works from high-impact, low-risk changes toward narrower technical changes. Use this table as the order of operations, not as a box-ticking contest.

Step	Free action	What should improve
1. Baseline	Run PageSpeed Insights and WebPageTest	LCP, INP/TBT, CLS, TTFB, request waterfall
2. Page cache	Use LiteSpeed Cache on LiteSpeed or WP Super Cache elsewhere	Cached HTML response and TTFB
3. Images	Resize, compress, and serve WebP or AVIF	LCP and total page weight
4. CDN	Enable Cloudflare Free	Static asset delivery and global latency
5. Runtime	Use PHP 8.3+ and OPcache	Uncached PHP work and admin response
6. Plugins	Remove unused features and measure expensive requests	Queries, scripts, CSS, and background work
7. Assets	Conditionally unload proven-unused CSS and JS	Render delay and main-thread work
8. Fonts	Use system fonts or a small self-hosted WOFF2 set	LCP, CLS, and transfer size
9. Database	Delete expired transients and limit future revisions	Database size and slow queries
10. Object cache	Enable Redis when the host supports it	Repeated database-query time
11. Retest	Compare the same URL, device, and location	Proof that the change helped

Don’t apply all 11 changes at once. If the score gets worse or a form breaks, you should know exactly which change caused it.

1. Measure Before You Change Anything

Start with a baseline from the exact page that feels slow. A homepage, a blog post, a WooCommerce product, and the WordPress dashboard can have four different bottlenecks.

• PageSpeed Insights: Check Chrome field data when available, then use the Lighthouse lab test to reproduce front-end problems.
• WebPageTest: Inspect the request waterfall, TTFB, LCP image, cache headers, and third-party requests from a chosen location.
• Query Monitor: Find slow database queries, PHP errors, HTTP API calls, hooks, and which plugin or theme owns the work.
• Hosting metrics: Compare cached and uncached TTFB, PHP worker saturation, CPU, memory, and slow-query logs. One TTFB number without cache state or location doesn’t diagnose hosting.

The current Core Web Vitals thresholds are evaluated at the 75th percentile of real visits. These are the numbers worth remembering:

Metric	Good	What it exposes
LCP	2.5 seconds or less	Slow server response, render-blocking files, or a heavy hero element
INP	200 milliseconds or less	Too much JavaScript or long main-thread tasks
CLS	0.1 or less	Missing dimensions, late banners, ads, or font swaps

PageSpeed’s mobile lab score is useful for debugging, but it isn’t the same thing as your visitors’ experience. Google Search Console and the field section in PageSpeed Insights show aggregated Chrome data. Lighthouse cannot measure INP in the lab, so it uses Total Blocking Time as a diagnostic proxy.

2. Add One Page Cache

Page caching is usually the highest-impact free fix for a public WordPress site. If you want to speed up WordPress without paying for another tool, start here. A cache stores generated HTML so WordPress doesn’t have to run PHP and repeat database queries for every anonymous visit.

• LiteSpeed server: Use LiteSpeed Cache. Its page cache integrates with the server, but many optimization features still need careful testing.
• Apache or Nginx without a host cache: Use WP Super Cache or the cache plugin your host officially supports.
• Managed hosting: Keep the host’s built-in page cache and avoid stacking a second page-cache plugin on top of it.

Test the cache in a logged-out browser. Open the same URL twice, check the response headers, and confirm that the second request is a cache hit. Then test forms, carts, account pages, search, and any page that shows personalized data.

Don’t run two page caches. Combining a host cache, LiteSpeed Cache, WP Super Cache, FlyingPress, or WP Rocket can create stale pages, broken exclusions, and purges that never reach every layer.

If you want the optimization controls in one interface, FlyingPress and WP Rocket are paid conveniences. They aren’t required to make WordPress faster.

3. Resize and Compress Images

Images often decide whether a page feels fast because the largest above-the-fold image commonly becomes the LCP element. A 2,000-pixel photo doesn’t belong in an 800-pixel content column.

• Resize before upload: Export the image near its largest displayed width instead of uploading the full camera or design canvas.
• Compress: Use Squoosh or a comparable local tool. A reasonable target is under 100 KB for ordinary content images and under 200 KB for a visually important hero, but visible quality wins over an arbitrary number.
• Choose a modern format: WordPress supports WebP uploads from version 5.8 and AVIF from version 6.5 when the server’s image library supports it. Core does not automatically convert every old JPEG to WebP.
• Keep responsive images: Let WordPress generate sizes and srcset. Don’t force a single large file on every screen.
• Protect the LCP image: Don’t lazy-load the likely hero or featured image. WordPress can add fetchpriority="high" to a likely LCP image, while below-the-fold images can remain lazy-loaded.
• Set dimensions: Width and height reserve layout space and reduce CLS.

My detailed WordPress image optimization guide covers the workflow. If you prefer automation, Imagify can compress and generate modern formats, while Smush has a limited free path.

4. Put Cloudflare Free in Front of WordPress

Cloudflare Free can reduce global latency, cache static files, negotiate HTTP/3, compress supported assets, and block a lot of junk traffic before it reaches WordPress. It won’t repair a slow database or a broken theme, but it is a sensible free edge layer.

Cloudflare occasionally moves dashboard labels, but the setup still has three parts: add the domain, confirm DNS records, and replace the registrar nameservers. Use my detailed Cloudflare for WordPress guide for the current dashboard path and settings.

Add the Domain and Confirm DNS

Create an account at Cloudflare, add the root domain, and choose the Free plan. Compare every imported A, AAAA, CNAME, MX, and TXT record with your current DNS before you continue. Email records deserve extra attention.

Change Nameservers

Cloudflare gives you two assigned nameservers. Replace the current nameservers at your domain registrar, then wait for Cloudflare to mark the zone active. DNS changes can take time, so don’t delete the old DNS zone until the site and email both resolve correctly.

Use Conservative Speed Settings

Start with settings that improve delivery without rewriting your site’s behavior. Cloudflare Free includes HTTP/3 and Early Hints, but each toggle still needs a before-and-after test.

• SSL/TLS: Use Full (strict) after installing a valid certificate on the origin.
• HTTP/3: Turn it on and verify the site in modern browsers.
• Early Hints: Test it. Keep it when the preload hints are correct and the waterfall improves.
• Compression: Let Cloudflare negotiate Brotli or Zstandard where supported. Also keep gzip or Brotli enabled at the origin for bypassed responses.
• Rocket Loader: Leave it off at first. It can change JavaScript execution order and break forms, menus, consent tools, or analytics.
• HTML caching: Don’t create a “Cache Everything” rule unless you understand exclusions for login, preview, cart, checkout, account, search, and personalized pages.

5. Upgrade PHP and Turn On OPcache

A current PHP runtime helps every uncached request, cron job, REST request, and admin action. WordPress currently recommends PHP 8.3 or newer, MySQL 8.0 or newer or MariaDB 10.11 or newer, and HTTPS.

Server item	Practical starting point	Important limit
PHP	8.3 or newer after staging compatibility tests	A dated plugin can still fail on a supported PHP version
OPcache	Enabled by the host	It speeds compiled PHP reuse, not slow external APIs
WordPress memory	256 MB is often comfortable for ordinary sites	More memory prevents exhaustion; it doesn’t automatically make code faster
PHP workers	Match traffic and uncached work	More workers cannot fix slow queries or third-party calls
Database	MySQL 8.0+ or MariaDB 10.11+	Schema and query quality still matter

Check versions in Tools > Site Health > Info or your hosting panel. Upgrade on staging first, inspect PHP logs, test checkout or lead forms, then repeat the PageSpeed and Query Monitor baseline. The official WordPress requirements are a better reference than an old hosting blog post.

6. Audit Plugins by Cost, Not Count

Plugin count is not a performance metric. One plugin that runs an uncached remote request can hurt more than 20 small plugins that load nothing on the page you are testing.

• Query Monitor: Sort database queries by time and component. Look for repeated queries, slow HTTP API calls, PHP warnings, and hooks with obvious ownership.
• Browser waterfall: Group CSS, JavaScript, fonts, and third-party requests by hostname and filename. A plugin can be cheap in PHP but expensive in the browser.
• Scheduled actions: Check Action Scheduler and cron queues for failed or constantly repeating jobs.
• Admin-only cost: A plugin that slows the editor or WooCommerce orders may never appear in a public PageSpeed test.
• Removal test: Clone to staging, disable one suspected component, clear every cache, and rerun the same test. Delete inactive plugins after you confirm they are not needed.

I still prefer lean sites, but “keep it under 15 plugins” is a maintenance preference, not a scientific threshold. The right question is what each plugin does on this request.

7. Load CSS and JavaScript Only Where Needed

Selective asset loading can improve LCP and INP, but this is where bad optimization advice breaks sites. Work with registered WordPress handles, apply conditions narrowly, and test templates one at a time.

Avoid blanket removals. Don’t dequeue wp-block-library or global styles across the site. Don’t strip jQuery Migrate until you have proved every theme and plugin is compatible. Don’t remove version query strings: WordPress uses the $ver value for cache busting.

For a script you own, WordPress 6.3 and newer can request defer or async through the dependency-aware script API:

wp_enqueue_script(
    'site-navigation',
    get_theme_file_uri( '/assets/js/navigation.js' ),
    array(),
    wp_get_theme()->get( 'Version' ),
    array(
        'in_footer' => true,
        'strategy'  => 'defer',
    )
);

For a plugin asset that is genuinely needed on one page, unload only the known handle outside that page. This example is deliberately narrow:

add_action( 'wp_enqueue_scripts', function() {
    if ( is_page( 'contact' ) ) {
        return;
    }

    wp_dequeue_style( 'contact-form-7' );
    wp_dequeue_script( 'contact-form-7' );
}, 100 );

Use the actual handle from the plugin, replace the page condition, and test forms, consent banners, analytics events, menus, search, and logged-in views. Put experiments in a small site plugin or Code Snippets so you can disable them without editing the active theme over FTP.

8. Keep Web Fonts Small

Fonts become a speed problem when a design loads too many families, weights, subsets, or third-party requests. A single system stack is fastest. A small self-hosted WOFF2 set is the usual compromise when brand typography matters.

• Keep one or two families and load only the weights the design uses.
• Prefer WOFF2 and subset only when the site language coverage is understood.
• Use font-display: swap or an intentional alternative based on the design.
• Preload only the font file needed for above-the-fold text. Preloading every weight competes with the LCP image and CSS.
• Match the fallback font closely to reduce layout shift during the swap.

Google Webfonts Helper can prepare files for manual self-hosting. OMGF automates local Google Fonts for WordPress, but check licensing, subsets, and the final network waterfall instead of assuming local always means faster.

9. Clean the Database Safely

Database cleanup is maintenance, not a magic front-end speed button. It helps when expired transients, revisions, spam, failed scheduled actions, or oversized autoloaded options are contributing to real query time.

• Take a tested database backup before deleting anything.
• Empty trash and spam through WordPress before touching database tables.
• Delete expired transients with WP-CLI: wp transient delete --expired.
• Inspect scheduled actions and cron events before deleting them. A stuck queue may be a symptom of a failing integration.
• Use Query Monitor or a database tool to identify large autoloaded options, then confirm which plugin owns each option.
• Avoid one-size-fits-all SQL copied from a blog post. Direct deletion can remove valid rows or leave orphaned relationships.

To limit future post revisions, add this before the “That’s all, stop editing” line in wp-config.php:

define( 'WP_POST_REVISIONS', 10 );

Ten is a maintenance choice, not a speed guarantee. If you prefer scheduled cleanup and a visual interface, Perfmatters can handle it, but confirm the backup and exclusions first.

10. Add Redis Only When Queries Are the Bottleneck

Redis persistent object caching stores reusable query results in memory across requests. It is most useful for WooCommerce, membership sites, busy dashboards, complex queries, and sites with a low page-cache hit rate.

• Ask the host whether Redis is available and supported for your plan.
• Enable the Redis service before installing a WordPress connector.
• Use the established Redis Object Cache plugin or the host’s integration.
• Confirm the plugin reports “Connected” and that the drop-in is active.
• Compare database time and query count on the same uncached request.

A mostly static blog with a reliable full-page cache may show little public benefit from Redis. That doesn’t mean Redis failed. It means the page cache already bypassed most WordPress work.

11. Retest and Fix the Largest Regression

Retest after every meaningful change using the same URL, device profile, test location, login state, and cache state. A trustworthy WordPress speed optimization result is repeatable. Keep a change only when it improves the median result or removes a measured risk.

1. Clear the relevant WordPress, host, CDN, and browser caches.
2. Warm the public page once if you are measuring a warm-cache experience.
3. Run at least three tests and use the median instead of celebrating the best run.
4. Test a second page type. A homepage win can hide a product-page regression.
5. Check the actual interface: menu, search, forms, comments, cookie consent, checkout, login, and editor.
6. Record the before and after values so the next optimization has a trustworthy baseline.

I also keep GTmetrix and Pingdom Tools around for a second waterfall or location. The brand of test matters less than repeating the same test honestly.

Free Fixes vs Paid Shortcuts

You can complete every core step in this guide without paying for a performance plugin. The free route can speed up WordPress and teach you which bottleneck mattered. Spend money when a tool saves enough testing or maintenance time to justify the cost.

Need	Free path	Paid shortcut
Page and asset optimization	LiteSpeed Cache or WP Super Cache plus manual tests	FlyingPress or WP Rocket
Image compression	Squoosh plus WordPress responsive images	Imagify
CDN	Cloudflare Free	Bunny CDN when you want simple usage-based delivery and storage
Conditional asset control	Theme/plugin settings and carefully scoped code	Perfmatters
Font delivery	System fonts or manual WOFF2 self-hosting	OMGF
Database cleanup	WordPress admin and documented WP-CLI commands	Perfmatters scheduled cleanup

My preference is simple: use the free path until the manual work becomes repetitive. Then pay for one tool that replaces that repetition, not five overlapping tools that create a new troubleshooting problem.

WordPress Speed Mistakes to Avoid

Most optimization damage comes from copying an old fix without understanding what WordPress now does for you. These shortcuts either provide little value or carry more risk than their promised gain.

• Removing query strings: Asset versions help browsers and CDNs invalidate old CSS and JavaScript after an update.
• Dequeuing global block styles: A page can look fine while a search result, archive, comment form, or future block loses styling.
• Removing jQuery Migrate blindly: The tiny theoretical win isn’t worth breaking an older theme or plugin. Test compatibility first.
• Disabling Heartbeat: Heartbeat supports autosave, post locks, and near-real-time admin updates. Throttle it only after measuring excessive requests.
• Lazy-loading the hero: Delaying the LCP image can make the page look slower even when total bytes fall.
• Running raw cleanup SQL: A query copied from another site doesn’t know your custom tables, retention needs, or plugin relationships.
• Chasing a score of 100: Fix user-visible delays, field Core Web Vitals, errors, and conversion friction before a final point in a synthetic test.

What to Fix When the Site Is Still Slow

When the first pass doesn’t solve the problem, use the failing metric to choose the next investigation. Don’t swap hosting because a hero image is 1.8 MB, and don’t compress images when the database spends two seconds on an external API call.

Symptom	Likely next check	Typical fix
High cached TTFB from several nearby tests	Cache hit headers, CDN path, origin latency	Repair cache rules, CDN routing, or hosting
High uncached TTFB only	Queries, PHP, external calls, workers	Fix slow code, add Redis, upgrade runtime, or right-size hosting
Poor LCP	LCP element, CSS, preload order, server response	Compress the hero, don’t lazy-load it, reduce render-blocking work
Poor INP or high TBT	Long JavaScript tasks and third-party tags	Remove, delay, or split noncritical scripts
Poor CLS	Images, embeds, ads, banners, fonts	Reserve dimensions and stabilize font and banner space
Fast public pages, slow admin	Query Monitor, cron, Action Scheduler, remote APIs	Fix the expensive plugin, queue, query, or integration

If cached TTFB remains bad after cache headers and geography are controlled, hosting may be the bottleneck. I use xCloud on a VPS or managed options such as Cloudways and Kinsta for sites that need predictable resources. Hostinger can suit tighter budgets. Technical users can compare the tradeoffs in my Hetzner, Vultr, and RackNerd guide.

My WordPress Performance Stack in 2026

A WordPress speed optimization stack should be boring enough that you can maintain it. Mine changes by site, but the default shape stays consistent:

• Theme: A lean custom build, GeneratePress, or Kadence, chosen for the project rather than a demo score.
• Caching: Host page cache or one plugin. I use FlyingPress when its workflow saves enough time, with WP Rocket as a solid alternative.
• Edge: Cloudflare Free for DNS, security, and delivery. Bunny CDN is optional when its storage and delivery model fits better.
• Images: Correct dimensions first, then compression and WebP or AVIF. The plugin is secondary.
• Object cache: Redis on query-heavy sites, not as a decorative Site Health checkbox.
• SEO: Rank Math, configured without turning every optional module on.

If you want a second pair of eyes, my WordPress optimization service starts with the same measurement pass. I find the bottleneck, document the changes, and avoid turning your production site into a snippet experiment.

FAQs

Disclaimer: This site is reader-supported. If you buy through some links, I may earn a small commission at no extra cost to you. I only recommend tools I trust and would use myself. Your support helps keep gauravtiwari.org free and focused on real-world advice. Thanks. - Gaurav Tiwari