Installing BlinkSpeed alongside other WordPress plugins is straightforward most of the time. But certain categories of plugins – caching plugins, other performance optimisers, translation plugins, security plugins, and e-commerce plugins – overlap with what BlinkSpeed does and can cause unpredictable behaviour when both are active at the same time.
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:
- Go to BlinkSpeed → HTML Caches and enable HTML Caching first – nothing else yet
- Clear cache and open your homepage, key inner pages, and your most complex pages in private browser windows
- If everything looks correct, enable CSS Optimization – clear cache and test again
- Enable JavaScript Optimization with Lazyload JavaScript set to No first – clear cache and test
- Switch Lazyload JavaScript to Yes – clear cache and test interactivity on every page
- Enable Image Lazy Loading – clear cache and test all image-heavy pages
- 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.
