Start With the Architecture, Not the Plugins
The fastest way to speed up a WordPress website is to stop treating speed as a plugin problem and start treating it as an architecture problem. Most of the advice you’ll find online focuses on installing caching plugins, compressing images, and toggling settings. That advice isn’t wrong, but it addresses symptoms rather than causes. If your WordPress site is slow, the root issues almost always trace back to decisions made before anyone thought about performance: the theme you chose, the hosting you’re running on, the plugins you accumulated, and the way your pages are constructed.
In our projects at NexusBond, we typically find that 80% of a WordPress site’s speed problems are locked in by the time it launches. The theme loads 14 stylesheets. The page builder adds 400KB of unused CSS. The hosting account is shared with 200 other sites. No amount of caching plugin configuration fixes those fundamentals. This article walks you through how to address speed at every level, starting with the decisions that have the biggest impact and working down to the fine-tuning that shaves off the last few hundred milliseconds.
Measure Before You Change Anything
You need a baseline. Without one, you won’t know whether your changes are actually helping, and you’ll waste time optimising things that don’t matter. Run your homepage, your most-visited landing page, and one blog post through Google PageSpeed Insights and note down the Core Web Vitals scores: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). These are the metrics Google uses for ranking signals, and they’re also the metrics that correlate most closely with user experience.
Pay attention to the field data section at the top of PageSpeed Insights, not just the lab data. Field data comes from real Chrome users visiting your site over the past 28 days. If your field data shows LCP above 2.5 seconds or INP above 200 milliseconds, you have a measurable problem that’s affecting both rankings and conversions. Write these numbers down. You’ll come back to them after each round of changes.
Beyond PageSpeed Insights, open your site in Chrome DevTools and look at the Network tab with caching disabled. Sort by size and by load time. You’ll often spot the culprits immediately: a 3MB hero image, a chat widget loading 600KB of JavaScript, a font provider making six separate requests. This ten-minute audit tells you more about what’s actually slowing your site down than any generic checklist.
Choose the Right Hosting (Or Move)
Hosting is the floor your site’s speed stands on. If the floor is weak, everything you build on top wobbles. Shared hosting, where your site shares a server with hundreds of others, typically delivers Time to First Byte (TTFB) of 800ms or more. That means the browser waits almost a full second before it even starts receiving your page. You cannot optimise your way out of that.
For a WordPress site that needs to perform well, you want managed WordPress hosting with server-level caching, PHP 8.2 or higher, and data centres close to your primary audience. Providers in this category typically deliver TTFB under 200ms for cached pages. The cost difference between poor shared hosting and decent managed hosting is usually £20-£50 per month, which is trivial compared to the revenue lost from a slow site.
What to look for in a hosting environment
- Server-level page caching so you’re not relying solely on a plugin to cache output
- Object caching via Redis or Memcached to speed up database-heavy pages
- HTTP/2 or HTTP/3 support for multiplexed connections
- PHP 8.2+, which is measurably faster than PHP 7.4 for WordPress workloads
- Built-in CDN integration or easy configuration with Cloudflare or a similar provider
What we see on most mid-market sites is that they launched on whatever hosting the original developer set up three or four years ago, and nobody has revisited that decision since. If your TTFB consistently exceeds 400ms on cached pages, switching hosts will give you the single biggest speed improvement for the least effort.
Audit Your Theme and Page Builder
Your WordPress theme is the single largest contributor to front-end bloat. A multipurpose theme like the ones sold on ThemeForest typically ships with dozens of built-in features you’ll never use: sliders, portfolio layouts, WooCommerce support, custom post types, and animation libraries. All of that code loads on every page whether you use it or not.
To put a number on it: a typical multipurpose theme loads 300-800KB of CSS and JavaScript before your actual content even begins to render. A well-built lightweight theme loads 30-60KB. That’s a 10x difference, and it directly impacts LCP and INP because the browser has to download, parse, and execute all of that code before it can paint your page.
If you’re using a page builder like Elementor, WPBakery, or Divi, the problem compounds. Page builders generate deeply nested HTML with inline styles, and they load their own CSS and JavaScript frameworks on top of whatever your theme already provides. We regularly audit sites where the page builder alone accounts for 1MB of front-end assets. Removing or replacing the page builder is often impractical for an existing site, but you should at minimum disable the builder’s scripts on pages that don’t use it. Most builders load everywhere by default.
If you’re considering a rebuild or a significant redesign, this is the moment to choose a theme built for performance. Block-based themes using the WordPress Site Editor, or developer-focused starter themes like GeneratePress or Jesuspended, give you a dramatically lighter foundation. Our team typically recommends setting a performance budget before design starts, as outlined in our performance architecture guide, so the theme and tooling decisions are made with speed as a constraint rather than an afterthought.
Reduce and Control Your Plugins
The average WordPress site runs 20-30 plugins. Some of those are essential (security, forms, SEO). Many are not. Every active plugin adds PHP execution time on the server, and many add their own CSS and JavaScript files to your front end. The problem isn’t the concept of plugins; it’s the accumulation of them without anyone ever asking whether each one is still needed or worth its performance cost.
Deactivate and delete every plugin you’re not actively using. Then review what remains. For each plugin, ask two questions: does this load front-end assets, and does it load them on every page? A contact form plugin that loads its styles and scripts site-wide, even though you only have a form on two pages, is wasting resources on every other page load.
You can use a plugin like Asset CleanUp or Perfmatters to selectively disable scripts and styles on a per-page basis. This is one of the highest-impact optimisations available for existing WordPress sites. On a recent project, we reduced front-end JavaScript by 40% simply by preventing WooCommerce scripts from loading on non-shop pages and stopping a slider plugin from loading its library on pages without sliders.
Common plugin offenders
Social sharing plugins often load multiple third-party scripts and tracking pixels. Slider and carousel plugins pull in heavy JavaScript libraries even on pages with no sliders. Live chat widgets can add 300-500KB of JavaScript and create additional network requests to external servers. Analytics and tag management setups sometimes load the same tracking script three different ways because different people added it at different times. Check your source code; you’d be surprised how often Google Analytics or the Meta pixel appears twice.
Optimise Your Images Properly
Images are still the heaviest assets on most WordPress pages. A single unoptimised hero image can be 4-5MB. Even after basic compression, many sites serve images that are far larger than they need to be for the screen they’re displayed on.
There are three dimensions to image optimisation, and you need all three:
Format: Serve images in WebP or AVIF rather than JPEG or PNG. WebP delivers roughly 25-35% smaller file sizes than JPEG at equivalent visual quality. AVIF goes further but has slightly less browser support. Plugins like ShortPixel or Imagify can automatically convert your existing media library to WebP and serve the original format as a fallback for older browsers.
Dimensions: Don’t upload a 4000px wide image and rely on CSS to scale it down to 800px on screen. WordPress generates multiple sizes when you upload, but many themes don’t use the srcset attribute correctly, so the browser downloads the full-size image regardless. Check your rendered HTML and confirm that your images include proper srcset and sizes attributes so the browser selects the right file for the device.
Lazy loading: WordPress has native lazy loading built in since version 5.5, adding loading="lazy" to images and iframes below the fold. However, your LCP image (typically the hero image or main banner) should not be lazy loaded. Lazy loading your LCP element delays it, which directly hurts your LCP score. You want that critical above-the-fold image to load eagerly, and optionally add a fetchpriority="high" attribute to tell the browser to prioritise it.
Implement Proper Caching
Caching stores a pre-built version of your pages so WordPress doesn’t have to run PHP and query the database for every visitor. If your hosting provider includes server-level caching, that should be your primary caching mechanism. If it doesn’t, a caching plugin fills the gap.
WP Super Cache is simple and reliable for basic setups. WP Rocket is a premium option that bundles caching with several other performance features like CSS/JS minification and lazy loading. LiteSpeed Cache is excellent if your server runs LiteSpeed or OpenLiteSpeed. The specific plugin matters less than getting the fundamentals right: page caching enabled, browser caching headers set correctly, and cache preloading turned on so the first visitor after a cache clear doesn’t bear the full load time.
One thing that catches teams out is cache exclusions. If you’re running WooCommerce, your cart and checkout pages must be excluded from page caching because they contain user-specific data. Logged-in user sessions typically need different handling too. A poorly configured caching setup that serves one user’s cart contents to another is worse than no caching at all.
Browser caching and CDN caching
Browser caching tells the visitor’s browser to store static assets locally so repeat visits are near-instant. Your server should send proper Cache-Control headers with long expiry times for CSS, JavaScript, images, and fonts. A year is standard for versioned assets.
A Content Delivery Network (CDN) stores copies of your site’s static files on servers distributed globally. When a visitor in Sydney loads your UK-hosted site, the CDN serves images, CSS, and JavaScript from a nearby node instead of making a round trip to London. Cloudflare’s free tier is perfectly adequate for most mid-market WordPress sites. If you need more control, Cloudflare’s paid tiers or services like KeyCDN and Bunny.net offer finer configuration.
Address Render-Blocking Resources
When the browser starts parsing your HTML and encounters a CSS file or a JavaScript file in the <head>, it stops everything and downloads that file before continuing. These are render-blocking resources, and they’re one of the most common reasons for slow LCP.
The fix involves several tactics working together. Critical CSS inlining extracts the styles needed for above-the-fold content and places them directly in the HTML, allowing the rest of your stylesheets to load asynchronously. WP Rocket and some other performance plugins can automate this, though the generated critical CSS sometimes needs manual review to avoid layout issues.
JavaScript deferral moves non-essential scripts to load after the page has rendered. Adding a defer attribute to script tags tells the browser to download the file in the background and execute it only after the HTML is fully parsed. Most WordPress performance plugins offer a setting to defer JavaScript. Be careful with scripts that manipulate the DOM early, like some analytics or A/B testing tools, because deferring them can cause visual glitches or tracking gaps.
A practical approach is to defer everything by default, then selectively exclude scripts that break when deferred. This is faster than trying to identify which scripts are safe to defer, because most of them are.
Clean Up Your Database
WordPress stores everything in a MySQL database: posts, pages, comments, plugin settings, revisions, transients, and metadata. Over time, this database accumulates dead weight. Post revisions pile up (WordPress saves unlimited revisions by default). Transients from deleted plugins linger. Auto-draft posts and trashed items sit indefinitely. Spam comments accumulate even if you have Akismet running.
A bloated database slows down every uncached page load because WordPress queries it for nearly everything. WP-Optimize or the database optimisation feature in WP Rocket can clean out revisions, transients, trashed posts, and spam comments. Run this once, then schedule it weekly.
To prevent the problem from recurring, add this line to your wp-config.php to limit post revisions:
define('WP_POST_REVISIONS', 5);
This keeps the five most recent revisions, which is enough for practical purposes, and prevents the database from growing unboundedly.
Tackle Third-Party Scripts
Third-party scripts are often the worst offenders on WordPress sites, and they’re the hardest to control because they load from external servers you don’t manage. Google Tag Manager, Meta Pixel, LinkedIn Insight Tag, Hotjar, Intercom, Drift, Google Fonts, reCAPTCHA, YouTube embeds: each of these makes additional network requests, downloads JavaScript, and competes for the browser’s main thread.
What we see on most mid-market sites is 8-15 third-party scripts, many of them added incrementally over months by different team members, with no one auditing the cumulative impact. Each individual script might only add 100-200ms of delay, but together they create a compounding effect that pushes your total blocking time well beyond acceptable thresholds.
You have several options. Remove what you’re not using. If nobody has looked at Hotjar recordings in six months, remove Hotjar. Delay loading until user interaction for scripts like chat widgets and video embeds. A chat widget that loads on page load when 95% of visitors never use it is pure waste. Many caching plugins offer a “delay JavaScript” feature that waits until the user scrolls, clicks, or moves their mouse before loading specified scripts. This dramatically improves initial page load while still making the functionality available when someone actually wants it.
For YouTube and Vimeo embeds, use a facade (also called a lite embed). Instead of loading the full YouTube player on page load, which pulls in over 1MB of scripts, display a static thumbnail with a play button. The actual player loads only when someone clicks. The WP YouTube Lyte plugin does this well, or you can implement it manually with a few lines of code.
Optimise Fonts
Web fonts are a frequent source of layout shift and render delay. If you’re loading Google Fonts from Google’s CDN, each font family requires a DNS lookup, a connection to fonts.googleapis.com, a CSS fetch, and then the actual font file download. This chain easily adds 200-400ms to render time.
Self-hosting your fonts eliminates the external DNS lookup and connection overhead. Download your font files, convert them to WOFF2 format (which is the smallest and most widely supported web font format), and serve them from your own domain. A plugin like OMGF (Optimize My Google Fonts) automates this for WordPress.
Use font-display: swap in your @font-face declarations so the browser shows text immediately in a system font and swaps in the web font once it loads. This prevents the invisible text flash (FOIT) that makes pages appear blank while fonts download. Limit yourself to two font families maximum and only the weights you actually use. Loading Regular, Italic, Bold, Bold Italic, Light, and Semi-Bold when your design only uses Regular and Bold doubles your font payload for no reason.
Monitor Performance Continuously
Speed optimisation is not a one-time task. WordPress sites degrade over time as plugins update, content is added, new scripts are inserted, and team members install tools without considering performance impact. A site that scores well today can slip below thresholds within a few months if nobody is watching.
Set up Google Search Console and check the Core Web Vitals report monthly. This shows you real-world performance data grouped by URL pattern, so you can spot regressions before they affect rankings. For more proactive monitoring, tools like DebugBear or Calibre run automated Lighthouse tests on a schedule and alert you when scores drop.
Establish a simple rule for your team: no new plugin or third-party script gets added without a performance check. Run PageSpeed Insights before and after installation. If a plugin adds more than 100ms to load time or 50KB of front-end assets, it needs to justify that cost with clear business value. This single habit prevents the gradual accumulation of bloat that slows most WordPress sites down over their lifetime.
Putting It All Together
The order of operations matters. If you spend a week fine-tuning CSS delivery while your site is running on slow shared hosting with a 5MB hero image, you’re optimising the wrong layer. Work from the foundation up: fix hosting first, audit your theme and plugins second, handle images and caching third, then refine script loading and font delivery last. Each layer builds on the one before it.
After each round of changes, re-test with PageSpeed Insights and compare against your baseline. You should see LCP improve in stages: hosting and image fixes typically deliver the largest gains, caching and script deferral handle the middle ground, and critical CSS and font optimisation polish the final numbers. For most mid-market WordPress sites, following this sequence gets LCP under 2.5 seconds and INP under 200 milliseconds, which puts you solidly in Google’s “good” threshold and ahead of the majority of your competitors.
