This guide covers every real-world WordPress plugin compatibility scenario you are likely to encounter: which plugins you should deactivate before using BlinkSpeed, which ones BlinkSpeed handles automatically, which ones need configuration adjustments, and which ones work alongside BlinkSpeed without any issues at all.

The Golden Rule: One Caching Plugin at a Time

Before anything else, this is the most important thing to understand about running BlinkSpeed on a WordPress site:

Never run two caching or performance optimisation plugins simultaneously.

BlinkSpeed and another caching plugin active at the same time will cause a performance plugin issue that is difficult to debug and has no clean fix. Both plugins try to serve cached HTML files for the same requests. Both write to your .htaccess file. Both intercept page output and modify HTML. Both manage cache clearing in isolation from each other, so clearing BlinkSpeed’s cache does not clear the other plugin’s cache and vice versa.

The result is unpredictable. Some pages load from one plugin’s cache, others from the other’s. JavaScript and CSS processing from both plugins can stack on top of each other, producing doubled output or broken scripts. Admin bar controls clear one cache layer but leave the other intact, so visitors continue seeing stale content even after you have cleared cache.

Deactivate – do not just disable caching in the settings, but actually deactivate any other caching or optimisation plugin before activating BlinkSpeed.

Plugins to Deactivate Before Using BlinkSpeed

WP Rocket

WP Rocket is one of the most popular WordPress caching plugins. It handles HTML page caching, CSS and JavaScript minification, file combination, lazy loading, critical CSS, and CDN integration – every feature that BlinkSpeed also provides.

Running both simultaneously creates a severe optimisation conflict situation. WP Rocket’s cache files and BlinkSpeed’s cache files will conflict for the same URLs. WP Rocket’s JS minification and BlinkSpeed’s JS minification will process the same files, potentially producing corrupt or duplicated output.

What to do: Deactivate WP Rocket entirely before activating BlinkSpeed. After deactivation, check your .htaccess file to ensure WP Rocket’s rules have been removed – WP Rocket typically cleans up its .htaccess block on deactivation, but verify this in your .htaccess file before activating BlinkSpeed.

W3 Total Cache

W3 Total Cache covers page caching, database caching, object caching, browser caching, CDN integration, and minification. Its .htaccess rules for page caching will conflict directly with BlinkSpeed’s own .htaccess caching rules.

W3 Total Cache also installs a db.php drop-in in wp-content/ for database caching. If left in place after deactivating W3 Total Cache, this file can interfere with BlinkSpeed’s cache warming process.

What to do: Deactivate W3 Total Cache. Go to its settings before deactivating and use the “Empty All Caches” button, then deactivate. After deactivation, check wp-content/db.php and delete it if it still exists. Check your .htaccess for any remaining # BEGIN W3TC blocks and remove them if the plugin has not done so automatically.

LiteSpeed Cache

LiteSpeed Cache is the native caching solution for LiteSpeed servers. On LiteSpeed or OpenLiteSpeed hosting environments, this plugin controls server-level cache via the LSCWP API. If you are on LiteSpeed hosting and activate BlinkSpeed alongside LiteSpeed Cache, both plugins will attempt to cache and serve your pages, and LiteSpeed’s server-level cache will often serve its version first, bypassing BlinkSpeed entirely.

What to do: Deactivate LiteSpeed Cache before activating BlinkSpeed. If you are on LiteSpeed hosting and want to use BlinkSpeed for its frontend optimisation features (JavaScript lazy loading, CSS minification, image optimisation, critical CSS), BlinkSpeed can operate alongside LiteSpeed’s server cache, but only if you disable LiteSpeed Cache’s own page caching feature. However, for the cleanest setup, deactivating LiteSpeed Cache entirely and using BlinkSpeed alone is the recommended approach.

WP Super Cache

WP Super Cache generates static HTML files and serves them via PHP or .htaccess – the same two delivery methods BlinkSpeed uses. Both plugins cannot occupy the same .htaccess delivery rules without conflicting.

What to do: Deactivate WP Super Cache. After deactivation, check that WP Super Cache has removed its wp-cache-phase1.php and wp-cache-phase2.php drop-in references from wp-content/advanced-cache.php, as these can persist after deactivation and interfere with BlinkSpeed’s own advanced-cache.php drop-in.

WP Fastest Cache

WP Fastest Cache writes .htaccess rules for page caching and creates cached HTML files in a separate directory. It also has its own minification and GZIP settings. All of these overlap directly with BlinkSpeed.

What to do: Deactivate WP Fastest Cache. Use its “Delete Cache” button before deactivating to ensure its .htaccess block is cleaned up. After deactivation, check your .htaccess for any remaining # BEGIN WEF blocks.

Autoptimize

Autoptimize handles CSS and JavaScript minification, combination, and deferral – specifically the script and stylesheet processing that BlinkSpeed’s CSS Optimization and JavaScript Optimization features cover. Running both simultaneously means your CSS and JS files go through two separate minification and combination pipelines, which typically produces broken output.

What to do: Deactivate Autoptimize entirely. BlinkSpeed covers all the optimisation features Autoptimize provides, so there is no functionality gap from removing it.

Hummingbird (by WPMU DEV)

Hummingbird covers page caching, asset optimisation, GZIP, browser caching, and performance reporting – a full overlap with BlinkSpeed. It also integrates with the WPMU DEV dashboard for hosting-level cache purging.

Note: BlinkSpeed already has native WPMU DEV hosting integration built in. When BlinkSpeed detects that the site is hosted on WPMU DEV infrastructure, it calls wpmudev_hosting_purge_static_cache() automatically during cache purge operations. You do not need Hummingbird for hosting-level cache integration.

What to do: Deactivate Hummingbird. BlinkSpeed’s built-in WPMU DEV hosting integration handles the server-level cache purging that Hummingbird’s hosting-aware purge feature provides.

NitroPack

NitroPack is an all-in-one performance plugin that uses a cloud-based processing pipeline for HTML, CSS, JavaScript, and image optimisation. It replaces your page output almost entirely with its own processed version.

Running NitroPack alongside BlinkSpeed is the most severe optimisation conflict fix scenario because NitroPack rewrites page output at a very deep level. The two plugins’ HTML processing layers will produce unpredictable results and are fundamentally incompatible.

What to do: Deactivate NitroPack completely before activating BlinkSpeed. NitroPack also installs a custom advanced-cache.php drop-in – after deactivating NitroPack, verify that wp-content/advanced-cache.php has been removed or replaced with BlinkSpeed’s version, and that WP_CACHE in wp-config.php is being set by BlinkSpeed rather than NitroPack.

Asset CleanUp (CSS & JavaScript Manager)

Asset CleanUp manages which CSS and JavaScript files load on each page, removing unnecessary scripts and stylesheets to reduce page weight. This overlaps with BlinkSpeed’s exclusion system and JS/CSS processing pipeline.

If Asset CleanUp is configured to remove scripts that BlinkSpeed then tries to minify and combine, or if Asset CleanUp’s own output buffering runs alongside BlinkSpeed’s, the combined processing can produce duplicate or missing file references.

What to do: Deactivate Asset CleanUp. BlinkSpeed’s Exclusions tab – specifically Exclude JavaScript from Lazyload and Exclude Stylesheet URLs from Optimization – gives you the same per-file and per-page control over which scripts and stylesheets are processed.

Flying Scripts and Flying Pages

These lightweight optimisation plugins defer JavaScript loading and preload internal pages. Both tasks are handled natively by BlinkSpeed – Flying Scripts overlaps with BlinkSpeed’s Lazyload JavaScript feature, and Flying Pages overlaps with BlinkSpeed’s preload caching system.

What to do: Deactivate both. Their functionality is fully covered by BlinkSpeed’s built-in JS lazy loading and cache preloading, and running both simultaneously creates CSS/JS conflicts and script loading conflicts.

Perfmatters

Perfmatters disables specific WordPress features and removes unnecessary scripts on a per-page basis. Its script manager and database optimisation features do not directly conflict with BlinkSpeed’s caching and minification pipeline, but its .htaccess changes (for disabling emoji scripts, removing query strings, etc.) can occasionally overlap.

What to do: If you are using Perfmatters primarily for its script manager to disable specific plugin scripts site-wide, deactivate it and use BlinkSpeed’s exclusion system instead. If you are using Perfmatters for its database cleanup, heartbeat control, or WordPress feature disabling features (removing Gutenberg, disabling embeds, etc.), it can coexist with BlinkSpeed as long as you disable Perfmatters’ own caching-adjacent features and its .htaccess modifications are reviewed to ensure no overlap.

Plugins BlinkSpeed Handles Automatically

BlinkSpeed includes built-in detection for several common plugins and adjusts its behaviour automatically – no configuration needed from you.

WooCommerce – Automatic Cache Exclusion

BlinkSpeed detects WooCommerce by checking for woocommerce/woocommerce.php in the active plugins list. When WooCommerce is active, BlinkSpeed automatically adds the cart, checkout, receipt, confirmation, and My Account pages to its internal cache exclusion list. These pages contain session-specific content (cart items, order data, account details) that must never be cached.

This means you do not need to manually add WooCommerce’s dynamic pages to the Exclude Pages from HTML Caching exclusion in BlinkSpeed – it is handled without any configuration on your part. BlinkSpeed matches these pages by both their WordPress page ID (using wc_get_page_id()) and their URL patterns (/cart/, /checkout/, /wc-api/).

WP EasyCart – Automatic Cache Exclusion

When WP EasyCart (wp-easycart/wpeasycart.php) is active, BlinkSpeed automatically adds /cart to its URL exclusion patterns, preventing BlinkSpeed from caching EasyCart’s dynamic cart pages.

Easy Digital Downloads – Automatic Cache Exclusion

When Easy Digital Downloads (easy-digital-downloads/easy-digital-downloads.php) is active, BlinkSpeed automatically excludes /cart and /checkout from caching – the standard EDD purchase flow pages that contain session-specific download access content.

Wordfence Security – Automatic Firewall Respect

Wordfence is a security plugin that blocks malicious requests and triggers 503 responses when its firewall activates. BlinkSpeed detects Wordfence and checks the DONOTCACHEPAGE constant that Wordfence sets during firewall events. When Wordfence triggers a 503 block, BlinkSpeed will not cache that response – the blocked page is never written to the HTML cache.

What this means for you: Wordfence and BlinkSpeed work together without any configuration. Wordfence handles security and signals BlinkSpeed not to cache its blocked responses. BlinkSpeed handles performance caching for all normal, non-blocked page responses.

GTranslate – Automatic Language Cache Paths

GTranslate is a WordPress translation plugin that serves different language versions of your pages. BlinkSpeed detects GTranslate (gtranslate/gtranslate.php) and adjusts its cache file path logic to incorporate the language identifier from the HTTP_X_GT_LANG request header.

This means BlinkSpeed generates and stores separate cached HTML files for each language version of each page – /en/page/, /es/page/, and /fr/page/ each get their own cache file rather than all language versions sharing the same cached output. No configuration is needed – BlinkSpeed handles this automatically when GTranslate is detected.

WPtouch – Mobile Cache Switching

WPtouch is a plugin that serves a mobile-optimised theme to mobile visitors. BlinkSpeed detects WPtouch and adjusts its .htaccess rewrite rules to account for WPtouch’s mobile theme switching logic, preventing the mobile cache files from conflicting with WPtouch’s own mobile routing.

Custom Permalinks – Trailing Slash Detection

The Custom Permalinks plugin replaces WordPress’s standard permalink structure with custom URL patterns that do not follow the standard trailing slash convention. BlinkSpeed detects Custom Permalinks and disables its trailing slash normalisation logic, which would otherwise incorrectly redirect custom permalink URLs.

Plugins That Need Manual Configuration to Work With BlinkSpeed

WPML and Polylang (Multilingual Plugins)

WPML and Polylang create separate URL structures for each language – either via subfolders (/fr/page/) or subdomains (fr.yoursite.com). BlinkSpeed’s cache system generates files based on the request URL, so separate language URLs will naturally receive separate cache files.

However, if you use WPML’s or Polylang’s URL structure with BlinkSpeed’s CDN settings, ensure your CDN configuration uses relative paths rather than absolute domain-specific paths, as these would not resolve correctly across language subdomains.

What to do: No deactivation needed. Test your multilingual pages in a private browser window after enabling BlinkSpeed to confirm each language version is receiving its own correctly cached output. If you notice a language version serving cached content from a different language, add the language-specific URL patterns to Exclude Pages from HTML Caching.

Jetpack (Performance Features)

Jetpack is a multi-feature plugin with many modules. Most Jetpack modules – contact forms, sharing buttons, social login, stats – coexist with BlinkSpeed without any issue. The modules that can conflict are Jetpack’s own performance features: Site Accelerator (CDN for images and static files) and Lazy Images.

What to do: Disable the Site Accelerator module in Jetpack → Settings → Performance if you are using BlinkSpeed’s CDN settings, to avoid two CDN URL rewriting systems running simultaneously. Disable the Lazy Images module in Jetpack if you have enabled BlinkSpeed’s image lazy loading, to prevent double lazy load processing on image tags.

All other Jetpack modules can remain active.
Gravity Forms, WPForms, Formidable Forms

Form plugins generally work fine with BlinkSpeed. The most common performance plugin issue with forms is that their AJAX submission scripts are delayed by BlinkSpeed’s JavaScript lazy loading, causing form submissions to appear unresponsive on the first interaction.

What to do: No deactivation needed. Go to BlinkSpeed → Exclusions → JS Exclusions → Exclude JavaScript from Lazyload and add the form plugin’s main script file with the defer modifier:

• For Gravity Forms: gravityforms/js/jquery.json.js defer and gravityforms/js/gravityforms.min.js defer
• For WPForms: wpforms/assets/js/frontend/wpforms.min.js defer
• For Formidable: formidable/js/formidable.min.js defer

Sliders (Revolution Slider, Smart Slider, Soliloquy)

Slider plugins load CSS and JavaScript that is tightly coupled to the slider initialisation sequence. BlinkSpeed’s lazy JavaScript loading can delay the slider script beyond the point where it initialises correctly, and CSS minification occasionally breaks slider stylesheet syntax.

What to do: No deactivation needed. Add the slider’s CSS to Exclude Stylesheet URLs from Optimization and the slider’s JavaScript to Exclude JavaScript from Lazyload with the defer modifier:

• For Revolution Slider: slider-revolution/public/assets/css and slider-revolution/public/assets/js/revolution.js defer
• For Smart Slider: smart-slider-3/src/Renderable/Asset/dist/smartslider-block-frontend.min.css

Table of Contents Plugins

Table of contents plugins inject inline JavaScript that scrolls the page to anchor links when a visitor clicks a TOC entry. When BlinkSpeed lazy loads inline JavaScript, TOC click handlers may not be registered by the time the visitor clicks.

What to do: Go to BlinkSpeed → Exclusions → JS Exclusions → Force Lazy Load JavaScript and add a distinctive string from the TOC plugin’s inline script content – typically a function name like smoothScroll or a variable like tocSettings. This ensures the TOC script is queued correctly within BlinkSpeed’s lazy load pipeline rather than being skipped.

Plugins That Work Fine Alongside BlinkSpeed

These plugin categories have no meaningful overlap with BlinkSpeed and do not need any configuration adjustments:

• SEO plugins (Yoast SEO, Rank Math, All in One SEO) – these add meta tags and structured data to page output, which BlinkSpeed caches without modification
• Security plugins (Wordfence, Sucuri, iThemes Security) – security scanning and firewall features operate at the server and PHP level, well before or after BlinkSpeed’s caching layer
• Page builders (Elementor, Divi, Beaver Builder, WPBakery) as content tools – the content they generate is cached by BlinkSpeed normally; only their specific scripts and stylesheets may need exclusion rules as described above; also configure the theme settings if it has its own performance optimization settings.
• Membership plugins (MemberPress, Restrict Content Pro) – BlinkSpeed automatically bypasses its cache for logged-in users by default; gated content is served dynamically per session
• Backup plugins (UpdraftPlus, BackupBuddy) – these operate on the database and file system level independently of BlinkSpeed
• Analytics plugins (MonsterInsights, ExactMetrics) – analytics code injected into the page is cached as part of the HTML and reported correctly
• Email marketing plugins (Mailchimp for WordPress, FluentCRM) – form output is cached normally; opt-in confirmation is handled server-side
• Contact page plugins (WPForms, Contact Form 7) – work fine after adding their scripts to Exclude JavaScript from Lazyload with defer modifier as noted above

How to Safely Test for Optimization Conflict Fixes After Installing BlinkSpeed

Once you have deactivated conflicting plugins and activated BlinkSpeed:

1. Go to BlinkSpeed → HTML Caches and enable HTML Caching first – nothing else yet
2. Clear cache and open your homepage, key inner pages, and your most complex pages in private browser windows
3. If everything looks correct, enable CSS Optimization – clear cache and test again
4. Enable JavaScript Optimization with Lazyload JavaScript set to No first – clear cache and test
5. Switch Lazyload JavaScript to Yes – clear cache and test interactivity on every page
6. Enable Image Lazy Loading – clear cache and test all image-heavy pages
7. Enable Critical CSS – clear cache and test first paint on each page type

Enabling one feature at a time means that if a conflict appears, you immediately know which feature caused it and which exclusion rule to write. Enabling everything at once and finding a broken page gives you no starting point.

Frequently Asked Questions

Q1. Can I use Cloudflare with BlinkSpeed?

Yes. Cloudflare operates at the DNS and CDN layer, well above the WordPress application layer where BlinkSpeed works. BlinkSpeed generates and serves optimised pages from your origin server; Cloudflare caches and delivers those pages at the edge. They are complementary, not conflicting. After any BlinkSpeed cache clear, purge Cloudflare’s cache separately from the Cloudflare dashboard or via its API to ensure edge nodes serve your updated content.

Q2. I had WP Rocket installed before BlinkSpeed. Do I need to do anything after deactivating it?

Yes. After deactivating WP Rocket, check three things: first, your .htaccess file for any remaining # BEGIN WP_ROCKET blocks – WP Rocket should clean these up on deactivation, but verify manually. Second, check wp-content/advanced-cache.php – if WP Rocket’s version is still present, delete it so BlinkSpeed can install its own.

Third, check wp-config.php for define(‘WP_CACHE’, true) – if present without BlinkSpeed having set it, remove it and let BlinkSpeed add it when its PHP cache mode is enabled.

Q3. I deactivated another caching plugin, but BlinkSpeed’s cache still seems wrong. Why?

Residual .htaccess rules from the previous plugin are the most common cause. Open your .htaccess file (in your site’s root directory, visible via FTP or File Manager in your hosting panel) and look for any cache plugin rule blocks – they are typically wrapped in # BEGIN [PluginName] and # END [PluginName] comments.

Remove any blocks that do not belong to the previous caching plugin. Then go to BlinkSpeed → General and re-save your settings, which rewrites the .htaccess rules BlinkSpeed needs.

Q4. Does BlinkSpeed work with WooCommerce out of the box?

Yes. BlinkSpeed automatically detects WooCommerce and excludes the cart, checkout, receipt, confirmation, and My Account pages from HTML caching – no manual configuration needed. Product pages, shop archives, and category pages are cached normally. For payment gateway scripts on the checkout page, those run on a page that BlinkSpeed already excludes from caching, so there is no WordPress plugin compatibility issue for the payment flow itself.

Q5. I am using a translation plugin (WPML or Polylang). Do I need to do anything special?

Not typically. BlinkSpeed caches based on the full request URL, so /en/about/ and /fr/about/ are treated as completely separate pages and receive separate cache files. The main thing to verify is that each language version of your most important pages is loading correctly in a private browser window.

If you use language subdomains rather than subfolders, also verify your CDN settings in BlinkSpeed are not using hardcoded domain-specific URLs that would fail to resolve on the language subdomains.

Q6. Will security plugins like Wordfence or Sucuri cause a performance plugin issue with BlinkSpeed?

Not in normal operation. BlinkSpeed has specific Wordfence awareness built into its source code – it checks for Wordfence’s DONOTCACHEPAGE constant and respects its 503 firewall responses by not caching them. Sucuri’s firewall operates at the DNS level (like Cloudflare) and does not interfere with BlinkSpeed at all.

iThemes Security, Solid Security, and similar plugins that work at the PHP and .htaccess level are compatible as long as their own .htaccess file modifications do not conflict with BlinkSpeed’s cache delivery rules – check your .htaccess if you have both active and notice issues.

Q7. Can I use a CDN plugin alongside BlinkSpeed?

It depends on which CDN plugin. BlinkSpeed has its own CDN URL rewriting feature under BlinkSpeed → CDN. If you use a separate CDN integration plugin (like WP Offload Media for S3/CloudFront), do not also enable BlinkSpeed’s CDN URL rewriting for the same asset types – two URL rewriting layers on the same assets produce broken URLs. Use one or the other. For CloudFront or BunnyCDN integration that simply pulls files from your origin without rewriting page URLs, it coexists with BlinkSpeed without issue.

The post BlinkSpeed Plugin Conflict Guide: What to Disable, Configure, or Leave Alone appeared first on Blinkspeed.

This guide walks through where a slow WooCommerce store actually loses time, which BlinkSpeed settings address each bottleneck, and how to configure everything so your shop runs fast without breaking checkout, cart updates, or your account dashboard along the way.

Where a WooCommerce Store Actually Loses Speed

Before changing settings, it helps to know what is typically slow on an ecommerce site and why a generic caching plugin setup often does not fully fix it.

Database load on product and category pages. Every time a product page renders, WooCommerce queries the database for price, stock status, variations, related products, and reviews. Multiply this across hundreds of products and thousands of monthly visits, and the cumulative database load becomes a real bottleneck if pages are not cached.

Image weight. Product photography is usually the single heaviest asset type on a store – multiple images per product, often at high resolution to support zoom functionality, displayed across shop grids, single product pages, and related-product widgets simultaneously.

Plugin-heavy frontend. A typical WooCommerce setup runs payment gateway scripts, shipping calculators, review plugins, wishlist plugins, and upsell or cross-sell tools – each adding their own CSS and JavaScript to the page.

Mobile traffic share. Ecommerce traffic skews heavily mobile, and mobile devices process JavaScript more slowly and have less reliable bandwidth than desktop, which exposes any unoptimised script or oversized image far more severely.

BlinkSpeed addresses all four of these directly, provided the right settings are configured for a store rather than a simple blog or brochure site.

Step 1 – Get HTML Caching Working Correctly for a WooCommerce Speed Fix

Go to BlinkSpeed → HTML Caches and enable HTML Caching.

This is the foundation of any WooCommerce speed fix; it eliminates the repeated database queries WooCommerce runs on every single page view by serving a static, pre-rendered version of the page to subsequent visitors instead.

Enable Caching for Pages with GET Parameters

WooCommerce shop and category pages frequently use query strings for sorting (?orderby=price) and pagination (?paged=2). Go to BlinkSpeed → HTML Caches and enable Enable Caching for Pages with GET Parameters. Without this, every sorted or paginated view of your shop bypasses the cache and triggers a fresh, slow render – which on a store with a large catalogue and active filtering can mean a large share of your real browsing traffic never benefits from caching at all.

Enable Preload Caching to Avoid Cold Product Pages

With a catalogue of any meaningful size, many product pages are visited infrequently enough that their cache regularly expires between visits. Go to BlinkSpeed → HTML Caches, enable Preload Caching, and set Preload Pages Per Minute to somewhere between 4 and 8 for a typical store. This runs a background process that keeps your product and category pages pre-warmed in the cache, so even a rarely-visited product page loads from cache rather than forcing the next visitor through a slow, uncached render.

One Important Exception: Cart, Checkout, and Account Pages

It’s worth noting that BlinkSpeed automatically detects WooCommerce and completely excludes the cart, checkout, receipt, confirmation, and My Account pages from this caching system – these pages contain session-specific content (your cart contents, order details, account info) that must never be served as a shared static file to different visitors. This happens automatically with no configuration needed, and it means your settings here apply fully to your shop, product, and category pages without any risk to the personalised parts of the buying flow.

Step 2 – Configure Image Settings for Product Page Optimization

Since product photography is usually the heaviest part of a store, image settings deliver some of the biggest wins for product page optimization.

Enable WebP Conversion

Go to BlinkSpeed → Image Optimization and enable Convert to WebP for both JPG and PNG. WebP delivers the same visual quality as a standard JPEG or PNG at roughly 30–50% smaller file size – a meaningful reduction when multiplied across a catalogue of products, each with several images.

License note: on the free version, WebP conversion only runs on the homepage. Since most shopping activity happens on product and category pages rather than the homepage, getting the full benefit of this feature for a real store requires a premium license, after which you can run BlinkSpeed → Optimize with AI to process your entire catalogue.

Enable Responsive Images

Go to BlinkSpeed → Image Optimization and enable Responsive Images. This serves a smaller, appropriately-sized image to mobile visitors rather than the same full desktop-resolution file – directly relevant given how much shopping traffic happens on phones.

Enable Lazy Loading, With One Key Exception

Go to BlinkSpeed → Image Optimization and enable Lazy Load for images. Product pages typically have a gallery, related-product carousels, and review images further down the page – none of which need to load immediately.

The one image that should never be lazy loaded is the main product photo, since it is very likely your page’s Largest Contentful Paint element. Go to BlinkSpeed → Exclusions → Media Exclusions → Exclude Media from Lazy Loading and add a matching string for it – typically a class like woocommerce-product-gallery__image on default WooCommerce themes – so it loads immediately and with priority instead of waiting for the visitor to scroll.

Step 3 – Configure CSS and JavaScript Optimisation Without Breaking Shop Functionality

Go to BlinkSpeed → CSS Optimization and enable CSS Optimization, then enable Load Critical CSS and run the AI Optimisation process so above-the-fold styles are generated for your product and category templates specifically. Since WooCommerce pages tend to follow a consistent template structure, critical CSS generated once typically applies well across your whole catalogue, speeding up how quickly the price and add-to-cart button visually appear.

Go to BlinkSpeed → JavaScript Optimization, enable Enable JavaScript Optimization, and set Lazyload Javascript to Yes. This minifies your JS and defers non-essential scripts until the visitor interacts with the page, which is one of the more effective ways to improve a stubbornly slow Lighthouse score on a script-heavy storefront.

Protect the Add-to-Cart Script

WooCommerce’s AJAX add-to-cart functionality needs to be ready the moment a shopper clicks the button – and the click itself is the interaction that would otherwise trigger BlinkSpeed’s JavaScript delay system, creating a timing conflict on the very first click. Go to BlinkSpeed → Exclusions → JS Exclusions → Exclude Javascript from Lazyload and add:

The defer modifier keeps the script non-blocking for page render speed while making sure it is active and ready as soon as the HTML finishes parsing, rather than waiting for an interaction.

Protect Variation Scripts on Variable Products

If your store sells products with size, colour, or other variations, add the same kind of protection for the variation script:

A WooCommerce Configuration Checklist

Step 4 – Improve Mobile Speed for Mobile Shoppers

Because so much shopping traffic is mobile, it’s worth checking your mobile-specific settings separately from desktop.
Go to BlinkSpeed → General Settings and enable Fix INP Issues. This adds preconnect hints for third-party domains – particularly relevant for payment gateway scripts, review widgets, and marketing pixels that mobile CPUs take longer to connect to and execute compared to desktop.

Confirm Responsive Images and Convert to WebP are both active, since the combined effect of smaller dimensions and a more efficient format has an outsized impact on mobile load times where bandwidth is more constrained.

Step 5 – Use the AI Optimisation Dashboard to Process Your Catalogue

A common reason a “configured” store still feels slow is that settings were enabled but the actual processing – Critical CSS generation and WebP conversion – has not run yet. Go to BlinkSpeed → Optimize with AI and click Start Optimization. This crawls your site’s URLs and queues each one for Critical CSS extraction and image conversion. For a store with a large catalogue, this can take some time depending on your preload speed setting – check the progress dashboard and confirm your most important category and product pages show as complete before judging results.

Common Reasons a WooCommerce Store Still Feels Slow After Setup

Frequently Asked Questions

Q1. What is the single most impactful setting for a WooCommerce speed fix?

For most stores, enabling HTML Caching combined with Preload Caching produces the largest single improvement, since it removes the repeated database queries WooCommerce runs on every page load for pricing, stock, and product data. Image optimisation (WebP and responsive images) is usually the second-biggest factor given how image-heavy most catalogues are.

Q2. Why does my checkout page feel just as slow as before I installed BlinkSpeed?

Checkout, along with cart and account pages, is automatically excluded from BlinkSpeed’s optimisation because it displays session-specific content – your specific cart items, your specific order, your specific account details – that can never safely be cached or shared between visitors. Checkout speed instead depends on your server’s processing speed, how many payment gateways and shipping calculators are active, and how lean your checkout page template is. The faster checkout speed gains from BlinkSpeed come indirectly, by making sure shoppers reach checkout in the first place rather than abandoning a slow product or category page earlier in their visit.

Q3. Will product page optimization actually affect my sales, or just my PageSpeed score?

It affects both, and the sales impact is usually the more meaningful one. Slow product and category pages are associated with higher bounce rates and lower add-to-cart rates in most studies on ecommerce performance. Since shoppers typically browse several product and category pages before deciding to buy, speeding up exactly those pages addresses the part of the shopping journey with the most opportunities to influence whether a sale happens at all.

Q4. Does an ecommerce speed plugin like BlinkSpeed work with WooCommerce extensions like Subscriptions or Bookings?

Generally yes. BlinkSpeed’s core optimisations – HTML caching, CSS/JS optimisation, image handling – operate at the page output level and are compatible with most WooCommerce extensions, since these extensions typically render within WooCommerce’s standard page structure. The same caution that applies to cart and checkout applies to any extension page showing live, session-specific data – such as a subscription management screen or a booking calendar with real-time availability. If you notice incorrect cached content on a page like this, add its specific URL to Exclude Pages from HTML Caching as a precaution.

Q5. How long should I wait after configuring settings before judging the results?

Lab test scores like PageSpeed Insights update immediately once you clear the cache and the AI Optimisation process has completed for the page you’re testing. Real-world improvement, measured through BlinkSpeed’s own Core Web Vitals logs, typically takes a few days of traffic to show a clear pattern. If you’re checking Google Search Console’s Core Web Vitals report specifically, allow up to 28 days, since that report is a rolling average of real visitor data rather than a live snapshot.

Q6. Can a cart performance fix from another plugin be used alongside BlinkSpeed?

It’s not generally recommended to run two plugins optimising the same pages, since overlapping caching or script-handling logic tends to produce unpredictable results. Since BlinkSpeed already leaves cart and checkout untouched by design, a separate plugin focused specifically on cart functionality (such as a persistent cart across devices, or an AJAX cart drawer) can be used without conflicting with BlinkSpeed’s optimisation of the rest of the store.

Q7. My store has thousands of products. Will the AI Optimisation process handle that?

Yes, though it will take longer than a small catalogue. The process works through your URL queue at the rate set in Preload Pages Per Minute, so a very large catalogue will take proportionally longer to fully process for Critical CSS and WebP conversion. You don’t need to wait for the entire catalogue to finish before benefiting – pages are usable and improved as soon as they’re individually marked complete, and BlinkSpeed processes new or updated product pages incrementally rather than requiring a full restart each time.

Summary

A genuinely effective BlinkSpeed WooCommerce optimization setup focuses on the pages that carry the most traffic and the most weight – shop pages, product pages, and category archives – with HTML caching, preload caching, WebP conversion, responsive images, lazy loading, and Critical CSS all configured specifically with a catalogue-driven site in mind. A small number of targeted JavaScript exclusions, like deferring the add-to-cart script, keep core shopping functionality reliable while everything else stays fully optimised.

Cart, checkout, and account pages are automatically excluded from this optimisation since they show personalised, session-specific content that should never be cached – this is expected behaviour, not something to configure around. Run through the checklist above, complete the AI Optimisation process for your catalogue, and check mobile settings separately given how much shopping traffic happens on phones, and most of the slowness reported on a WooCommerce store resolves without any risk to the buying process itself.

The post A Practical Guide to BlinkSpeed WooCommerce Optimization appeared first on Blinkspeed.

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.

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:

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

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 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.

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.

The post The Complete BlinkSpeed PageSpeed Fix Guide appeared first on Blinkspeed.

Mobile performance is harder to fix than desktop performance for a simple reason: the conditions are worse. Mobile devices have slower processors, less RAM, and often rely on 4G or weak Wi-Fi connections rather than fibre broadband. A page that loads in 1.5 seconds on a desktop over a wired connection might take 4 or 5 seconds on a mid-range Android phone over 4G. The same HTML, the same CSS, the same images – a completely different experience.

Google’s mobile Core Web Vitals are measured under those real-world conditions, which is why so many sites pass on desktop and fail on mobile. The good news is that BlinkSpeed has a full set of features built specifically for slow mobile website issues – separate mobile caching, mobile-specific image handling, deferred JavaScript, and more.

This is your complete mobile optimization guide: every BlinkSpeed setting that affects mobile performance, why it matters, and exactly how to configure it.

Why Your Mobile Score Is Lower Than Desktop

Before diving into settings, it helps to understand the gap. Google measures mobile Core Web Vitals using a simulated mid-range device (the Moto G Power category) on a throttled 4G connection. Under those conditions:

• LCP (Largest Contentful Paint) is nearly always worse on mobile because images take longer to download and the CPU takes longer to render them
• INP (Interaction to Next Paint) is worse because mobile CPUs process JavaScript more slowly, so script execution blocks interactions for longer
• CLS (Cumulative Layout Shift) can be worse on mobile because elements that fit on a wide desktop viewport may reflow on a narrow mobile screen, causing shifts that do not occur on desktop

Every BlinkSpeed setting that addresses a slow mobile website problem does so by reducing what the browser has to download, process, or execute before showing a usable, stable page to the visitor.

How BlinkSpeed Detects Mobile Devices

BlinkSpeed determines whether a visitor is on a mobile device by reading the User-Agent string sent with every HTTP request. Its detection pattern covers a comprehensive list of mobile browsers (including Chrome Mobile, Firefox for Android, Safari for iPhone, Samsung Browser, Opera Mini, UC Browser, and others) and mobile operating systems (Android, iOS, BlackBerry, Windows Phone, Symbian, WebOS, and more).

When a visitor is identified as a mobile user, BlinkSpeed switches to a parallel set of processing rules. Mobile CSS files are cached with the extension .mob.css. Mobile JavaScript files are cached as .mob.js. Mobile HTML pages are stored in a separate /bsmob/ directory within the cache folder. This means mobile and desktop visitors never share the same cached files – mobile visitors always receive an output that was generated and optimised specifically for their device context.

This is the foundation that makes every other mobile-specific optimisation possible. Every setting described in this guide benefits from this architecture.

Step 1 – Enable HTML Caching: The Biggest Win for Mobile Speed

The single largest improvement you can make to a slow mobile website is enabling HTML page caching. Without caching, every mobile visitor triggers a full WordPress PHP execution cycle – database queries, plugin hooks, template rendering – before a single byte of HTML reaches their device. On a slow mobile connection, the time-to-first-byte alone can be 500ms to over a second just from this overhead.

Go to BlinkSpeed → HTML Caches and enable HTML Caching.

BlinkSpeed generates a static HTML file the first time a page is loaded and stores it in the cache directory. Every subsequent mobile visitor receives that static file directly – the web server sends it without loading PHP, WordPress, or any plugins. This can reduce your server response time from 800–1200ms to under 50ms.

Mobile Cache Files Are Stored Separately

BlinkSpeed stores mobile HTML cache files in a dedicated /bsmob/ subdirectory, separate from desktop cache files. This means:

• Changes to mobile output (from responsive themes, mobile-specific plugins, or AMP) do not affect desktop cache
• Mobile cache can be cleared independently if needed without touching desktop pages
• If your theme or page builder renders different HTML for mobile visitors, the correct mobile version is cached

Enable Preload Caching for Mobile Visitors

After enabling HTML caching, also enable Preload Caching and set a Preload Pages Per Minute value. Without preloading, every page starts uncached after a clear – the first mobile visitor to each URL gets the slow, dynamically rendered response while everyone after them gets the fast cached version.

Preloading runs a background process that generates cached versions of your pages before any real visitor arrives. Set the preload rate between 3 and 6 pages per minute for most hosting environments. This ensures that even after a cache clear or a content update, mobile visitors always receive pre-warmed, fast-loading pages.

Step 2 – Enable GZIP Compression to Improve Mobile Speed

Mobile connections transfer data more slowly than broadband. A 60KB HTML file takes noticeably longer to download over 4G than over fibre. GZIP compression reduces the file size of your HTML, CSS, and JavaScript files before they travel across the network.

Go to BlinkSpeed → HTML Caches and enable GZIP Compression.

With GZIP enabled, BlinkSpeed adds compression rules to your .htaccess file. A typical 80KB HTML page compresses to around 18–22KB – a 75% reduction. For CSS files, the compression ratio is often even better because CSS contains highly repetitive patterns that compress extremely well.

For mobile visitors on 4G or lower connections, this reduction in transfer size translates directly into faster perceived load times. GZIP is one of the lowest-effort, highest-impact changes you can make to improve mobile speed.

Step 3 – Enable Leverage Browser Caching for Returning Mobile Visitors

Mobile visitors who return to your site should not have to re-download the same CSS, JavaScript, images, and fonts they already downloaded on their first visit. Browser caching tells their device to store those files locally and reuse them on subsequent visits.

Go to BlinkSpeed → HTML Caches and enable Leverage Browsing Cache.

BlinkSpeed writes Cache-Control and Expires headers into your .htaccess file. These tell mobile browsers to cache static assets – typically images and fonts for up to a year, CSS and JavaScript files for up to a month. For a returning mobile visitor, page load times on the second and subsequent visits are dramatically lower because most of the page’s assets are already on their device.

This has a significant positive effect on mobile Core Web Vitals for return visitors. LCP in particular improves substantially when the LCP image or hero background is loaded from the device’s own cache rather than downloaded again over a mobile connection.

Step 4 – Enable Responsive Images for Mobile Visitors

This is one of the most impactful settings specifically for a slow mobile website. When BlinkSpeed converts your images to WebP and serves them, it can optionally serve a smaller, resized version of each image to mobile visitors rather than the same full-resolution image served to desktop users.

Go to BlinkSpeed → Image Optimization and enable Responsive Images.

When this setting is on, and a mobile visitor loads a page, BlinkSpeed detects the mobile device context using its is_mobile flag and serves a resized version of images – specifically a 595-pixel-wide WebP variant – rather than the full-size original. On a desktop, a 2000-pixel-wide hero image might display at 1800 pixels wide, and the full file is appropriate. On a mobile phone where the screen is 390 pixels wide, that same image is overkill – the device downloads 2000 pixels of data and displays 390 pixels of output.
With responsive images enabled:

• Mobile visitors receive a smaller file (sometimes 70–80% smaller than the desktop version)
• Download time on mobile connections drops proportionally
• LCP time improves because the image the browser needs to paint arrives faster

This is one of the most direct improvements you can make to mobile Core Web Vitals scores because LCP on most pages is determined by a large image, and that image loads faster when it is sized appropriately for the device.

Step 5 – Enable WebP Conversion for Faster Image Loading

In addition to resizing images for mobile, BlinkSpeed can convert all your JPG and PNG images to the WebP format – a modern format that delivers the same visual quality at 25–50% smaller file sizes.

Go to BlinkSpeed → Image Optimization and enable Convert to WebP for both JPG and PNG.

WebP images are supported by all major mobile browsers, including Chrome for Android, Safari for iOS (version 14 and later), and Samsung Internet. For mobile visitors, the combined effect of WebP conversion and responsive image sizing means they receive an image that is:

• 595 pixels wide instead of 2000 pixels wide (the responsive images benefit)
• 30–50% smaller at that resolution (the WebP benefit)

Together these two optimisations can reduce an image’s download footprint by 80% or more compared to a full-size original JPEG – a profound improvement for mobile speed on image-heavy pages.

Remember: WebP conversion runs on all pages with a premium license. With the free version, it runs on the homepage only. If your mobile Core Web Vitals are failing on inner pages (blog posts, product pages, category archives), a premium license is required for site-wide WebP delivery.

Step 6 – Enable Image and Media Lazy Loading

Images that are below the fold – below what the mobile visitor can see without scrolling – do not need to load immediately. Loading them upfront wastes precious mobile bandwidth and delays the loading of content that is actually visible.

Go to BlinkSpeed → Image Optimization and enable Lazy Load for Images, Iframes, Videos, and Audio.

BlinkSpeed replaces below-the-fold image src attributes with a tiny transparent placeholder and stores the real image URL in a data-* attribute. A small JavaScript file then watches for each image approaching the viewport as the user scrolls, and swaps in the real source at that moment.

The impact on mobile Core Web Vitals is significant:

• LCP improves because the browser spends its initial bandwidth on above-the-fold content only
• Total Blocking Time improves because the lazy load script is lightweight and does not block rendering
• Data savings benefit mobile visitors on limited data plans – images they never scroll to are never downloaded at all

Do Not Lazy Load Your LCP Image

The most important exception: never lazy load the hero image or largest above-the-fold image on any page. Lazy loading delays an image until the user scrolls toward it – if the LCP image is lazy loaded, the browser intentionally delays the element that determines your LCP score, making it worse rather than better.

Go to BlinkSpeed → Exclusions and add your LCP image URL or CSS class to Exclude Resources from Lazy Loading. BlinkSpeed then applies a tag for that image, actively telling the browser to prioritise it – the opposite of lazy loading.

Step 7 – Fix INP Issues to Improve Mobile Interaction Speed

INP (Interaction to Next Paint) measures how quickly your page responds when a mobile visitor taps a button, link, or interactive element. On mobile devices, INP is frequently worse than desktop because mobile CPUs process JavaScript more slowly. A JavaScript-heavy page can have 400–600ms of input delay on mobile even if desktop INP is under 100ms.

Go to BlinkSpeed → General Settings and enable Fix INP Issues.

When this toggle is on, BlinkSpeed scans every external JavaScript URL in your page output and adds hints for their origin domains – including domains referenced inside inline scripts. Preconnect establishes the DNS, TCP, and TLS connections to those third-party domains early in the page load, before those scripts are needed.

On mobile connections, connection setup time (DNS + TCP + TLS handshake) to a third-party domain can easily add 300–500ms to script loading time. Preconnect eliminates most of this delay by completing the setup in parallel with the HTML parsing, so that by the time BlinkSpeed’s lazy-load system triggers those scripts, the connection is already established and scripts arrive almost immediately.

This directly benefits mobile Core Web Vitals because INP on mobile is often dominated by third-party scripts – analytics, chat widgets, tracking pixels, advertising – that are slow to establish connections.

Step 8 – Delay JavaScript to Eliminate Render-Blocking on Mobile

JavaScript that loads and executes during page parsing prevents the browser from displaying any content until the script is finished. On a mobile CPU that processes JavaScript 3–5 times more slowly than a desktop CPU, a render-blocking script that takes 50ms on desktop might take 200–300ms on mobile – directly worsening LCP and Total Blocking Time.

Go to BlinkSpeed → JavaScript Optimization and set Lazyload JavaScript to Yes.

When enabled, BlinkSpeed changes script tags from type=”text/javascript” to type=”lazyJs”, which the browser ignores during page parsing. BlinkSpeed’s lightweight loader (script-load.min.js) then triggers all deferred scripts on the first user interaction, a tap, scroll, or touch event on mobile. This means the browser can fully paint and display the page before executing any JavaScript, resulting in dramatically lower LCP and TBT times.

Additionally, enable JavaScript Optimization to minify all JS files, reducing their byte size before they are downloaded on mobile connections.
Protect Critical Scripts with Exclusions

If certain interactive elements need to work immediately on page load – a mobile menu toggle, a sticky header script, or a mobile search form – add those scripts to BlinkSpeed → Exclusions → Exclude Javascript from Lazyload with the defer modifier. This keeps them non-blocking (they do not run during parsing) but ensures they execute immediately after the HTML has been parsed, without waiting for user interaction.

Step 9 – Load Critical CSS for Mobile Devices

Critical CSS extracts the above-the-fold styles for each page and delivers them inline at the top of the HTML, so the browser can paint the visible layout immediately without waiting for the full stylesheet to download.

Go to BlinkSpeed → CSS Optimization and enable Load Critical CSS.

BlinkSpeed generates critical CSS separately for mobile and desktop. When a mobile visitor loads a page, BlinkSpeed serves the mobile-specific critical CSS file (stored with a mob token in the critical CSS path). This file contains only the styles needed to paint the mobile above-the-fold layout – typically a much smaller set than the desktop equivalent, since mobile layouts are simpler.

The result is that mobile visitors see a fully styled, properly laid-out page almost immediately after the HTML arrives – even before the full main stylesheet has finished loading. This directly improves LCP because the largest above-the-fold element is painted correctly on the first render rather than waiting for styles to load.

Use Load Critical CSS in Style Tag for Faster Mobile Paint

Go to BlinkSpeed → CSS Optimization and enable Load Critical CSS in Style Tag.

This sub-setting delivers the critical CSS inside a <style>  block rather than via a preload link. On mobile devices, the <style> tag approach is often faster because the browser applies inline styles without a separate preload step, reducing the number of rendering phases before the first paint.

Step 10 – Enable CSS Optimisation for Smaller Stylesheet Downloads

Every CSS file your site loads takes time to download over a mobile connection. Minifying CSS removes comments, whitespace, and redundant formatting, reducing file sizes by 20–40%.

Go to BlinkSpeed → CSS Optimization and enable CSS Optimization.

BlinkSpeed minifies all CSS files and stores the minified versions in the cache directory. Combined CSS files are served as a single request rather than multiple individual file requests. On mobile, where each HTTP request adds connection overhead, reducing the number of CSS requests can be as impactful as reducing their file sizes.

Also enable Localise Google Fonts if your site uses Google Fonts. This downloads font files from Google’s servers and hosts them locally under your own domain. Mobile visitors no longer need to establish a separate connection to fonts.googleapis.com and fonts.gstatic.com – both of which add connection overhead and can fail on restricted mobile networks or behind corporate proxies.

The Mobile Optimization Checklist

Go through this checklist in order to make sure every mobile-relevant setting in BlinkSpeed is configured:

BlinkSpeed → HTML Caches

• Enable HTML Caching – On
• Enable Preload Caching – On
• Preload Pages Per Minute – 3 to 6 (adjust for your host)
• Enable Leverage Browsing Cache – On
• Enable GZIP Compression – On

BlinkSpeed → CSS Optimization

• Enable CSS Optimization – On
• Localise Google Fonts – On (if your site uses Google Fonts)
• Load Critical CSS – On
• Load Critical CSS in Style Tag – On

BlinkSpeed → JavaScript Optimization

• Enable JavaScript Optimization – On
• Lazyload Javascript – Yes

BlinkSpeed → Image Optimization

• Enable Lazy Load (Images) – On
• Enable Lazy Load (Iframes) – On
• Enable Lazy Load (Videos) – On
• Responsive Images – On
• Convert to WebP (JPG) – On
• Convert to WebP (PNG) – On

BlinkSpeed → General Settings

• Fix INP Issues – On

BlinkSpeed → Exclusions

• LCP image added to Exclude Resources from Lazy Loading

Reading Your Mobile Core Web Vitals Logs After Applying Fixes

After making these changes, give your site 24–48 hours of live traffic and then check BlinkSpeed’s built-in performance logs.

Go to BlinkSpeed → Debug Logs and enable Core Web Vitals Logs if you have not already. Then use the Device Type filter to select Mobile and the Issue Type filter to select LCP.

The log table shows which pages are still experiencing slow mobile website LCP events, what rating they received (needs improvement or poor), and – via the View More button on each entry – which specific element is the LCP candidate and whether the delay is in the network transfer or the render phase.

This real-user data from actual mobile visitors is more reliable than any lab test for identifying which pages still need attention after your initial configuration pass. Use the Date Range filter to compare log volume before and after your BlinkSpeed changes – a reduction in mobile LCP entries is direct evidence of speed improvement tracking in action.

Frequently Asked Questions

Q1. Why does my mobile speed score stay low even after enabling all BlinkSpeed settings?

The most common reason is that the LCP image is still slow. Run Google PageSpeed Insights on your homepage and look at the “Opportunities” section. If it lists “Preload Largest Contentful Paint image” or “Reduce initial server response time”, your LCP image may be loading without the preconnect benefit, or it may not be in WebP format yet.

Go to BlinkSpeed → Optimize with AI and run the full optimization process to ensure WebP versions of all images have been generated. Also confirm that the LCP image is added to the exclusions list rather than being lazy loaded.

Q2. Does BlinkSpeed’s mobile cache work with Accelerated Mobile Pages (AMP)?

BlinkSpeed’s mobile caching is based on User-Agent detection rather than URL patterns, so it does not specifically target AMP URLs. If you are using an AMP plugin that generates separate /amp/ URLs, those pages are typically excluded from standard caching because they have different HTML structure. For non-AMP mobile optimisation – which is the standard approach for most modern WordPress sites – BlinkSpeed’s mobile cache system works fully and independently.

Q3. How do I know if the responsive images feature is working for mobile visitors?

Open your site on a mobile device or use Chrome DevTools in mobile emulation mode (F12 → toggle device toolbar → select a mobile device). Then open the Network tab, filter by Images, and reload the page. If responsive images are working, the image URLs will point to files ending in WebP format, and the file sizes will be noticeably smaller than the desktop equivalents. You can also use the BlinkSpeed debug logs to check whether mobile Core Web Vitals are improving – improving LCP values for mobile visitors directly reflect faster image delivery.

Q4. Will delaying JavaScript break my mobile menu or navigation?

It can if the mobile menu’s toggle script runs on user interaction and is also delayed by BlinkSpeed’s lazy load until the first interaction. This creates a brief window where the menu toggle does not work on the very first tap. The fix is straightforward:

Go to BlinkSpeed → Exclusions → Exclude JavaScript from Lazyload, add the mobile menu’s script file path with the defer modifier. This makes the script execute immediately after HTML parsing without blocking rendering – the menu toggle works from the first tap and your LCP and TBT scores remain improved.

Q5. My mobile speed improved, but CLS is still failing. What does BlinkSpeed address for CLS?

CLS on mobile is often caused by images without reserved dimensions loading and pushing content down, or by fonts loading mid-render and reflowing text. For images, ensure you have not lazy-loaded your above-the-fold hero image (which causes a layout shift as it loads in).

For fonts, enable Localise Google Fonts to serve fonts from your own domain over a pre-established connection – this reduces the time between initial text render (in fallback font) and font swap (to the web font), which reduces the CLS delta. You can also use Load Style Tag in Head to Avoid CLS in the CSS Optimization tab to move any inline styles that are causing layout shifts at render time.

Q6. Does enabling Lazyload Javascript affect mobile differently than desktop?

Yes, slightly. The trigger for lazy-loaded scripts differs by device. On desktop, scripts fire on the first click event or after the user scrolls 200 pixels. On mobile, the trigger is a touchstart event – the first touch anywhere on the screen.

In practice, this difference is minimal for most visitor behaviour, but it means scripts fire on the first intentional touch on mobile, which typically happens within 1–2 seconds of page load. This is intentional: mobile visitors interact more quickly than desktop visitors, so the trigger is appropriately sensitive to touch input.

Q7. The mobile performance logs show LCP issues on my blog posts but not the homepage. Why?

This is a common situation and usually means WebP conversion is running on the homepage only – which indicates the free version of BlinkSpeed is active. Blog post images are not being served in WebP format, which means they are larger and slower to download on mobile connections.

Upgrading to a premium license and running the AI Optimization process on your full site URL list will extend WebP conversion and critical CSS generation to every blog post, which typically resolves the LCP gap between the homepage and inner pages for mobile visitors.

Q8. How long after making changes will I see improvement in Google Search Console?

Google Search Console’s Core Web Vitals report uses a rolling 28-day window of real-user field data. This means changes you make today will take up to 28 days to fully reflect in the Search Console report. For faster feedback, use BlinkSpeed’s own performance logs filtered to Mobile device type – these update within hours of real mobile visits and give you immediate confirmation that your settings are improving actual visitor experience, even before the Search Console report catches up.

The post The Complete Slow Mobile Speed Fix Using BlinkSpeed appeared first on Blinkspeed.

Don’t panic. You’re not alone, and this is more common than you think.

In this guide, we’ll break down exactly what’s happening, why JavaScript delays cause these headaches, and most importantly how you actually fix it. No tech degree needed.

What Even Is JavaScript and Why Does It Matter?

Think of your website like a human body.

• HTML is the skeleton of the basic structure.
• CSS is the skin and clothes how it looks.
• JavaScript is the muscle that makes things move and react.

When JavaScript breaks or loads too slowly, your website becomes a body that can’t move. Buttons don’t respond. Sliders freeze. Forms go dead.

That’s the short version of what a JS delay issue does to your site.

What Is the JavaScript Issue in Blinkspeed?

BlinkSpeed is an optimization tool that speeds up your website by controlling how and when scripts load. Sounds great, right? And usually, it is.

But here’s where things get tricky.

BlinkSpeed sometimes gets a little too aggressive with how it handles JavaScript. It tries to load scripts faster or delay certain ones and in doing that, it accidentally messes up the order in which things load. When scripts don’t load in the right order, your website starts throwing JavaScript errors left and right.

It’s like telling all the musicians in an orchestra to start playing at different random times. Even if each musician is great, the result is just noise.

Why Does JavaScript Loading Order Even Matter?

Imagine you have a script that makes your contact form work. But that script depends on another script called jQuery to run first. If jQuery loads a second late or doesn’t load at all your contact form script is basically trying to build a house on no foundation. It crashes.

This dependency problem is at the heart of most JavaScript errors you’ll see.

Common Signs You Have a JavaScript Delay Problem

Not sure if this is your issue? Here are the red flags:

• Pages look fine visually but interactive things don’t work
• You see error messages in the browser like “$ is not defined” or “Cannot read properties of undefined”
• Your site works fine on a fresh load but breaks after a plugin update
• The issue started after you installed or updated a speed optimization plugin
• Mobile users are complaining more than desktop users

If any of these sound familiar, keep reading.

The Most Common Cause: Script Conflict Fix Gone Wrong

When optimization tools try to “fix” your site speed, they often move or delay scripts using something called defer or async attributes. These are legitimate techniques but they need to be applied carefully.

Defer tells the browser: “Load this script, but don’t run it until the page has fully loaded.”

Async tells the browser: “Load and run this script as soon as it’s ready, without waiting for anything else.”

Both sound helpful. And they are when used correctly. But slap defer on the wrong script, and suddenly the thing that script was supposed to control has no idea what to do.

This is where most script conflict fixes go sideways.

Broken Functionality in WordPress: Why It Happens More There

If you’re on WordPress, you’re probably dealing with this even more.

WordPress websites run on plugins. And plugins each bring their own JavaScript files. Sometimes ten, sometimes thirty different script files running on a single page. Each one was written by a different developer, on a different day, for a different purpose.

Now add a speed optimization plugin into that mix, one that starts delaying and deferring all these scripts and you’ve got a recipe for broken functionality in WordPress.

The optimization plugin doesn’t know that Plugin A’s script needs to run before Plugin B’s. It just sees a bunch of script files and starts shuffling them around like a deck of cards.

Result? Your site slows down in weird ways, or stops working in even weirder ways.

How to Troubleshoot This Step by Step

Let’s get into the actual defer JS troubleshooting process. Take it one step at a time.

Step 1: Open Your Browser Console

Right-click anywhere on your webpage and click Inspect (or press F12). Then go to the Console tab.

You’ll see red error messages if JavaScript is broken. These messages are actually really helpful; they tell you which script is failing and why.

Look for things like:

• Uncaught ReferenceError
• Uncaught TypeError
• $ is not defined

Screenshot these. You’ll need them.

Step 2: Temporarily Disable Your Optimization Plugin

If you’re using a plugin like BlinkSpeed, WP Rocket, LiteSpeed Cache, or any other performance optimizer, disable it temporarily.

Then reload your page.

Did things start working again? If yes, you’ve found your culprit. The optimization plugin was interfering with your scripts.

Step 3: Re-Enable It and Look for the Exclusion Settings

Here’s the thing you don’t need to permanently disable your speed plugin. You just need to tell it which scripts to leave alone.

Most optimization plugins, including BlinkSpeed, have an exclusion list for JavaScript. This is where you list the scripts that should NOT be deferred or delayed.
Go to the plugin settings and look for:

• “Exclude JS files from defer”
• “Do not optimize these scripts”
• “Script exclusions”

Step 4: Add the Problematic Scripts to the Exclusion List

From the console errors you found in Step 1, you’ll see file names like: /wp-content/plugins/some-plugin/js/main.js

Add that file path (or just the file name) to your exclusion list. Save and clear cache and reload.

Do this one script at a time until things start working. It’s a little trial and error, but it works.

Step 5: Check jQuery Is Loading First

jQuery is like the big boss of many WordPress scripts. If jQuery is being deferred or delayed, almost everything else will break.

Make sure blinkspeed is not deferring jQuery. Add jquery.min.js and jquery-migrate.min.js to your exclusion list right away if you haven’t already.

The Real Script Conflict Fix: Exclusions + Testing

There’s no magic one-click button to fix script conflicts (wouldn’t that be nice). The real script conflict fix is a combination of:

• Identifying which scripts are causing errors
• Excluding them from optimization
• Testing after every change

It takes maybe 15-30 minutes, but once it’s done, it’s done.

What If the Errors Are Still Happening?

Sometimes the issue goes deeper than just deferring scripts. Here are a few other things to check:

Check for Plugin Version Conflicts

If a plugin recently updated, its JavaScript might conflict with another plugin that hasn’t updated. Go to your plugin list and check if multiple plugins updated around the same time your issues started.
Rolling back to a previous version of one plugin can sometimes instantly fix the issue.

Check Your Theme’s JavaScript

Your theme also loads JavaScript files. If your theme recently updated or if you recently changed themes that could be the source of the conflict.

Try switching to a default WordPress theme temporarily (like Twenty Twenty-Four) and see if the errors disappear.

Check for Caching Issues

Caching saves old versions of your page to serve it faster. But if your cache still has an old, broken version of a script, you’ll keep seeing errors even after you’ve fixed the actual file.
Clear your cache after every change you make. Always.

Preventive Tips So This Doesn’t Happen Again

Once you’ve fixed the JavaScript issues in Blinkspeed, here’s how to keep things running smoothly:

• Update plugins one at a time, not all together, so you can identify if any single update causes a problem
• Test your site after every optimization change don’t set and forget
• Keep a list of excluded scripts so you don’t lose your settings if you reinstall the plugin
• Use a staging site to test changes before pushing them live most good hosts offer this for free now
• Check your console regularly, even when things seem fine

FAQs

Q1. What is the JavaScript issue in BlinkSpeed exactly?

The JavaScript issue happens when BlinkSpeed’s script optimization interferes with how JavaScript files load on your website. It can cause scripts to load out of order, which leads to broken buttons, forms, or other interactive elements on your site.

Q2. Why am I seeing JS delay issues after installing a speed plugin?

Speed plugins often defer or delay JavaScript to improve load time. But if a critical script is delayed, the features that depend on it stop working. This is the most common cause of a JS delay issue after adding optimization plugins.

Q3. How do I fix broken functionality in WordPress caused by JavaScript?

Start by opening your browser console and noting any JavaScript errors. Then check your optimization plugin’s settings and add the failing scripts to the exclusion list. Make sure jQuery is never deferred. Test after each change until everything works.

Q4. Is defer JS troubleshooting something a beginner can do?

Yes, absolutely. The process of defer JS troubleshooting doesn’t require coding knowledge. You just need to find the error in your browser console, match it to the script file, and exclude that file from your optimization settings. It’s more detective work than coding.

Q5. Can JavaScript errors hurt my SEO?

They can, yes. If JavaScript errors prevent your page content from loading properly, Google might not index all your content correctly. Also, broken functionality in WordPress leads to a bad user experience, which indirectly affects your rankings over time.

Q6. How do I know which script to exclude?

Open your browser’s developer tools (F12), go to the Console tab, and look at the red error messages. They usually mention the script file name that’s causing the problem. That’s the file you want to exclude from optimization.

The post BlinkSpeed JavaScript Issue: JavaScript Delay Causing Website Errors? Here’s the Fix appeared first on Blinkspeed.

This is one of the most common things that happens when CSS optimisation is switched on for the first time, and it almost always has a straightforward fix inside BlinkSpeed’s settings. No need to disable the entire plugin, no need to roll back changes, no need to rebuild anything.

This guide walks through every CSS-related setting BlinkSpeed gives you, explains why specific types of style issue troubleshooting point to specific settings, and gives you a clear decision path to get your WordPress design back to exactly how it should look – while keeping all the performance benefits turned on.

Why CSS Optimisation Can Break a Layout

Before getting into the fixes, it helps to understand why this happens at all, especially if you have never touched CSS optimisation before.

What Minification Does to Your Stylesheets

When BlinkSpeed minifies a CSS file, it strips out whitespace, line breaks, comments, and redundant formatting. The rule color: red; becomes color:red. A 100KB stylesheet might become 65KB. This is completely safe for valid CSS, but some older or poorly written stylesheets contain syntax that browsers tolerate in their unminified form, but that breaks when compressed.

A typical example is a malformed comment block that does not close properly. In the original file, the browser ignores it. When BlinkSpeed’s minifier removes the comment, everything after the unclosed comment marker gets accidentally removed too – causing a broken layout after minify that looks like styles are missing entirely.

What Combining CSS Files Can Do

BlinkSpeed can combine multiple CSS files into fewer, larger files. When files are combined, their contents are concatenated. If two stylesheets define conflicting rules for the same selector, the order they appear in the combined file determines which rule wins – and that order may differ from the order they originally loaded in. This is the most common cause of a CSS conflict fix being needed: the combined file applies rules in a slightly different order than the originals did.

What Critical CSS Can Cause

Critical CSS is the above-the-fold stylesheet BlinkSpeed extracts and inlines at the top of each page. It speeds up the visible render, but if it is generated incorrectly – or if it includes styles that are not actually needed above the fold – it can cause a flash of incorrectly styled content, override styles that the main stylesheet was supposed to apply, or cause layout shifts as the full CSS loads after the critical CSS has already painted the page.

What Deferred CSS Loading Can Cause

BlinkSpeed can delay the loading of non-critical CSS until after the page has rendered. While this is great for performance, stylesheets that control the layout of above-the-fold content must never be deferred. If a font stylesheet, a page builder base stylesheet, or a theme layout file gets deferred, the page will appear briefly unstyled before the deferred CSS loads – a jarring experience for visitors that also shows up as a CLS (Cumulative Layout Shift) problem in Core Web Vitals.

Step One – Identify Which Setting Is Causing the Style Issue

Before making any changes, you need to know which specific operation is causing the broken layout. Here is the fastest way to isolate it.

Open the Page in a Private Browser Window While Logged In

BlinkSpeed serves cached, optimised output to non-logged-in visitors. When you are logged in as an admin, you sometimes see the unoptimised live version. Open your affected page in an incognito window to see exactly what visitors are seeing.

Use Browser DevTools to Check the Network Tab

Open DevTools (press F12 in Chrome or Firefox), go to the Network tab, filter by CSS, and reload the page. Look at which CSS files are loading and where they are coming from. If you see a URL containing /bs-cache/css/, BlinkSpeed has combined and cached those files. If you see fewer CSS files than you would expect, BlinkSpeed has combined them. If you see no CSS link tags at all, the stylesheets may have been deferred via Force Lazy Load.

Check the Elements Tab for Inline Styles

In the Elements panel of DevTools, look at the <head> section. If you see a large block of inline CSS between <style> tags above your other stylesheets, that is the Critical CSS BlinkSpeed has generated. If those inline styles are overriding something they should not, the critical CSS issue is the likely cause.

Temporarily Disable Individual Settings

Go to BlinkSpeed → CSS Optimization and disable one setting at a time, then clear the cache and check the page:

1. Turn off Enable CSS Optimization completely → if the layout fixes itself, one of the CSS processing steps is the cause.
2. If it fixes the layout, re-enable CSS Optimization and turn off Load Critical CSS → if the layout breaks again, the critical CSS issue is the source.
3. If Critical CSS is not the cause, check whether any files are listed in Force Lazy Load Stylesheet URLs → if removing those fixes the layout, you have a deferred CSS loading problem.

This process of elimination takes just a few minutes and tells you exactly which setting to address before applying the correct fix.

Fix 1 – Broken Layout After Minify: Exclude the Problem Stylesheet

When the broken layout after minify affects a specific visual component, a slider, a page builder section, or a custom widget, the stylesheet responsible for that component is the place to start.

How to Exclude a Stylesheet from CSS Optimisation

Go to BlinkSpeed → Exclusions → CSS Exclusions → Exclude Stylesheet URLs from Optimization.
Click Add Rule and enter a matching string from the URL of the problematic CSS file. You do not need the full URL – just a distinctive part of the filename or path.

For example:

• If the broken component comes from a slider plugin, enter the plugin’s folder name: slider-revolution
• If it is a page builder style, enter part of the file path: elementor/assets/css/frontend.min.css
• If it is a theme stylesheet, enter part of the filename: themes/yourtheme/style.css

BlinkSpeed checks every CSS file’s URL against this list before minifying. Any file whose URL contains your matching string is left completely untouched – loaded exactly as WordPress registered it, with no minification, path rewriting, or cache copying.

Save your changes, then go to BlinkSpeed → Cache → Delete HTML/JS/CSS Cache and clear the cache. Check the page again. In most cases, excluding the one conflicting stylesheet while keeping CSS optimisation active on all other files resolves the broken layout after minification completely.

How to Write the Exclusion Rule

The matching string is case-sensitive and matches against the full URL of the stylesheet link tag. Be specific enough that the string only matches the intended file, but not so specific that a version number or query string causes it to fail. File path fragments like plugins/plugin-name/css/ or themes/theme-name/ are usually the right level of specificity.

Fix 2 – CSS Conflict Fix: Resolve Issues from File Combining

If excluding the problematic file from minification does not resolve the issue, the problem may be in how files are being combined – specifically, the order in which their rules end up in the combined file.

Force Lazy Load as a Conflict Isolation Tool

Go to BlinkSpeed → Exclusions → CSS Exclusions → Force Lazy Load Stylesheet URLs.

Click Add Rule and enter a matching string from the conflicting stylesheet’s URL. When a file is added to Force Lazy Load, BlinkSpeed does not include it in the combined CSS bundle. Instead, it is loaded separately after the initial page render, when the user interacts with the page.

This removes the file from the combination process and effectively tests whether the CSS conflict fix is a loading-order problem. If the layout looks correct after adding the file to Force Lazy Load, the conflict was caused by the file’s rules being applied in the wrong order within the combined bundle.

Note: Force Lazy Load is not always the final fix for above-the-fold styles – a stylesheet that controls layout elements visible immediately on page load should not be lazily loaded, as this creates a visible style jump. Use it as a diagnostic tool. If it confirms the file is the source of the conflict, use Exclude Stylesheet URLs from Optimization instead, which keeps the file loading at its original position without putting it in the lazy-load queue.

Exclude Entire Pages from CSS Optimisation

If a specific page or page type is producing a WordPress design broken experience – a WooCommerce checkout page, a custom landing page, a portfolio template – but the rest of your site looks fine, you can bypass CSS optimisation entirely for those specific pages.

Go to BlinkSpeed → Exclusions → CSS Exclusions → Exclude Pages from CSS Optimization.

Click Add Rule and enter the page’s URL slug or any unique part of its URL. BlinkSpeed matches the current request URL against this list before applying CSS optimisation. When a match is found, no CSS minification, combining, or lazy loading is applied to that page. All stylesheets load exactly as WordPress originally registered them.

This is the most targeted fix for a WordPress design broken issue that is localised to one or two specific pages. It preserves full CSS optimisation on all other pages while giving the problematic page a clean, unprocessed stylesheet loading experience.

Fix 3 – Critical CSS Issue: Adjust How Above-the-Fold Styles Load

Critical CSS problems are distinct from minification or combination issues because they affect the timing and priority of CSS delivery, not just the content of the files. There are two sub-settings under Load Critical CSS that give you precise control.

Load Critical CSS in Style Tag

When Load Critical CSS is enabled, BlinkSpeed inlines the extracted above-the-fold styles at the top of the page HTML. By default, it inlines them as a preload link. The sub-setting Load Critical CSS in Style Tag changes this so the critical CSS is placed directly inside a <style> block in the <head>.

If you are seeing a flash of unstyled content at page load – the page appears briefly without background colours, fonts, or layout, then jumps into place – switching between these two modes can resolve it. Some browsers and server configurations handle inline <style> tags differently from preload link tags, and the <style> tag approach often provides more immediate styling for the very first paint.

Go to BlinkSpeed → CSS Optimization, make sure Load Critical CSS is enabled, and then toggle Load Critical CSS in Style Tag on. Save changes, clear cache, and test the page.

Load Style Tag in Head to Avoid CLS

This setting addresses a very specific critical CSS issue: inline

<style> blocks generated by plugins or page builders that are placed in the body of the HTML rather than the head, causing layout shifts as the browser encounters them mid-parse.

 Go to BlinkSpeed → CSS Optimization → Load Style Tag in Head to Avoid CLS.

Click Add Rule and enter a matching string from the content of the inline style block you want to move – a distinctive CSS class name, property, or selector that appears uniquely in that block. BlinkSpeed detects inline <style> blocks containing your matching string and moves them to the <head> section of the HTML output.

 This is the correct style issue troubleshooting step when your CLS (Cumulative Layout Shift) score is failing because of an inline style that appears in the wrong position in the page. The style content is unchanged – only its position in the HTML moves from the body to the head, where the browser processes it before rendering any content.

 How to identify the matching string: Open DevTools, go to Elements, and look for <style> tags anywhere below the <head>. Click into each one and look for a distinctive class name or property. For example, if the inline style contains .hero-section { background: #fff; }, entering hero-section as your matching string will reliably identify that specific block.

Delete Critical CSS Cache After Changes

Any time you make changes to your theme, page builder, or global stylesheet – or after changing Critical CSS settings – you must delete the critical CSS cache separately. Go to BlinkSpeed → Cache → Delete Critical CSS Cache. The regular HTML/JS/CSS cache delete does not remove critical CSS files. Critical CSS is stored in a separate directory (wp-content/cache/critical-css/) and must be explicitly cleared and regenerated via the AI Optimisation process.

Fix 4 – Font-Related Style Issue: Localise Google Fonts

A common but less obvious WordPress design broken issue is font loading. If your site uses Google Fonts and your server has strict privacy rules, a slow connection to Google’s font servers, or Content Security Policy headers that block external font URLs, the Google Fonts request may fail silently – causing your site to render in a fallback system font instead of your intended typeface.

Enable Localise Google Fonts

Go to BlinkSpeed → CSS Optimization → Localise Google Fonts.

When this setting is enabled, BlinkSpeed intercepts Google Fonts requests, downloads the font files from Google’s servers, and saves them locally under your own domain. Your pages then load fonts from your own server rather than calling out to fonts.googleapis.com. The result is:

• No cross-origin font requests that CSP rules can block
• No dependency on Google’s server availability
• Faster font loading because the font comes from the same connection as the rest of your page content
• Elimination of the layout shift that occurs when a web font loads after the page has already rendered in a fallback font

This setting is the correct style issue troubleshooting step when fonts appear incorrect, and you notice fonts.googleapis.com or fonts.gstatic.com requests failing in your browser’s Network tab.

Step-by-Step Style Issue Troubleshooting Reference

Use this flow when you encounter any CSS-related issue after enabling BlinkSpeed optimisation:

Step 1 – Is the issue visible on all pages or just specific pages?

• All pages → a stylesheet that loads everywhere is affected → use Exclude Stylesheet URLs
• Specific pages → use Exclude Pages from CSS Optimization for those page slugs.

Step 2 – Is the issue a flash of unstyled content at the very start of page load?

• Yes → Critical CSS issue → try Load Critical CSS in Style Tag, or delete and regenerate Critical CSS
• No → proceed to Step 3

Step 3 – Is the issue a style that disappears briefly then comes back?

• Yes → a stylesheet is being deferred that should not be → check Force Lazy Load Stylesheet URLs and remove the affected file from that list

Step 4 – Is the issue a layout that is permanently wrong with no flash?

• Yes → likely a broken layout after minify or a CSS conflict fix situation → exclude the specific stylesheet from optimisation using Exclude Stylesheet URLs.

Step 5 – Is the issue fonts rendering in the wrong typeface?

• Yes → enable Localise Google Fonts or check that font file URLs are not in the Force Lazy Load list.

Step 6 – Is the issue layout shifts (content jumping as page loads)?

• Yes → use Load Style Tag in Head to Avoid CLS for inline style blocks, or check that your LCP image is not being lazy loaded

Settings Location Quick Reference

Frequently Asked Questions

Q1. My entire site layout is broken after enabling CSS optimisation. Where do I start?

Start by going to BlinkSpeed → CSS Optimization and turning off Enable CSS Optimization completely. Then clear the cache. If the site looks normal again, CSS optimisation is the cause. Re-enable it and go to the Exclusions tab. Open your site in a browser with DevTools (F12) and look at the Network tab’s CSS files. Identify which stylesheet seems to be the problem by checking which combined cache file contains the conflicting styles. Add that file’s path to Exclude Stylesheet URLs from Optimization and test again. This step-by-step approach for style issue troubleshooting resolves the vast majority of broken layout after minify cases.

Q2. How do I find the right matching string to exclude a CSS file?

In your browser’s DevTools, go to the Network tab and filter by CSS. You will see the original stylesheet URLs. For a file like https://yoursite.com/wp-content/plugins/elementor/assets/css/frontend.min.css, the matching string elementor/assets/css/frontend.min.css or simply elementor/assets/css is specific enough to identify that file without being so specific it fails when the file path changes slightly. Avoid using query strings like ?ver=3.18 as part of your matching string since version numbers change frequently.

Q3. The site looks fine on desktop, but the WordPress design is broken on mobile. Why?

BlinkSpeed generates separate cached files for desktop and mobile. If critical CSS was generated on a desktop session, it may contain styles that do not match the mobile layout. Go to BlinkSpeed → Cache and delete the full cache, then visit your site from a mobile device (or use Chrome DevTools mobile emulation) to trigger mobile-specific cache generation. Also check whether your theme registers different stylesheets for mobile – if so, the mobile stylesheets may need their own entries in the Exclude Stylesheet URLs list.

Q4. Can I exclude a CSS file from minification but still include it in the combined file?

No. BlinkSpeed’s CSS exclusion removes the file from all processing, including combination. An excluded stylesheet loads at its original position in the HTML exactly as WordPress registered it. If you want the file processed but not minified, the closest option is to leave it in the general CSS optimisation pipeline and check whether the broken layout after minify resolves itself once the specific stylesheet causing the issue is identified and excluded. There is no separate “skip minify but keep combine” option.

Q5. My critical CSS issue is causing a flash on every page load. How do I fix it?

First, delete the critical CSS cache from BlinkSpeed → Cache → Delete Critical CSS Cache and go to BlinkSpeed → Optimize with AI to regenerate it. If the flash persists after regeneration, go to BlinkSpeed → CSS Optimization and enable Load Critical CSS in Style Tag. This changes the delivery method from a preload link to a direct inline <style> block, which the browser applies to the first paint without a separate preload step. Clear the full cache after making this change.

Q6. Force Lazy Load fixed my CSS conflict issue, but now there is a style jump on page load. What do I do?

This means the stylesheet you added to Force Lazy Load is controlling styles that are visible above the fold before the user interacts with the page. Force Lazy Load is the correct tool for below-the-fold or non-visual CSS, but not for layout-critical above-the-fold styles. Remove the file from the Force Lazy Load list and instead add it to Exclude Stylesheet URLs from Optimization. That keeps it loading at its original position in the page HTML – preventing the style jump – while removing it from the process that was causing the CSS conflict fix to be needed.

Q7. My page builder (Elementor / Divi / Beaver Builder) layout is broken after enabling CSS optimisation. What is the safest fix?

Page builders register dozens of CSS files across their core, widgets, and third-party add-ons. The safest style issue troubleshooting approach is to first add the page builder’s main plugin folder to Exclude Pages from CSS Optimization for your most complex template pages. Test those pages. Then, using the DevTools Network tab on a simpler page, identify which specific page builder stylesheet is being minified incorrectly and add just that file to Exclude Stylesheet URLs from Optimization. This way you keep CSS optimisation running on as much of your site as possible while protecting the specific files causing the WordPress design broken experience.

Q8. Does clearing the cache always apply CSS setting changes immediately?

Yes – but you need to clear the right type of cache. Changes to CSS optimisation settings (exclusions, Force Lazy Load, Style Tag in Head) require deleting the HTML/JS/CSS cache from the Cache tab. Changes to Critical CSS settings also require deleting the Critical CSS cache specifically. The HTML cache alone is not sufficient for CSS changes. After clearing the correct cache types, the next visitor to any page will receive a freshly generated, optimised version with your new settings applied.

The post How to Find and Apply the Right BlinkSpeed CSS Issue Fix for Your Site appeared first on Blinkspeed.

When the BlinkSpeed cache is not working, the plugin usually isn’t broken. Something small is getting in the way. Maybe another cache is still active on your host. Maybe a setting got switched off and nobody noticed.

This guide covers the usual causes in plain English. No code. No server jargon. Just a simple page cache troubleshooting walkthrough so you can get your site moving again without learning WordPress inside out.

How BlinkSpeed Cache Is Supposed to Work

Fixing cache blind is a waste of time. So first, what does it look like when things are actually working?

Picture a visitor landing on one of your pages. WordPress has to wake up, talk to the database, run your theme, run your plugins, and only then spit out the finished page. That whole chain takes a few seconds on a slow site.

BlinkSpeed steps in before that happens again. It keeps a saved copy of the page ready to go. The next visitor gets the saved version. WordPress does not have to do the full job every single time.
That is the basic idea. Everything else in this guide builds on that.

BlinkSpeed skips a chunk of that work. It saves a finished copy of the page (the HTML cache) and hands that to the next visitor instead of rebuilding from zero.

It also trims your CSS and JavaScript. Files get minified and combined so the browser has less to download.

When things are running right, repeat visits feel quicker, speed tools look better after a second test, and your edits show up once cache is cleared. The BlinkSpeed menu in your admin bar is there when you need to wipe cache in one click.

If none of that is happening, something in the chain is off. That is what the rest of this guide sorts out.

When cache is healthy:

• Repeat visits load noticeably faster
• PageSpeed or GTmetrix scores improve (not always on the first run cache needs to warm up)
• After you edit a post, the new version shows up once cache is cleared
• The BlinkSpeed item in your WordPress admin bar lets you purge cache in one click

When something is off, you usually notice stale content, no speed gain, layout glitches, or cache plugin errors in your dashboard.

Signs Your BlinkSpeed Cache Is Not Working

Not every slow site is a cache problem. But these patterns show up again and again when caching has stalled.

If two or three of those sound familiar, you are dealing with a WordPress cache problem not a mystery gremlin.

Why BlinkSpeed Cache Stops Working (Root Causes)

1. HTML Caching Is Turned Off

Sounds obvious, but it happens. Someone updates settings, imports a config from another site, or a teammate toggles something during testing.

Check: BlinkSpeed → HTML Caches → Enable HTML Caching should be on. Hit Save Changes even if it already looks enabled, sometimes the save is what actually commits it.

2. Two Cache Plugins Fighting Each Other

Running BlinkSpeed alongside WP Rocket, LiteSpeed Cache, W3 Total Cache, or your host’s built-in cache is the number one cause of a WordPress cache problem.
Two plugins both trying to cache the same pages is like two people editing the same document without talking. One overwrites the other. Purging one does not clear the other. Speed tests give confusing results.

Fix: Pick one page cache plugin. Deactivate the other completely, not just “turn off caching” inside it, actually deactivate the plugin. Then purge everything and test again.

3. Hosting Cache Sitting on Top of BlinkSpeed

SiteGround, Kinsta, WP Engine, Cloudways, GoDaddy, and plenty of others run their own server-side cache. That is good for speed until it serves an old copy after you already purged BlinkSpeed.
BlinkSpeed can detect many hosts and purge their cache too, but not every setup plays nice out of the box.

Fix: After purging BlinkSpeed cache, also clear your hosting cache from the hosting control panel or the host’s WordPress plugin. Do both, every time you test a change.

4. Wrong Cache Delivery Method for Your Server

BlinkSpeed lets you serve cached HTML via Htaccess or PHP Cache (labeled “Advance Cache” in settings). Htaccess is faster on Apache servers that allow it. PHP Cache works when .htaccess rules cannot be written; some managed hosts lock that down.
If you picked Htaccess and your server blocks it, cache files may generate but never get served to visitors.

Fix: Switch to PHP Cache, save, purge HTML cache, then visit your homepage in a private/incognito window.

5. Pages With GET Parameters or Logged-In Users

By default, BlinkSpeed skips caching for logged-in WordPress users smartly, because your admin bar and personalized content should not be frozen into a public page. If you are testing while logged in, you might think the cache is broken when it is actually doing its job.
URLs with query strings (?utm_source=email or ?s=search) also behave differently unless you enable caching pages with GET parameters.

Fix: Test in an incognito window while logged out.

6. Exclusion Rules Blocking Important Pages

BlinkSpeed → Exclusions lets you keep sensitive URLs out of cache cart, checkout, my-account, wp-admin. That is correct behavior.
But an overly broad exclusion (like excluding all of /blog/ or your entire homepage path) means cache never kicks in where you need it most.

Fix: Review exclusion rules. Remove anything broader than necessary. When in doubt, exclude specific WooCommerce or membership paths, not whole sections of the site.

7. File Permission or .htaccess Issues

BlinkSpeed writes cache files and sometimes .htaccess rules to your server. If folder permissions are too tight, cache cannot be created. If .htaccess gets corrupted by another plugin, you may see cache plugin errors or 500 errors.

Fix: Make sure your wp-content folder is writable. Check .htaccess for duplicate or broken cache rules from old plugins. Back up .htaccess first, then remove leftover rules from deactivated cache plugins.

8. Free vs Premium Scope

On the free BlinkSpeed plan, critical CSS and advanced image optimization run on the homepage only. HTML caching, minification, and lazy loading still work site-wide but if you expect every inner page to get the full premium treatment without a license, performance gains may feel uneven.

That is not cache “broken” it is the plan boundary. Inner pages still benefit from HTML cache and basic optimizations.

Step-by-Step Cache Issue Fix (Start Here)

When you want a reliable cache issue fix without guessing, run through this list in order. Most people solve it before step 6.

Step 1 : Confirm HTML caching is on.
BlinkSpeed → HTML Caches → Enable HTML Caching → Save Changes.

Step 2 : Deactivate other cache plugins.
One caching plugin per site. Seriously.

Step 3 : Purge all BlinkSpeed cache.
BlinkSpeed → Cache tab → Delete HTML cache, then Delete HTML/JS/CSS Cache. Or use BlinkSpeed → Clear Cache in the WordPress admin bar.

Step 4 : Purge hosting cache.
Log into your host panel or use their plugin. Clear everything.

Step 5 : Test logged out.
Open your site incognito. View page source and look for signs BlinkSpeed served a cached version (or use a speed tool on the live URL).

Step 6 : Switch cache delivery method.
If still stuck, toggle between Htaccess and PHP Cache, save, purge again, retest.

Step 7 : Review exclusions.
Trim any rules that accidentally block high-traffic pages.

Step 8 : Check Change Logs.
BlinkSpeed → Change Logs see if someone disabled caching or changed expiry time recently.
That sequence covers the majority of real-world page cache troubleshooting cases. No terminal required.

Fixing Stale Content (When Updates Do Not Show)

Stale pages are the most annoying WordPress cache problem because your content is right in the dashboard but wrong on the front end.

Turn on auto-purge when content changes.

BlinkSpeed → HTML Caches → Clear Cache when Page or Post is Updated. Save. From now on, editing a post triggers a refresh.

Set a sensible cache expiry.

The default is 3600 seconds – one hour. If you shorten that, visitors see fresher content, but the cache does not help as much. Longer expiry means faster repeat loads, but stale risk if auto-purge is off.

Manually purge after big changes.

Redesigned homepage? New plugin? Changed theme? Do not wait for expiry. Hit Delete HTML/JS/CSS Cache and clear hosting cache too.

Preload caching uses it wisely.

Preload rebuilds cache after a purge so visitors do not hit uncached pages first. Enable it if your host can handle the background load. If your server is on a small plan, keep preload pages-per-minute modest.

When Minified CSS or JS Breaks Your Layout

Sometimes cache “not working” is actually cache working too aggressively. Combined and minified files can clash with certain themes or plugins.
Symptoms: Broken mobile menu, slider stuck, checkout button unresponsive, fonts wrong but only for visitors, not always in admin.

Speed issue fix path:

1. Purge HTML/JS/CSS cache first half of layout bugs are just old files
2. BlinkSpeed → CSS / JavaScript tabs try turning off combine while keeping minify on
3. Add problematic script or stylesheet URLs to the exclusion list
4. Test one page at a time in incognito

If the site looks perfect with minify off, re-enable features one by one until you find the troublemaker. That is normal tuning, not failure.

Cache Plugin Errors and What They Mean

Seeing an error beats silent failure at least you know where to look.

For persistent cache plugin errors, note the exact message, check BlinkSpeed Change Logs for recent setting flips, and make sure you are on the latest plugin version.

Speed Still Low After Cache Is Fixed?

Cache is one piece of the puzzle. If page cache troubleshooting checks out but scores stay flat:

• Images large uncompressed images hurt even with HTML cache. Enable lazy loading. Consider WebP on the homepage (free) or all pages (premium).
• Third-party scripts chat widgets, ad trackers, and heavy fonts load outside BlinkSpeed’s cache layer. Trim what you do not need.
• Databases bloat old post revisions and bloated tables slow uncached requests and admin. Cache helps visitors; cleanup helps everything.
• CDN not configured BlinkSpeed → CDN tab. Serving static assets from a CDN reduces load on your origin server.
• Testing too soon runs speed tests twice. First visit warms cache; second visit shows the real gain.

A proper speed issue fix usually combines caching, image work, and cutting dead weight, not just one toggle.

Hosting-Specific Tips (Short Version)

BlinkSpeed integrates with many of these automatically on purge. Still when in doubt, clear both sides.

Prevention: Keep Cache Healthy Going Forward

A few habits stop most repeat visits to this guide.

• One cache plugin. Say it until it sticks.
• Enable Change Logs so you can see who turned off HTML caching at 9pm on a Friday.
• Purge after updates BlinkSpeed version, theme update, WooCommerce update. Old minified files cause ghost bugs.
• Exclude sensitive URLs checkout, account, password reset. Always.
• Test in incognito when judging cache logged-in view lies to you.
• Update BlinkSpeed when WordPress shows a new version. Bug fixes and compatibility improvements land regularly.

Treat cache like a garden, not a statue. It needs the occasional clear-out.

FAQs

Q1. Why isn’t my BlinkSpeed cache working after I installed it?

Usually because HTML caching is off, another cache plugin is still active, or you are testing while logged in. Turn on HTML caching, deactivate competing plugins, purge all cache, and test in a private browser window while logged out.

Q2. How do I fix a WordPress cache problem without breaking my site?

Start with backups. Then deactivate duplicate cache plugins, purge BlinkSpeed and hosting cache, and confirm exclusions only cover pages that must stay dynamic (cart, checkout, login). Change one setting at a time so you know what fixed it.

Q3. What is the fastest cache issue fix for stale content?

Enable Clear Cache when Page or Post is Updated, manually purge HTML and JS/CSS cache from the Cache tab, and clear your host’s cache. Hard-refresh your browser or use incognito to verify.

Q4. Can two cache plugins run together?

Technically yes. Practically, no. Running two page cache systems causes conflicts, stale content, and unreliable purging. Pick BlinkSpeed or another plugin not both.

Q5. Why does my site look broken after enabling cache?

Often old minified CSS or JS is being served. Purge HTML/JS/CSS cache completely. If it persists, disable CSS or JS combine and exclude the specific file causing conflict. The layout issue is usually a file clash, not broken cache logic.

Q6. Should I use Htaccess or PHP Cache?

Use Htaccess if your Apache server allows .htaccess modifications it is faster. Use PHP Cache if your host blocks .htaccess writes or you see errors after enabling Htaccess mode. Both store cache; delivery methods differ.

Q7. Does BlinkSpeed cache work on the free version?

Yes. HTML page caching, CSS/JS minification, lazy loading, browser caching, and GZIP work without a license. Critical CSS and advanced image optimization on inner pages require premium but basic cache is fully functional for free.

Q8. How do I know if page cache troubleshooting worked?

Test logged out in incognito. Run PageSpeed Insights or GTmetrix twice on the same URL; the second run should be faster. Edit a test post; with auto-purge on, the front end should update after you save. If all three pass, cache is doing its job.

Q9. What if I still see cache plugin errors after following every step?

Update BlinkSpeed to the latest version. Check file permissions on wp-content. Review .htaccess for conflicts. Contact your host if the server blocks cache writes and share the exact error message. That detail saves back-and-forth.

Q10. Is a speed issue fixed only about caching?

No. Cache handles repeat page loads. You still need reasonable image sizes, lean plugins, and limited third-party scripts for strong scores. Cache is the foundation not the entire house.

The post BlinkSpeed Cache Not Working: Fixes That Actually Work appeared first on Blinkspeed.

The short version: the free version of BlinkSpeed is genuinely useful and not just a stripped-down teaser. It gives you real, meaningful performance improvements right away, across every page on your site. The premium version takes two specific features – Critical CSS generation and advanced image optimisation with WebP conversion – and extends them from your homepage to your entire site.

That difference sounds small, but depending on what kind of site you are running, it can be the difference between passing and failing your Core Web Vitals.

This guide breaks down every feature in the free version, explains exactly what the premium plan adds, and helps you make a confident plugin pricing decision without any guesswork.

What the Free Version Actually Gives You

The free version of BlinkSpeed is not a trial. There is no expiry date. You do not need a credit card. Every feature listed here works permanently, on all pages, with no hidden limits – all you need is to install the plugin.

HTML Page Caching

When a visitor lands on any page of your site, WordPress normally runs dozens of behind-the-scenes operations to build the page, checking the database, loading plugins, processing templates, before sending the result to the browser. This typically takes several hundred milliseconds.

BlinkSpeed’s HTML caching saves a ready-made version of each page as a static file. When the next visitor arrives, that static file is delivered directly, skipping all the background processing. Page load times typically drop by 50–80% from this one feature alone.

This works on every page of your site in the free version. Your homepage, blog posts, product pages, contact page, archive pages – all of them.

CSS Minification

CSS files contain a lot of extra whitespace, comments, and formatting that helps developers write and read the code but adds no value for the browser. BlinkSpeed’s CSS minification strips all of that out, producing a leaner file that the browser downloads faster. File sizes typically reduce by 20–40%.

JavaScript Minification

The same process is applied to JavaScript files. BlinkSpeed uses its built-in minifier to remove whitespace, comments, and unnecessary characters from your JS files, reducing their size without changing how they behave.

JavaScript Lazy Loading

JavaScript files that load the normal way can block your page from being displayed while the browser downloads and runs them. BlinkSpeed’s JavaScript lazy loading changes this so scripts only run after the visible part of the page has already been displayed to the visitor – or when the visitor first interacts with the page.

The result is that your pages feel faster immediately because the browser focuses on displaying content first and handles scripts afterwards. This is one of the most effective free vs paid plugin advantages that BlinkSpeed makes available to everyone.

Image Lazy Loading

Images below the fold, the parts of the page a visitor has not scrolled to yet, do not need to load immediately. BlinkSpeed’s image lazy loading delays the download of those images until the visitor is about to scroll to them. This reduces the amount of data downloaded on initial page load and speeds up how quickly the visible content appears.
This also applies to iframes, videos, and audio elements embedded in your pages.

Browser Caching

Browser caching tells your visitors’ browsers to save copies of your site’s static files, images, CSS, and JavaScript locally on their device. The next time they visit your site, their browser loads these files from its own local storage rather than downloading them from your server again.

For returning visitors, this can make page load times feel almost instant. BlinkSpeed handles the technical configuration for this automatically through your .htaccess file.

GZIP Compression

Before BlinkSpeed sends your HTML, CSS, and JavaScript files to the browser, GZIP compression squeezes them into a much smaller size for the journey across the network. A typical HTML page of 80KB might compress to under 20KB. The browser then decompresses it locally, which takes almost no time at all.

Cache Management Tools

BlinkSpeed gives you full control over your cache from both the plugin settings panel and a quick-access menu in the WordPress admin bar. You can clear all cache with one click, clear only the cache for a specific page, or let the system manage cache expiry automatically.

Critical CSS Generation – Homepage Only

This is where the free vs paid plugin distinction begins. Critical CSS is a technique that identifies the styles needed to display the top of your page, the part visible without scrolling, and loads those styles inline right at the top of the page. Everything else loads separately.

The benefit is that your page appears styled and readable much faster, even before all your stylesheet files have finished loading. This directly improves your Largest Contentful Paint (LCP) score, one of Google’s Core Web Vitals ranking signals.

BlinkSpeed generates critical CSS through its cloud API, which analyses each page and extracts the above-the-fold styles. In the free version, this process runs only for your homepage. Every other page on your site does not receive critical CSS generation.

Advanced Image Optimisation and WebP Conversion – Homepage Only

WebP is a modern image format that delivers the same visual quality as JPEG or PNG but at a significantly smaller file size – typically 25–50% smaller. BlinkSpeed converts your JPG and PNG images to WebP via its cloud API and serves the WebP version to browsers that support it, which includes Chrome, Firefox, Edge, and Safari.
Smaller images mean faster load times, less bandwidth used, and better performance scores.
In the free version, this conversion and delivery run only for images on your homepage. Images on blog posts, product pages, category pages, and every other URL are not converted or served in WebP format without a premium license.

What the Premium Version Adds

The premium version of BlinkSpeed is the same plugin, same interface, same settings, same features – with one key difference: the homepage-only restriction on Critical CSS and advanced image optimisation is removed.

Everything in the free version continues to work exactly as it did. The premium license simply unlocks those two cloud-powered features for your entire site rather than just the homepage.

Critical CSS Generation – Premium, All Pages

With a premium license, BlinkSpeed generates critical CSS for every page on your site, not just the homepage. Every blog post, product page, category archive, landing page, and custom post type gets its own above-the-fold stylesheet extracted and delivered inline.

This means faster initial display on every page, not just the first one a visitor lands on. For sites where visitors enter through blog posts, product pages, or category archives rather than the homepage, this advanced optimization is especially significant. A visitor who discovers your site through a Google search and lands directly on a blog post or product page gets the same performance benefit as someone visiting your homepage.

Advanced Image Optimisation and WebP Conversion – Premium, All Pages

With a premium license, BlinkSpeed converts images on every page of your site to WebP and serves the optimised versions to all visitors. Every product image, blog post photo, gallery image, and background graphic across your entire site is delivered in the smaller, faster WebP format.

The AI Optimisation dashboard can process your entire URL list automatically – crawling every page, queuing images for WebP conversion, and building critical CSS for each URL in the background. In the free version, this processing is limited to the homepage URL only.

Why These Two Features Require a Premium License

Critical CSS extraction and WebP conversion both rely on BlinkSpeed’s cloud services. These are not operations that run on your own server; they require external processing resources to analyse pages, extract styles, and convert images.

Providing these cloud services has real infrastructure costs. Making them available across an entire site for every user without any license would not be sustainable. The premium license is what funds the cloud processing capacity that makes site-wide advanced optimization possible.

All other performance features – caching, minification, lazy loading, GZIP, browser cache – run entirely on your own server. That is why they are available in full on the free version with no cloud dependency.

Premium Features Comparison – Free vs Premium Side by Side

Feature	Free Version	Premium Version
HTML page caching	✓ All pages	✓ All pages
CSS minification	✓ All pages	✓ All pages
JavaScript minification	✓ All pages	✓ All pages
JavaScript lazy loading	✓ All pages	✓ All pages
Image lazy loading	✓ All pages	✓ All pages
Browser caching	✓ All pages	✓ All pages
GZIP compression	✓ All pages	✓ All pages
Cache management tools	✓ All pages	✓ All pages
Multisite compatibility	✓ All sites	✓ All sites
Critical CSS generation	Homepage only	✓ All pages
WebP image conversion	Homepage only	✓ All pages
Advanced image optimisation	Homepage only	✓ All pages
AI Optimisation full crawl	Homepage only	✓ Full site

How to Make the Plugin Pricing Decision for Your Site

The right choice depends on one key question: what percentage of your real visitor traffic lands on a page that is not your homepage?

For most WordPress sites, the answer is: a lot. Blog readers arrive through individual post URLs. Online shop visitors land on product and category pages. Service business leads arrive through location or service landing pages. If most of your visitors are entering your site through inner pages rather than the homepage, the free version’s homepage-only limit means the majority of your traffic is missing out on the two most impactful advanced optimization features.

Choose the Free Version If

• Your site is simple – a personal blog, a portfolio, or a brochure site where the homepage is the main destination and most visitors start and end there
• Your images are already optimised before upload, and you do not need automated WebP conversion across the whole site
• Your site already passes Core Web Vitals on inner pages; verify this through Google Search Console or a Google PageSpeed Insights test on a few key inner pages
• You want to experience BlinkSpeed and see how much the free features improve your scores before making a plugin pricing decision about the premium plan

Choose the Premium Version If

• Your site has a lot of inner pages that receive direct organic traffic – a blog, a WooCommerce shop, or any content-driven site where Google ranks individual posts and pages
• Your images are large or numerous, and you want automated advanced optimization and WebP conversion across every page without manually compressing images before upload
• Your Core Web Vitals are failing on inner pages, not just the homepage, particularly LCP (Largest Contentful Paint), where critical CSS and WebP conversion have the most direct impact
• You manage multiple sites and want to apply a consistent premium configuration quickly using BlinkSpeed’s import and export feature
• You are running a WooCommerce store where product and category pages are the most important pages for your business, and you need those pages to load as fast as your homepage

How to Upgrade Your Plugin Plan and Activate Premium

If you have a BlinkSpeed license key and want to upgrade your plugin plan:

1. Go to the BlinkSpeed website and buy the WordPress plugin
2. At the order confirmation, you will receive a license key, which you can also get from my order page in your account.
3. Go to BlinkSpeed → General Settings in your WordPress admin dashboard
4. Find the License Key field near the top of the page
5. Enter your license key exactly as provided
6. Click Activate

BlinkSpeed verifies the key against its API and, if valid, sets your activation status immediately. From that point, the AI Optimisation dashboard can crawl your full site URL list and process critical CSS and WebP conversion for every page.

Once activated, go to BlinkSpeed → Optimize with AI and click Start Optimization to begin the full-site processing queue.

Frequently Asked Questions

Q1. Is the free version of BlinkSpeed really free forever?

Yes. There is no trial period, no expiry date, and no credit card required. HTML caching, minification, lazy loading, browser caching, and GZIP compression all work permanently on every page without a license key. The only features limited to the homepage on the free version are critical CSS generation and advanced image optimisation with WebP conversion – both of which depend on BlinkSpeed’s cloud API for processing.

Q2. Can I try the advanced optimization features before buying a premium plan?

Yes, in a limited way. BlinkSpeed automatically generates a demo license key for your site that allows critical CSS generation and WebP conversion to run on your homepage. This gives you a real preview of what those features look like on your actual site before making a plugin pricing decision about upgrading to premium.

Q3. What happens to my advanced optimization if my premium license expires?

If a premium license expires and is not renewed, BlinkSpeed falls back to the free version behaviour. Critical CSS and WebP conversion continue to work on your homepage but stop being applied to other pages. Your existing cached files, optimised styles, and WebP images remain on your server – they are not deleted. But new pages and new images will not be processed for advanced optimization across the full site. Performance for inner pages will gradually revert as the cache expires and is rebuilt without critical CSS.

Q4. I only have one important page: my homepage. Do I need premium?

Probably not right away. If your homepage is genuinely the main page that matters – a single landing page, a coming-soon page, or a one-page business site – the free version covers your entire meaningful use case. You get critical CSS and WebP on your homepage, plus all the caching, minification, and lazy loading features across the rest of the site. In this situation, the free vs paid plugin difference does not affect your most important page at all.

Q5. Will upgrading to premium instantly improve my PageSpeed scores?

Not instantly – the AI Optimisation process needs to run first. After entering your license key and activating it, go to BlinkSpeed → Optimize with AI and start the optimisation process. BlinkSpeed crawls your site URLs, generates critical CSS for each page, and converts images to WebP. Depending on the size of your site and the preload speed setting you have configured, this can take anywhere from a few minutes to a couple of hours. Once processing is complete, the advanced optimization improvements become visible for all pages.

Q6. Does the premium plan cover multiple WordPress sites?

Each BlinkSpeed premium license covers one WordPress site installation. If you manage multiple sites, you need a separate license for each one. However, BlinkSpeed’s import and export feature makes it very straightforward to apply a consistent configuration across all your sites quickly – configure one site perfectly, export the settings as a .dat file, and import that file into each subsequent site in seconds. This makes managing agency or portfolio-wide upgrade plugin plan deployments much more efficient.

Q7. Can I use the free version on a WooCommerce store?

Yes, and it will make a noticeable difference. HTML caching, minification, lazy loading, and GZIP compression all work across your shop, product, and category pages in the free version. The limitation is that WebP conversion and critical CSS generation only run on your homepage without a premium license. For a WooCommerce store where product pages and category archives are the pages that drive conversions, upgrading to premium ensures those high-value pages receive the full advanced optimization treatment – which is typically worth it for e-commerce sites where page speed directly affects how many visitors complete a purchase.

Q8. Is the premium features comparison different for multisite networks?

No. The same free vs premium rules apply across multisite. Each subsite in a WordPress multisite network is treated as an individual site for license purposes. The free version gives all subsites the full set of server-side features, while critical CSS and WebP conversion remain homepage-only per subsite without a premium license. With a premium license on a subsite, the AI Optimisation process runs the full site crawl for that specific subsite’s URLs.

Q9. How do I know if the premium upgrade is worth it for my specific site?

The clearest signal is your Google Search Console Core Web Vitals report. If your inner pages – blog posts, product pages, category archives – are showing failing LCP scores while your homepage passes, that is a direct indication that the free version’s homepage-only advanced optimization is not covering the pages where you need it most. Run a Google PageSpeed Insights test on three to five of your most important non-homepage URLs. If those pages are scoring significantly lower than your homepage, the plugin pricing decision for premium pays for itself through improved rankings and user experience on your highest-traffic pages.

The post BlinkSpeed Free vs Premium Plugin: Which One Should You Choose? appeared first on Blinkspeed.

The post BlinkSpeed Change Logs: Why Plugin Updates Matter appeared first on Blinkspeed.

The post BlinkSpeed Import Export Settings for Multiple Sites appeared first on Blinkspeed.

The post How to Read BlinkSpeed Core Web Vitals Logs appeared first on Blinkspeed.

This guide covers everything inside BlinkSpeed’s cache system: what each setting controls, when to purge cache vs clear cache WordPress-wide, how the preload cache system rebuilds pages automatically, and how hosted environment purging works across more than a dozen platforms.

How BlinkSpeed Caching Works

When a visitor lands on a page on your WordPress site, PHP executes hundreds of database queries, template functions, and plugin hooks before sending a single byte of HTML to the browser. This process typically takes 300ms to over a second on a busy server.

BlinkSpeed bypasses this entirely. The first time a page is requested, it processes and saves a complete static HTML file to disk at wp-content/cache/bs-cache/. Every subsequent visitor receives that static file directly; no PHP, no database, no plugins executed. The response time drops to single-digit milliseconds.

The cache system also stores separate files for different asset types – CSS, JavaScript, and critical CSS all have their own cache directories – and maintains separate versions for desktop and mobile visitors (.mob.html, .mob.css, .mob.js). This ensures mobile-optimised output does not bleed into desktop delivery and vice versa.
Understanding this structure is key to knowing when you need to purge cache, clear cache, or trigger a cache refresh across different parts of the system.

Navigating BlinkSpeed’s Cache Settings

BlinkSpeed has two cache-related admin panels:
BlinkSpeed → HTML Caches – Controls how caching is generated: expiry time, delivery method, preload behaviour, browser caching, GZIP, and query parameter handling. This is where you configure how the cache is built.

BlinkSpeed → Cache – Contains the manual deletion buttons to immediately clear cache for HTML, JS/CSS, and critical CSS. This is where you trigger manual cache refreshes.

The admin bar at the top of every page also provides quick-access cache purge controls so you can clear cache WordPress-wide without entering the plugin settings.

HTML Caching Settings Explained

Enable HTML Caching

This master toggle activates the static HTML page cache. When turned on, every publicly accessible page on your site is eligible to be cached as a static file. When turned off, WordPress processes every request dynamically, ignoring all cached files.

Leave this on at all times in production. There is rarely a reason to disable it unless you are actively debugging a conflict or working on live content where you need to see real-time changes on every page load.

Enable Caching for Logged-In Users

By default, BlinkSpeed skips the cache entirely for logged-in users. This protects account-specific content – dashboard data, WooCommerce cart information, personalised greetings – from leaking into cached pages that other visitors might see.

Enabling this setting extends the cache to logged-in users. It is appropriate for membership sites where authenticated pages are publicly readable in nature, or for admin teams who want to test cached output. For most WooCommerce or membership sites, leave this disabled to prevent personalised content from appearing in shared cached pages.

Serve HTML Cache File By

This dropdown controls the mechanism BlinkSpeed uses to deliver cached HTML files to incoming visitors. Two options are available:

Htaccess – BlinkSpeed writes Apache .htaccess rules that intercept requests before PHP boots. When a matching static cache file exists, Apache serves it directly. This is the fastest possible delivery method because PHP never loads at all, but it requires an Apache server with mod_rewrite enabled. This is the default and recommended setting for most shared and managed hosting environments.

PHP Cache (Advanced Cache) – BlinkSpeed installs a advanced-cache.php drop-in file and sets WP_CACHE = true in wp-config.php. WordPress loads this file very early in its boot sequence, before plugins, themes, or database connections. If a cache file exists, it is served and PHP exits immediately. Choose this option on Nginx servers or any environment where .htaccess rules are not supported.

Changing this setting rewrites your .htaccess file or installs/removes the advanced cache drop-in respectively. After switching, purge the full cache so new files are generated under the correct delivery mechanism.

Enable Caching for Pages with GET Parameters

URLs with query strings – like yoursite.com/shop/?orderby=price or yoursite.com/blog/?paged=2 – are typically excluded from page caches because each unique query string produces a different page. Enabling this setting instructs BlinkSpeed to cache pages regardless of their query parameters, creating separate cache files for each unique URL variant.

This can dramatically improve performance on paginated archives and filtered shop pages. The tradeoff is increased cache storage since every unique query string URL generates its own cached file. Enable it if your site has heavy traffic to filtered or paginated pages and your server has adequate disk space.

Cache Expiry Time

This field sets the maximum age of a cached HTML page in seconds. The default value is 3600, which equals one hour. After this duration, the next request to that URL regenerates the cached file from a fresh PHP render.

Common configurations:

Lowering the value creates a more frequent cache refresh but increases server load as pages regenerate more often. Raising it reduces server load but risks serving outdated content for longer after changes. If you have the preload cache system enabled (covered below), a longer expiry with automatic preloading is usually the optimal combination.

Clear Cache When Page or Post Is Updated

When enabled, BlinkSpeed hooks into WordPress’s save_post action and automatically triggers a cache refresh for any page or post the moment it is published or updated. The relevant cached HTML file is deleted immediately, and the next visitor triggers a fresh generation.

This setting ensures that content editors never have to manually clear cache WordPress-wide after making changes. A blog post with a corrected typo, an updated product price, or a revised landing page headline becomes live for visitors the instant the editor clicks Update.

Enable this for any site where content changes happen regularly and accuracy of the cached output matters. On very high-traffic sites, consider combining this with the preload cache option so the page is rebuilt in the background rather than waiting for the next live visitor to trigger regeneration.

Preload Caching

Preload cache solves the cold-start problem. Without preloading, every page on your site starts uncached after a clear. The first visitor to each URL triggers a fresh PHP render – which takes full dynamic loading time – and only subsequent visitors see the cached, fast version.

When preload cache is enabled, BlinkSpeed uses its built-in cron system to proactively visit and cache pages in the background. A custom WordPress cron job fires every minute and works through your site’s URL list, requesting each page so it is cached before any real visitor arrives.

The wp_blinkspeed_site_urls database table stores the URL queue. BlinkSpeed populates this table automatically from your sitemap and existing post/page data. The preload system reads URLs from this queue, generates cached files, and marks each URL as complete – running continuously to keep the entire site warm.

This is the difference between a cache that is fast for returning visitors and one that is fast for every visitor, including the first one after a deployment, cache clear, or content update.

Preload Page Caching Per Minute

This numeric input (range 1–12) controls how aggressively the preload system works. The value represents how many pages BlinkSpeed will cache per minute during each cron cycle.

Choosing the right value:

• 1–3 pages/minute – Conservative. Suitable for sites with limited server resources or shared hosting where aggressive background processing could affect foreground request handling.
• 4–8 pages/minute – Balanced. Good for most VPS or managed hosting environments with moderate resources.
• 9–12 pages/minute – Aggressive preloading. Use this for large sites on dedicated or high-resource hosting where speed of cache warmup matters more than background resource conservation.

For a 500-page site preloading at 5 pages per minute, the full site warms up in approximately 100 minutes – less than two hours. Preloading is throttled to avoid overwhelming the server, so it will never attempt to cache dozens of pages simultaneously.

Enable Leverage Browsing Cache

Browser caching tells visitors’ browsers to store static assets locally – CSS files, JavaScript files, images, fonts – so they do not need to download them again on return visits or when navigating between pages.

When this setting is enabled, BlinkSpeed writes Cache-Control and Expires HTTP headers into your .htaccess file. These headers instruct browsers to cache different asset types for varying durations: typically 1 year for images and fonts, 1 month for CSS and JavaScript files.

The practical effect is significant for returning visitors. A visitor who has already browsed your site once and returns the next day will load the page from their local browser cache for the assets they have already downloaded, reducing both page load time and bandwidth consumption.
Enable this setting on any production site. It requires Apache’s mod_headers or mod_expires module, which are available on virtually all hosting environments.

Enable GZIP Compression

GZIP is a server-side compression standard that compresses HTML, CSS, and JavaScript files before sending them to the browser. A typical uncompressed HTML page of 80KB often compresses to under 20KB – a 75% reduction in transfer size.

When this setting is on, BlinkSpeed adds GZIP directives to your .htaccess file. Modern browsers send an Accept-Encoding: gzip header with every request, and the server responds with a compressed version of the file. The browser decompresses it locally, which takes microseconds – far less time than the network transfer of the uncompressed file would have taken.

GZIP compression is one of the easiest wins in web performance. It requires Apache’s mod_deflate module and has no meaningful downsides. Keep it enabled.

Remove Query Parameters

Static assets in WordPress often have version query strings appended to their URLs – for example, /wp-content/themes/mytheme/style.css?ver=6.4.2. These version strings are useful for cache busting during development, but they also prevent browser and proxy caches from caching those assets aggressively since many caching layers treat URLs with query strings as dynamic and uncacheable.

When this setting is enabled, BlinkSpeed strips the ?ver=… and similar query parameters from static asset URLs in the rendered HTML. The cleaned URLs allow browser caching and CDN caching to work more effectively for those assets.

Enable this on production sites unless a specific plugin relies on version strings to force cache refreshes when the file changes.

Cache Path

By default, BlinkSpeed stores all cached files in wp-content/cache/bs-cache/. The Cache Path field lets you specify a custom absolute filesystem path if you need to redirect cache storage to a different directory – for example, a RAM disk, a partition with more space, or a directory outside the web root.

Leave this empty unless you have a specific hosting or storage reason to change it. If you enter a custom path, ensure the directory is writable by the web server user and has sufficient space.

Manual Cache Deletion – The Cache Panel

Delete HTML Cache

This button immediately deletes all static HTML page cache files from the BlinkSpeed cache directory. Cached JS and CSS files, critical CSS, and WebP images are not affected.

When to use it:

• After making theme or template changes that affect page layout or content structure
• After updating plugin output that appears on multiple pages
• After changing site-wide content like menus, headers, or footers
• When a page is showing outdated content and you need it refreshed immediately

After clicking Delete HTML Cache, the next visitor to each page triggers a fresh render that is cached and served to all subsequent visitors. If preload cache is active, the background process will rebuild pages automatically within minutes.

Delete HTML/JS/CSS Cache

This button clears HTML page cache along with all minified and combined JavaScript and CSS cache files. Choosing this option performs a deeper cache refresh across the performance layer.

When to use it:

• After enabling or disabling CSS or JavaScript optimization settings
• After adding or removing plugins that register scripts or stylesheets
• After changing CSS exclusion or JS exclusion rules in the Exclusions tab
• After any change to the Critical CSS, JS Optimization, or CSS Optimization settings
• After updating your theme’s stylesheets or scripts through the theme customizer

This is the correct option after making any changes to BlinkSpeed’s CSS or JS settings. The HTML-only delete would not remove the stale combined JS/CSS files, so pages would still load the old optimised bundles until they expired naturally.

Delete Critical CSS Cache

Critical CSS is the above-the-fold stylesheet extract that BlinkSpeed generates per-page via its cloud API. It is stored separately from the main CSS cache and represents significant API processing time to regenerate.
This button deletes only the critical CSS cache, leaving HTML and JS/CSS caches intact.

When to use it:

• After making visible changes to above-the-fold design elements – hero sections, navigation, headers, banners
• After changing your primary theme stylesheet
• After switching themes or page builder templates
• After adding new above-the-fold content blocks that were not present when critical CSS was last generated

Important: Critical CSS regeneration takes considerably longer than HTML or JS/CSS cache rebuilding because each page’s critical CSS must be extracted individually via the BlinkSpeed cloud API. For a site with 200 pages, regeneration might take 20–40 minutes depending on the preload speed setting. Only delete critical CSS when a layout change makes the existing critical CSS visually incorrect.

The Admin Bar Cache Purge Controls

BlinkSpeed adds a BlinkSpeed menu item to the WordPress admin bar, visible at the top of every page when you are logged in as an administrator. This menu provides quick-access purge controls without requiring you to open the plugin settings:

• Purge All Cache – Clears all BlinkSpeed cache files and simultaneously triggers a purge request to your hosting provider’s server-level cache (Varnish, Redis, or similar). Equivalent to pressing all three Delete buttons in the Cache panel in one click.
• Purge Page Cache – Purges the cache for the specific page you are currently viewing. Useful when you have updated a single post or page and want only that page’s cache refreshed without touching the rest of the site.

These admin bar controls are available on both the frontend and in the WordPress admin dashboard, making them the fastest path to a manual cache refresh during content updates or debugging sessions.

Automatic Cache Purging on Managed Hosting

One of BlinkSpeed’s most significant technical capabilities is its awareness of managed hosting environments. Most managed WordPress hosts run server-level caches – Varnish, Redis, or proprietary caching layers – that sit in front of PHP and serve responses even before WordPress loads. Clearing BlinkSpeed’s own file cache is not enough on these hosts; the hosting provider’s cache layer must also be purged, or visitors continue receiving the host’s cached version of old content.

BlinkSpeed automatically detects your hosting environment and calls the correct purge API for each provider when any cache purge is triggered – whether from the admin bar, the Cache panel, or an automatic post-update purge. No manual configuration is required.

Cache Preloading vs. Cache Purging: Understanding the Difference

These two operations are commonly confused but serve opposite purposes in a performance cache settings workflow.

Purge cache means removing existing cached files so they will be regenerated on the next request. A purge clears stale content but leaves pages temporarily uncached – the next visitor to each URL gets a slower, dynamically rendered response.

Preload cache means proactively generating new cached files before visitors arrive. A preload warms the cache without any visitor triggering a fresh render.

The optimal workflow combines both:

1. A content update triggers an automatic cache purge for the affected pages via the save_post hook
2. The preload system detects that those URLs are no longer cached and adds them back to the crawl queue
3. Within minutes, the pages are re-cached in the background
4. Visitors always receive fast cached responses, even immediately after a content update

Without preloading, there is always a window after a purge where the first visitor to each page gets a slower uncached response. With preloading, this window is eliminated.

Performance Cache Settings Reference

When to Clear Cache in Different Scenarios

After Updating WordPress, a Plugin, or Theme

Run Delete HTML/JS/CSS Cache from the Cache panel. Plugin and theme updates can change both page structure (HTML) and asset files (CSS/JS). Clearing only the HTML cache would leave old bundled JS and CSS files being served with updated HTML.

After Changing BlinkSpeed Settings

Always clear cache after saving any BlinkSpeed settings change. The plugin does not automatically regenerate cached files when settings change. If you enabled lazy loading for JavaScript and saved settings, existing cached pages still contain the old script tags until the cache is cleared and pages are regenerated.

After Making Content Changes via the Editor

If Clear Cache When Page or Post Is Updated is enabled, this happens automatically. If it is not enabled, use the admin bar Purge Page Cache control on the page you just edited to trigger an immediate cache refresh for that URL only.

After Changing Menus, Widgets, or Global Elements

Menus, sidebars, footers, and headers appear on every page. Changes to these elements require clearing the HTML cache site-wide since every cached page contains the old version of these global elements.

After Installing a New Plugin That Adds Frontend Output

New plugins often register scripts, stylesheets, or HTML output that was not present when existing cache files were generated. Run Delete HTML/JS/CSS Cache after installing and activating any plugin that affects frontend output.

Summary

BlinkSpeed’s cache system is one of the most complete performance cache settings implementations available for WordPress. Static HTML caching eliminates PHP processing time for every visitor. The dual delivery modes (Htaccess and PHP Cache) ensure compatibility across Apache and Nginx environments.

The automatic post-update purge keeps content accurate without manual intervention. The preload cache system eliminates cold-start penalties by warming pages proactively. Browser caching and GZIP compression reduce transfer overhead. And native hosting provider integration ensures that server-level cache layers on platforms from SiteGround to Kinsta to Cloudways are purged in sync with BlinkSpeed’s own file cache.

Start with HTML Caching and preload cache enabled, set Cache Expiry to 3600, turn on browser cache and GZIP, then enable clear cache on post update. That baseline configuration covers the majority of WordPress sites. From there, use the Cache panel and admin bar controls to manage manual purge cache operations as your site evolves.

Frequently Asked Questions Related to BlinkSpeed Cache Management

Q1. What is the difference between purge cache and clear cache WordPress plugins offer?

In BlinkSpeed, both terms describe removing existing cached files, but they apply at different levels. Clearing cache typically refers to deleting BlinkSpeed’s own local cache files from the bs-cache directory. Purging cache includes that deletion plus sending purge requests to your hosting provider’s server-level cache layer (Varnish, Redis, and similar). The admin bar Purge All Cache option performs both. The Cache panel Delete buttons perform local file deletion only.

Q2. How does preload cache work with WooCommerce?

The preload cache system respects BlinkSpeed’s exclusion rules. WooCommerce’s cart, checkout, and account pages are typically excluded from caching (via cookie-based exclusions) because they contain session-specific content. The preloader skips excluded URLs and only warms pages that are eligible for caching, so it will not attempt to cache your checkout page even during a full-site preload run.

Q3. How often does the preload cache cron job run?

BlinkSpeed registers a custom WordPress cron schedule called blinkspeed_every_minute that fires once per minute. On each run, it processes the number of URLs specified in the Preload Pages Per Minute setting. The cron system is WordPress-native, meaning it fires when traffic arrives and a cron event is due. On very low-traffic sites with long gaps between visitors, cron jobs may fire less frequently than once per minute.

Q4. Why do changes on my site appear cached for visitors but not for me?

BlinkSpeed bypasses the cache for logged-in administrators by default (unless Enable Caching for Logged-In Users is turned on). When you are logged in and viewing a page, you see the live dynamically rendered version. Your visitors are seeing the cached version. If you want to verify what visitors see, open the page in a private/incognito browser window where you are not logged in.

Q5. Is GZIP compression the same as image compression?

No. GZIP compression is a transfer encoding that reduces the byte size of HTML, CSS, and JavaScript files sent over the network. It operates on text-based assets during transmission. Image compression reduces the file size of image files themselves and is handled separately by BlinkSpeed’s WebP conversion and image optimisation settings. Both are performance cache settings worth enabling, but they operate on different asset types and at different stages of the request/response cycle.

Q6. Does deleting critical CSS break my site?

Deleting critical CSS removes the above-the-fold stylesheet extract for your pages. Until the critical CSS is regenerated, pages will load using the full stylesheet link rather than the inline critical CSS – which is how most WordPress sites load CSS without any caching plugin. Your site will look and function correctly. The only difference is a potential brief flash of unstyled content on initial page load until the critical CSS is regenerated. This is temporary and resolves automatically as the preload system rebuilds the critical CSS per page.

Q7. How does cache expiry time interact with the preload cache setting?

Cache Expiry Time defines the maximum age of a cached file. When preload cache is enabled, BlinkSpeed’s cron system regularly re-caches pages before or after they expire, effectively keeping them perpetually warm regardless of the expiry value. The expiry time acts as a safety net – if the preloader has not reached a given URL yet, the expired cache triggers a fresh render on the next live visitor request. With preloading active, set a longer expiry time (7200 seconds or more) to reduce unnecessary regeneration cycles.

Q8. Can I use BlinkSpeed cache with a CDN?

Yes. BlinkSpeed generates optimised static HTML files that CDN origin caches can serve. After configuring your CDN to pull from your origin server, the CDN receives and caches BlinkSpeed’s already-optimised HTML output. For cache purge refresh guide compatibility, note that CDN edge caches have their own invalidation cycles – a purge in BlinkSpeed clears your origin and hosting-level cache but does not automatically invalidate edge cache nodes. Configure your CDN’s cache invalidation separately or set a short CDN TTL for HTML content.

Q9. Does BlinkSpeed’s cache work on multisite WordPress installations?

BlinkSpeed is multisite compatible. The cache system generates separate cache directories and files per subsite, and cache purge operations respect the current site context. Each subsite in the network operates its own independent cache lifecycle, expiry timing, and preload queue.

The post BlinkSpeed Cache Management: Purge, Preload & Clear Cache appeared first on Blinkspeed.

Some pages, scripts, stylesheets, and media files need to load in their original, untouched form. A WooCommerce checkout page that depends on a specific JavaScript initialization sequence, a third-party chat widget with inline styles that break under minification, or a custom slider that conflicts with combined CSS these are exactly the situations that BlinkSpeed’s dedicated Exclusions panel was designed to handle.

WordPress exclusions inside BlinkSpeed give you surgical control. You tell the plugin precisely which resources to leave untouched while letting everything else benefit from full optimization. The result is a site that is both fast and fully functional with no broken layouts, no white screens, no plugin conflict chaos.

Knowing when and how to use BlinkSpeed exclusions is what separates a professionally optimized WordPress site from a half-working one. They are not a sign of plugin failure. They are an intentional feature of the advanced optimization settings that puts you in control of exactly how aggressively the plugin touches your assets.

In this guide you will learn how every exclusion type inside BlinkSpeed works, how to correctly exclude CSS JS files that cause visual or functional issues, how page exclusions protect your most sensitive URLs, and how to use the exclusion system as a reliable plugin conflict fix all without sacrificing a single point of PageSpeed score on the pages that matter most.

When Should You Use WordPress Exclusions?

Before diving into the mechanics, it is worth understanding the triggers that tell you WordPress exclusions are necessary. Not every visual glitch or functional problem requires an exclusion; sometimes a full cache purge resolves the issue. But certain signals are clear indicators that a targeted exclusion rule needs to be added through BlinkSpeed’s advanced optimization settings.

The checkout or cart page breaking is one of the most common triggers. Minified or combined JavaScript disrupts WooCommerce, Easy Digital Downloads, or any other e-commerce checkout flow. Adding page exclusions for those URLs is the standard plugin conflict fix in this scenario. A second common trigger is a layout that looks visually wrong after optimization is enabled. Combined CSS sometimes strips a vendor prefix or an @import rule that a theme depends on. Using BlinkSpeed’s option to exclude CSS JS files belonging to that theme component restores the layout immediately.

Login pages, account dashboards, and other session-aware pages should never be HTML-cached. Dynamic page exclusions guarantee these URLs are always served fresh from PHP, preventing stale data from reaching logged-in users. Third-party widgets such as live chat tools, booking calendars, and payment iframes often embed their own inline scripts that depend on synchronous execution. Force-lazy-load rules or excluding those scripts from JS optimization are the go-to plugin conflict fix in these cases.

Hero images and above-the-fold banners represent another category where WordPress exclusions become important for performance rather than compatibility. Applying lazy loading to your LCP image hurts Core Web Vitals scores. BlinkSpeed’s media exclusion rules let you pull that specific image out of lazy loading while keeping every other image deferred. Page builders like Elementor and Divi, form plugins, and membership systems all ship their own JavaScript and CSS assets. Advanced optimization settings let you exclude those files without disabling BlinkSpeed globally, giving you a clean plugin conflict fix that preserves speed everywhere else.

How to Exclude CSS JS Files From Optimization

The most frequently used exclusion rules in BlinkSpeed are those that let you exclude CSS JS files from minification, combination, or deferred loading. BlinkSpeed processes these assets at the file level using URL pattern matching. You do not need to specify a full path, just a recognizable fragment of the stylesheet or script URL is enough for the plugin to identify and exclude the correct file.

Accessing the CSS Exclusions Panel

Navigate to BlinkSpeed → Exclusions in your WordPress admin and expand the CSS Exclusions accordion. Two sub-controls form the core of the advanced optimization settings for stylesheets.

The first is Exclude Stylesheet URLs from Optimization. Enter any matching fragment of a CSS file URL here. BlinkSpeed will skip minification, combination, and URL rewriting for any stylesheet whose URL contains this string. This is ideal for third-party CSS that uses proprietary syntax, non-standard at-rules, or complex calc() expressions that break under aggressive minification.

The second is Force Lazy Load Stylesheet URLs. This pushes non-critical stylesheets into a deferred load queue, meaning they load on first user interaction rather than during the critical rendering path. Use this for below-the-fold fonts, widget styles, or feature CSS that is never visible during the initial page view. It is a performance-enhancing WordPress exclusion rather than a compatibility fix: you are not removing the file from optimization, you are changing when it loads.

When you need to exclude CSS JS files, always use the most unique fragment of the URL: a plugin slug, a version folder, or a distinct filename. Overly generic patterns can inadvertently match and exclude far more files than intended, quietly undoing much of the benefit of your advanced optimization settings without any visible warning.

Excluding JavaScript Files: Two Levels of Control

The JS Exclusions section within BlinkSpeed’s advanced optimization settings provides two complementary controls that let you fine-tune which scripts are excluded and in what way.

Force Lazy Load Javascript forces inline JavaScript to load on user interaction rather than at page load. This is appropriate for analytics snippets, chat widgets, cookie consent scripts, and other non-critical trackers that do not affect the visible page render.

Excluding Javascript from Lazyload does the opposite: it removes a JS file from the lazy loading and combination queue entirely, letting it load synchronously in the normal WordPress script order. Use this for jQuery, critical initialization scripts, and payment SDKs where execution order is non-negotiable.

A practical example: if Stripe’s stripe.js breaks when deferred, enter stripe.js in the Exclude Javascript from Lazyload field. BlinkSpeed will load it synchronously while deferring everything else. This is the cleanest plugin conflict fix for payment-related scripts because it targets the single problematic file rather than disabling JS optimization for the whole page.

Common exclusion patterns that cover the most frequent compatibility scenarios include woocommerce/assets/js for WooCommerce scripts, elementor/assets/js for Elementor’s front-end scripts, jquery.min.js to ensure jQuery is never deferred, and stripe.js or paypal/sdk for payment integrations. These patterns entered into the appropriate field in BlinkSpeed’s advanced optimization settings will resolve the majority of plugin conflicts related to JavaScript loading.

Setting Up Page Exclusions in BlinkSpeed

Page exclusions are the broadest type of WordPress exclusions available in BlinkSpeed. Rather than targeting a specific file, they target entire URLs or URL patterns telling the plugin to skip optimization or caching for matching pages entirely. This is essential for dynamic pages, user-specific pages, and pages that generate unique content per session.

Four Page-Level Exclusion Controls

BlinkSpeed provides four distinct page exclusion controls under the Pages Exclusions accordion, each operating at a different level of the optimization stack.

Exclude Pages from HTML Caching ensures any URL fragment or slug entered here is permanently skipped by BlinkSpeed’s HTML caching engine. The page will always be served dynamically from PHP rather than from a cached file. Use this for checkout flows, account dashboards, and any page that displays user-specific data. WooCommerce generates dynamic cart tokens, nonces, and session data per user. If BlinkSpeed’s HTML cache serves a stale version of the checkout page to a new visitor, the nonce will expire and the order will fail. Always add /cart/, /checkout/, and /my-account/ to this field as a baseline this is standard practice under any advanced optimization settings configuration for e-commerce sites.

Exclude Pages From Optimization is a full bypass for the entire BlinkSpeed optimization pipeline. Pages matching this rule receive no CSS combination, no JS deferral, no minification, and no HTML processing. Use it sparingly only for pages where every single optimization breaks something simultaneously. A common example is a landing page built with a custom page builder that manages its own asset loading pipeline and conflicts with BlinkSpeed’s processing at every level.

Exclude Pages from CSS Optimization is a more surgical WordPress exclusion. CSS on matching pages will not be combined or minified, but all other optimizations remain fully active. This is useful when a page uses a CSS animation library that breaks under combination but whose JavaScript is otherwise safe to defer and minify.

Exclude Pages from JavaScript Optimization is the JS equivalent. Pages matching this rule skip JS minification and combination while still benefiting from HTML caching, image optimization, and CSS improvements. This is typically the first page exclusion to try when a specific page’s interactive functionality breaks after enabling BlinkSpeed, because it narrows the problem to JavaScript without disabling every other performance gain.

How to Add Page Exclusions in BlinkSpeed

Go to BlinkSpeed → Exclusions and expand the Pages Exclusions section. Click Add Rule next to the relevant exclusion type. Enter the slug or partial URL of the page for example /checkout/, /cart/, or /my-account/. Click Save Changes at the bottom of the Exclusions panel. Then purge all caches from the BlinkSpeed admin bar menu and test the excluded page in a private browser window to confirm normal behaviour.

BlinkSpeed’s page exclusions use partial string matching. Entering /checkout/ will match the root checkout URL, any step parameter appended to it, and any child paths beneath it. You do not need to enumerate every variation of a URL; a single slug covering the parent path is sufficient for most page exclusions.

Media and Lazy Load Exclusions

BlinkSpeed automatically applies lazy loading to images, iframes, videos, and audio elements deferring their load until they approach the viewport. For below-the-fold content this is excellent, but applying it to the Largest Contentful Paint element actively harms Core Web Vitals when that element is an above-the-fold hero image or primary banner. The Media Exclusions section within BlinkSpeed’s advanced optimization settings provides two controls for fine-tuning lazy loading behaviour as part of your overall WordPress exclusions strategy.

Preload Media

Enter the URL of any critical resource here a hero image, a web font, or a video poster and BlinkSpeed injects a link rel=”preload” tag for it in the document head. This is not technically an exclusion from optimization; it is a performance-positive addition that ensures the browser fetches the resource at the highest priority before the main render begins. Using this field for your LCP image, combined with excluding it from lazy loading, is one of the highest-impact advanced optimization settings adjustments you can make for Google PageSpeed scores.

Exclude Media from Lazy Loading

Enter any matching text found within an image, iframe, video, or audio tag. This can be a CSS class name, an element ID, a partial URL, or an alt attribute value. BlinkSpeed will skip lazy loading for any media element whose tag markup contains this string. Common WordPress exclusions in this category include the class name of the hero image such as hero-image or hero-banner, a custom class you apply to above-the-fold elements such as above-fold, a fragment of the filename for a critical brand image, or the logo identifier to ensure the site logo never lazy-loads.

If your site’s LCP image is being lazy-loaded by BlinkSpeed and you have not added a media exclusion for it, Google PageSpeed will penalize your performance score. Fixing this particular WordPress exclusion should take priority over most other advanced optimization settings adjustments, because the LCP metric carries significant weight in both Core Web Vitals assessments and Google Search ranking signals.

Using Exclusions as a Plugin Conflict Fix

One of the most practical applications of BlinkSpeed’s exclusion system is diagnosing and resolving plugin conflicts. When another WordPress plugin stops working correctly after BlinkSpeed is activated, the instinctive response is to deactivate BlinkSpeed entirely. But that discards all your performance gains across the entire site. A far better approach is to use targeted WordPress exclusions as your plugin conflict fix, isolating exactly which optimization is causing the incompatibility.

A Systematic Approach to Plugin Conflict Fixing

Start by identifying the broken page and confirming the issue is visible to regular visitors in a private browser window where no admin cookies are active. This rules out admin-side rendering differences before you begin making changes.

Next, try a JS page exclusion first. Go to BlinkSpeed advanced optimization settings → Exclusions → Pages Exclusions and add the broken page’s slug under Exclude Pages from Javascript Optimization. JS deferral and combination cause the majority of plugin conflicts. Test in a private window after clearing all caches. If the issue resolves, you know JavaScript optimization is the cause and can now narrow it further to a file-level exclusion. If the page is still broken after excluding JS optimization, try CSS. Add the same slug to Exclude Pages from CSS Optimization. Many visual glitches caused by combined or minified CSS resolve at this step.

Once you have identified which type of optimization is causing the plugin conflict, shift from a broad page exclusion to a file-level approach. Exclude CSS JS files by entering the specific filename or plugin folder fragment into the relevant file-level exclusion field. This preserves optimization on every other asset loaded by that page while neutralizing the one problematic file. It is a more precise plugin conflict fix and a better long-term advanced optimization setting than a full page exclusion.

After each change, purge all caches using BlinkSpeed’s admin bar Clear All Cache option and reload the page with a hard refresh to ensure you are viewing the newly served content and not a browser-cached version. Gravity Forms and Contact Form 7 both load conditional scripts that conflict with JS combination. WPBakery and Divi frequently ship CSS with non-standard syntax that breaks under minification. Elementor’s widgets rely on a specific script initialization order that JS deferral disrupts. In all three cases the correct WordPress exclusion is to exclude CSS JS files for that specific plugin, not to disable optimization globally.

Advanced Optimization Settings: Rules and Patterns

BlinkSpeed’s exclusion engine operates on substring matching. If the string you enter appears anywhere within the asset URL or tag markup, the exclusion applies. Understanding this opens up powerful pattern-based WordPress exclusions that can cover entire plugin asset directories with a single rule in the advanced optimization settings panel.

For WooCommerce JavaScript, entering woocommerce/assets/js in the Exclude Javascript from Lazyload field covers every WooCommerce script in a single rule. For Elementor’s editor environment, adding /?elementor-preview= to the full page exclusion field ensures the live editor is never touched by optimization. To keep the Google Fonts stylesheet from being combined with local stylesheets, entering fonts.googleapis.com in the Exclude Stylesheet URLs field is sufficient. For a hero image excluded from lazy loading, entering the image’s CSS class such as hero-banner or site-logo covers every instance of that image across all pages simultaneously.

Using Multiple Rules Together

Advanced optimization settings frequently require combining multiple exclusion types simultaneously. Consider a WooCommerce store running Elementor on product pages. You might exclude CSS JS files belonging to WooCommerce’s payment gateway, add page exclusions for /checkout/ and /cart/ from HTML caching, exclude Elementor’s preview URL from full optimization, and force-lazy-load the slider CSS on the homepage all at the same time. BlinkSpeed evaluates each rule independently, so multiple WordPress exclusions stack without interfering with each other.

Exclusion Checklist Before Going Live

Whether you are launching a new site or enabling BlinkSpeed on an existing one, use this checklist to make sure your advanced optimization settings and WordPress exclusions are properly configured before traffic arrives. Add e-commerce page exclusions first. Enter /cart/, /checkout/, /my-account/, and /order-received/ into Exclude from HTML Caching and Exclude Pages From Optimization if you are running WooCommerce or any other e-commerce plugin. This is the single most important plugin conflict fix for transactional sites and prevents the most damaging type of caching-related breakage.

Review your LCP image using Google PageSpeed Insights or Chrome’s Performance panel to identify the Largest Contentful Paint element. If it is an image, add its class or filename to Exclude Media from Lazy Loading. Optionally also add it to the Preload Media field to give it maximum load priority. Test every interactive form in a private browser window after BlinkSpeed is fully active. Contact forms, booking widgets, multi-step calculators, and login forms all depend on inline JavaScript. Use the Force Lazy Load or exclude CSS JS files controls under JS Exclusions if any form submission fails or behaves unexpectedly.

Verify every third-party widget loads and triggers correctly. Live chat tools, pop-up managers, and cookie consent banners often embed proprietary scripts that assume synchronous loading. A file-level JS exclusion is the appropriate plugin conflict fix when a widget is non-functional after optimization is enabled.

Run a final PageSpeed Insights audit from a clean browser after setting all your page exclusions and file-level WordPress exclusions. Confirm that scores have improved and that the pages you excluded still perform within an acceptable range for their type.

Frequently Asked Questions

Q1. How do I know which CSS or JS file to exclude in BlinkSpeed?

The fastest way to identify which file to exclude CSS JS files from is to open Chrome DevTools, go to the Console tab, and reload the broken page. JavaScript errors typically reference the originating file by name. For CSS issues, inspect the broken element in the Styles panel and trace the missing or malformed rule back to its source stylesheet.

Once you have the original filename or plugin folder, enter that as the pattern in BlinkSpeed’s advanced optimization settings exclusion field.

Q2. Will adding page exclusions hurt my PageSpeed score?

Adding page exclusions to transactional pages like /checkout/ or /my-account/ will not negatively affect your PageSpeed score because Google’s performance audits focus on publicly accessible, non-session-specific URLs. For publicly visible pages, only use WordPress exclusions where absolutely necessary as a plugin conflict fix.

Prefer file-level exclusions over full page exclusions to preserve as much optimization as possible on pages that do appear in PageSpeed reports.

Q3. What is the difference between excluding a file and excluding a page in BlinkSpeed?

When you exclude CSS JS files at the file level, only that specific stylesheet or script is left unoptimized across every page that loads it. Every other asset on every other page continues to receive full BlinkSpeed optimization. When you add page exclusions, every asset on that specific URL is excluded from a particular type of optimization.

File-level exclusions are more surgical and should always be tried first. Page exclusions are broader and best reserved for pages where multiple assets are causing simultaneous issues.

Q4. My WooCommerce checkout is broken after enabling BlinkSpeed. What should I do?

This is one of the most common plugin conflict scenarios with performance plugins. Go to BlinkSpeed → Exclusions → Pages Exclusions and add /checkout/ and /cart/ to both Exclude pages from HTML caching and Exclude Pages from Javascript Optimization.

Then add WooCommerce’s payment gateway scripts identifiable by the pattern woocommerce/assets/js to the Exclude Javascript from Lazyload field under JS Exclusions. Purge all caches and test in a private browser window. This combination of page exclusions and file-level WordPress exclusions resolves the overwhelming majority of WooCommerce conflicts.

Q5. Can I exclude a specific image from lazy loading in BlinkSpeed?

Yes. Navigate to BlinkSpeed → Exclusions → Media Exclusions and expand the section. In the Exclude Media from Lazy Loading field, enter any text that uniquely identifies your image, its CSS class, a portion of its filename, its alt attribute value, or its element ID.

BlinkSpeed matches this string against the full image tag and excludes any matching media element from lazy loading. This is the recommended WordPress exclusion for your LCP image and should be one of the first advanced optimization settings you review on any new installation.

Q6. Do BlinkSpeed’s WordPress exclusions apply to the mobile version of my site too?

Yes. BlinkSpeed maintains separate cache files for desktop and mobile using distinct file extensions internally, but exclusion rules are applied universally across all device types. When you exclude CSS JS files or set page exclusions, those rules are enforced for both desktop and mobile visitors.

If a specific issue only occurs on mobile, use Chrome’s device emulation mode to identify the mobile-specific asset and add a targeted exclusion for it through BlinkSpeed’s advanced optimization settings.

Q7. How do I use the Force Lazy Load Stylesheet setting, and how is it different from excluding a stylesheet?

Force Lazy Load Stylesheet URLs push a CSS file into a deferred loading queue so it loads after the initial render on first user interaction. This is a performance-enhancing WordPress exclusion: you are not removing the file from optimization, you are changing when it loads.

Use it for non-critical styles like sidebar widget CSS or modal overlays. Excluding a stylesheet from optimization entirely keeps it loading at normal timing but prevents BlinkSpeed from minifying or combining it. Use the file exclusion approach when a stylesheet’s content breaks under optimization, and use Force Lazy Load when the stylesheet content is fine but you want to defer it purely for performance.

The post How to Use BlinkSpeed Exclusions Without Breaking Your Site appeared first on Blinkspeed.