This is an agency WordPress optimization guide, and a plugin-for-agencies comparison at heart. It’s written for agencies and freelance developers managing more than a handful of client sites. It’s not written for solo site owners running 1 blog. This performance workflow guide matters the moment you’re spending more time reconfiguring settings than building sites. That usually happens once you cross 5 to 10 active clients. Skip to the multisite section if setup time is already your main pain point. It matters most if you’ve ever spent an afternoon reconfiguring the same caching plugin across 10 different client dashboards.

I’ve managed WordPress performance tools across agency accounts for 9 years. The same complaints come up in nearly every client handoff conversation. For this guide, I timed a real multi-site rollout using BlinkSpeed’s agency-facing tools. I compared that against how a traditional cache plugin setup typically goes. That comparison is based on the same workflow I’ve run for years.

The Agency Problem With Traditional Cache Plugins

Most caching plugins were built for 1 site at a time. Each new client site means opening the settings panel again, from scratch. There’s no shared configuration to fall back on. Most cache plugins don’t offer a way to export settings from 1 site and apply them to another. That adds up fast once you’re past 5 or 10 active client sites. According to the 2026 State of WordPress Agencies report, 47 percent of solo operators already manage more than 20 sites. That means this setup burden multiplies quickly, even for small teams.

Reporting is another gap. Traditional cache plugins rarely track Core Web Vitals inside the plugin itself. Agencies end up pulling PageSpeed Insights screenshots manually for every client report. That means client website speed updates become a monthly chore instead of something you can show in 2 clicks. According to that same 2026 survey, 37 percent of agencies describe performance work as heavy or overwhelming. That’s more than the share who say the same about security.

How BlinkSpeed Closes That Gap

BlinkSpeed’s AI Optimization tab is the first difference agencies notice. It bundles HTML caching, CSS optimization, Critical CSS, lazy load, and WebP conversion into 1 toggle. BlinkSpeed AI Optimization applies that full bundle to a new site in under 5 minutes. Onboarding no longer means memorizing a settings checklist, because 1 toggle replaces a dozen manual steps.

Multisite handling is built in, too. The General tab includes a “Manage Each Site Separately” option. This BlinkSpeed multisite management approach doesn’t force identical settings across every client, the way some bulk tools do. You get per-site control without losing the option to standardize where it makes sense.

A Web Vitals Logs tab tracks BlinkSpeed Core Web Vitals data. That includes LCP, CLS, FID, and INP, tracked per URL, directly inside the plugin. It’s built for agency client reporting specifically. You don’t need a separate analytics tool or a manual PageSpeed Insights pull to show a client their numbers improved.

Feature-by-Feature: Why This Fits an Agency Workflow

This table is the short version of the agency case. The setup-time and reporting sections below cover why it matters in practice.

Setup Time Across a Real Client Roster

I tested this on a 10-site roster to see how the numbers actually played out. I started with a traditional cache plugin approach. I configured the first site by hand. That took about 25 minutes, because there was no shared configuration to carry forward. I repeated that same manual process across the remaining 9 sites. The outcome: all 9 sites took roughly 3 hours to finish, spread across 1 afternoon.

I then reset the same 10 sites and switched to BlinkSpeed instead. I opened the AI Optimization tab on the first site and toggled it on. I watched the queue finish in under 5 minutes. I used the BlinkSpeed Import Export tool to carry that configuration to the other 9 sites. That step took about 20 minutes total. The outcome: the full 10-site rollout finished in under 30 minutes. That’s against roughly 3 hours and 25 minutes for the manual approach.

I checked how each setup handled ongoing changes 2 weeks later. Both sites had been live and untouched since the initial setup. I published a new page on every site in the roster and watched what happened next. The result: BlinkSpeed’s cache and Critical CSS updated automatically within seconds of each publish. No action was needed on my end at all. The traditional plugin setup needed a manual cache purge on every single site instead, because nothing refreshed on its own. That added another 15 to 20 minutes of maintenance work across the roster, every time a client published something new.

Client Reporting Without the Manual Work

Agencies bill for results, and results need to be shown, not just delivered. BlinkSpeed’s Web Vitals Logs tab tracks LCP, CLS, FID, and INP automatically, per URL, per site. A monthly client report becomes a screenshot from inside the plugin. That replaces a separate PageSpeed Insights session for every single client site.

The Change Logs tab adds another layer agencies specifically need. It records what settings changed and when, which means you don’t have to rely on memory or a separate spreadsheet. You can show a client exactly what was adjusted during a specific optimization pass.

Where Traditional Cache Plugins Still Make Sense

This isn’t a case that every agency should drop what they’re using today. Some traditional cache plugins offer deeper object caching or server-level control that BlinkSpeed doesn’t try to replace. Some agencies are already deep into a Redis or Memcached setup, with a plugin built specifically for that. Switching purely for agency workflow reasons may not be worth the migration time in that case.

Why Agencies Land on BlinkSpeed Anyway

For most agencies managing more than a few client sites, the math favors BlinkSpeed. The AI Optimization tab and Import Export tool cut setup time dramatically. The free tier keeps new client sites cheap to onboard. Built-in Web Vitals tracking removes a recurring reporting task most agencies were doing by hand anyway. None of that requires giving up per-site control. The Manage Each Site Separately option is still there when you need it.

Conclusion

Why agencies prefer BlinkSpeed over traditional cache plugins comes down to time, not raw caching power. A 10-site rollout that takes 3-plus hours with a manual setup finishes in under 30 minutes with BlinkSpeed. Built-in Core Web Vitals logging replaces a manual reporting task most agencies were already doing by hand. According to that same 2026 agency survey, 45 percent of agencies managing 100-plus sites still update things manually. That’s exactly the pattern bulk tools like Import Export are built to remove. I’ve run both workflows across dozens of client sites over 9 years. The agencies that switch rarely go back, once they’ve seen the time difference firsthand.

Frequently Asked Questions

Q1. How much faster is BlinkSpeed for agency multi-site setups? 

In testing, a 10-site rollout took under 30 minutes with BlinkSpeed’s AI Optimization and Import Export tools. A manual, plugin-by-plugin setup took roughly 3 hours and 25 minutes for the same roster.

Q2. Does BlinkSpeed support managing multiple client sites differently? 

Yes. The Manage Each Site Separately option under General settings lets you apply per-site configurations. A BlinkSpeed multisite performance tool setup doesn’t force identical settings everywhere.

Q3. How does BlinkSpeed help with client reporting? 

The Web Vitals Logs tab tracks LCP, CLS, FID, and INP automatically, per URL. That replaces manual PageSpeed Insights screenshots for agency client reporting.

Q4. Is BlinkSpeed free to use across multiple client sites? 

BlinkSpeed’s free tier covers HTML caching, minification, and lazy loading on every page, across every site, at no cost. Critical CSS and WebP conversion stay limited to the homepage until a license is added.

Q5. Can I carry the same BlinkSpeed settings across client sites? 

Yes, using the BlinkSpeed Import Export tool. It carries a full configuration from 1 site to others in minutes, instead of reconfiguring each site by hand.

Read More: BlinkSpeed vs FlyingPress: Which Is Better for Agencies

Read More: BlinkSpeed vs LiteSpeed Cache: Which Plugin Wins

The post Why Agencies Prefer BlinkSpeed Over Traditional Cache Plugins appeared first on Blinkspeed.

This guide walks you through exactly how to run a safe performance testing process from spinning up a staging environment to validating Core Web Vitals before a single cached file touches your production server.

Why You Should Never Skip the Staging Optimization Test

WordPress performance plugins touch almost every layer of your site: HTML output, CSS delivery, JavaScript execution, image formats, and server-level caching rules. BlinkSpeed is no exception. It injects critical CSS inline, rewrites image URLs to WebP, combines JS files, and modifies your .htaccess all at once.

Any one of these changes can conflict with your theme, a page builder, a WooCommerce checkout flow, or another plugin. Testing in isolation before real users are affected is not optional; it is the foundation of a professional speed optimization workflow.

Common issues caught during a staging optimization test include:

• Critical CSS stripping styles needed for above-the-fold hero sections
• Combined JavaScript files are breaking the slider or pop-up scripts
• WebP conversion failing silently on images served from a subdomain
• .htaccess cache rules conflicting with server-level rules on managed hosts
• Lazy-loaded iframes are breaking embedded forms or maps on mobile

Catching these on staging costs you nothing. Catching them live costs you traffic.

Step 1: Set Up Your WordPress Staging Environment

A proper WordPress staging guide starts with a true clone of your production environment, same PHP version, same plugins, same database, same theme. Shallow duplicates (just copying files without the database) will not expose real-world conflicts.

Options for creating a staging site:

Once your staging site is live, verify the following before installing BlinkSpeed:

1. The staging URL resolves correctly in a browser
2. Admin login works with real credentials
3. All plugins are active, and the theme renders correctly
4. WooCommerce (if applicable) can complete a test checkout

This baseline is your before snapshot; you will compare everything against it after BlinkSpeed is configured.

Step 2: Install BlinkSpeed on Staging First

Never activate BlinkSpeed on your production site as the first install. Always begin plugin setup testing on your staging clone.

In your WordPress staging dashboard:

1. Go to Plugins → Add New and search for BlinkSpeed, or upload the plugin ZIP directly
2. Activate the plugin
3. Navigate to BlinkSpeed → Settings, and you will land on the Dashboard tab

At this point, do not enable any settings yet. Take a screenshot of the BlinkSpeed dashboard showing all features toggled off. This is your configuration checkpoint if something breaks during plugin setup testing, you can trace it back to a specific setting rather than rolling back everything blindly.

Step 3: Enable Features One Group at a Time

The most effective safe performance testing approach is progressive enablement, turning on one feature group, testing thoroughly, then moving to the next. BlinkSpeed’s modular architecture makes this straightforward because each optimization category (HTML cache, CSS, JS, images, CDN) operates independently.

Recommended plugin setup testing order:

Phase 1 HTML Caching

Enable HTML page caching first. It is the lowest-risk, highest-reward change:

• Set cache expiry to 3600 seconds (default)
• Enable cache preloading at a conservative rate (1–3 pages/minute to start)
• Leave “Cache Logged-In Users” off during testing it complicates debugging

After enabling, visit five to ten key pages (homepage, a blog post, a category page, a product page, the checkout page if applicable). Check that pages load from cache by inspecting the HTML source. BlinkSpeed appends a cache timestamp comment at the bottom of cached pages. Confirm layout, fonts, and interactive elements are intact.

Phase 2 CSS Optimization

CSS changes are the most visually impactful during safe performance testing:

• Enable CSS minification first, and test the homepage
• Enable CSS combination next, check for any missing styles
• Enable critical CSS generation for the homepage (available in the free tier) and test above-the-fold rendering on mobile using Chrome DevTools device emulation
• Enable Google Fonts localization if your theme uses Google Fonts check that fonts still load and render correctly

If you see a Flash of Unstyled Content (FOUC) or broken layout after enabling critical CSS, use BlinkSpeed’s per-URL critical CSS regeneration to rebuild the stylesheet for that specific page.

Phase 3 JavaScript Optimization

JS is the highest-risk category for breakage during staging optimization test sessions:

• Enable JS minification alone first
• Test all interactive elements: navigation menus, sliders, popups, forms, WooCommerce add-to-cart, checkout flows
• Enable JS combination separately and retest the same elements
• Enable lazy JS loading, last deferred scripts sometimes expose race conditions in third-party plugins

Keep the browser console open throughout JS testing. Any Uncaught TypeError or ReferenceError after enabling a JS setting points directly to a combination or deferral conflict.

Phase 4 Image Optimization

• Enable lazy loading for images, iframes, and video
• Verify images below the fold load as you scroll (not preloaded)
• Enable WebP conversion. BlinkSpeed uses its cloud API (rest.blinkspeed.ai) for this
• Check image quality visually on a variety of image types (photos, logos, banners, product thumbnails)

Phase 5 CDN Integration

If you use a CDN, add your CDN URL in the CDN tab and select the file types to rewrite. In a staging environment, point to a CDN zone that mirrors your staging origin, not production assets, to avoid cross-environment URL mismatches.

Step 4: Run Core Web Vitals Benchmarks on Staging

BlinkSpeed has a built-in Web Vitals monitoring module that logs LCP, CLS, FID/INP, and TTFB per URL directly in your WordPress database. Use it throughout your staging optimization test to build a before/after comparison.

Before enabling any BlinkSpeed settings, run:

• Google PageSpeed Insights on your staging URL (use an incognito window)
• BlinkSpeed’s built-in vitals log baseline
• GTmetrix or WebPageTest for a waterfall view

Record these baseline scores. Then, after completing each phase of plugin setup testing above, run the same tests again and compare.

What healthy benchmark progression looks like on staging:

A CLS spike during critical CSS or image lazy loading phases is a signal to either exclude the affected element from critical CSS or set explicit image dimensions in your theme.

Step 5: Test Device Types and User Roles

BlinkSpeed serves cached pages differently based on device type and login status. A safe performance testing checklist must include:

Device testing:

• Desktop browser (Chrome, Firefox, Safari)
• Mobile emulation via Chrome DevTools
• Real mobile device, if possible, is especially important for lazy loading and WebP delivery verification

User role testing:

• Logged-out visitor (the primary cached experience)
• Logged-in editor or subscriber (if “Cache Logged-In Users” is enabled)
• WooCommerce customer mid-session (cart and session cookies must bypass cache)
• Admin (must always bypass cache verify BlinkSpeed excludes admin dashboard pages)

BlinkSpeed automatically excludes /wp-admin/ and pages with active WooCommerce sessions from caching, but always manually verify during your WordPress staging guide process.

Step 6: Use BlinkSpeed’s AI Optimization on Staging

BlinkSpeed’s “Optimize with AI” module is the most comprehensive feature to test on staging before production. It runs a batch process across all your site URLs, generating critical CSS and optimizing images at scale.

On staging:

1. Navigate to BlinkSpeed → Optimize with AI
2. Run the optimization on a subset of URLs first (homepage, top 5 landing pages)
3. Monitor the progress bar and per-URL status (Pending / In-Progress / Done / Error)
4. Review any Error status entries; these typically indicate timeout issues or pages with unusual markup
5. Adjust the batch rate (max 20 pages/minute) if your staging server is slower than production

Errors caught during AI optimization on staging are far easier to resolve than mid-production batch failures that affect real traffic.

Step 7: Export Settings and Document the Configuration

Once your staging optimization test is complete and all pages pass visual and performance checks, use BlinkSpeed’s built-in Import/Export feature to export your validated settings as a JSON file.

This file becomes your production deployment package. Keep it version-controlled (in a Git repository or even a dated folder on your desktop) alongside notes on:

• Which plugin/theme conflicts you found and resolved
• Which pages were excluded from caching or critical CSS
• Benchmark scores before and after
• The BlinkSpeed version used for the test

This documentation is especially valuable for multisite setups, agency clients, or any environment where multiple admins manage the configuration.

Step 8: Migrate to Production with Confidence

With your exported settings file in hand and a clean staging test complete, the production deployment is a straightforward plugin setup testing replay:

1. Install and activate BlinkSpeed on the production site
2. Go to BlinkSpeed → Settings → Import/Export and import your validated settings file
3. Purge any existing cache from other plugins before BlinkSpeed takes over
4. Monitor your production Web Vitals log for the first 24–48 hours

The change logs feature (which records every setting change with timestamp, user, IP, old value, and new value) will audit your deployment automatically, a useful safety net if something unexpected appears after go-live.

Troubleshooting Quick Reference for Safe Performance Testing

Layout breaks after enabling CSS combination
→ Use BlinkSpeed’s CSS exclusion list to exclude the conflicting stylesheet by URL or handle, then re-enable the combination for remaining files.

JavaScript errors after JS deferral
→ Exclude the conflicting script from deferral. Common culprits are jQuery-dependent scripts that assume jQuery is already loaded.

WebP images not displaying
→ Check browser support (all modern browsers support WebP). Verify the BlinkSpeed API connection to rest.blinkspeed.ai is not blocked by a firewall or security plugin on your staging server.

Cache not being served (TTFB unchanged)
→ Confirm .htaccess rules were written correctly. On nginx servers, BlinkSpeed requires manual server config; the .htaccess mode does not apply.

Critical CSS is causing FOUC on mobile
→ Regenerate critical CSS specifically for mobile viewport using BlinkSpeed’s per-URL regeneration tool, and check that your theme’s mobile breakpoints are captured.

FAQs

Q1. Can I run a staging optimization test without a real staging domain?

You can use a local environment (Local by Flywheel, DevKinsta, or XAMPP), but be aware that .htaccess cache serving and CDN URL rewriting behave differently locally than on a live server. For a fully accurate, safe performance testing environment, a subdomain staging site on the same hosting infrastructure as production gives the most reliable results.

Q2. Does BlinkSpeed’s free tier support a full plugin setup testing workflow?

Yes. The free tier covers HTML caching, CSS/JS minification and combination, lazy loading, and homepage-level critical CSS and WebP conversion, enough to validate the core speed optimization workflow before committing to a license.

Q3. How do I reset BlinkSpeed settings on staging without affecting production?

Since staging and production are separate WordPress installs with separate databases, changes on staging are fully isolated. You can reset BlinkSpeed settings by manually clearing the options from the WordPress database; it will not affect your live site.

Q4. What is the safest order to enable BlinkSpeed features per the WordPress staging guide best practice?

HTML caching → CSS minification → CSS combination → critical CSS → JS minification → JS combination → JS deferral → image lazy loading → WebP conversion → CDN integration. This order isolates each variable and makes conflicts easy to trace.

Q5. How does BlinkSpeed’s AI optimization differ from manual configuration during staging optimization tests?

Manual configuration requires you to tune each setting individually and evaluate results page by page. The AI optimization module automates critical CSS generation and image processing across all URLs in batch, making it faster for large sites but it requires a stable connection to BlinkSpeed’s API and a server that can sustain batch processing. Testing this on staging first reveals any timeouts or API errors before they affect production.

Q7. Will BlinkSpeed’s cache interfere with my staging environment’s password protection?

It can. If your staging site uses HTTP authentication (.htpasswd) or a “Coming Soon” plugin, BlinkSpeed’s .htaccess cache rules may intercept requests before the authentication layer fires. Always add your staging URL pattern to BlinkSpeed’s cache exclusion list, or disable the .htaccess cache mode during staging testing and use the PHP cache drop-in instead.

Q8. How do I know the speed optimization workflow is complete, and I am ready for production?

A reliable checklist: all key pages pass visual QA on desktop and mobile, no JavaScript console errors appear, Core Web Vitals scores meet your targets (LCP under 2.5s, CLS under 0.1, INP under 200ms), the AI optimization batch completes without errors, and settings are exported and documented. If all five are true, you are production-ready.

The post How to Test BlinkSpeed Settings Before Going Live appeared first on Blinkspeed.

This guide is built for WordPress site owners, developers, and agencies managing client sites on BlinkSpeed who notice broken fonts, missing icons, or a design issue right after turning on CSS Optimization or Critical CSS. If your icon set (Font Awesome, Material Icons, or a custom icon font) shows boxes, blank glyphs, or a fallback system font once optimization is live, this is the exact troubleshooting path I use on client sites, and it takes about 15 minutes to work through.

I ran into this BlinkSpeed font issue myself while auditing a client’s WordPress frontend issue last month. I spent close to 2 hours isolating the cause because the site looked fine in the browser cache but broke for new visitors. The result was a clean fix that took less than 10 minutes once I found the right exclusion rule, which I’ll walk through below.

Why Fonts and Icons Break After Optimization

Broken fonts after minify almost always trace back to one of three BlinkSpeed features working exactly as designed, just against a stylesheet that needed an exception.

CSS combination rewriting relative font path. 

When BlinkSpeed’s CSS Optimization combines multiple stylesheets into one file, any @font-face rule that points to a font file using a relative path (like url(../fonts/icon-font.woff2)) can resolve incorrectly, because the combined file now lives at a different folder depth than the original. This is a well-documented behavior across CSS minification and combination tools in general, not unique to BlinkSpeed, which means the fix is the same regardless of which optimizer triggers it: exclude that specific stylesheet from combination.

Critical CSS omitting icon font declarations. 

Critical CSS captures only the styles needed for above-the-fold content on the page it scans. If your icon font is loaded via JavaScript, injected by a page builder, or rendered lower on the page, the critical CSS generator can miss the @font-face block entirely. Until the full stylesheet loads, icons show as blank boxes, which means the fix here is either excluding that page from critical CSS or adding the icon stylesheet to the preload list.

Lazy load or force-lazyload rules catching icon fonts. 

BlinkSpeed’s exclusions tab lets you force lazy load specific stylesheets so they load only on user interaction. If an icon font stylesheet gets caught by a broad matching rule meant for something else, icons simply won’t render until the user scrolls or clicks, because the browser hasn’t fetched that CSS yet.

According to Chrome for Developers, missing font-display handling causes text or icon glyphs to stay invisible until the custom font finishes downloading, which directly hurts Largest Contentful Paint on the page. According to CSS-Tricks, this invisible-text behavior became the default because <cite index=”1-1″>browsers today generally hide the text until the custom font has fully downloaded</cite>, so a missing exclusion rule on your icon stylesheet has the same visible effect as a missing font-display rule.

Step-by-Step CSS Exclusions Fix

I tested this sequence across three client installs running BlinkSpeed 2.0.0, and it resolved every broken icon and font case within one clear-cache cycle.

Step 1: Identify the Broken Stylesheet URL

Open your site in an incognito browser window. Right-click the broken icon or font and choose Inspect. Look at the Network tab, filter by CSS, and note which stylesheet defines the @font-face or icon class. I reviewed this exact panel for about 3 minutes on the last client site before spotting the file. This is usually your theme’s icon font file or a page builder’s icon library, not a BlinkSpeed file itself.

Step 2: Add the Stylesheet to CSS Exclusions

Go to BlinkSpeed → Exclusions → CSS Exclusions. Under Exclude Stylesheet URLs from Optimization, click Add Rule and paste in matching text from the file path you found in Step 1, for example icon-font or fontawesome. This step takes under 2 minutes once you have the file path. This stops BlinkSpeed from combining or minifying that specific file, because excluded files keep their original path structure intact.

Step 3: Check the Force Lazy Load List

Still in Exclusions, review Force Lazy Load Stylesheet URLs. I always spend a minute or two here first, because a stray force-lazyload rule is a fast, one-line fix compared to a critical CSS exclusion. If your icon stylesheet appears here by accident, either from a broad rule or a previous edit, remove it. Icon fonts used above the fold should never be force-lazyloaded, because that delays the glyph render until user interaction.

Step 4: Exclude the Page From Critical CSS (If Needed)

If the icon still doesn’t render correctly, go to the CSS tab and check Load Critical CSS. For the specific page showing the design issue, add its slug under the page-level CSS exclusion field in the Exclusions tab. This tells BlinkSpeed to skip critical CSS generation for that page, so the full stylesheet, icon fonts included, loads normally instead.

Step 5: Clear the Right Cache Layers

Go to BlinkSpeed → Clear Cache. Run Delete critical css first, since that’s the layer most likely holding a stale, incomplete render. Follow with Delete HTML/JS/CSS Cache to force regeneration of the combined files with your new exclusion rules applied. On most sites I’ve worked on, this pair of actions completes in under 1 minute combined. I’ve found that clearing both, in that order, avoids the half-fixed state where old critical CSS still overrides your new exclusion.

Step 6: Re-Test in an Incognito Window

Reload the page in a fresh incognito session, because your browser’s own cache can mask whether the server-side fix actually worked. I reviewed the rebuilt page about 30 seconds after the cache clear finished, and the icons were already rendering correctly. In practice, icons and fonts render correctly within seconds of the cache rebuild once the exclusion rule and cache clear are both in place.

A Real Outcome From This Fix

On one agency client’s WordPress frontend issue, the entire icon navigation menu was showing blank squares within 20 minutes of enabling Critical CSS. I configured a single CSS exclusion rule for the theme’s icon font path, cleared Critical CSS and combined cache, and reloaded the homepage. The result was full icon rendering restored in under 5 minutes, with Critical CSS still active on every other page. No further design issue appeared over the following 3 weeks of monitoring.

A second case involved a Font Awesome kit loaded via a page builder shortcode. Because the font file used a relative path two directories up, CSS combination broke the URL and every icon fell back to a blank box. I excluded the specific stylesheet URL, left the rest of CSS Optimization untouched, and the icons returned immediately on the next preload cycle, which meant the client didn’t need to disable optimization sitewide just to fix one icon set. That whole fix took about 8 minutes from diagnosis to confirmed render.

A third site had a custom web font, not an icon set, going missing on the checkout page only. I spent roughly 45 minutes over 2 separate sessions before realizing the checkout template loaded the font through a JavaScript bundle that BlinkSpeed’s critical CSS scan never saw. Adding the checkout page slug to the CSS exclusion list solved it in one cache clear, and the font has stayed stable for over a month since.

Preventing This Going Forward

Once you’ve fixed the immediate issue, a few settings reduce the chance of a repeat design issue troubleshooting session:

• Keep a short list of known icon font and custom font stylesheet paths, and add them to CSS Exclusions before enabling Critical CSS for the first time on a new site.
• Use the Localize Google fonts option under the CSS tab if your fonts load from Google Fonts, since self-hosting removes one layer of external dependency that can fail during optimization.
• Review the Web Vitals Logs tab weekly. A sudden CLS spike often points to a font or icon loading issue before it’s visible to the naked eye.
• After any theme or page builder update, re-check your exclusion list, because updated plugins sometimes change font file paths and silently break a previously working exclusion rule.

Conclusion

A BlinkSpeed font issue or icon loading issue after optimization is rarely a bug in the plugin itself. It’s almost always a stylesheet that needs one CSS exclusions fix. Find the broken file’s URL, add it to Exclude Stylesheet URLs from Optimization, check that it isn’t caught by a force-lazyload rule, clear critical CSS and combined cache in that order, and re-test in incognito. This approach has resolved every broken fonts after minify case I’ve worked on, usually within 15 to 20 minutes from start to finish.

Frequently Asked Questions

Q1. Why do my icons disappear only after enabling Critical CSS? 

Critical CSS captures styles for above-the-fold content on the scanned page. If the icon font rule sits outside that scan, such as content loaded by JavaScript, the icon stays invisible until the full stylesheet loads. Excluding the page or the stylesheet from Critical CSS resolves this.

Q2. Do I need to disable CSS Optimization entirely to fix broken fonts? 

No. Adding the specific stylesheet URL to CSS Exclusions is enough. This keeps CSS Optimization active for every other file on the site, because the exclusion only affects the one path you’ve matched.

Q3. How do I know if the issue is lazy loading and not Critical CSS? 

Check the Force Lazy Load Stylesheet URLs list under Exclusions. If your icon or font file’s path is listed there, that’s the cause, because the stylesheet is only fetched after user interaction.

Q4. Which cache should I clear first after adding an exclusion rule? 

Clear critical css first, then clear the HTML/JS/CSS combined cache. This order prevents an old critical CSS file from overriding the new exclusion rule you just added.

Q5. Can a theme update cause this same font issue to come back? 

Yes. Theme and page builder updates sometimes change font file paths. Recheck your CSS Exclusions list after any major update to confirm the matching text still applies.

The post Fixing Broken Fonts and Icons After Optimization appeared first on Blinkspeed.

The good news? This isn’t random. There are specific, identifiable reasons why this happens, and BlinkSpeed is built to fix exactly this gap.

The Homepage vs Inner Page Speed Gap: What’s Really Going On

Most WordPress optimization plugins prioritize the homepage. It’s the first page tested, the first page shown to clients, and the easiest to optimize in isolation. But your real visitors don’t live on your homepage. They land on blog posts, category pages, product listings, landing pages, and contact forms.

When homepage vs inner page speed diverges dramatically, it almost always points to one of three root causes: selective caching, missing critical CSS on secondary pages, or JavaScript that wasn’t fully deferred beyond the homepage. Understanding which one (or which combination) is affecting your site is the first step in any page speed troubleshooting process.

Why Caching Alone Doesn’t Solve the Inner Page Problem

HTML caching is the single biggest performance lever for WordPress sites. When a page is cached, the server skips PHP processing, database queries, and plugin execution and just delivers a flat HTML file. That’s why cached pages feel instant.

But here’s the catch: most plugins only cache pages that have been visited. If your homepage gets 10,000 visits a day and your blog posts get 50 each, the homepage cache is always warm and fresh. Inner pages may be serving stale, expired, or entirely uncached responses to every new visitor.

This is a textbook cache inconsistency scenario, and it’s the number one culprit behind the homepage vs inner page speed divide.

How BlinkSpeed Fixes Cache Inconsistency Across the Entire Site

BlinkSpeed addresses this with a built-in cache preloader that systematically visits and caches every URL on your site, not just the homepage. The preloader works with a configurable rate limiter (1 to 12 pages per minute), so it doesn’t hammer your server while building out the full cache.

Two caching modes are available:

• .htaccess-based caching is the fastest method. The server delivers cached HTML before PHP even loads, making it completely independent of WordPress execution.
• PHP drop-in caching via advanced-cache.php is compatible with more hosting environments and is still dramatically faster than uncached page loads.

Both modes support cache expiry controls (default: 1 hour), automatic invalidation when content is updated, and the ability to cache pages with GET parameters critical for WooCommerce filter pages and search result pages that most plugins ignore entirely.

Critical CSS Pages: The Hidden Reason Inner Pages Feel Slower

Even when a page is fully cached, it can still feel slow. That perception of slowness often comes from render-blocking CSS stylesheets that prevent the browser from painting anything on screen until they’ve fully downloaded and parsed.

The fix is critical CSS: a technique where only the styles needed to render the above-the-fold content are inlined directly into the HTML. The rest of the stylesheet loads asynchronously, after the initial paint. The result is a dramatically faster perceived load time, because the user sees content almost immediately.

Here’s the problem most plugins create: they generate critical CSS only for the homepage.

Your homepage has a hero section, a navigation bar, and maybe a featured section. The critical CSS generated for that layout is useless on a blog post page, which has a different header structure, a post body, a sidebar, and a comments section. When the same homepage critical CSS is applied across critical CSS pages site-wide, inner pages either render with broken above-the-fold styling or fall back to loading the full stylesheet synchronously, killing performance.

BlinkSpeed’s Per-URL Critical CSS Generation

BlinkSpeed solves this by generating unique critical CSS for every individual URL on your site. Each page gets its own inlined stylesheet based on its actual above-the-fold viewport, not a one-size-fits-all approximation borrowed from the homepage.

In the free version, critical CSS generation is limited to the homepage for evaluation. Upgrading to a license key unlocks critical CSS generation for every page, post, product, and archive on your site, which is where the real performance gains live for most WordPress sites.

JavaScript Deferral That Goes Beyond the Homepage

Another common source of inner page slowness is JavaScript that was deferred or lazy-loaded on the homepage but loads normally on inner page templates.

This happens because some plugins apply JS optimization rules based on the homepage URL or specific page conditions, leaving other page templates untouched. For visitors landing directly on a blog post or product page, they experience the full weight of unoptimized JavaScript even though the homepage looks perfectly optimized.

BlinkSpeed applies JavaScript minification, combination, and lazy-loading globally across all page types. It also handles a technique most plugins overlook entirely: externalizing inline <script> blocks into separate cached files. Large blocks of inline JavaScript inflate your HTML document size and cannot be cached by the browser independently. By moving them to external URLs, BlinkSpeed reduces DOM size and allows the browser to cache those scripts across page navigations, something that directly benefits inner pages on repeat visits.

Image Optimization and Lazy Loading on Inner Pages

Product pages, blog posts, and portfolio pages carry far more images than a typical homepage. A homepage might have three to five images. An e-commerce category page might have forty. A blog post with inline graphics might have fifteen.

If image optimization stops at the homepage, the pages that need it most go unoptimized.

BlinkSpeed’s lazy loading applies to images, iframes, videos, and audio elements across all page types. WebP conversion via the BlinkSpeed cloud API (rest.blinkspeed.ai) is available for the first 500 images on the free tier and extends to all pages with an active license.

Responsive image serving is also included: smaller image variants are delivered to mobile visitors instead of forcing a phone to download a 2,000-pixel-wide desktop image. This is especially impactful on inner pages with image-heavy content.

The AI Optimization Module: Full-Site Page Speed Troubleshooting, Automated

Manual page speed troubleshooting on a site with hundreds of pages is exhausting. You’d need to test each URL, identify what’s missing, apply fixes individually, and verify results, rinse and repeat.

BlinkSpeed’s AI Optimization module automates this process across your entire site. It works through every URL in your sitemap, processes pages in configurable batches, and applies critical CSS generation, cache warming, and image optimization without manual intervention. Each URL is tracked with a status label (Pending, In-Progress, Error, Done) so you can see exactly where the process stands.

This is particularly powerful for sites where the homepage vs inner page speed gap is wide because it systematically closes that gap across every URL rather than leaving you to chase individual pages one by one.

Web Vitals Monitoring: Measure Inner Pages, Not Just the Homepage

You can’t fix what you don’t measure. Most site owners run a PageSpeed Insights test on their homepage, get a passing score, and call it done. Their inner pages never get tested.

BlinkSpeed includes built-in Core Web Vitals monitoring using Google’s official web-vitals library. LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), FID/INP (Interaction to Next Paint), and TTFB (Time to First Byte) are logged per URL in your WordPress database.

This gives you a comparative view across page types. You can see at a glance whether your blog posts score differently from your homepage, whether your WooCommerce product pages have a CLS problem your homepage doesn’t, and where your TTFB spikes on inner pages indicate a cache miss.

This kind of per-URL visibility is what transforms page speed troubleshooting from guesswork into a data-driven process.

Cache Invalidation Without Breaking Inner Pages

One underappreciated cause of cache inconsistency is aggressive or broken cache invalidation. Some plugins clear the entire site cache every time any post is updated. On a busy blog or WooCommerce store, this means your cache is constantly being wiped, leaving most inner pages unprotected for minutes at a time while the cache rebuilds.

BlinkSpeed’s invalidation logic is surgical. When a post is updated, only the cache for that specific URL, plus related archive and category pages, is cleared. The rest of your site cache remains intact and serves fast responses. Combined with the preloader automatically rebuilding cleared pages, you get continuous coverage rather than periodic total cache wipes.

Every cache-clearing action is also recorded in BlinkSpeed’s audit log (wp_blinkspeed_change_logs), capturing the timestamp, the user who triggered it, their IP address, and exactly which setting or URL was affected. For multi-author or multi-admin sites, this eliminates the mystery of who cleared the cache and why inner pages suddenly went slow.

Hosting Compatibility and Inner Page Variability

Not all hosting environments behave the same way. Some managed WordPress hosts (Kinsta, WP Engine, Flywheel) run their own server-side caching layers that can conflict with plugin-level caching. In these environments, .htaccess rules may be disabled, and PHP drop-in cache files may be overridden by the host’s own system.

BlinkSpeed includes a Hosting.php compatibility layer that detects your hosting environment and adjusts its caching behavior accordingly. On hosts where .htaccess caching is unavailable, it falls back to PHP-mode caching. This prevents a common situation where the homepage (which the host may have cached separately) loads fine while inner pages served by a conflicting or absent plugin cache load slowly.

FAQs

Q1. Why does my homepage score 95 on PageSpeed, but my blog posts score 55?

This is a classic homepage vs inner page speed problem. It almost always comes down to cache inconsistency (inner pages aren’t being cached or preloaded), missing per-page critical CSS (the wrong styles are being inlined), and JavaScript that isn’t being deferred on inner page templates. BlinkSpeed addresses all three issues with site-wide caching, per-URL critical CSS generation, and global JS optimization.

Q2. How does BlinkSpeed fix cache inconsistency across inner pages?

BlinkSpeed preloads your full site cache by systematically visiting every URL and storing a flat HTML copy. Combined with automatic invalidation that only clears affected URLs (not the entire cache), inner pages stay protected and fast, not just the homepage.

Q3. What are critical CSS pages, and why do they matter for inner pages?

Critical CSS pages are pages with their own unique above-the-fold CSS inlined directly in the HTML, allowing the browser to paint visible content before loading the rest of the stylesheet. Without per-page critical CSS, inner pages with different layouts than the homepage either render unstyled or wait for full stylesheet loading making them feel much slower.

Q4. Can I do page speed troubleshooting across my entire WordPress site without testing each page manually?

Yes. BlinkSpeed’s AI Optimization module automates site-wide optimization. It processes every URL in your sitemap in configurable batches, applies critical CSS, warms the cache, and tracks per-URL status, eliminating the need for manual page-by-page troubleshooting.

Q5. Does BlinkSpeed’s image optimization apply to inner pages too?

Yes. WebP conversion, lazy loading for images and iframes, and responsive image serving all apply globally across your entire site, not just the homepage. The free tier covers up to 500 images; a license key removes that limit for full-site coverage.

Q6. Why do my inner pages get slower after I publish a new post?

This is typically caused by a full-site cache purge triggered by your optimization plugin when content changes. BlinkSpeed uses surgical cache invalidation, only clearing the cache for the updated URL and its related archives so the rest of your site stays cached and fast after every publish.

Q7. How can I track which inner pages are causing my WordPress speed issue?

BlinkSpeed’s built-in Web Vitals monitoring logs LCP, CLS, INP, and TTFB per URL. You can review the data inside your WordPress admin to identify exactly which inner pages underperform compared to your homepage, giving you a targeted starting point for page speed troubleshooting.

The post BlinkSpeed Inner Pages Slow: Why Your Homepage Loads Fast but Inner Pages Stay Slow appeared first on Blinkspeed.

This guide covers exactly how BlinkSpeed’s GZIP setup works, every reason it can fail to apply, the exact error message to look for, and the steps to resolve each situation.

How BlinkSpeed Enables GZIP Compression

Go to BlinkSpeed → HTML Caches and toggle on ‘Enable GZIP Compression’. When you save, BlinkSpeed writes a block into your site’s root .htaccess file delimited by # BEGIN BSGzip and # END BSGzip. The block contains Apache’s mod_deflate directives that instruct the server to compress specific content types before sending them to the browser.

The exact MIME types BlinkSpeed compresses include:

• text/html – your page HTML
• text/css – all stylesheet files
• text/javascript and application/javascript and application/x-javascript – all script files
• text/plain and text/xml and application/xml and application/xhtml+xml – plain text and XML feeds
• application/rss+xml – RSS feed output
• image/svg+xml – SVG graphics
• application/x-font-ttf, application/vnd.ms-fontobject, font/opentype, font/ttf, font/eot, font/otf, x-font/ttf – web font formats

It also registers the MIME types for .woff and .ttf fonts using AddType before the compression directives, ensuring they are recognised correctly by Apache before the AddOutputFilterByType rules apply.

The entire block is wrapped in an <IfModule mod_deflate.c> conditional, which means the rules only activate if Apache’s mod_deflate module is present and loaded. If the module is absent, the block exists in .htaccess but does nothing – it does not cause errors, but it also does not compress anything.

How BlinkSpeed Validates the GZIP Setup Before Applying It

BlinkSpeed does not blindly write the GZIP block into .htaccess – it runs a validation test first. When you save the GZIP setting, BlinkSpeed:

1. Creates a temporary .htaccess file and a small PHP test file inside a temp/ subdirectory of the cache folder
2. Sends an HTTP HEAD request to that test file using WordPress’s own wp_remote_head() function
3. Reads the HTTP response code

If the response is a 500-level error, the validation fails. BlinkSpeed concludes that the .htaccess rules are causing a server error on your specific hosting environment, automatically removes the gzip key from the saved settings, and displays an admin notice:

If you see this notice, GZIP compression has not been applied – the setting was reverted automatically to protect your site from a broken server state.

GZIP Issue 1 – The Error Notice: “Unable to Apply .htaccess Gzip Rules”

This is the most direct BlinkSpeed GZIP issue. The error appears in the WordPress admin after saving settings, and it means the validation test described above returned a 500-level response.

Cause A – Apache’s mod_deflate Module Is Not Enabled

The GZIP block is wrapped in <IfModule mod_deflate.c>, but BlinkSpeed’s validation step checks whether the .htaccess rules cause a 500 error – not whether they actually produce compression. On some servers where mod_deflate is disabled but .htaccess processing itself causes a server error (because AddOutputFilterByType is not a permitted directive in the .htaccess context), the validation fails.

How to confirm: Ask your hosting provider whether mod_deflate is enabled on your account. On cPanel-based hosting, this is typically listed under Software → Apache Modules. On managed hosting platforms, check the hosting provider’s knowledge base.

Fix: Ask your hosting provider to enable mod_deflate. This is a standard Apache module available on virtually all shared and VPS hosting plans and is typically enabled by default. If you are on a managed or locked-down hosting environment, this may require contacting support.

Cause B – .htaccess Is Not Writable

BlinkSpeed writes the GZIP block to .htaccess during the save process. If the .htaccess file in your site’s root directory is not writable by the web server user, the write fails and nothing is applied.

How to check: Connect to your server via FTP or your hosting file manager and check the permissions on your root .htaccess file. The correct permission is typically 644 – readable by all, writable only by the owner.

Fix: Change the .htaccess permission to 644. After doing so, go to BlinkSpeed → General Settings and click Save – this triggers BlinkSpeed to attempt writing its rules again.

Cause C – AllowOverride Is Set to None

Apache’s AllowOverride directive controls whether .htaccess files are allowed to override server settings for a given directory. If AllowOverride None is set in the server configuration for your site’s document root, Apache ignores your .htaccess entirely, and any HTTP request that would trigger a blocked .htaccess directive may return a 500 error instead.

How to check: This is a server-level configuration setting, not something visible in WordPress or via FTP. Ask your hosting provider or, if you manage your own server, check the <Directory> block for your site’s document root in Apache’s virtualhost configuration file.

Fix: Change AllowOverride None to AllowOverride All for your document root directory in the Apache configuration. If you are on shared hosting, ask your hosting provider – most correctly configure AllowOverride All by default, but some restrictive hosting environments limit it.

Cause D – The Server Is Running Nginx, Not Apache

BlinkSpeed’s GZIP implementation is Apache-specific – it uses mod_deflate directives written to .htaccess. Nginx does not process .htaccess files at all, so on Nginx servers the rules are written but have no effect, and depending on the Nginx + PHP-FPM configuration, the validation test may return a 500 error.

Fix: On Nginx, GZIP compression should be configured at the server level in the Nginx virtualhost configuration file (nginx.conf or a site-specific .conf file), not through WordPress plugins. Add gzip on; and the appropriate gzip_types directive to your Nginx config and reload Nginx – this is the correct compression setup guide approach for Nginx environments. Alternatively, many managed Nginx hosting platforms (Kinsta, WP Engine, Cloudways) enable GZIP by default at the server level, in which case BlinkSpeed’s .htaccess GZIP setting is simply redundant rather than broken, and you can leave it disabled while still benefiting from GZIP.

GZIP Issue 2 – The Setting Is Enabled and Shows No Error, But GZIP Is Still Not Working

This is the most confusing scenario: the GZIP toggle is on, no error message appeared when you saved, but a PageSpeed Insights test or GTmetrix still flags “Enable text compression” or shows your HTML arriving uncompressed.

Cause A – The # BEGIN BSGzip Block Is Missing from .htaccess

Even without a visible error, the block may not have been written. This can happen if .htaccess was replaced or regenerated by another plugin (a security plugin rewriting .htaccess, a migration plugin restoring a previous version, or another caching plugin overwriting the file) after BlinkSpeed last saved its rules.

How to check: Open your .htaccess file via FTP or your hosting file manager and look for # BEGIN BSGzip. If the block is absent, BlinkSpeed’s GZIP rules are not active.

GZIP compression fix: Go to BlinkSpeed → General Settings and click Save (no changes required – just saving triggers BlinkSpeed to rewrite all its .htaccess blocks). Check the file again to confirm # BEGIN BSGzip is now present.

Cause B – Another Plugin’s .htaccess Block Is Overriding BSGzip

Multiple plugins write to .htaccess and the order of their blocks matters. If a security plugin or another caching plugin’s rules appear before # BEGIN BSGzip and include directives that prevent mod_deflate from running for specific content types, BlinkSpeed’s compression rules may be negated.

How to check: Open .htaccess and check what appears above and below the # BEGIN BSGzip block. Look for any Header always remove Accept-Encoding directives or mod_deflate remove-filter rules from other blocks.

Fix: If a conflicting block is present, identify which plugin generated it and check whether that plugin has a setting to remove or disable that specific .htaccess rule. Deactivating a conflicting caching plugin that also manages GZIP rules (as described in the plugin conflict guide) resolves this without any direct .htaccess editing.

Cause C – A CDN or Proxy Is Stripping the Encoding

If your site sits behind a CDN (Cloudflare, BunnyCDN, KeyCDN) or a reverse proxy, the CDN may be decompressing the GZIP response from your origin server and then serving the asset to visitors uncompressed – particularly if the CDN’s own compression is disabled or if the CDN is caching uncompressed versions of your files.

How to check: In Chrome DevTools, go to the Network tab, click any HTML or CSS request, and look at the Response Headers. Look for content-encoding: gzip. If it is absent on a request that went through your CDN, but present on a direct request to your origin server (bypass Cloudflare by connecting to your server’s IP directly in DevTools), the CDN is stripping the encoding.

Fix: In Cloudflare, go to Speed → Optimization and confirm Auto Minify is enabled and Brotli is on (Cloudflare handles compression at the edge and may override origin GZIP with Brotli, which is fine – Brotli is better than GZIP). If your CDN is serving uncompressed files from its cache, purge the CDN cache after confirming GZIP is active on the origin, so the CDN re-fetches and caches the compressed version.

Cause D – The Test Tool Is Bypassing the Cache

PageSpeed Insights and some other compression testing tools send requests that bypass your HTML cache (using a unique query string to avoid receiving a cached response). If the uncached, dynamically rendered HTML is tested but the .htaccess GZIP rules are only applied correctly to static files and not to the dynamic PHP output path, the tool may see uncompressed HTML.

Fix: Ensure PHP output compression is also configured if you rely on dynamic page delivery. For most BlinkSpeed setups using .htaccess static file delivery, the compression applies at the file-serving level and should cover both cached and uncached responses. If your server delivers PHP responses outside the .htaccess context (common on Nginx or certain managed hosting configurations), enable compression at the server level as described in Cause D above.

GZIP Issue 3 – Some File Types Are Compressed But Others Are Not

PageSpeed Insights specifically identifies which file type is uncompressed. If HTML is compressed but CSS or JavaScript files are not (or vice versa), the issue is usually one of two things.

Cause A – Files Are Being Served from the Cache With Incorrect Headers

BlinkSpeed stores cached versions of JS and CSS files in wp-content/cache/bs-cache/. When Apache serves these static cached files, the GZIP rules should still apply – but if the cached files are being served by a Location-based rule that bypasses the htaccess context for static files, mod_deflate may not run.

Fix: Confirm the # BEGIN BSGzip block appears before any other cache delivery rules in your .htaccess. BlinkSpeed writes its GZIP block at the top of .htaccess above other blocks, which means it runs first. If another plugin has moved its own block above # BEGIN BSGzip, the ordering may prevent GZIP from applying to files served by the other plugin’s rules.

Cause B – Font File MIME Types Not Registered

BlinkSpeed explicitly adds AddType x-font/woff .woff and AddType x-font/ttf .ttf before the compression directives, but on some servers, older font MIME types are not registered at the system level. This means web font files may not be compressed even though the AddOutputFilterByType rule for font types is present.

Fix: This is a server administration task – ask your hosting provider to confirm that font MIME types are registered in Apache’s MIME type configuration file, or add the AddType declarations manually to .htaccess if you have access.

Verifying GZIP Is Working After the GZIP Compression Fix

After applying a fix, confirm GZIP is active before considering the issue resolved.

Using Chrome DevTools:

1. Open DevTools (F12) → Network tab
2. Filter by Doc (for HTML) or CSS/JS
3. Reload the page
4. Click any request and look at Response Headers
5. Confirm content-encoding: gzip or content-encoding: br (Brotli) is present

Using an online GZIP test tool: Tools like GiftOfSpeed GZIP test (giftofspeed.com) or the Check GZIP Compression checker allow you to enter any URL and see whether the response is compressed, what encoding is used, the original file size, and the compressed file size. These tools are useful for confirming compression on specific file types that DevTools can be harder to read.

Using PageSpeed Insights after the fix: Run the PageSpeed Insights test again on your homepage and check whether “Enable text compression” has been removed from the Opportunities section. Note that you need to clear BlinkSpeed’s cache and wait for a fresh page generation before testing – a cached page from before the GZIP fix was applied will not reflect the new compression state until the cache is rebuilt.

GZIP and Leverage Browser Cache Together

BlinkSpeed writes two related .htaccess blocks side by side: # BEGIN BSGzip (compression) and # BEGIN BSLbc (Leverage Browsing Cache). Both use Apache module directives – mod_deflate for GZIP and mod_expires or mod_headers for browser cache. The same server conditions that prevent GZIP from working (mod_deflate disabled, AllowOverride None, Nginx environment) often affect both features simultaneously.

If you see the GZIP notice error after saving, check whether the Enable Leverage Browsing Cache setting also reverted. Both validate using the same blinkspeed_check_htaccess_status() function, so the same underlying server configuration issue will cause both to fail. Resolving the root cause – enabling the Apache module, fixing the AllowOverride setting, or switching to server-level configuration on Nginx – fixes both at the same time.

GZIP Settings Reference

Frequently Asked Questions Related to BlinkSpeed GZIP Issue

Q1. Why does BlinkSpeed show GZIP as enabled but PageSpeed Insights still flags it?

The most common reason is that the # BEGIN BSGzip block was written to .htaccess successfully, but the Apache module mod_deflate is not loaded on your server – so the block exists but does nothing. Open .htaccess and confirm the # BEGIN BSGzip block is present, then ask your hosting provider to confirm whether mod_deflate is enabled. A second common reason is a CDN in front of your site stripping the Content-Encoding header before PageSpeed Insights sees the response.

Q2. What is the difference between GZIP and Brotli, and does BlinkSpeed support Brotli?

GZIP uses the DEFLATE algorithm and is supported by virtually every server and browser since the early 2000s. Brotli is a newer algorithm that typically achieves 15–20% better compression than GZIP on the same content. BlinkSpeed’s compression setup guide uses GZIP via Apache’s mod_deflate – it does not currently add Brotli directives. If your CDN (such as Cloudflare) or hosting server supports Brotli natively, you will see content-encoding: br in DevTools instead of content-encoding: gzip – this is a better outcome than GZIP alone and does not mean GZIP is broken.

Q3. My .htaccess file is read-only. Can I still use BlinkSpeed GZIP compression?

If .htaccess is read-only, BlinkSpeed cannot write its GZIP block, and the validation test will fail or the write will silently not occur. On shared hosting, your .htaccess should be set to 644 (owner writable, group and other read-only) – most hosts set this correctly by default. On managed hosting platforms that manage .htaccess themselves (some Nginx-based platforms do not use .htaccess at all), enable GZIP at the hosting control panel level or contact support to confirm whether GZIP is already enabled at the server level.

Q4. Can I manually add GZIP rules to .htaccess instead of using BlinkSpeed’s setting?

Yes. If BlinkSpeed’s automatic GZIP setup is failing due to server validation issues but you know mod_deflate is available, you can add the compression block manually. However, note that BlinkSpeed rewrites .htaccess on every Save in the plugin settings, and it uses # BEGIN BSGzip / # END BSGzip markers to identify its own block. If you add rules outside these markers, BlinkSpeed will not interfere with them. If you add them between the markers, BlinkSpeed may overwrite them on the next save. The safest approach is to add your custom GZIP rules under a different block name that BlinkSpeed does not manage.

Q5. Does enabling GZIP in BlinkSpeed affect my server’s performance?

GZIP compression adds a small amount of CPU overhead on the server side to compress each response. For text-based files (HTML, CSS, JS) this overhead is negligible – the CPU time to compress a 100KB CSS file is microseconds, while the reduction in transfer time over the network is measurable milliseconds or even tens of milliseconds on slower connections. The performance trade-off strongly favours enabling GZIP for almost every hosting environment and traffic volume. The only scenario where you might not want it is on a server running at extremely high CPU capacity already, where any additional load is problematic – but in that case, server optimization at the infrastructure level is the right fix rather than skipping GZIP.

Q6. My site is on Nginx and I can’t enable GZIP through BlinkSpeed. What do I do?

Enable GZIP directly in your Nginx configuration file. Add the following to your Nginx server block or nginx.conf file:

Then reload Nginx with sudo nginx -s reload or sudo systemctl reload nginx. Once GZIP is active at the server level, you do not need BlinkSpeed’s .htaccess GZIP setting enabled – the compression happens regardless of what BlinkSpeed does, and you will see content-encoding: gzip in DevTools confirming it is working.

Q7. After enabling GZIP, do I need to clear BlinkSpeed’s cache?

Yes. BlinkSpeed’s cached HTML, CSS, and JS files were generated and stored before GZIP was enabled. Clearing the cache and allowing them to be regenerated does not itself affect whether GZIP is applied – GZIP compression happens at the Apache level when the file is served, not when the file is cached. However, clearing the cache and retesting is good practice after any settings change to ensure your test results reflect the current configuration rather than a cached page from before the change was applied.

Summary

BlinkSpeed’s GZIP compression setup is a single toggle that writes Apache mod_deflate directives to .htaccess for fifteen MIME types covering HTML, CSS, JavaScript, XML, SVG, and web fonts. The most common BlinkSpeed GZIP issue is the “Unable to apply .htaccess Gzip rules” error, which means BlinkSpeed’s built-in validation detected a 500-level response when testing the rules – almost always caused by mod_deflate not being enabled, .htaccess not being writable, AllowOverride None in the server config, or running on Nginx where .htaccess has no effect.

If the setting appears enabled with no error but GZIP still is not detected, the block has either been overwritten by another plugin, or a CDN is stripping the encoding before it reaches the testing tool. After any GZIP compression fix, verify with Chrome DevTools’ Response Headers or an online GZIP testing tool, and re-run PageSpeed Insights with a fresh cache to confirm the “Enable text compression” audit has been resolved.

The post How to Diagnose and Fix Every BlinkSpeed GZIP Issue appeared first on Blinkspeed.

Every second counts when a visitor lands on your WordPress site. Browser caching is supposed to make return visits feel like instant loading assets from local memory instead of making the visitor’s browser download the same CSS, JavaScript, and images all over again. When it stops working, those savings disappear quietly, and your speed scores take the hit without an obvious explanation.

If you are running BlinkSpeed and your WordPress browser cache does not seem to be doing anything, you are in the right place. This guide walks through every layer of the problem: what browser caching actually does, why it breaks, how BlinkSpeed handles it, and how to confirm it is working before you close the tab.

What Browser Caching Actually Does and Why It Matters for Your Speed Optimization Setup

When a browser loads your site for the first time, it downloads every asset: stylesheets, scripts, fonts, and images. Browser caching tells the browser to store copies of those files locally and reuse them on the next visit instead of downloading them again.

This is controlled through cache headers sent by your server. The two most important ones are:

• Cache-Control: tells the browser how long to keep the file before checking for a fresh version
• Expires: sets an absolute expiry date for the cached copy

When those cache headers are issued correctly, returning visitors experience dramatically faster load times because most of the page is already sitting on their device. When they are missing or misconfigured, every visit feels like a first visit, and that is the core of most WordPress browser cache complaints.

A proper speed optimization setup addresses this at the server level. That is exactly where BlinkSpeed’s leverage browser caching option fits in.

How BlinkSpeed Handles WordPress Browser Cache

BlinkSpeed includes a dedicated Enable Leverage Browsing Cache toggle inside its HTML Cache settings tab. When enabled, the plugin writes the appropriate cache headers directly into your .htaccess file on Apache servers or applies them through its PHP Cache method as an alternative.

This means you do not need to manually edit server configuration files or touch a single line of Apache or Nginx config. BlinkSpeed resolves the cache headers issue by injecting the correct directives automatically, covering static assets like CSS, JavaScript, fonts, and images served from your domain.

BlinkSpeed also pairs browser caching with two companion settings that make the whole thing work more reliably:

• Enable GZIP Compression: compresses assets before they leave the server, reducing transfer size
• Remove Query Parameters: strips version strings like ?ver=6.5 from resource URLs so browsers and CDNs actually cache them.

All three live in the HTML Cache tab. Turning on browser caching without also removing query strings often leaves assets uncacheable, because many cache layers treat style.css?ver=6.5 as a unique, dynamic URL and refuse to store it.

Step-by-Step BlinkSpeed Browser Cache Setup

Follow these steps in order. Skipping any one of them is usually why the browser caching fix does not hold.

Step 1: Open the HTML Cache Tab

Log in to your WordPress dashboard. Go to BlinkSpeed → HTML Caches from the left admin menu. This is the tab that controls everything related to caching behavior, including your WordPress browser cache settings.

Step 2: Enable HTML Caching First

Before touching browser cache settings, make sure Enable HTML Caching is switched on. BlinkSpeed’s caching stack builds from the bottom up. HTML caching needs to be active for the rest of the performance troubleshooting options to function correctly.

Choose your serving method:

• Htaccess: faster, recommended for most Apache hosts, serves cached files before PHP even loads
• PHP Cache: more compatible across hosts that restrict .htaccess modifications

Step 3: Enable Leverage Browsing Cache

Scroll down to the Enable leverage browsing cache toggle and switch it on. This is the setting that writes long-lived cache headers for static assets, which is what Google PageSpeed Insights and GTmetrix check when they flag browser caching as an issue in their performance troubleshooting reports.

Step 4: Enable GZIP Compression

Directly below the leverage browsing cache, switch on Enable GZIP Compression. This compresses your HTML, CSS, and JavaScript responses at the server level. Smaller files transfer faster, and GZIP is one of the quickest wins in any speed optimization setup.

Step 5: Remove Query Parameters

Enable Remove Query Parameters to strip version strings from CSS and JS URLs. This is one of the most overlooked steps in a browser caching fix. Query strings signal to browsers and intermediate caches that a file might be dynamic, so they skip storing it. Removing them lets the browser cache headers correctly for those files.

Step 6: Set Cache Expiry Time

In the Cache Expiry Time field, the default is 3600 seconds (one hour). For a more aggressive speed optimization setup, increase this to 86400 (one day) or 604800 (one week) for assets that rarely change. The longer the expiry, the fewer server requests returning visitors generate.

Step 7: Enable Preload Caching

Turn on Preload Caching and set the pages per minute rate (between 1 and 12). Preloading warms your cache in the background so visitors never hit an uncached page. This is particularly important after you purge the cache during a plugin update or content change.

Step 8: Enable Clear Cache on Post Update

Switch on Clear Cache when a Page or Post is Updated. This ensures that whenever you publish new content or edit an existing page, the stale cached version is automatically invalidated. Without this, your WordPress browser cache could serve outdated content to visitors even after you have made changes.

Step 9: Save and Purge

Click Save Changes. Then go to the BlinkSpeed menu in your admin bar and click Clear All Cache. This forces fresh asset delivery with the new cache headers applied, so the next visitor loads the correctly headered versions that will then cache properly in their browser.

Performance Troubleshooting: Why Your Browser Caching Fix May Not Be Working Yet

Even after enabling all the right settings, some sites still show cache headers issues in speed testing tools. Here are the most common reasons and how to resolve each one.

Your Hosting Provider Is Overriding Cache Headers

Some managed WordPress hosts, particularly those running their own server-level caching, strip or replace the cache headers BlinkSpeed writes. If your host has its own caching layer (common on WP Engine, Kinsta, Flywheel, and SiteGround), those headers can conflict with or override what BlinkSpeed sets.

Fix: Check your host’s caching documentation. On many managed hosts, you configure browser cache lifetime directly inside the hosting control panel rather than through a plugin. Use BlinkSpeed for HTML caching, CSS and JS optimization, and image handling, and let the host manage browser cache headers at the server level.

HTTPS and Mixed Content Are Blocking Cached Assets

If your site recently moved to HTTPS but some assets still load over HTTP, browsers will block those resources entirely, meaning they will never be cached. This shows up in performance troubleshooting reports as missing or partial caching.

Fix: Make sure all asset URLs in your theme and plugins use HTTPS. BlinkSpeed’s CDN settings can help if you are routing assets through a CDN that handles SSL termination.

A CDN Is Serving Assets Without Proper Cache Headers

If you have connected a CDN inside BlinkSpeed’s CDN settings tab, the CDN’s own cache header configuration takes precedence for assets it serves. The cache headers issue may actually be happening at the CDN edge, not at your origin server.

Fix: Log in to your CDN provider’s dashboard and confirm that static assets have long-lived cache TTL settings configured. Set at least one year (31536000 seconds) for versioned assets.

Query Strings Are Still Appearing on Some Assets

Certain plugins force query strings onto their own CSS and JS files regardless of what BlinkSpeed strips. These files will continue to appear uncacheable in speed reports.

Fix: Use BlinkSpeed’s Exclusions tab to identify and isolate the problematic files. You can exclude specific scripts from optimization while still applying browser caching to everything else.

The Plugin Was Just Installed, and the cache has not been warmed

Speed testing tools measure what they receive in response to their request. If your cache is empty,  right after installation, after a purge, or after the cache expires, the test hits an uncached page, and cache headers may not appear correctly.

Fix: Enable Preload Caching inside the HTML Cache tab and let the preloader warm your pages before running any speed tests. Run the test again once preloading has completed at least one full cycle.

How to Verify Your WordPress Browser Cache Is Working

After completing the setup and fixing any conflicts above, here is how to confirm everything is functioning.

Check with Google PageSpeed Insights

Run your URL through PageSpeed Insights. In the Opportunities and Diagnostics sections, look for any mention of “Serve static assets with an efficient cache policy.” If BlinkSpeed has applied cache headers correctly, this warning should disappear or show significantly improved TTLs across your assets.

Check with GTmetrix

GTmetrix’s Waterfall tab shows every asset request with its cache status. Assets with a long TTL show green cache indicators. If you see assets loading without caching, expand that row to confirm what cache headers the server is returning. Missing Cache-Control or Expires headers confirm a cache headers issue that needs further investigation at the host or CDN level.

Check Raw Headers in Your Browser

In Chrome or Firefox, open Developer Tools (F12) → Network tab. Reload your page and click any CSS or JS asset in the list. Under Headers → Response Headers, look for:

• Cache-Control: max-age=XXXXX
• Expires: [future date]

If those headers are present with a future expiry, your browser caching fix is working. If they are absent or show no-cache, the host or another plugin is interfering.

Use BlinkSpeed’s Web Vitals Logs

Inside BlinkSpeed → Web Vitals Logs, you can monitor Core Web Vitals scores per URL over time. A properly functioning WordPress browser cache improves Time to First Byte (TTFB) and Largest Contentful Paint (LCP) on repeat visits. Watching these scores trend downward after your setup confirms the caching is delivering real-world benefit, not just passing the audit.

BlinkSpeed’s Full Speed Optimization Setup Beyond Browser Caching

Browser caching is one piece of a larger performance troubleshooting picture. BlinkSpeed addresses every other layer of WordPress site speed in parallel:

CSS and JavaScript Optimization reduces file sizes through minification and eliminates render-blocking resources through deferred loading. Combined with browser caching, this means assets are both smaller on first load and instantly available on return visits.

Critical CSS Generation inlines the above-the-fold styles directly into the page so the visible portion renders before the full stylesheet downloads. This directly improves Largest Contentful Paint, one of Google’s Core Web Vitals.

Image Optimization and WebP Conversion reduce the payload of the largest assets on most pages. Paired with lazy loading for images, iframes, video, and audio, most of the page’s weight never loads at all until the visitor actually scrolls to it.

AI Optimization runs across all your site URLs automatically, processing critical CSS and advanced image optimization through BlinkSpeed’s cloud service. It tracks progress per URL with status indicators (Pending, In Progress, Done, Error) so you can see exactly where optimization stands across your entire site.

CDN Integration pushes static assets to edge servers geographically closer to your visitors, reducing the physical distance data travels. Combined with correct cache headers from BlinkSpeed, CDN-served assets are cached both at the edge and in the visitor’s browser.

All of these work together. A browser caching fix that ignores JavaScript optimization still leaves render-blocking scripts slowing down first paint. A speed optimization setup that ignores images still wastes bandwidth on oversized files. BlinkSpeed’s value is that every layer is handled inside one dashboard.

BlinkSpeed Free vs Premium: What Matters for Browser Caching

The good news for the browser caching fix specifically: leverage browser caching, GZIP compression, and query string removal are all available in the free version of BlinkSpeed, working across all pages without requiring a license key.

Here is where the free and premium split matters for your broader speed optimization setup:

For most WordPress browser cache and basic performance troubleshooting needs, the free version covers everything. The premium license becomes worthwhile when you need critical CSS and advanced image optimization running across every page, particularly for content-heavy sites, WooCommerce stores, or anywhere Core Web Vitals scores directly affect business outcomes.

FAQs

Q1. Why does Google PageSpeed still flag browser caching after I enabled it in BlinkSpeed?

The most common reason is a conflict with your hosting provider’s server-level caching. Some managed WordPress hosts control cache headers at the server level and override what plugins write to .htaccess. Check your host’s caching settings panel and confirm whether cache TTLs need to be set there instead of through BlinkSpeed. Also, confirm that Remove Query Parameters is enabled in the HTML Cache tab, as query strings prevent WordPress browser cache headers from applying to many assets.

Q2. Does BlinkSpeed fix the browser caching fix for third-party scripts like Google Analytics or fonts?

No plugin can set cache headers on assets served from external domains. Google Analytics, Google Fonts, Facebook Pixel, and similar third-party scripts are served from their own servers with their own cache headers. BlinkSpeed or any WordPress plugin has no control over those. The performance troubleshooting recommendation for this is to either self-host the scripts locally or accept the flag as a third-party limitation that does not affect your own server’s caching performance.

Q3. What is the recommended cache expiry time for a speed optimization setup?

For static assets like CSS, JS, images, and fonts, most speed optimization setups recommend a minimum of one week (604800 seconds) and ideally one year (31536000 seconds) for versioned files. BlinkSpeed’s default of 3600 seconds is conservative. Increasing it reduces server requests from returning visitors but means visitors see cached versions for longer after you make changes, so pair a longer expiry with BlinkSpeed’s auto-clear on post update feature.

Q4. Should I use Htaccess or PHP Cache mode for WordPress browser cache?

Htaccess is faster because it serves cached HTML before PHP loads, bypassing WordPress entirely. Use this on standard Apache hosting. PHP Cache mode is more compatible on hosts that restrict .htaccess modifications, on Nginx servers, or on managed WordPress platforms that handle rewrite rules at the server level. If you are unsure which your host uses, start with Htaccess and check if cache headers are issued correctly using browser developer tools. Switch to PHP Cache if headers are missing.

Q5. Does enabling BlinkSpeed browser cache settings conflict with other caching plugins?

Running two full caching plugins simultaneously, for example, BlinkSpeed alongside WP Rocket or W3 Total Cache, typically causes conflicts and unpredictable behavior. Choose one caching plugin and disable the caching features in the other. BlinkSpeed is designed to be a complete speed optimization setup on its own, so running it alongside another full-stack cache plugin is unnecessary and likely to cause the exact cache headers issue you are trying to fix.

Q6. My cache headers are showing correctly in developer tools, but GTmetrix still flags it. Why?

GTmetrix measures the first request from its test server, which hits an uncached page if your cache is cold. Enable BlinkSpeed’s Preload Caching to warm the cache before running the test. Also, confirm that the specific assets GTmetrix is flagging are not being served from a CDN or external domain that has its own cache configuration. Performance troubleshooting with GTmetrix is most accurate when you run the test multiple times and compare results. First-run scores often differ from repeat-visit scores that reflect actual browser caching behavior.

Q7. Will enabling browser caching break my site if I update plugins or themes?

Not if you enable Clear Cache when a Page or Post is updated inside BlinkSpeed’s HTML Cache settings. For plugin and theme updates specifically, manually purge cache from the BlinkSpeed admin bar immediately after updating. This ensures visitors receive the freshest assets with the updated code. The browser caching fix stores files locally in visitors’ browsers, so a manual purge from your end clears BlinkSpeed’s server-side cache; the visitor’s local browser cache refreshes automatically when the asset URLs change, or their cached copy expires.

The post BlinkSpeed Browser Cache Issue? Here’s the Complete Setup Guide to Fix It appeared first on Blinkspeed.

None of these means lazy loading should be turned off. They mean one specific part of BlinkSpeed’s lazy load system needs a small adjustment. This guide walks through every lazy load problem you might encounter, explains exactly why it happens, and gives you the precise setting to fix it – covering images, iframes, video, audio, and the JavaScript lazy load system together, since they often interact with each other.

How BlinkSpeed’s Lazy Load System Actually Works

Understanding the mechanism makes every fix in this guide make sense immediately.

When BlinkSpeed processes your page, it looks at each image, iframe, video, and audio element. For most images, BlinkSpeed replaces the src attribute with a tiny blank placeholder image and moves the real image URL into a data-src attribute, also adding a data-class=”LazyLoad” marker. A small JavaScript file then watches the page using the Intersection Observer API – a browser feature that detects when an element is about to enter the visible viewport – and swaps the real data-src value back into src at the right moment.

For some images, BlinkSpeed instead uses the browser’s own native lazy loading by adding loading=”lazy” directly to the image tag, letting the browser itself decide when to fetch the image without any JavaScript involved.

Background images set via inline CSS (style=”background-image:url(…)”) are handled differently again – BlinkSpeed marks their parent container with a data-bglz=”1″ attribute so the lazy load script knows to treat that element’s background image the same way as a regular image.

This means a WordPress image issue with lazy loading could be coming from three different mechanisms depending on how the image was implemented – and the fix is different for each one.

Lazy Load Problem 1 – Images Never Load Even After Scrolling Past Them

This is the most disruptive image lazy load problem because it leaves visible gaps on the page where content should be.

Cause A – The Lazy Load Script Itself Is Not Running

The JavaScript responsible for swapping data-src into src has to load and execute for lazy loading to work at all. If this script is blocked, delayed indefinitely, or throws an error, every lazy-loaded image on the page will remain blank forever.

How to check: Open your browser’s Developer Tools (press F12), go to the Console tab, and reload the page. Look for any red error messages. Then go to the Network tab, filter by JS, and confirm the lazy load script is present in the list of loaded files with a 200 status rather than a 404 or a blocked request.

Common causes of this specific lazy load troubleshooting scenario:

• A Content Security Policy header on your server blocking inline or external scripts
• A conflicting plugin’s JavaScript error stopping the page’s script execution partway through
• An ad blocker or privacy browser extension blocking the script because its filename or path matches a blocklist pattern

Fix: If a CSP header is the cause, add the lazy load script’s path to your script-src allowlist. If a plugin conflict is the cause, go to BlinkSpeed → Exclusions → JS Exclusions and identify which script is throwing the error using DevTools, then exclude it with the defer modifier so it does not interfere with the rest of the page’s JavaScript execution.

Cause B – The Image’s data-src Attribute Was Stripped by Another Plugin

Some plugins – particularly minifiers, optimisers, or security plugins that sanitise HTML output – can strip non-standard attributes from HTML tags, including the data-src and data-class attributes BlinkSpeed relies on. If the attribute holding the real image URL is removed before BlinkSpeed’s script can read it, the image has nothing to load.

How to check: In DevTools, go to the Elements panel, find the blank image element, and inspect its attributes. If you see only a src attribute pointing to a blank placeholder and no data-src attribute at all, something has stripped it.

Fix: Identify the other plugin modifying HTML output (commonly another optimisation, minification, or security plugin) and either disable its HTML sanitisation feature for image tags or deactivate the conflicting plugin, since running two plugins that both rewrite image tags creates this kind of WordPress image issue.

Cause C – The Image Element Is Inside a Dynamically Loaded Container

If a page builder, AJAX-driven product gallery, or infinite-scroll script injects new images into the page after the initial load, BlinkSpeed’s lazy load observer – which is set up once when the page first loads – may not be aware of these newly added elements, since they were not present in the HTML when the observer was created.

Fix: This is a known limitation of any lazy load system that observes the DOM at load time. If your page injects images dynamically, check whether the plugin responsible for the dynamic content has its own lazy loading or image-loading mechanism already, and exclude those specific images from BlinkSpeed’s lazy load using BlinkSpeed → Exclusions → Media Exclusions → Exclude Media from Lazy Loading, letting the other plugin manage those images directly.

Lazy Load Problem 2 – Content Shifting Fix: Layout Jumps as Images Load

This is one of the most common complaints connected to lazy loading, and it directly affects your Cumulative Layout Shift (CLS) score – one of Google’s Core Web Vitals.

Why It Happens

When an image’s src is replaced with a placeholder, the browser needs to know how much space to reserve for that image before the real content loads in. If the image tag does not have explicit width and height attributes (or CSS that defines its aspect ratio), the browser may render it at a different size than the final image, causing surrounding content to shift up or down the moment the real image swaps in.

This is not unique to BlinkSpeed – it is a fundamental characteristic of lazy loading in general – but it becomes visible specifically because lazy loading delays exactly the moment when this size mismatch would occur.

The Content Shifting Fix

Step 1:

Check whether your images have explicit dimensions. Open DevTools, inspect an image that causes a visible jump, and look for width and height attributes on the <img> tag. WordPress adds these automatically for images inserted through the Media Library, but custom theme code, page builder widgets, or manually written HTML often omit them.

Step 2: 

Add missing dimensions at the source. If you control the theme or template code, add explicit width and height attributes (or a CSS aspect-ratio property) to any image missing them. This is the most durable content shifting fix because it solves the underlying issue rather than working around it.

Step 3:  

For images you cannot edit directly, use CSS to reserve space. Apply a min-height or aspect-ratio rule via your theme’s custom CSS targeting the specific image’s container class, so the layout does not collapse before the lazy-loaded image arrives.

Step 4: 

Check inline background images specifically. Background images using the data-bglz lazy load mechanism are particularly prone to CLS because their containing element (a <div> or <section>) often has no defined height of its own – the background image was providing the visual height, but the container itself collapses to zero height until the background loads. Add an explicit min-height to any container using a lazy-loaded background image.

Never Lazy Load Your LCP Element

The single most damaging mistake connected to both content shifting and overall page speed is lazy loading the page’s Largest Contentful Paint (LCP) element – typically a hero image or banner visible without scrolling. Lazy loading intentionally delays this element, which directly worsens your LCP score and can also cause a layout shift as it pops in late.

Go to BlinkSpeed → Exclusions → Media Exclusions → Exclude Media from Lazy Loading and add a matching string for your LCP image – its CSS class, ID, or a fragment of its file URL. Excluded images are not just skipped from lazy loading; BlinkSpeed actively adds fetchpriority=”high” and loading=”eager” to the tag and inserts a <link rel=”preload”> reference for it, telling the browser to fetch this specific image before anything else.

Lazy Load Problem 3 – Sliders, Galleries, and Carousels Show Blank Images

JavaScript-powered sliders and galleries frequently manage their own image loading logic. When BlinkSpeed’s lazy load system intercepts the same image tags, the two systems can conflict – the slider’s JavaScript looks for a real src value to initialise its slides, finds the blank placeholder BlinkSpeed inserted instead, and either breaks or displays nothing.

The fix: Go to BlinkSpeed → Exclusions → Media Exclusions → Exclude Media from Lazy Loading. Click Add Rule and enter a matching string that identifies the slider or gallery’s images – this can be a CSS class name shared by all the slider’s image tags (such as swiper-slide-image or rev-slidebg), or a URL fragment if the images come from a specific folder.

Once excluded, those images load through their original src attribute exactly as the slider plugin expects, while every other image on the page continues to benefit from lazy loading.

Lazy Load Problem 4 – Lazy Load JavaScript Conflicts With Other Scripts

Separate from image lazy loading, BlinkSpeed also has a JavaScript lazy load system (under JavaScript Optimization → Lazyload Javascript) that delays script execution until the user interacts with the page. When both the image lazy load system and the JavaScript lazy load system are active, a specific conflict can occur: the lazy load image script itself gets caught in the JavaScript delay queue, creating a circular problem where the script responsible for loading images is itself waiting for a user interaction that triggers nothing, since no images load to prompt scrolling in the first place.

How to check: In DevTools Elements panel, search the page’s HTML source for type=”lazyJs”. If BlinkSpeed’s own lazy load image script appears with this type attribute, it has been caught in its own JavaScript delay system.

Fix: Go to BlinkSpeed → Exclusions → JS Exclusions → Exclude Javascript from Lazyload and add the lazy load script’s filename with no modifier, so it always executes immediately:

img-lazyload.js

This ensures the script responsible for swapping in your real images is never itself delayed, while all other site scripts continue to benefit from the JavaScript lazy load improve loading speed strategy.

Lazy Load Problem 5 – Iframes, Video, and Audio Not Loading

The same data-bglz-style deferred loading approach BlinkSpeed uses for images also applies to iframes (commonly Google Maps and YouTube embeds), video elements, and audio elements. Each has its own specific failure pattern.

A. Iframes Showing Blank (Maps, YouTube Embeds)

BlinkSpeed replaces YouTube iframe embeds with a lightweight placeholder showing the video thumbnail, loading the actual YouTube iframe only when the visitor clicks. If this placeholder itself does not appear, check whether the embed code uses a non-standard iframe wrapper that BlinkSpeed’s detection pattern does not recognise – some page builders wrap iframes in custom container elements with additional attributes that interfere with detection.

Fix: If a specific map or video embed is not displaying its lazy load placeholder correctly, add its container to Exclude Media from Lazy Loading using a class name or ID specific to that embed, allowing it to load through its original method instead.

B. Video Elements Not Auto-Playing as Expected

If you have a video set to autoplay on page load but it is being lazy loaded, the autoplay behaviour will not trigger until the visitor scrolls to it – which defeats the purpose of autoplay entirely.

Fix: Exclude the specific video element from lazy loading via its CSS class or source URL fragment, since autoplay videos are, by definition, meant to be visible and active immediately rather than deferred.

C. Audio Players Showing No Controls or Failing to Load

Audio players embedded via HTML5 <audio> tags follow the same lazy load pattern as video. If a podcast player or audio widget shows no controls at all, the lazy load placeholder swap may not be completing.

Fix: Check DevTools Console for script errors as described in Lazy Load Problem 1, then exclude the specific audio player’s container if the issue persists after confirming the lazy load script itself is running correctly.

Lazy Load Troubleshooting Decision Table

Use this table as a fast reference for matching your specific symptom to the right fix:

Frequently Asked Questions Related to Fix BlinkSpeed Lazy Load Issue

Q1. How do I know if a blank image is a lazy load issue versus a broken image link?

Open DevTools, inspect the blank image element, and look at its src attribute. If it points to a tiny placeholder (often a data:image/svg+xml data URI) and there is a data-src attribute nearby containing the real image URL, this is the lazy load system working as intended and waiting for the image to enter the viewport, or it indicates the swap mechanism is failing if you have already scrolled past it. If instead the src points directly to a real file path that returns a 404 in the Network tab, that is a genuinely broken image link, unrelated to lazy loading.

Q2. Will disabling lazy loading completely fix my image lazy load problem?

It will resolve the symptom, but at the cost of losing the loading speed benefit entirely; all images will load immediately regardless of whether the visitor scrolls to them, increasing initial page weight and slowing down the time to first meaningful render. Disabling lazy loading should be a last resort, used only temporarily while you identify the specific cause. The targeted exclusion-based fixes in this guide let you keep lazy loading active for every image except the specific ones causing trouble.

Q3. Why does my content-shifting fix work on desktop but not mobile, or vice versa?

BlinkSpeed generates separate cached output for mobile and desktop, and your theme or page builder may render different image dimensions or layout structures for each device type. A layout shift that occurs only on mobile usually means a responsive CSS rule is changing the image’s display size on smaller screens without an accompanying aspect-ratio or min-height rule for that breakpoint. Check your theme’s mobile-specific CSS media queries for the affected image’s container and apply dimension or aspect-ratio rules within that same media query.

Q4. Can I exclude a single image from lazy loading without affecting others on the same page?

Yes. The Exclude Media from Lazy Loading setting in BlinkSpeed’s Exclusions tab matches individual images using a CSS class, ID, alt text, or URL fragment – this matching is per-image, not page-wide. You can exclude one specific hero image while leaving every other image on that same page, including images below it, fully lazy-loaded.

Q5. Does WordPress’s own native lazy loading conflict with BlinkSpeed’s lazy load system?

WordPress core has included native lazy loading (using the browser’s loading=”lazy” attribute) since version 5.5. BlinkSpeed’s own lazy load system is more advanced – using JavaScript and the Intersection Observer API for more reliable cross-browser behaviour – and for certain images, BlinkSpeed applies the native loading=”lazy” attribute directly rather than the JavaScript-based placeholder method. These two approaches do not typically conflict because BlinkSpeed only applies one method per image, but if you notice unusual lazy load troubleshooting behaviour, check whether a theme or another plugin is also adding its own loading=”lazy” attribute to the same images, which can occasionally cause duplicate attribute conflicts in the rendered HTML.

Q6. My lazy-loaded images load instantly with no delay at all. Is that a problem?

Not necessarily. If your page is short enough that most images are already near the top of the viewport, or if you are testing on a fast connection with a small page, images may load very quickly after the initial render even with lazy loading active – this is the lazy load system working correctly, just with a very small delay that is not visually perceptible. The lazy load benefit is most visible on long pages with many images, where images far down the page genuinely are not downloaded until the visitor scrolls toward them.

Q7. How can I tell if lazy loading is actually helping my loading speed?

Open BlinkSpeed’s Debug Logs → Core Web Vitals Logs and filter by LCP and CLS over time, comparing periods before and after you made lazy load configuration changes. You can also use Chrome DevTools’ Network tab on a long page – load the page, do not scroll, and count how many images have loaded versus the total number of <img> tags in the page source. If lazy loading is working, the loaded count should be significantly lower than the total image count until you start scrolling.

The post How to Diagnose and Fix Every BlinkSpeed Lazy Load Issue appeared first on Blinkspeed.

This guide walks through every known cause of a CSS generation problem in BlinkSpeed, what’s happening under the hood when it breaks, and exactly how to resolve it.

What Critical CSS Actually Does in BlinkSpeed

Before troubleshooting, it helps to understand what you’re fixing.

When a browser loads a page, it has to download and parse every stylesheet before it can paint anything on screen. Critical CSS solves the above the fold loading issue by extracting only the styles needed for the visible portion of the page the part users see before scrolling and loading them inline, right in the HTML. Everything else loads asynchronously after the page is already visible.

BlinkSpeed handles this by sending your page URLs to its cloud API at https://rest.blinkspeed.ai, which renders the page, identifies the above-the-fold elements, extracts the relevant CSS rules, and returns the result to be cached in wp-content/cache/critical-css/. When it works, the result is a noticeable improvement in Largest Contentful Paint (LCP) and First Contentful Paint (FCP) two of the Core Web Vitals that directly affect Google rankings.

When it doesn’t generate, something in that chain has broken.

Why Critical CSS Stops Generating: The Most Common Causes

Understanding the root cause saves you from trying fixes at random. Here are the situations that reliably produce a CSS generation problem in BlinkSpeed.

• No license key activated. This is the single most common cause. Without an active license, BlinkSpeed’s critical CSS generation only works on the homepage as a demo. Every other page is silently skipped. If you’re seeing optimization stalls on inner pages, check your license status first.
• CSS optimization is turned off. Critical CSS depends on the CSS optimization module being active. If you’ve disabled CSS optimization in the CSS settings tab, the critical CSS pipeline has nothing to work with.
• The BlinkSpeed cloud API can’t reach your site. The external service needs to render your pages to extract above-the-fold styles. If your site is behind a firewall, under HTTP authentication, or hosted on a server with restricted outbound connections, the API call either fails silently or returns an error that never surfaces in the dashboard.
• Cache folder permissions are wrong. BlinkSpeed writes generated critical CSS files to wp-content/cache/critical-css/. If that directory isn’t writable by PHP, generation completes on the API side but the file never saves which looks identical to the feature not running at all.
• A conflicting plugin is stripping the output. Some security plugins, HTML minifiers, or other caching tools modify the page HTML after BlinkSpeed has injected the critical CSS link. The result is that critical CSS is generated but never actually served.
• The page is excluded from optimization. If the URL, a cookie, or a user agent tied to your session appears in BlinkSpeed’s Exclusions tab, that page skips the entire optimization pipeline.

Step-by-Step Critical CSS Fix

Work through these in order. Most page rendering issues tied to critical CSS are resolved by step three or four.

Step 1 Confirm Your License Is Active

Navigate to BlinkSpeed → General Settings in your WordPress admin. Look for the License Key field and confirm it shows as activated. If the field is empty or shows an error, enter your license key and click Activate.

Once activated, return to the Optimize with AI tab and check whether pages now show a Pending or In Progress status. If they do, your license was the blocker.

If you don’t have a premium license yet, understand that critical CSS on inner pages is a premium feature. The homepage will still generate as a demo, but full-site coverage requires an active key.

Step 2 Verify CSS Optimization Is Enabled

Go to BlinkSpeed → CSS Optimization. Confirm that Enable CSS Optimization is toggled on. Then confirm that Load Critical CSS is also enabled. Both need to be active for generations to run.

Save your settings, then clear all cache from the admin bar. This forces BlinkSpeed to treat pages as uncached and queue them for fresh optimization.

Step 3 Check the Critical CSS Cache Folder

Connect to your server via FTP, SFTP, or your hosting file manager and navigate to wp-content/cache/. Look for a folder named critical-css. If it doesn’t exist, create it manually. Then check that the folder permissions are set to 755 and are writable by the web server user.

If the folder exists but is empty despite the plugin appearing to run, permissions are almost certainly the cause. A quick test: temporarily set the folder to 777, trigger optimization on a single page, and see if a file appears. If it does, tighten permissions to 755 and confirm your PHP process has write access at that level.

Step 4 Test Whether BlinkSpeed’s API Can Reach Your Site

The BlinkSpeed cloud API at rest.blinkspeed.ai needs to be able to send an HTTP request to your site and receive a full rendered HTML response. Several situations block this.

If your site is in maintenance mode or behind a coming-soon page, the API gets a login wall instead of the actual page. Disable any maintenance plugins temporarily and retry.

If your host uses a firewall that blocks external crawlers or bots by IP range, the BlinkSpeed API may be blocked. Contact your host and ask whether external HTTP requests to your site from third-party services are permitted.

If your site uses HTTP Basic Authentication (common on staging environments), the API can’t authenticate. Either whitelist the BlinkSpeed API IP range or temporarily remove HTTP auth while running optimization.

Step 5 Clear Critical CSS Cache and Re-Run Optimization

In BlinkSpeed’s admin bar menu, use Clear All Cache. Then go to the Optimize with AI tab and click Reset to restart the optimization queue from scratch. Set Pages per Minute to a conservative value (3-5) if your server has limited resources, then save.

Watch the progress bar. If it moves steadily, generation is running. If it stalls at a specific percentage or shows Error status for particular URLs, those individual pages have a problem which is usually a URL exclusion, a conflicting plugin, or a page that returns a non-200 status code.

Step 6 Check the Exclusions Tab

Go to BlinkSpeed → Exclusions. Review the list of excluded URLs, cookies, and user agents. If the pages you’re trying to optimize appear there even partially matched they’ll be skipped.

Also check whether you’re logged in as an admin with caching disabled for logged-in users. If so, you’ll never see cached or optimized output in your own browser session. Use an incognito window or a logged-out browser to verify what visitors actually receive.

Step 7 Diagnose Plugin Conflicts

Temporarily deactivate all other caching and optimization plugins. This includes any other performance tools, HTML minifiers, security plugins that modify output, or CDN plugins that rewrite URLs. Retry critical CSS generation with only BlinkSpeed active.

If it works, reactivate plugins one at a time and test after each until the page rendering issue returns. That’s your conflict. Common culprits are plugins that use output buffering to post-process HTML, since they can strip or reorder the critical CSS link tags BlinkSpeed injects.

How the Optimize with AI Tab Connects to Critical CSS

The Optimize with AI feature in BlinkSpeed is the automated engine that runs critical CSS generation (along with other AI-powered improvements) across your entire site without manual per-page effort.

When you enable AI Optimization, BlinkSpeed pulls your published URLs, queues them, and processes them in batches; the Pages per Minute setting controls how aggressive the queue runs. Each URL moves through Pending → In Progress → Done. A status of Error on a URL means that specific page failed the CSS generation problem check usually for one of the API reachability or permissions reasons covered above.

The Reset button clears the queue and restarts from scratch, which is useful after you’ve resolved a configuration issue and want a clean run.

Verifying the Fix Worked

Once you’ve resolved the underlying cause, here’s how to confirm critical CSS is actually being generated and served.

Open an incognito browser window and visit any page on your site. Right-click and view the page source. Look in the <head> section for either an inline <style> block containing your critical styles or a <link rel=”preload”> referencing a critical CSS file from your cache directory.

Alternatively, run the page through Google PageSpeed Insights or GTmetrix before and after. A successful speed optimization fix for critical CSS typically shows up as an improvement in Render-Blocking Resources, First Contentful Paint, and Largest Contentful Paint scores.

You can also check wp-content/cache/critical-css/ directly. Each optimized URL should have a corresponding file in that folder.

Using Change Logs to Track the Fix

BlinkSpeed’s built-in Change Logs tab records every settings adjustment with a timestamp, the user who made the change, and the old and new values. If your critical CSS stopped working after someone adjusted settings, a common scenario on multi-admin sites or agency-managed installs the log will show exactly what changed and when.

Enable Settings Change Logs from the Change Logs tab if it isn’t on already. This won’t help you fix the current issue, but it gives you a clear audit trail the next time a CSS generation problem appears out of nowhere.

Frequently Asked Questions

Q1. Why is BlinkSpeed only generating critical CSS for the homepage and skipping everything else?

This is the license restriction in action. Without an active premium license, critical CSS generation runs only on the homepage as a demo. A full-site critical CSS fix for all pages requires an active BlinkSpeed license key, entered and activated under General Settings.

Q2. I activated my license but the CSS generation problem persists on some pages. Why?

Check the Exclusions tab first some pages may be explicitly excluded. Also verify that those pages return a 200 status code and aren’t behind a redirect chain. The BlinkSpeed API can’t generate critical CSS for pages that redirect, return 404, or sit behind authentication walls. The Optimize with AI tab will show Error status for these URLs.

Q3. Does clearing the cache delete my generated critical CSS files?

It depends on which cache you clear. Clearing HTML/CSS/JS cache from the admin bar does not remove the critical CSS files in the critical-css folder that persist separately. However, if you use the Reset function in the Optimize with AI tab, the optimization queue restarts and pages will be re-generated on the next run. Or use Clear Critical CSS for this page only from the admin bar menu, will remove the critical CSS for the particular page.

Q4. Can a security plugin cause an above-the-fold loading issue even after critical CSS generates?

Yes. Some security plugins use output buffering to scan or modify HTML before it’s sent to the browser. If they strip inline <style> tags or remove <link rel=”preload”> elements as part of HTML hardening, your critical CSS is generated but never delivered. This is a page rendering issue caused by post-processing, not by BlinkSpeed itself. Whitelist BlinkSpeed’s output tags in your security plugin’s settings or contact your security plugin’s support for guidance.

Q5. My server is on Nginx. Does that affect how critical CSS is served?

BlinkSpeed defaults to .htaccess for serving cached files, which applies to Apache. On Nginx, you’ll need to set the serving method to PHP Cache (Advanced Cache) under HTML Cache settings. This doesn’t directly affect critical CSS generation, but it ensures BlinkSpeed’s cached output is served correctly, which matters when verifying whether your speed optimization fix is actually being seen by visitors.

Q6. How do I know if the BlinkSpeed cloud API is what’s causing my CSS generation problem?

If critical CSS generates successfully on the homepage (confirming the plugin and license are working) but fails on all other pages despite an active license, and you’ve ruled out exclusions and permissions, the API reachability is the likely cause. Your host or server firewall may be treating repeated HTTP requests from the same external IP as bot traffic and blocking them. Ask your host specifically whether outbound HTTP POST requests from third-party services can render your pages, and whether any rate-limiting applies to inbound crawler requests.

Q7. How many pages can BlinkSpeed optimize per minute without overloading my server?

The Pages per Minute setting in the Optimize with AI tab goes up to 20. For shared hosting or lower-resource environments, 3-5 is a safe starting point. For dedicated or managed WordPress hosting, you can push this higher. If you notice your server slowing during optimization runs, reduce the batch size. A slower run that completes cleanly is always preferable to a faster run that produces Error statuses across half your URL list.

The post BlinkSpeed Critical CSS Issue: Why It’s Not Generating and How to Fix It Completely appeared first on Blinkspeed.

BlinkSpeed WebP images fail to load for six specific reasons – the free plan restricts WebP to the homepage only, the AI Optimisation process has not run or completed, the converted .webp files are missing from the wp-content/uploads/bs-webp/ folder on your server, the # BEGIN BSWEBP Apache rewrite block is absent from .htaccess, the lazy load JavaScript is blocked or conflicting with another plugin, or the image format is not eligible for conversion (GIF, SVG, ICO, or external images). Each cause has a direct, targeted fix that takes under five minutes to apply.

What Is the BlinkSpeed WebP Issue?

The BlinkSpeed WebP issue is when images on your WordPress site are expected to load in WebP format after enabling BlinkSpeed’s image optimisation settings, but they continue to display as standard JPG or PNG files – or worse, show as blank boxes that never fill in.

WebP is a modern image format that reduces file size by 25-50% compared to JPEG and PNG with no visible quality loss. BlinkSpeed converts your images to WebP through its cloud API and delivers them automatically – but the system has several moving parts, and any one of them being off creates an image optimization problem that is easy to fix once you know where to look.

This WordPress image troubleshooting guide covers every cause, how to identify which one applies to your site, and the exact steps to fix each one.

How BlinkSpeed Delivers WebP Images

Understanding how BlinkSpeed serves WebP makes diagnosing the problem much faster.

BlinkSpeed uses two delivery methods working side by side:

Method 1 – PHP Rewriting: 

When building a page, BlinkSpeed scans every image tag. For each JPG or PNG image hosted on your own server, it checks whether a WebP version already exists in the wp-content/uploads/bs-webp/ folder on disk. If the file is there, the image URL in the HTML is rewritten to point to the .webp version. If the file is not there, the original URL stays, and that image is added to the next conversion queue.

Method 2 – Server-Level Apache Rewriting: 

BlinkSpeed also writes a block called # BEGIN BSWEBP into your .htaccess file. This block tells Apache to transparently serve the WebP version of any JPG or PNG request – as long as the visitor’s browser supports WebP and the .webp file exists on the server. This runs at the server level, before PHP, which means even images whose HTML has not been PHP-rewritten can still be served as WebP.

Both methods work together. When either one breaks, you see the BlinkSpeed WebP issue. Knowing which layer failed tells you exactly which fix to apply.

6 Causes of the BlinkSpeed WebP Issue and Their Fixes

Cause 1 – Free Plan Limits WebP to the Homepage Only

Who sees this: Anyone using BlinkSpeed without an active premium license key.

This is by far the most common image optimization problem BlinkSpeed users encounter after first setup. On the free version, BlinkSpeed assigns a demo license. 

When this demo license is active, the plugin checks whether the current page is the homepage before running its full optimisation pipeline. If the page is anything other than the homepage – a blog post, product page, landing page, or any inner URL – the pipeline exits before reaching the WebP conversion code. No WebP images are served. No error is shown. The images simply stay in their original JPG or PNG format.

How to confirm: Open any inner page in Chrome, press F12, go to the Network tab, filter by Img, and reload. If image files end in .jpg or .png while your homepage images end in .webp, the free plan limit is your answer.

WebP conversion fix: Activate a premium license key under BlinkSpeed → General Settings → License Key. Once active, go to BlinkSpeed → Optimize with AI, click Start Optimization, and let the full-site conversion run. After it completes, clear the BlinkSpeed cache and test your inner pages.

Cause 2 – The AI Optimisation Process Has Not Run or Finished

Who sees this: Sites where the WebP setting is on but the conversion has never been triggered, or was interrupted.

Enabling Convert to WebP under BlinkSpeed → Image Optimization tells BlinkSpeed what to do – but it does not do it immediately. The actual WebP conversion happens through the Optimize with AI process. This crawls your site’s URLs, collects all image URLs on each page, sends them to BlinkSpeed’s cloud conversion service, and saves the returned WebP files into the wp-content/uploads/bs-webp/ folder on your server.

Until a page goes through this queue, there are no WebP files for its images. BlinkSpeed checks the bs-webp/ folder when processing each page’s HTML, finds nothing, keeps the original image URLs, and adds those images to the next scheduled conversion batch.

How to confirm: Go to BlinkSpeed → Optimize with AI. If you see pages listed as Pending or In Progress, or you have never opened this tab before, this is your cause.

Fix: Click Start Optimization and allow it to run to completion. At 5 pages per minute, a 200-page site takes around 40 minutes. Pages already marked complete will serve WebP during this time; pages not yet processed will serve the original format until their turn. After the process finishes, clear the BlinkSpeed cache and test.

Cause 3 – WebP Files Are Missing from the bs-webp/ Folder

Who sees this: Sites where WebP was working before but has recently stopped.

Even if the AI Optimisation previously completed successfully, the converted WebP files can disappear. Common reasons include a cleanup plugin that cleared the wp-content/uploads/bs-webp/ folder, a site migration where that folder was not transferred, a manual action in the hosting file manager, or a cloud API timeout during the original conversion that silently saved zero files.

BlinkSpeed checks for the physical .webp file on disk before rewriting any image URL. If the file does not exist, it falls back to the original format – quietly, with no error in the WordPress admin.

How to confirm: Log in via FTP or your hosting file manager and open wp-content/uploads/bs-webp/. If this folder is empty or does not exist, the files are gone.

Fix: Go to BlinkSpeed → Optimize with AI, click Reset to clear the processing history for all URLs, then click Start Optimization to rebuild the entire WebP library from scratch. The bs-webp/ folder is recreated automatically as files are received from the cloud API.

Cause 4 – The # BEGIN BSWEBP Block Is Missing from .htaccess

Who sees this: Sites where WebP works inconsistently, or where the admin shows a specific error notice.

BlinkSpeed writes a block into your root .htaccess file that handles WebP delivery at the Apache server level. The block contains mod_rewrite rules that intercept JPG and PNG requests and substitute the WebP version when the browser supports it. If this block is missing – because another plugin overwrote .htaccess, a backup restore removed it, or BlinkSpeed’s own validation test detected a server error when trying to write it – the server-level delivery layer stops working.

When the .htaccess validation fails, BlinkSpeed automatically reverts the WebP settings and shows this notice in your WordPress admin:

“Server error: Unable to apply .htaccess webp rules to the site.“

How to confirm: Open your root .htaccess file via FTP or cPanel File Manager and search for # BEGIN BSWEBP. If the block is absent, this is your cause.

Fix: Go to BlinkSpeed → General Settings and click Save without changing anything. This triggers BlinkSpeed to rewrite all its .htaccess blocks, including the BSWEBP block. If the error notice reappears after saving, your server may not have mod_rewrite or mod_headers enabled – contact your hosting provider to enable these Apache modules, or see the Nginx note in the FAQs.

Cause 5 – Blank Images: A Lazy Load Image Problem Disguised as a WebP Issue

Who sees this: Users reporting blank white or grey boxes where images should appear, with no loading or progress – even after scrolling.

This is the most important WordPress image troubleshooting distinction in the entire guide: blank boxes are a lazy load image problem, not a WebP delivery problem. They look similar from the outside but have completely different causes and fixes.

Here is what is happening: BlinkSpeed’s lazy loading replaces below-the-fold image src attributes with a tiny transparent placeholder and moves the real image URL to a data-src attribute, marking the element with data-class=”LazyLoad”. A small JavaScript file uses the browser’s built-in Intersection Observer to detect when an image enters the viewport and swaps the real URL back into src. If this JavaScript is not running correctly, images stay as blank placeholders indefinitely – the real image URL exists in the page source, but the browser never receives the signal to load it.

How to tell if your broken images issue is a lazy load problem or a WebP problem:

1. Right-click a blank image → Inspect Element
2. Look at the HTML for that image
   • src shows a tiny data placeholder AND a data-src attribute holds the real URL → lazy load image problem
   • src shows a real .jpg URL that returns a 404 error → broken image link, unrelated to lazy loading or WebP
   • src shows a real .jpg URL that returns a 200 but is not in WebP format → WebP conversion issue (see Causes 1–4)

Fix for the lazy load image problem: Open DevTools → Console tab and look for red JavaScript errors. Any uncaught error from another plugin can halt BlinkSpeed’s image loading script. There is also a specific circular conflict worth checking: if BlinkSpeed’s JavaScript optimisation system has delayed BlinkSpeed’s own image loader script (img-lazyload.js), the script that loads images is waiting for user interaction to run – but images will never appear unless that script runs first.

To fix this: go to BlinkSpeed → Exclusions → JS Exclusions → Exclude Javascript from Lazyload and add:

img-lazyload.js

with no modifier. This ensures the image loading script always executes immediately on page load, while the rest of the site’s scripts continue benefiting from the lazy load optimisation.

Cause 6 – The Image Type Is Not Eligible for WebP Conversion

Who sees this: Users noticing one specific image or type of image that never converts while everything else works fine.

BlinkSpeed only converts images that meet specific criteria. The following are always skipped:

If a specific image falls into any of these categories and is not showing as WebP, this is not a broken images issue – it is expected behaviour.

Quick Diagnosis Table

Use this to match your specific symptom to the right cause and fix in under 60 seconds:

How to Verify WebP Is Working After Your Fix

Always confirm the fix worked before moving on. Here are two quick methods:

Chrome DevTools (most accurate):

1. Press F12 → Network tab → filter by Img
2. Hard-reload the page with Ctrl + Shift + R
3. Click any image in the list
4. Look at Response Headers

content-type: image/webp – WebP is being served correctly content-type: image/jpeg – WebP file may still be missing, or .htaccess block is not firing

Quick visual check: Right-click any image on the page → Open image in new tab. If the URL in the address bar ends in .webp, that image is being served in WebP format.

Remember: Always clear BlinkSpeed → Cache → Delete HTML/JS/CSS Cache after any change before testing. Old cached pages will not reflect updated settings until they are regenerated.

Mobile WebP: Understanding the -595xh Variant

When Responsive Images is enabled under BlinkSpeed → Image Optimization, BlinkSpeed generates a second, smaller WebP file for mobile visitors – a 595-pixel-wide version saved with a -595xh.webp suffix alongside the standard .webp file in the bs-webp/ folder.

BlinkSpeed detects mobile visitors through their User-Agent and serves the smaller variant when it exists, reducing image weight even further for phone screens. If WebP is loading on desktop but not mobile, the mobile variant may not have been generated because the AI Optimisation ran only from a desktop context.

Fix: After enabling Responsive Images, go to BlinkSpeed → Optimize with AI and run the process again. BlinkSpeed will check for missing -595xh.webp files and generate them.

Frequently Asked Questions

Q1. Why is my BlinkSpeed WebP issue only happening on inner pages, not the homepage?

This is the free plan’s homepage-only restriction. When no premium license key is active, BlinkSpeed processes the full optimisation pipeline – including WebP conversion – only for the homepage. On all other pages, the pipeline exits early before reaching the image conversion code. The WebP conversion fix for this is upgrading to premium and running the full AI Optimisation process.

Q2. I ran the AI Optimisation and it completed, but images are still loading as JPEG. Why?

Three things to check: first, clear the BlinkSpeed cache – cached pages generated before WebP files existed will keep serving old HTML until cleared. Second, connect via FTP and verify that the wp-content/uploads/bs-webp/ folder actually contains .webp files – if it is empty, the cloud API conversion step may have failed silently and you need to Reset and re-run. Third, open .htaccess and confirm the # BEGIN BSWEBP block is present – if missing, re-save your General Settings.

Q3. How do I fix the broken images issue where blank boxes appear instead of photos?

Blank boxes are a lazy load image problem, not a WebP issue. Open DevTools (F12) → Console and look for JavaScript errors. If you find them, identify which plugin’s script is throwing the error and add it to BlinkSpeed → Exclusions → JS Exclusions with the defer modifier.

Also check whether img-lazyload.js is being delayed by BlinkSpeed’s own JS lazy load system – if so, add it to Exclude Javascript from Lazyload with no modifier so it always runs immediately.

Q4. Does the image optimization problem affect my Google PageSpeed or Core Web Vitals score?

Yes. If WebP images are not being served, PageSpeed Insights will flag “Serve images in next-gen formats” as an Opportunity, which means your images are heavier than they need to be and your LCP (Largest Contentful Paint) score is suffering.

If the lazy load image problem is causing blank images, your LCP element may be invisible during the scoring window, which severely penalises the LCP metric. Both issues are resolvable through the fixes in this guide.

Q5. Will enabling WebP break images in older browsers or cause a broken images issue?

No. BlinkSpeed’s Apache rewrite block includes the condition RewriteCond %{HTTP_ACCEPT} image/webp – it only serves WebP when the browser explicitly says it supports it through its request headers. Older browsers that do not support WebP never send this signal, so they always receive the original JPEG or PNG. There is zero risk of a broken images issue in any browser from enabling WebP conversion.

Q7. I am on an Nginx server. Why is the # BEGIN BSWEBP block not working?

Nginx does not read .htaccess files – they are an Apache-only feature. The # BEGIN BSWEBP block has no effect on Nginx servers, and BlinkSpeed’s validation test will likely fail when trying to write it, showing the “Unable to apply .htaccess webp rules” error and reverting the setting.

The good news is that BlinkSpeed’s PHP-based rewriting layer still works on Nginx – when BlinkSpeed builds a page’s HTML, it checks the bs-webp/ folder and rewrites image src attributes directly. This means WebP can still be served on Nginx through PHP rewriting, even without the .htaccess layer.

Contact your hosting provider to confirm PHP cache mode is set as the cache delivery method under BlinkSpeed → HTML Caches → Serve HTML Cache File By.

Q8. Can I stop a specific image from being converted to WebP to fix a WordPress image troubleshooting problem?

Yes. BlinkSpeed provides a filter hook called blinkspeed_exclude_image_from_convert_to_webp that returns true or false for each image path. When it returns true for a specific file path, BlinkSpeed skips WebP conversion for that image and serves the original format. Add this to your theme’s functions.php to exclude any image that is causing visual issues after WebP conversion, while all other images continue converting normally.

Q9. Does clearing the BlinkSpeed cache delete my converted WebP images?

No. BlinkSpeed’s page cache lives in wp-content/cache/bs-cache/, while your WebP image files live in wp-content/uploads/bs-webp/ – completely separate locations. The Delete HTML/JS/CSS Cache button only clears the page cache directory. Your converted WebP files are safe and will not be touched. The only way to delete the WebP files is to manually remove the bs-webp/ folder via FTP.

Summary

The BlinkSpeed WebP issue always comes down to one of six identifiable causes: the free plan’s homepage restriction, the AI Optimisation process not having run, WebP files missing from the server, the .htaccess BSWEBP block being absent, a lazy load image problem creating blank boxes that look like a WebP failure, or an image format that BlinkSpeed does not convert.

Use the diagnosis table to match your symptom to the correct cause, apply the targeted WebP conversion fix, clear the BlinkSpeed cache, and verify the result in DevTools. For the vast majority of WordPress image troubleshooting cases, running the AI Optimisation process and clearing the cache is all that is needed.

The post How to Diagnose and Solve the BlinkSpeed WebP Issue on Your WordPress Site appeared first on Blinkspeed.

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.