You installed BlinkSpeed, enabled the main settings, and ran a Google PageSpeed Insights test expecting a big jump – but the score barely moved, or it actually went down. This is more common than you would think, and it almost never means the plugin is not working. It usually means one or two specific settings have not been configured yet, or the score is being held back by something outside BlinkSpeed’s default scope entirely.
This guide walks through every reason a low performance score can persist after installing BlinkSpeed, in the order you should check them, with the exact setting to change for each one. By the end, you will have a complete website speed troubleshooting checklist you can run through in under thirty minutes.
Step 1 – Confirm You Are Testing the Right Thing
Before changing any settings, make sure your test conditions are giving you an accurate reading. This step alone resolves a surprising number of “BlinkSpeed isn’t working” reports.
Clear Your Cache Before Every Test
If you change a BlinkSpeed setting and immediately run a PageSpeed Insights test, you may be testing against a stale cached version of the page that was generated before your change. Go to BlinkSpeed → Cache and click Delete HTML/JS/CSS Cache after every settings change, then wait a moment for the page to regenerate before testing again.
Test the Actual URL, Not Just the Homepage
A common mistake is enabling every BlinkSpeed feature, testing the homepage, seeing a great score, and assuming the whole site improved. If you are on the free version of BlinkSpeed, Critical CSS generation and WebP image conversion only apply to the homepage by default – every other page is missing those two optimisations entirely. Test your actual landing pages, blog posts, and product pages, not just the homepage.
Lab Data vs Field Data
PageSpeed Insights shows two different types of data: lab data (a single simulated test run at that moment) and field data (real visitor experience aggregated over the past 28 days from the Chrome User Experience Report). If your site is new or low-traffic, you may only see lab data – which is more sensitive to one-off network conditions. Lab data fluctuates more than field data. Run the test three or four times and look at the average rather than reacting to a single low score.
| Data Type | Source | Update Frequency | Best Used For |
|---|---|---|---|
| Lab Data | Single simulated test at request time | Instant, every test run | Diagnosing specific issues right now |
| Field Data (CrUX) | Real Chrome users over 28 days | Rolling 28-day average | Confirming real-world improvement over time |
Step 2 – Check Whether the Core Settings Are Actually Enabled
This sounds obvious, but the single most common cause of a low performance score after installing BlinkSpeed is that one or more of the foundational settings were never turned on. Run through this list in your BlinkSpeed dashboard:
| Setting | Location | Why It Matters for PageSpeed |
|---|---|---|
| Enable HTML Caching | HTML Caches | Removes PHP execution time on every visit — the single biggest score factor |
| Enable CSS Optimization | CSS Optimization | Reduces file size and request count for stylesheets |
| Enable JavaScript Optimization | JavaScript Optimization | Reduces file size and removes render-blocking |
| Lazyload Javascript | JavaScript Optimization | Eliminates Total Blocking Time from scripts |
| Load Critical CSS | CSS Optimization | Improves LCP by painting above-the-fold styles immediately |
| Enable Lazy Load (Images) | Image Optimization | Reduces initial page weight from below-the-fold images |
| Enable GZIP Compression | HTML Caches | Reduces transfer size of HTML, CSS, JS |
| Enable Leverage Browsing Cache | HTML Caches | Improves repeat-visit speed (affects some PageSpeed audits) |
If any of these are off, your score is being held back by missing optimisation rather than a configuration problem. Enable them, clear the cache, and test again before doing anything else.
Step 3 – Read the PageSpeed Insights Report Like a Diagnostic Tool
PageSpeed Insights groups issues into categories. Each category maps to a specific area of BlinkSpeed’s settings. Treat the report as a checklist rather than a single number.
“Eliminate Render-Blocking Resources”
This audit flags CSS and JavaScript files that delay the browser from displaying content. If this is appearing despite BlinkSpeed being active, check that Enable CSS Optimization and Lazyload Javascript (set to Yes) are both turned on. If they are on and the audit still flags specific files, those files may be excluded from optimisation – check BlinkSpeed → Exclusions for any rules that might be keeping a heavy file render-blocking.
“Reduce Unused CSS / JavaScript”
This indicates files are loading more code than the page actually needs. BlinkSpeed’s CSS combination and Critical CSS settings reduce this somewhat by inlining only above-the-fold styles, but BlinkSpeed does not remove unused CSS rules from a stylesheet – it minifies and combines, it does not strip dead code. If this audit is heavily flagged, the unused CSS is likely coming from a page builder or theme framework loading its full style library regardless of which components are actually used on the page. This is a Lighthouse score factor that sits outside what any caching plugin can fully resolve – it requires either a leaner theme or a dedicated unused-CSS removal tool.
“Largest Contentful Paint Element”
This audit identifies which specific element is your LCP and how long it took. Use this information directly:
- If the LCP element is an image, confirm it is not in your lazy load exclusion list as an excluded item – wait, actually confirm it is added to Exclude Media from Lazy Loading so BlinkSpeed preloads it with fetchpriority=”high” instead of delaying it
- If the LCP element is a heading or text block, confirm Load Critical CSS is enabled so the styles needed to render it arrive inline rather than waiting for the main stylesheet
- If the LCP element loads from an external resource (a CDN-hosted hero image, an embedded video poster), confirm Fix INP Issues is enabled under General Settings, which adds preconnect hints for external domains
“Reduce Initial Server Response Time”
This measures Time to First Byte (TTFB) – how long the server takes to start sending a response. If HTML caching is enabled and this is still flagged, your server itself may be slow, or the page being tested is excluded from caching (check Exclude Pages from HTML Caching). If TTFB is consistently high across all pages even with caching enabled, the underlying hosting infrastructure may be the bottleneck rather than anything BlinkSpeed controls.
“Minimize Main-Thread Work” and “Reduce JavaScript Execution Time”
These both point to JavaScript that is keeping the browser’s main thread busy. Confirm Enable JavaScript Optimization is on (for minification) and Lazyload Javascript is set to Yes (to delay execution until interaction). If a specific third-party script (analytics, chat widgets, ad scripts) is the dominant contributor according to the report’s treemap, consider whether that script is necessary on every page, or whether it can be excluded and deferred using Exclude Javascript from Lazyload with the defer modifier.
Step 4 – Common Reasons BlinkSpeed Doesn’t Seem to Improve the Score
| Symptom | Likely Cause | Fix |
|---|---|---|
| Homepage score improved, inner pages did not | Free version limits Critical CSS and WebP to homepage only | Upgrade to premium and run AI Optimisation on full site |
| Score improved slightly but not dramatically | Core settings (caching, CSS/JS optimisation) were not all enabled | Re-check Step 2 checklist above |
| Score is the same as before installing BlinkSpeed | Cache was not cleared after enabling settings | Clear HTML/JS/CSS cache and Critical CSS cache, then retest |
| Score dropped after enabling settings | A conflicting plugin or theme script is breaking under optimisation | Check Exclusions tab; isolate by disabling features one at a time |
| LCP score still poor | Hero image still lazy loaded, or no Critical CSS generated for that page | Exclude LCP image from lazy load; confirm Critical CSS ran for that URL |
| TBT/INP still poor | JavaScript lazy load not enabled, or third-party scripts not preconnected | Set Lazyload Javascript to Yes; enable Fix INP Issues |
| CLS still poor | Images missing dimensions, fonts swapping late, inline styles in wrong position | Enable Localise Google Fonts; use Load Style Tag in Head to Avoid CLS |
| Score is inconsistent between tests | Lab data noise, or server load varying between test runs | Run multiple tests and average; check field data in Search Console instead |
Step 5 – Run the AI Optimisation Process (Most Overlooked Step)
A significant number of low performance score reports come down to one missed step: enabling Critical CSS and WebP conversion in the settings is not the same as them actually running. These two features depend on BlinkSpeed’s cloud API processing each page individually.
Go to BlinkSpeed → Optimize with AI and click Start Optimization. This crawls your site’s URLs and queues each one for:
Critical CSS extraction (above-the-fold styles for that specific page)
WebP conversion for every image on that page
Until this process completes for a given URL, that page is running with CSS and JS optimisation but without Critical CSS or WebP – which are two of the most direct contributors to a Core Web Vitals improvement, especially for LCP. Check the progress dashboard and confirm your key pages show as complete before drawing conclusions about your PageSpeed score.
Step 6 – Improve Lighthouse Score on Pages With Heavy Third-Party Scripts
If your site embeds third-party widgets – live chat, advertising, marketing automation pixels, social media embeds – these are frequently the dominant cause of a stubbornly low performance score that BlinkSpeed’s caching and minification cannot fully resolve on their own, because the slow part is code running on someone else’s server.
What BlinkSpeed Can Do
- Fix INP Issues (General Settings) adds preconnect hints for third-party domains, reducing connection setup time
- Lazyload Javascript delays execution of these scripts until user interaction, removing them from the initial render-blocking path
- Exclude Javascript from Lazyload with the defer modifier can be used if a specific third-party script needs to run sooner but should not block rendering
What Is Outside BlinkSpeed’s Control
The actual execution time of third-party code, the size of their JavaScript bundles, and how many additional requests they trigger are controlled entirely by the third party. If your PageSpeed Insights report shows third-party scripts dominating the “Reduce JavaScript Execution Time” or “Minimize Third-Party Usage” audits, the realistic options are: removing scripts that are not essential, loading them only on pages where they are actually needed (rather than site-wide), or accepting the tradeoff between the functionality they provide and the score impact they cause.
Step 7 – Verify Mobile Specifically
PageSpeed Insights scores mobile and desktop separately, and mobile is usually lower. If your overall score concern is really a mobile-specific concern, check these settings:
| Mobile-Specific Setting | Location | Effect |
|---|---|---|
| Responsive Images | Image Optimization | Serves smaller, resized images to mobile visitors |
| Convert to WebP | Image Optimization | Reduces image file size further on top of resizing |
| Preload Caching | HTML Caches | Ensures mobile visitors get pre-warmed cache, not a cold render |
| Fix INP Issues | General Settings | Mobile CPUs process JS slower, making preconnect more impactful |
Mobile devices process JavaScript significantly slower than desktop, so settings related to script optimisation (Lazyload Javascript, JS minification) tend to have a larger relative impact on mobile scores than on desktop scores.
A Realistic Website Speed Troubleshooting Timeline
Improvements from configuration changes are not always visible immediately, particularly in PageSpeed Insights field data and in Google Search Console’s Core Web Vitals report.
| Timeframe | What to Check | What to Expect |
|---|---|---|
| Immediately after changes | Lab data in PageSpeed Insights | Should reflect changes right away, once cache is cleared |
| 24–48 hours | BlinkSpeed’s own Core Web Vitals logs (Debug Logs tab) | Real visitor data starts accumulating |
| 1–2 weeks | PageSpeed Insights field data (CrUX) | Begins to show updated real-user metrics |
| Up to 28 days | Google Search Console Core Web Vitals report | Full rolling window reflects your changes |
If your lab score improved immediately but the report still shows old field data, this is expected – field data takes time to catch up because it is a rolling average of real visits, not a snapshot.
Frequently Asked Questions
Q1. I enabled every BlinkSpeed setting and my score barely changed. What am I missing?
The most common cause is that the AI Optimisation process has not run, so Critical CSS and WebP conversion – the two features with the largest impact on LCP – are not actually active on the pages you are testing. Go to BlinkSpeed → Optimize with AI and confirm the page you are testing shows as complete. The second most common cause is testing against a stale cache; clear the HTML/JS/CSS cache and the Critical CSS cache, then retest.
Q2. My desktop PageSpeed Insights fix worked but mobile is still low. Is that normal?
Yes, this is extremely common and expected. Mobile devices are tested under simulated mid-range hardware with a throttled 4G connection, which exposes JavaScript execution time and image size issues far more than desktop testing does. Focus on Responsive Images, WebP conversion, and Lazyload Javascript specifically – these have a disproportionately larger effect on mobile than on desktop.
Q3. Can BlinkSpeed alone get me a 90+ Lighthouse score?
For most standard WordPress sites with a reasonably lean theme, yes – when fully configured (caching, CSS/JS optimisation, Critical CSS, WebP, lazy loading, and Fix INP Issues all enabled and the AI Optimisation completed). However, sites with very heavy themes, large numbers of third-party scripts, or unusually large unoptimised media libraries may need additional changes outside BlinkSpeed’s scope – such as switching to a lighter theme or reducing third-party script usage – to consistently reach 90+.
Q4. Why does my score fluctuate between test runs even though I haven’t changed anything?
PageSpeed Insights lab data is a single test run under simulated conditions, and natural variance exists between runs due to server load at that moment, network conditions to Google’s testing servers, and minor timing differences in JavaScript execution. This is normal and is not a sign that something is broken. Run the test multiple times and look at the typical range rather than treating any single result as definitive. For a more stable view of real-world performance, check the field data section of the report or BlinkSpeed’s own Core Web Vitals logs.
Q5. Does clearing the cache reset my PageSpeed Insights score?
Clearing the BlinkSpeed cache does not directly affect your PageSpeed Insights score – clearing cache simply means the next visitor (including the PageSpeed Insights testing bot) triggers a fresh page render that gets re-cached. If you test immediately after clearing the cache, you may briefly see a slower response time for that one request before the page is cached again. For consistent testing, clear the cache, visit the page once yourself to trigger caching, then run the PageSpeed Insights test.
Q6. I fixed the issues PageSpeed Insights listed but the score still says “Needs Improvement.” Why?
PageSpeed Insights scores are a weighted combination of multiple metrics (LCP, CLS, INP/TBT, FCP, Speed Index), not a simple checklist. Fixing one flagged issue improves the underlying metric but may not be enough to move the overall score into a different bracket if other metrics are still borderline. Check the Core Web Vitals improvement on each individual metric in the report rather than focusing only on the single overall number – incremental improvement across several metrics is normal before the score crosses into the next bracket.
Q7. Is there a way to see real performance data without waiting for Google’s 28-day window?
Yes. Go to BlinkSpeed → Debug Logs and enable Core Web Vitals Logs. This collects real visitor LCP, CLS, and INP data directly into your WordPress database, updating within hours rather than weeks. Use the Issue Type and Device Type filters to check whether your changes are reducing the number of poor-rated events for real visitors, well before Google Search Console’s slower-updating report reflects the same improvement.
Summary
A low performance score after installing BlinkSpeed is rarely a sign the plugin isn’t working – it is almost always a sign that one part of the configuration hasn’t been completed or tested correctly. Work through this order: confirm the core settings are enabled, clear the cache, run the AI Optimisation process to activate Critical CSS and WebP, read the PageSpeed Insights report as a category-by-category diagnostic rather than a single number, and check mobile separately from desktop.
For the small number of cases where BlinkSpeed alone cannot close the gap – heavy third-party scripts, bloated themes, large amounts of genuinely unused CSS – recognising that the bottleneck sits outside the caching layer saves you from endlessly tweaking settings that were never going to move the needle. Combine the configuration checklist in this guide with a periodic check of BlinkSpeed’s own Core Web Vitals logs, and you will have a reliable, ongoing website speed troubleshooting process rather than a one-time fix.
