WordPress Speed Optimisation: A Practical Step-by-Step Guide

A slow WordPress site costs you in three ways simultaneously: visitors leave before your page finishes loading, Google ranks faster competitors above you, and every second of delay reduces the chance a visitor converts into a customer or lead.

The good news is that most WordPress speed problems are fixable without a developer, without expensive hosting upgrades, and without rebuilding your site. The bad news is that most WordPress speed optimisation guides treat it as a list of tips rather than a layered system — which leads to spending hours on fixes that barely move the needle while ignoring the changes that would have the biggest impact.

This guide takes a different approach. Speed optimisation is a sequence of layers, each one building on the previous. Fix hosting first, then caching, then images, then code, then database. Work through them in order and test after each layer — that’s how you know what actually made a difference on your specific site.

Before reading this, it’s worth understanding what you’re actually optimising for. The Core Web Vitals guide covers LCP, INP, and CLS in detail — what they measure, why they matter for rankings, and the difference between lab scores and field data. This guide focuses on the practical implementation: what to change, which tools to use, and in what order.

This post is part of the Technical SEO: The Complete Guide series.

Before You Start: Measure First, Fix Second

Never start optimising without a baseline. Without a before measurement, you can’t know whether your changes helped, hurt, or did nothing.

Run your homepage and two or three representative inner pages through these tools before touching anything:

Google PageSpeed Insights (pagespeed.web.dev) — your primary tool. Run both the Mobile and Desktop tabs. Note the scores and the specific issues flagged in the Diagnostics section. The mobile score is more important — Google uses mobile field data for ranking.

Google Search Console → Core Web Vitals — shows real user experience data for your site over the past 28 days. This is what actually affects your rankings. If you don’t have enough traffic for field data, use PageSpeed Insights lab data as your working measure.

GTmetrix — provides a waterfall chart showing exactly which resources load in what order and how long each takes. Particularly useful for identifying which specific files are causing delays.

Record your scores in a simple document:

• Mobile PageSpeed score
• Desktop PageSpeed score
• LCP value
• INP value
• CLS score
• TTFB (Time to First Byte — shown in GTmetrix)

These are your baseline numbers. Test again after each layer of optimisation to see exactly what moved and by how much.

What’s Actually Slowing Your WordPress Site Down

Before fixing anything, it helps to understand the categories of causes. Most slow WordPress sites have problems in one or more of these areas:

Server-level issues: Slow hosting, poor PHP performance, no server-side caching, distant server location. These cause high TTFB — everything else waits while the server processes the request.

WordPress-level issues: Too many plugins, poorly coded plugins or themes, bloated database with thousands of post revisions and expired transients, no page caching.

Asset issues: Uncompressed images, wrong image format, render-blocking CSS and JavaScript, too many HTTP requests, no minification.

Third-party issues: External scripts from analytics, advertising, chat widgets, social share buttons — each loading from a different server with its own latency.

The sequence matters because server-level issues can’t be fixed with plugin-level solutions. Fixing your images won’t help much if your TTFB is 1.5 seconds — that delay happens before any images start loading.

Layer 1: Hosting and Server Configuration

Your hosting environment is the foundation. Everything else you do is limited by the ceiling your hosting sets.

Check Your TTFB First

Open GTmetrix, run your homepage, and look at the waterfall chart. The first bar — the initial HTML document request — shows your TTFB. This is how long your server takes to start responding.

• Under 200ms — excellent
• 200-600ms — acceptable
• 600ms-1s — worth investigating
• Over 1s — your hosting is the primary performance problem

If your TTFB is consistently above 600ms, no amount of image optimisation or caching plugin configuration will get you to consistently good Core Web Vitals in field data. The hosting fix is the only fix that matters at this point.

Key Hosting Factors for WordPress Speed

Web server type: LiteSpeed significantly outperforms Apache for WordPress because it handles PHP requests more efficiently and includes native server-side caching through LiteSpeed Cache. If you’re on Hostinger’s WordPress hosting, you’re already on LiteSpeed — this is one of the reasons Hostinger performs well for Core Web Vitals compared to budget Apache-based hosts.

PHP version: Running PHP 8.2 or 8.3 instead of 7.4 or 8.0 produces measurable performance gains — up to 40% faster PHP execution in benchmarks. Check your PHP version in Hostinger’s hPanel → PHP Configuration. If you’re on anything below 8.1, upgrade (verify plugin compatibility before doing so).

Server location: Network latency adds to TTFB for every visitor. A server in the US adds 150-250ms of latency for visitors in India. In Hostinger’s hPanel, you can see and sometimes change your server location. Pair with a CDN (covered below) if your audience is geographically distributed.

Server-side caching: On LiteSpeed hosting, the server can cache WordPress pages at the server level — serving pre-built HTML without executing PHP or querying the database. This reduces TTFB from 400-600ms to under 50ms for cached pages. This is different from WordPress plugin caching and needs to be enabled through your hosting panel or the LiteSpeed Cache plugin.

Enable Server-Side Caching in Hostinger

In Hostinger’s hPanel, go to WordPress → Cache and confirm caching is enabled. This enables LiteSpeed’s server-side page caching. The LiteSpeed Cache plugin (covered in Layer 2) then communicates with this server-level cache for optimal performance.

Layer 2: WordPress Caching Configuration

Caching is the single most impactful WordPress-level optimisation you can make. A properly configured caching plugin can reduce page load time by 50-80% for cached pages by serving pre-generated HTML instead of executing PHP and database queries on every visit.

Choosing the Right Caching Plugin

LiteSpeed Cache (free) — recommended for Hostinger users

If you’re on Hostinger (LiteSpeed hosting), LiteSpeed Cache is the right choice. It integrates directly with the LiteSpeed web server at the server level — meaning caching happens in the server itself, not just in WordPress. This is fundamentally faster than WordPress-only caching plugins.

WP Rocket (paid, $59/year for 1 site)

The most comprehensive WordPress caching and performance plugin available. Handles page caching, browser caching, render-blocking resource deferral, critical CSS generation, lazy loading, and image optimisation in one plugin with a clean interface. Worth the cost for non-LiteSpeed hosting environments or if you want a one-plugin solution that handles most optimisation tasks automatically.

W3 Total Cache / WP Super Cache (free)

Functional but require more manual configuration and don’t include the frontend optimisation features of LiteSpeed Cache or WP Rocket. Reasonable for very simple sites on tight budgets.

LiteSpeed Cache — Full Configuration for Hostinger Sites

Install LiteSpeed Cache from Plugins → Add New. Once activated, go through these settings:

Cache tab:

• Enable Page Cache: ON
• Cache Logged-in Users: OFF (logged-in users should see live content)
• Cache Commenters: OFF
• Login Page Cache: OFF (never cache login pages)
• Browser Cache: ON
• Browser Cache TTL: 31557600 (one year for static assets)

CDN tab (if using QUIC.cloud or Cloudflare):
Enable CDN if you’ve set one up. LiteSpeed Cache has native integration with QUIC.cloud (LiteSpeed’s own CDN, which has a free tier) and works well with Cloudflare.

Optimise tab:

• CSS Minify: ON
• CSS Combine: ON (test — can occasionally break styles)
• JS Minify: ON
• JS Combine: OFF (frequently breaks functionality — leave off unless you test carefully)
• JS Defer: ON (defers non-critical JavaScript — test all interactive elements after enabling)
• HTML Minify: ON
• DNS Prefetch: Add any external domains your site loads resources from (Google Fonts, analytics scripts)

Media tab:

• Lazy Load Images: ON
• Lazy Load Iframes: ON
• Add Missing Image Dimensions: ON (helps prevent CLS)
• WebP Replacement: ON (converts images to WebP if you’ve generated WebP versions)
• Responsive Placeholder: ON

Important: After enabling JS Defer, test every interactive element on your site — contact forms, menus, sliders, any JavaScript-powered functionality. Deferring scripts occasionally breaks plugins that need their JavaScript to load immediately. If something breaks, use the JS Defer Excludes field to exclude the specific script causing the problem.

After configuring: Go to LiteSpeed Cache → Purge → Purge All. Then test your site and run PageSpeed Insights again. You should see a meaningful improvement in your scores after proper caching configuration.

What Good Caching Achieves

A properly configured LiteSpeed Cache on Hostinger should bring your TTFB from 400-600ms down to 50-150ms for cached pages. PageSpeed scores typically improve by 15-30 points from caching alone on a previously uncached site.

Layer 3: Image Optimisation

Images are typically the largest files on any webpage and the most common cause of poor LCP. Getting images right has the highest single-optimisation impact of anything in this guide.

Format: WebP and AVIF in 2026

JPEG and PNG are outdated formats for web use. The modern alternatives:

WebP — 25-35% smaller than JPEG at equivalent quality. Supported by all major browsers. The minimum standard for web images in 2026.

AVIF — 50% smaller than JPEG at equivalent quality. AVIF generally provides better compression than WebP, and browser support is now strong across modern browsers (Chrome, Firefox, Safari, Edge all support it). For most WordPress sites in 2026, AVIF can be used safely with proper fallbacks.

The practical approach: use WebP as your baseline, AVIF where your image optimisation tool supports it. Most visitors will receive AVIF; older browsers fall back to the original format automatically when served with proper ‘<picture>‘ element markup.

How to convert:

Before uploading — use Squoosh (squoosh.app) for free browser-based conversion, or TinyPNG for batch compression. Aim for under 150KB for most images, under 300KB for large hero images.

After uploading via plugin — ShortPixel, Imagify, and Smush all convert existing images to WebP or AVIF automatically. ShortPixel’s free tier (100 images/month) is sufficient for most small sites.

In LiteSpeed Cache — the Image Optimisation section (Media tab → Image Optimisation) connects to LiteSpeed’s QUIC.cloud image service for automatic WebP conversion. Free with a QUIC.cloud account.

Dimensions and Sizing

Uploading a 4000px wide image for a 800px wide column wastes bandwidth and slows loading. Resize images to the maximum display size before uploading.

For a typical WordPress blog post with a 1200px wide content area:

• Featured image: 1200px wide maximum
• In-content images: 800-1000px wide maximum
• Hero/banner images: 1920px wide maximum for full-width sections

WordPress generates multiple image sizes automatically (thumbnail, medium, large, full). Make sure your theme and page builder are serving the appropriately sized version for each context rather than always loading the full-size original.

The LCP Image — Special Treatment Required

Your LCP element — usually the hero image or the first large image above the fold — needs specific handling that’s different from all other images:

Never lazy load the LCP image. Lazy loading delays image loading until the browser thinks it’s needed. For the LCP image, the browser needs it immediately. In Divi, check your Section or Row background image settings and ensure lazy loading is disabled for above-the-fold images.

Preload the LCP image. A preload hint in your page’s ‘<head>’ tells the browser to start downloading the LCP image immediately rather than waiting until it discovers it during parsing. In LiteSpeed Cache, go to Page Optimisation → LCP and specify your LCP image URL. WP Rocket’s Preload section handles this similarly.

Use an ‘<img>’ tag rather than a CSS background for LCP images where possible. CSS background images are discovered later in the loading process than inline ‘<img>’ tags, which delays LCP. In Divi, hero section background images are CSS backgrounds — this is a known limitation. The workaround is preloading the background image via a preload link tag.

Alt Text and Image Dimensions

Every image should have descriptive alt text — both for accessibility and for SEO. In WordPress, add alt text in the Media Library when you upload images or in the image block settings.

Every image should have explicit width and height attributes. WordPress adds these automatically for images inserted through the media library, but images added via HTML or page builder background settings may not have them. Missing dimensions cause CLS (layout shift) as the browser doesn’t know how much space to reserve before the image loads.

Layer 4: Plugin Audit and JavaScript Reduction

Every active WordPress plugin loads code on every page load — even plugins you’re not actively using. An accumulation of plugins is one of the most common causes of slow WordPress sites, particularly for INP (Interaction to Next Paint) scores.

How to Audit Your Plugins for Performance Impact

Don’t just remove plugins randomly — audit them systematically to know which ones are actually causing problems.

Method 1 — Chrome DevTools Coverage tab:

Open Chrome, press F12, go to the three-dot menu → More Tools → Coverage. Click the record button and load your page. The Coverage tab shows every JavaScript and CSS file loaded and what percentage of each file is actually used on that page.

Files with 80% or more unused code are candidates for removal or conditional loading. A plugin that loads 500KB of JavaScript on your homepage but only uses 5% of it is causing significant unnecessary load.

Method 2 — Query Monitor plugin:

Install the free Query Monitor plugin and load your site while logged in. It adds a toolbar showing database query count, query time, and which plugins are making which queries. If a plugin is running 50 database queries on every page load, it’s a significant performance drag.

Method 3 — Process of elimination:

Disable all plugins except essential ones (caching, SEO, security). Run PageSpeed Insights. Note the score. Re-enable plugins one at a time, testing after each. If a specific plugin causes a significant score drop, that’s a performance-heavy plugin worth replacing or removing.

Which Plugins Are Common Performance Culprits

• Slider plugins — particularly ones that load their libraries globally on every page. If you use a slider on only one page, the JavaScript shouldn’t load on all pages
• Social sharing plugins — many load external scripts from social networks. These add latency and third-party request counts
• Old or unmaintained plugins — plugins not updated in over a year often have poor performance due to outdated code
• Multiple plugins doing the same job — having both a caching plugin and a minification plugin and an image optimisation plugin and a CDN plugin can create conflicts and redundancy
• Page builder addons — third-party Divi or Elementor addon plugins that load all their module assets globally even when those modules aren’t used on the current page

Conditional Script Loading

Rather than deleting plugins outright, consider loading their scripts only on pages where they’re actually used. The free Asset CleanUp plugin or the paid Perfmatters plugin let you disable specific plugin scripts on specific pages or post types.

For example: disable your contact form plugin’s JavaScript on every page except your contact page. Disable your WooCommerce scripts on non-shop pages. This keeps the plugin active and functional while significantly reducing JavaScript load on pages that don’t need it.

Layer 5: Code Optimisation

After fixing hosting, caching, images, and plugins, code-level optimisation addresses the remaining render-blocking resources and file size issues.

Minification

Minification removes whitespace, comments, and unnecessary characters from CSS and JavaScript files, reducing their size by 20-40% without changing functionality.

LiteSpeed Cache and WP Rocket both handle CSS and JS minification through their Optimise settings. Enable CSS minification first, test your site, then enable JS minification and test again. JS minification occasionally breaks things — testing after each step lets you catch issues immediately.

Eliminating Render-Blocking Resources

Render-blocking resources are CSS and JavaScript files that the browser must download and process before it can display anything on screen. Every render-blocking resource delays your LCP.

Defer non-critical JavaScript: Add the ‘defer’ attribute to JavaScript that isn’t needed for the initial page render. LiteSpeed Cache’s JS Defer setting handles this automatically. Test all interactive elements after enabling — forms, menus, and sliders are common breakage points.

Async external scripts: Third-party scripts (analytics, pixels) should load asynchronously so they don’t block page rendering. Most well-coded third-party scripts include async by default, but it’s worth verifying in your page source.

Google Fonts optimisation: Google Fonts loaded via a standard ‘<link>’ tag are render-blocking. Options in order of performance impact:

• Host fonts locally on your server (fastest — eliminates the external request entirely)
• Preconnect to Google’s font servers and use font-display: swap
• Use system fonts instead of custom fonts (fastest of all, but limits design flexibility)

LiteSpeed Cache has a Google Fonts section under Optimise → Font Settings that handles font preloading and display settings automatically.

Critical CSS: Critical CSS is the minimum CSS needed to render the above-the-fold portion of a page. Loading only critical CSS inline and deferring everything else lets the browser render the visible portion of the page before the full CSS finishes loading. WP Rocket generates critical CSS automatically. LiteSpeed Cache offers critical CSS generation through its QUIC.cloud integration.

GZIP and Brotli Compression

Server compression reduces the size of files transferred from your server to the visitor’s browser — typically reducing HTML, CSS, and JavaScript file sizes by 60-80%.

Brotli is the modern replacement for GZIP, offering better compression ratios. LiteSpeed servers support Brotli natively. Verify compression is enabled in LiteSpeed Cache → Optimise → Browser Cache → Enable Browser Cache.

You can verify compression is working by pasting your URL into GiftOfSpeed.com/gzip-test and checking the compression type and savings percentage.

Layer 6: Content Delivery Network (CDN)

A CDN stores cached copies of your static assets (images, CSS, JavaScript) on servers around the world. When a visitor loads your site, these files are served from the server closest to them rather than from your hosting server — reducing latency for geographically distant visitors.

For a site hosted in Singapore serving primarily Indian visitors, a CDN adds relatively little benefit. For a site with a global audience, a CDN can reduce asset load times by 40-70% for international visitors.

CDN Options for WordPress Sites

Cloudflare (free tier available) — the most widely used CDN for WordPress. The free tier includes a global CDN, basic DDoS protection, and SSL. Points your domain’s DNS to Cloudflare, which proxies all traffic through its network. Easy to set up and requires no changes to your WordPress configuration. Works with LiteSpeed Cache via the Cloudflare integration.

Configure Cloudflare for WordPress:

• Set SSL/TLS encryption mode to Full (Strict)
• Enable Auto Minify for HTML, CSS, and JavaScript
• Enable Brotli compression
• Create a Page Rule to bypass cache for wp-admin and wp-login.php URLs
• Create a Page Rule to set Cache Level: Cache Everything for your static pages

QUIC.cloud (free tier available) — LiteSpeed’s own CDN, which integrates natively with LiteSpeed Cache. The free tier provides CDN for images and static assets. Simpler to configure for LiteSpeed Cache users than Cloudflare — activate from within LiteSpeed Cache → CDN → QUIC.cloud.

BunnyCDN (paid, low cost) — affordable premium CDN option starting at around $1/month for typical small site usage. Integrates with LiteSpeed Cache and WP Rocket. Good performance-to-price ratio.

Layer 7: Database Optimisation

WordPress stores everything in its MySQL database — posts, pages, comments, settings, plugin data, user information. Over time, databases accumulate overhead: thousands of post revisions, expired transients, spam comments, orphaned metadata from deleted plugins, and deleted post data. This overhead slows database queries, which increases TTFB and page generation time.

Database optimisation is particularly impactful on sites that have been running for several years and have published significant content.

What to Clean

Post revisions: WordPress saves a revision every time you save or autosave a post. A post edited 50 times has 50 revisions sitting in the database. Multiply across hundreds of posts and the revision table becomes enormous. Limit future revisions by adding this to wp-config.php:

define('WP_POST_REVISIONS', 5);

Expired transients: Transients are temporary data stored in the database by WordPress core and plugins. When they expire, WordPress should delete them — but it doesn’t always. Expired transients accumulate and slow option table queries.

Spam and trashed comments: Comments in the spam and trash folders sit in the database indefinitely unless deleted.

Orphaned metadata: When you deactivate and delete a plugin, it often leaves behind rows in the postmeta and usermeta tables. These orphaned rows add bulk to database queries.

How to Optimise

WP-Optimize (free) is the most straightforward database optimisation plugin. It cleans post revisions, expired transients, spam comments, trashed posts, and orphaned data through a simple dashboard. Run it manually, or schedule automatic weekly cleanup.

Go to WP-Optimize → Database and run a clean on:

• All post revisions
• All auto-draft posts
• Trashed posts
• Spam comments
• Trashed comments
• Expired transients
• Orphaned postmeta

Always back up your database before running any cleanup. Database operations are not reversible without a backup.

After cleanup: Run Optimise Tables to rebuild and compact the database tables, removing fragmentation. WP-Optimize includes this as a one-click operation.

Object Caching (Advanced)

WordPress makes database queries on every page load even with page caching enabled — for things like menu items, widget settings, and sidebar content. Object caching stores the results of these repeated database queries in memory (RAM) so they don’t have to be re-run.

Redis and Memcached are the two common object cache backends. Some managed WordPress hosts (Kinsta, WP Engine) provide Redis automatically. On Hostinger’s standard plans, object caching isn’t available as a built-in feature, but it’s worth asking your host if Redis object caching is available on your plan.

For most small to medium WordPress sites without object caching, the impact of database optimisation (above) is sufficient. Object caching becomes more impactful on high-traffic sites with many concurrent visitors.

Layer 8: Third-Party Scripts

Third-party scripts — Google Analytics, Facebook Pixel, chat widgets, heat mapping tools, A/B testing scripts — are loaded from external servers and execute in the browser’s main thread. Each one adds network requests, latency, and JavaScript execution time that directly impacts INP scores.

Audit What You’re Actually Loading

Open your site in Chrome, press F12 → Network tab → reload the page. Filter by “Script” to see every JavaScript file being loaded. Look at the Domain column — every row showing a domain other than your own is a third-party script.

List them and ask honestly: is this script generating value proportionate to its performance cost? Analytics — yes, essential. Facebook Pixel — only if you’re running Facebook ads and actually using the conversion data. A chat widget you haven’t checked in months — probably not.

Load Non-Critical Scripts After Interaction

For third-party scripts that don’t need to load immediately — chat widgets, certain analytics, social widgets — consider loading them only after the user first interacts with the page (scrolls, clicks, or moves the mouse). This dramatically improves initial INP and LCP scores since the main thread isn’t blocked by scripts the visitor hasn’t interacted with yet.

WP Rocket’s “Delay JavaScript Execution” feature does this automatically for specified scripts. In LiteSpeed Cache, the JS Defer feature handles similar deferral.

Use a Facade for Embedded Videos

Embedded YouTube videos load significant JavaScript and CSS from Google’s servers even when the visitor never clicks play. A video facade shows a static thumbnail image instead of the full embed until the visitor clicks to load the video. This eliminates the third-party script load entirely for visitors who don’t watch the video.

WP Rocket includes a YouTube facade feature. The Lite YouTube Embed plugin provides a free standalone solution.

Measuring Your Results: What Good Looks Like

After working through the optimisation layers, run your pages through PageSpeed Insights again and compare against your baseline measurements.

Realistic targets for an optimised WordPress site with a page builder in 2026:

A mobile score of 90+ is achievable on minimal sites without page builders. On a Divi or Elementor site with standard plugins, 70-85 on mobile is a realistic well-optimised target. Chasing 100 on a complex WordPress site with a page builder is not a productive use of time.

What matters for rankings is passing Core Web Vitals in Google Search Console field data — not achieving a specific PageSpeed score. A site with a mobile score of 72 that passes all three Core Web Vitals in field data is in a better position than a site with a score of 88 that fails LCP in real user data.

Ongoing Speed Maintenance

Speed optimisation isn’t a one-time project. WordPress sites get slower over time as content, plugins, and the general web evolve. Build these habits into your regular site maintenance:

Test monthly. Run your key pages through PageSpeed Insights monthly and note any score changes. A sudden drop usually indicates a new plugin, a content addition, or a hosting issue.

Test after every major plugin update. Plugin updates occasionally introduce new JavaScript, change how assets are loaded, or break caching configurations. A quick PageSpeed test after significant updates catches regressions immediately.

Clean the database quarterly. Run WP-Optimize’s database cleanup every three months to keep revision and transient accumulation under control.

Audit plugins annually. Once a year, go through every active plugin and ask: am I still using this? Is there a lighter alternative? Are there two plugins doing similar things?

Monitor in Search Console. The Core Web Vitals report in Search Console shows your real-user performance trends over time. Check it monthly alongside your general Search Console review.

Frequently Asked Questions

What’s the difference between page speed optimisation and Core Web Vitals?

Core Web Vitals (LCP, INP, CLS) are specific metrics Google uses to measure user experience — they’re what affects your rankings. Page speed optimisation is the practical process of improving your site’s performance across all metrics, including but not limited to Core Web Vitals. The Core Web Vitals guide explains what to measure; this guide explains how to fix it. Both are needed — the metrics tell you what’s wrong, the optimisation techniques tell you how to address it.

How much does speed optimisation improve SEO rankings?

Core Web Vitals are a confirmed ranking signal — Google has included them in its ranking algorithm since 2021. The impact is most noticeable in competitive niches where multiple pages have comparable content quality, where speed becomes a tiebreaker. Beyond direct ranking impact, faster pages have lower bounce rates, higher average session times, and better conversion rates — all of which contribute indirectly to better SEO performance over time.

Can I speed up my WordPress site without a caching plugin?

You can make some improvements without a caching plugin — image optimisation, plugin reduction, and CDN setup all help. But page caching is the single highest-impact optimisation available for a dynamic WordPress site. Without it, every page request executes PHP and queries the database, adding hundreds of milliseconds to every TTFB. On Hostinger, the LiteSpeed Cache plugin is free and integrates natively with the server — there’s no good reason not to use it.

Will using Divi or Elementor always hurt my speed scores?

No — but page builders do add overhead compared to a minimal theme, and this needs to be offset with proper optimisation. Divi 5 in particular has improved significantly with static CSS generation and reduced JavaScript. A Divi 5 site with LiteSpeed Cache properly configured, WebP images, and JS deferral enabled can consistently score 75-85 on mobile PageSpeed and pass Core Web Vitals in field data. The page builder isn’t the bottleneck — unconfigured caching, unoptimised images, and too many plugins are the usual culprits on slow page builder sites.

How do I know which plugin is slowing my site down?

Use the Chrome DevTools Coverage tab to see which JavaScript files have the most unused code. Use the Query Monitor plugin to see which plugins are running the most database queries. Or use the process of elimination — disable all plugins except essentials, test, then re-enable one at a time, testing after each. The plugin that causes a significant PageSpeed score drop when re-enabled is your performance culprit.

Is a 100 PageSpeed Insights score achievable on a WordPress site?

On a very minimal WordPress site with a lightweight theme, no page builder, and few plugins — yes. On a typical business or portfolio site with Divi or Elementor, multiple plugins, and normal content requirements — not realistically without compromising functionality. This is fine: Google’s ranking signals use Core Web Vitals field data thresholds (LCP under 2.5s, INP under 200ms, CLS under 0.1), not PageSpeed scores. A site scoring 78 on mobile that passes all three Core Web Vitals in field data is performing well for SEO purposes.

Part of the Technical SEO: The Complete Guide series.

Speed Is a System, Not a Checklist

The reason most speed optimisation attempts produce disappointing results is that they’re treated as a random checklist rather than a layered system. Fix the foundation first — hosting and caching. Then images. Then code and plugins. Then CDN. Then database. Each layer builds on the previous.

Work through the layers in order. Test after each one. Document what changed. And revisit your measurements monthly to catch regressions before they compound.

A fast WordPress site isn’t a one-time achievement — it’s an ongoing practice. But once the core optimisations are in place, maintaining good performance takes far less effort than getting there in the first place.

Related reading: Core Web Vitals for WordPress: What They Are and How to Improve Them | Technical SEO Audit Checklist for WordPress | WordPress Stuck in Maintenance Mode? Here’s How to Fix It