Your desktop PageSpeed score is green. Your mobile score is red. If that describes your WordPress site right now, you are in very good company – and you are in exactly the right place.
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.
