# How to Speed Up WordPress Site: 8 Fixes Ranked by Impact URL: https://noonwp.com/journal/how-to-speed-up-wordpress-site Type: blog Locale: en Published: 2026-09-29 Updated: 2026-09-29 --- > A practical order of work for a slow WordPress site: baseline first, then hosting and caching, images, render-blocking code, plugins, CDN and speculative loading. Here is how to speed up WordPress site performance in practice: measure first, then fix in order of payoff: server response time and page caching, then the heavy hero image, then render-blocking CSS and JavaScript, then the database and plugin load. Most slow sites are held back by two or three of those, not all of them. Run PageSpeed Insights on your slowest template, note the Largest Contentful Paint element, and work down this list until the number turns green. ## Start with a baseline, or you will optimise the wrong thing Speed work without a baseline is superstition. Before touching a plugin, record three numbers on your slowest real template (usually a post with a large hero image, or a WooCommerce product page): Largest Contentful Paint, Interaction to Next Paint and Time to First Byte. Test on mobile settings, because that is where the gap between "fast on my machine" and "fast for the client's customers" shows up. The targets are published, not folklore. [Google's web.dev guidance on LCP](https://web.dev/articles/lcp) treats 2.5 seconds or less as good at the 75th percentile of real visits. INP should stay under 200 milliseconds and layout shift under 0.1. Write those on a sticky note next to your screen. Lab tools such as Lighthouse give you a repeatable bench. Field data from the Chrome User Experience Report, surfaced at the top of PageSpeed Insights, tells you what visitors actually got. When the two disagree, trust the field data and use the lab run to find the cause. Marginalia: this order of work holds for WordPress 6.5 and later. Older installs have more to fix before any of it matters. ## Fix the server first: hosting, PHP and Time to First Byte Every front-end trick sits on top of the first response. If the HTML takes 1.5 seconds to arrive, no image compression rescues your LCP. Time to First Byte is the number that exposes a weak host, an outdated PHP branch or a page that is rebuilt from scratch on every request. Check three things in this order. Run a currently supported PHP branch, since each release is measurably cheaper per request than the last. Confirm that the host offers a persistent object cache (Redis or Memcached), because it removes repeated database reads for options, menus and queries. And look at the plan itself: a shared server with a hundred neighbours will throttle you at exactly the moment traffic spikes. If you manage many client sites, this is where managed hosting earns its fee. A platform that bundles hosting, caching and a performance target removes a whole category of guesswork. [10Web](https://10web.io) is one example that hosts WordPress on Google Cloud and aims for a 90+ PageSpeed score out of the box, which is a reasonable default for a small agency without a dedicated ops person. Skip the temptation to buy a bigger plan before you have enabled caching. Upgrading hardware to serve uncached pages is paying more to do the same wasteful work faster. ## Turn on full-page caching and check that it actually hits WordPress builds each page with PHP and MySQL every time someone asks for it. A page cache saves the finished HTML and serves that file instead. For a mostly-read site such as a blog, a brochure site or a portfolio, this single change often moves TTFB from seconds to tens of milliseconds. Pick one page-caching layer and only one. Stacking a host-level cache, a caching plugin and a CDN cache without knowing which one serves the request is how you end up debugging stale content for a full afternoon. Ask your host what it already provides before installing anything. Then verify the cache is hitting. Open the browser's network panel, reload a public page twice, and read the response headers. Most caches announce a hit or a miss, and many add an age value. If you only ever see misses, your cache is bypassed by a cookie, a query string or a logged-in state, and the "optimisation" is decoration. Stores need extra care. Cart, checkout and account pages must never be cached, and WooCommerce sites usually depend on a cache plugin that knows those exclusions. Get the exclusions wrong and customers see each other's baskets, which is a worse problem than a slow page. ## Shrink the hero image, the usual LCP culprit On most slow WordPress pages, the LCP element is an image: a hero, a featured image or a full-width banner. That makes image weight the most common single cause of a failing score. A 4000-pixel wide JPEG exported straight from a camera, displayed in a 1200-pixel column, ships several times more bytes than the layout can use. ![Digital scale weighing a stack of paper against a single printed photograph, a metaphor for image weight](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-09/50469b-img1.webp) Work through the image pipeline in this order: - Resize to the largest size the layout really displays, not the size the designer exported. - Serve WebP or AVIF, both of which WordPress core has handled for several releases. - Let core generate the responsive `srcset` variants instead of hard-coding one large file. - Do not lazy-load the hero. Core has skipped lazy loading on the first content image and added `fetchpriority="high"` to it since WordPress 6.3, so check that your theme or plugin has not undone that. - Give every image explicit width and height so the browser reserves space and layout shift stays near zero. Below the fold, lazy loading is correct and free. Above the fold, it is a self-inflicted delay, and it is the mistake that shows up most often after someone installs a "lazy load everything" plugin. For e-commerce, the weight often comes from product photography. Producing consistent, right-sized visuals at the source is cheaper than compressing fifty oversized files afterwards, and an AI product-photography platform such as Klayn turns one product photo into a set of scenes, so you can plan the dimensions before anything reaches the media library. ## Cut render-blocking CSS and JavaScript at the source Once the server and the hero are sorted, the next delay is what the browser must download and run before it paints. Every stylesheet in the head blocks rendering. Every synchronous script blocks parsing. Page builders and multipurpose themes are the usual offenders, because they ship styles and scripts for every feature whether the page uses it or not. Block themes have a structural advantage here. Core loads the styles for a block only when that block appears on the page, so a plain post does not pay for the Query Loop or the Gallery. That is one reason a lean Full Site Editing theme starts ahead of a legacy theme with a bundled slider and a bundled icon font. Classic page builders can close the gap, but only if you disable the modules you do not use. ![Server rack cables with green status lights in a clean data center aisle](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-09/098a03-img2.webp) Divi is a fair test case. Divi 5 was rebuilt on a more modern architecture and ships hundreds of modules, which is exactly why its performance settings, such as dynamic CSS and critical CSS, deserve a careful look on every site you deliver. Practical steps, in order of risk: - Defer non-critical JavaScript and load third-party scripts (chat widgets, analytics, tag managers) after interaction where you can. - Inline the critical CSS for above-the-fold content and load the rest asynchronously, if your cache tool supports it. - Self-host fonts, subset them, and use `font-display: swap` so text is visible while the font loads. - Remove or replace any plugin that loads a large script on every page for a feature used on one. - Test after each change. Aggressive JavaScript deferral is the number one cause of a broken menu or a dead checkout button. ## Prune the plugin stack and let the database breathe Plugin count is a poor metric. What matters is what each plugin loads on the front end and what it does on every request. One badly written plugin with a heavy query can cost more than thirty well-behaved ones. Use Query Monitor on a staging copy to see slow queries, the plugin that triggered them, and the scripts each one enqueues. Then look at the options table. Plugins that were removed years ago often leave rows behind marked to autoload, which means WordPress reads them into memory on every request. Site Health starts flagging autoloaded options once they reach roughly 800 KB. If you see that warning, audit the largest rows and clean up leftovers from plugins you no longer run. Post revisions, expired transients and orphaned metadata add weight over time, but treat this as maintenance rather than a headline fix. Back up first, run the cleanup on staging, and measure again. The gain is often modest on a small site and significant on a store with years of orders and sessions. ![Craftsman workbench with a plumb line, calipers and a brass hourglass laid out in order](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/noonwp/2026-09/a80ad0-img3.webp) ## Use a CDN and speculative loading for the last stretch A content delivery network serves static files, and often the cached HTML too, from a location close to the visitor. For an audience spread across regions, such as an Arabic-language site read from the Gulf and North Africa while the origin server sits in Europe, the latency saved is not cosmetic. Distance is a cost, and a CDN is the cheapest way to shorten it. WordPress 6.8 added something that costs nothing: speculative loading. It uses the Speculation Rules API to prefetch a page as the visitor starts to click, so the next navigation feels almost instant. The core team reports that sites using the earlier plugin version improved their LCP pass rate by about 1.9% at the median, as described in the [WordPress 6.8 speculative loading developer note](https://make.wordpress.org/core/2025/03/06/speculative-loading-in-6-8/). That is small per site, and it comes with no configuration. Core enables it for logged-out visitors on sites with pretty permalinks. If a plugin uses action URLs that change state on a plain GET request, exclude those paths with the `wp_speculation_rules_href_exclude_paths` filter before you make the setting more eager. Stay on the default until you have checked your carts and your analytics. ## When to stop tuning, and which fix to run first There is a point where more WordPress tuning costs more than it returns. If a small shop spends every month fighting caching exclusions, plugin conflicts and hosting upgrades, the honest question is whether the stack fits the business. A hosted platform such as WiziShop trades some flexibility for a store whose speed is somebody else's job, and it is worth pricing against the hours you bill for maintenance. For content sites, agencies and RTL projects, WordPress remains the right tool, and everything above stays worth doing. The point is to know which side of the line each client sits on. Run the baseline on your slowest template today. If TTFB is above 800 milliseconds, start with hosting, PHP and caching. If TTFB is healthy but LCP fails, open the waterfall and find the hero image. If both pass and interaction is sluggish, look at JavaScript and the plugin stack. Which of those three does your worst page fail? ## FAQ ### What is the fastest way to speed up a WordPress site? Enable full-page caching and check that it actually serves hits. For mostly-read sites this often cuts Time to First Byte from seconds to tens of milliseconds, and it costs less effort than any other single change. ### Why is my WordPress site slow even with a caching plugin? The cache is probably being bypassed by cookies, query strings or logged-in state, or the real bottleneck is the hero image or render-blocking scripts. Read the response headers on a public page to confirm whether you get hits or misses. ### Do too many plugins slow down WordPress? Count matters less than behaviour. One plugin that runs heavy queries or loads a large script on every page can cost more than thirty light ones. Use Query Monitor on a staging copy to find the expensive ones. ### What is a good Largest Contentful Paint for WordPress? Google's web.dev guidance treats 2.5 seconds or less as good, measured at the 75th percentile of real visits. Aim for Interaction to Next Paint under 200 milliseconds and layout shift under 0.1 as well. ### Should I lazy-load the hero image? No. Lazy loading is right for images below the fold, but the first content image is usually the LCP element and should load early. WordPress core has skipped lazy loading on it and added fetchpriority high since version 6.3. ### Does WordPress 6.8 make sites faster by default? Slightly. Speculative loading prefetches pages as a visitor starts to click, and the core team reported about a 1.9% median improvement in LCP pass rate for sites using the earlier plugin. It is on by default for logged-out visitors with pretty permalinks.