From a Lighthouse Score of 5 to 70–90: How We Improved WordPress PageSpeed
We run several WordPress websites with different kinds of content. After implementing the main frontend SEO improvements, we turned our attention to performance.
One of our content-heavy WordPress sites had reached a Lighthouse performance score of 5 on mobile and 34 on desktop. After analysing the frontend, plugins, images, scripts and server behaviour, we increased the score to between 70 and 90, depending on the page and test conditions.
That result did not come from installing one speed plugin. It came from understanding what the browser was being asked to download, process and display.
This article explains what we changed, what we learned and how the same principles apply to WordPress today. The original measurements date from 2020, but the case has been updated to reflect the current Google PageSpeed Insights, Lighthouse and Core Web Vitals standards.
Step 1. Run Google PageSpeed Insights
If you have avoided the most common SEO mistakes, the next step is to establish a performance baseline.
Google PageSpeed Insights analyses an individual URL and combines two different kinds of information:
1. Field data, when available, based on real Chrome users collected through the Chrome User Experience Report.
2. Lab data, generated by Lighthouse in a controlled simulated environment.
This distinction matters. A Lighthouse test can help you diagnose a page, but it is still a snapshot. Real visitors use different devices, connections and browsers. That is why the same page can receive different Lighthouse scores between tests without anything on the website having changed.
Chrome DevTools also includes Lighthouse, which is convenient while developing and testing individual changes. Always run several comparable tests and use the median result instead of treating one score as definitive.
Should you aim for a score of 100 in Google PageSpeed?
No. A score of 100 can be useful as an engineering challenge, but it should not become the business objective.
Lighthouse converts measured performance into scores using non-linear scoring curves. Moving from a poor score to a reasonable score can create a substantial improvement for visitors. Moving from 95 to 100 may require considerable work while producing little noticeable difference.
Google classifies a Lighthouse performance score of 90 to 100 as good. But the score is only a diagnostic summary. A page with a score of 95 can still create a poor experience for some real users, while a page with a lower lab score may perform well in the field.
Focus first on the causes behind the score and on the experience of actual visitors.
Historical Lighthouse scoring curve. The metric shown in the original image has since been retired, but the principle of non-linear scoring still applies.
How to read the current Lighthouse performance metrics
The Lighthouse performance score currently uses five weighted lab metrics:
First Contentful Paint, 10%: when the first visible content appears.
Speed Index, 10%: how quickly the visible content is displayed during loading.
Largest Contentful Paint, 25%: when the largest visible content element is rendered.
Total Blocking Time, 30%: how long the main thread is blocked and unable to respond during loading.
Cumulative Layout Shift, 25%: how much the layout moves unexpectedly.
These weights can change as Lighthouse develops. Do not hard-code them into your long-term performance strategy. Use them to interpret the current lab report and identify what needs investigation.
Core Web Vitals are not the same as the Lighthouse score
The current Core Web Vitals are:
Largest Contentful Paint: loading performance. A good result is 2.5 seconds or less.
Interaction to Next Paint: responsiveness. A good result is 200 milliseconds or less.
Cumulative Layout Shift: visual stability. A good result is 0.1 or less.
These thresholds should be achieved at the 75th percentile of page visits, separately for mobile and desktop.
Lighthouse cannot measure real INP because a lab test has no real visitor interacting with the page. It uses Total Blocking Time as a diagnostic proxy. This is another reason why a good Lighthouse score and good real-world performance are related, but not identical.
How can you check the performance of your whole website?
PageSpeed Insights tests one URL at a time. The Core Web Vitals report in Google Search Console groups similar URLs using real-user data where sufficient data is available.
Search Console does not give one universal average loading time for the entire website. It shows whether groups of pages provide a good, needs-improvement or poor experience for LCP, INP and CLS.
For important websites, combine three perspectives:
PageSpeed Insights for page-level lab and field information.
Search Console for grouped Core Web Vitals issues.
Real-user monitoring for detailed performance across actual visits, devices and templates.
Our original monitoring showed that the time spent downloading a page frequently exceeded one second before optimisation. After the changes, it fell substantially and became more consistent. These graphs are historical measurements from the case, not current Core Web Vitals reports.
Before page-speed optimisation
Historical measurement before optimisation. Download times frequently exceeded one second and fluctuated considerably.
After page-speed optimisation
Historical measurement after optimisation. Download times were lower and more stable.
What makes a WordPress website slow?
WordPress is not automatically slow. A lightweight WordPress website on suitable hosting can perform extremely well. Performance problems usually develop because themes, plugins, third-party scripts, images, fonts and database activity accumulate over time.
A browser does not care whether a feature came from WordPress core, a premium theme, a plugin or custom code. It still has to download, parse, execute and render everything it receives.
Common reasons why a WordPress website becomes slow
Themes and plugins load more CSS and JavaScript than a page needs.
Large images are uploaded and served without appropriate dimensions or compression.
Third-party scripts for analytics, advertising, video, chat, forms or consent block the main thread.
Fonts delay rendering or cause layout movement.
Database queries, remote API calls or slow application code increase server response time.
Caching is missing, misconfigured or invalidated too often.
Important content, such as the hero image, is discovered too late by the browser.
The solution is not to avoid plugins altogether. The solution is to understand the cost of every feature and load it only where and when it is needed.
Step 2. Start with the user journey through the browser
In the original case, the largest improvements came from the client side: images, JavaScript, CSS, fonts and plugin assets. That does not mean the server is unimportant. A slow server delays every other resource because the browser cannot start building the page until it receives the initial HTML.
A good analysis therefore follows the entire request chain:
DNS, connection and server response.
Initial HTML.
Critical CSS, fonts and the main visible image.
JavaScript execution and main-thread work.
Secondary images and functionality below the fold.
Can most servers handle normal WordPress traffic?
Traffic volume alone says little about whether a server can cope. One hundred thousand visits per month averages only a few visits per minute, but real traffic is not evenly distributed. Campaigns, search traffic and news events can create peaks.
A single uncached request can also trigger expensive database queries, external API calls or complex PHP processing.
Evaluate hosting through Time to First Byte, capacity during peaks, database performance, cache behaviour and reliability. Do not select a server based only on average monthly visits.
WordPress caching helps, but does not repair inefficient pages
Caching is valuable. Page caching can prevent WordPress from rebuilding the same page for every visitor. Object caching can reduce repeated database work. Browser caching prevents returning visitors from downloading unchanged assets again.
But caching a page does not make oversized images, unused JavaScript or poor HTML disappear. It only delivers them more efficiently.
Our approach is therefore:
Remove or reduce unnecessary work.
Optimise the resources that remain.
Cache them appropriately.
Confirm the result in both lab and field data.
Static assets with content-hashed or versioned filenames can often receive a long browser cache lifetime. The exact server configuration depends on Apache, Nginx, the hosting platform and whether a CDN or managed cache is involved.
Example for Apache:
apache
<FilesMatch "\.(css|js|jpg|jpeg|png|gif|webp|avif|svg|ico|woff|woff2|ttf)$">
Header set Cache-Control "max-age=31536000, public, immutable"
</FilesMatch>
Example for Nginx:
nginx
location ~* \.(css|js|jpg|jpeg|png|gif|webp|avif|svg|ico|woff|woff2|ttf)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
Only apply long immutable caching when filenames change after the file changes. Otherwise visitors may continue receiving an outdated file.
A CDN is useful when it solves a real delivery problem
A content delivery network can reduce latency, cache static or generated content closer to visitors, absorb traffic peaks and add security controls. Its value depends on the audience, hosting location, cacheability and website architecture.
A CDN will not compensate for an unnecessarily heavy page. But it is no longer accurate to dismiss CDNs as useful only for very large global websites. Modern CDN and edge platforms can improve reliability, security and delivery even for smaller sites.
Cloudflare can help, but configuration still matters
Cloudflare combines CDN, caching, DNS, security and optimisation features. It can be effective, but it is not a substitute for understanding the application.
Cache rules, HTML caching, bot protection, script optimisation and security settings can all affect website behaviour. Use only the features you understand, test logged-in and transactional journeys carefully, and keep control of cache invalidation.
Yoast is an SEO plugin, not a performance strategy
Yoast SEO helps manage search-related elements such as metadata, canonical URLs, XML sitemaps and structured data. It is not designed to diagnose every cause of poor WordPress performance.
Like any plugin, it adds code and should be tested within the complete website. But whether Yoast materially affects performance depends on the configuration, extensions, theme and other plugins.
The correct question is not whether a well-known plugin is inherently good or bad. The question is whether the value it adds justifies its measurable cost on your website.
Step 3. Optimise the WordPress foundation
Start with a lean theme, not necessarily from scratch
A custom theme can provide complete control, but developing everything from scratch is not always the most efficient or maintainable choice.
Start with a lean, well-supported theme or a carefully built custom theme. Avoid systems that load large frameworks and features on every page regardless of whether they are used.
Assess the generated HTML, CSS and JavaScript, not the marketing promise of the theme.
For custom development, starter themes can still provide a useful foundation, but performance depends on what is eventually built on top of them.
Optimise images before they reach the browser
Images are still one of the most common causes of poor LCP and excessive page weight. Good image handling includes:
Serving dimensions appropriate to the displayed size.
Using responsive srcset and sizes attributes.
Using modern formats such as WebP or AVIF where appropriate.
Compressing images without unacceptable quality loss.
Specifying width and height to prevent layout shifts.
Lazy-loading images below the fold.
Not lazy-loading the main LCP image.
Prioritising the main visible image when necessary.
WordPress automatically creates multiple image sizes and supports responsive images. Configure those sizes around the actual design.
A plugin or image CDN can also be useful when it reliably resizes, compresses and converts images. The important question is whether the browser receives the right image, not whether the optimisation happened manually or through a plugin.
Step 4. Analyse the impact of WordPress plugins
Plugins should be judged by measured impact, not reputation or download count.
Test performance before and after activating a plugin, but keep the conditions comparable. Clear relevant caches, repeat the tests and inspect the browser network and performance traces. A Lighthouse score alone will not tell you why the result changed.
In our historical case, five components had a substantial cumulative effect:
Jetpack.
MEOW Gallery and Lightbox.
Contact Form 7 combined with reCAPTCHA.
WPML.
Our own TheONE Blog integration.
Together, these reduced the Lighthouse score from approximately 90 to 5 in the configuration we tested.
That is a finding from one website at one point in time. It should not be presented as proof that every current version of these plugins produces the same result.
For every costly plugin, you have four options:
Remove functionality that no longer creates value.
Configure the plugin so assets load only where needed.
Replace it with a more efficient alternative.
Improve or rebuild the required functionality.
What we learned from Jetpack
On the tested website, disabling Jetpack improved the Lighthouse score by approximately 10 to 15 points. We were mainly using its gallery functionality.
We chose to keep it at the time because replacing the gallery would have required development work that did not justify the additional performance gain.
That trade-off remains important: technical perfection is not automatically the best business decision.
What we learned from MEOW Gallery and Lightbox
The MEOW gallery and lightbox assets were present even though the website already used another gallery solution. Removing the unused functionality improved the test result by approximately 5 to 10 points.
The lesson is broader than this specific plugin. Duplicate functionality creates duplicate code, maintenance and performance costs. Audit what is actually in use.
What we learned from WPML
WPML is a comprehensive paid multilingual solution. It adds translation management, URL handling, database tables and additional processing because that is the work required to manage a multilingual website.
In our historical configuration, disabling the WPML components improved the Lighthouse result by approximately 15 to 20 points. We still concluded that replacing the complete multilingual system was not economically justified.
For multilingual sites, test the current version, follow the vendor’s performance guidance, remove unused modules and use appropriate page and object caching.
Do not assume that an observation from an older installation describes every present-day WPML website.
What we learned from Contact Form 7 and reCAPTCHA
The largest cost did not come from the form itself, but from reCAPTCHA JavaScript being loaded on pages where no form was present. In our test, removing that unnecessary loading improved the Lighthouse result by approximately 10 to 15 points.
This pattern still deserves attention. Form, chat, consent and anti-spam scripts are often loaded globally for functionality used on only one or two pages.
Conditional loading can reduce page weight and main-thread work, provided the form and spam protection continue to work correctly.
Your own WordPress plugins can also be the problem
Our in-house plugin loaded navigation, search functionality and article widgets from CallTheONE on another server. Disabling it improved the Lighthouse score by approximately 15 points.
We identified three improvements:
Store reusable external data locally. Frequently requested content did not need to be fetched from another server for every page view. A scheduled background process could synchronise the information.
Separate editor and frontend assets. Code needed only in the WordPress editor should not be loaded for visitors. Use the appropriate WordPress enqueue hooks for each context.
Load scripts according to their dependencies and timing needs. Use defer, async, modules or footer loading where appropriate. Do not move every script blindly because execution order and dependencies still matter.
Step 5. Improve what visitors see and can use first
The old version of this article focused mainly on First Contentful Paint. Today, the stronger approach is to consider LCP, INP and CLS together.
Improve Largest Contentful Paint
Identify the LCP element on each important template. It is often a hero image, heading block or banner.
Reduce server response time.
Ensure critical CSS is available quickly.
Compress and correctly size the LCP image.
Do not lazy-load the LCP image.
Avoid discovering it late through JavaScript or CSS.
Preload or increase fetch priority only when the resource is genuinely critical.
Improve Interaction to Next Paint
INP measures how responsive the page feels when someone interacts with it.
Reduce long JavaScript tasks.
Break heavy work into smaller tasks.
Remove unused third-party scripts.
Avoid complex rendering after clicks or taps.
Test menus, forms, filters and consent interfaces on real mobile devices.
Reduce Cumulative Layout Shift
Unexpected movement damages the experience even when the page loads quickly.
Reserve dimensions for images, video, advertisements and embeds.
Avoid inserting banners above existing content after load.
Use font-loading strategies that minimise reflow.
Keep cookie and consent interfaces from moving the page unexpectedly.
Load what matters and delay what does not
Critical CSS can be inlined or prioritised, but avoid turning the complete stylesheet into inline code. Fonts, below-the-fold images and non-critical scripts can often load later.
The objective is not to move every file to the bottom of the HTML. It is to give the browser the right priorities.
Conclusion
Our WordPress performance improved from a Lighthouse score of 5 on mobile and 34 on desktop to scores between 70 and 90.
The largest gains came from reducing unnecessary plugin assets, improving image handling, removing avoidable remote requests and controlling when code was loaded.
The exact scores belong to one historical case. The method remains relevant:
Measure both lab performance and real-user experience.
Identify the actual bottleneck instead of guessing.
Remove unnecessary work before adding optimisation layers.
Make deliberate trade-offs between performance, functionality, cost and maintainability.
Validate every change using comparable tests and field data.
Site speed and Core Web Vitals support a better user experience and contribute to the page experience Google seeks to reward. They do not replace relevant content, clear architecture or authority. A fast page that does not answer the question is still not a useful page. Technical performance is therefore one part of a broader search and AI visibility system, not the complete strategy.
The NieuweStroom SEO and content strategy case shows how technical optimisation, site structure and useful content can strengthen each other.
The goal is therefore not a perfect score. The goal is a website that responds quickly, remains stable, works reliably and helps visitors do what they came to do.
Comments