Run a Lighthouse audit on your WordPress site and look at the performance scores. There is almost always a gap: desktop scores higher, sometimes significantly higher, than mobile. This surprises people who assume that if a site performs well on desktop, it should perform similarly on mobile. The gap is not a glitch in the testing tool. It reflects something real about how Lighthouse tests each environment, and about how browsers on mobile devices handle web content.
Understanding why the gap exists is the first step to closing it.
Why Lighthouse Tests Mobile and Desktop Differently
Lighthouse does not measure your site from your phone and your laptop. It simulates the conditions of each device type using a set of predefined assumptions.
- Mobile simulation applies a CPU throttle of 4x, artificially slowing the processing speed to approximate a mid-range Android device. Desktop runs with no CPU throttle.
- Network throttling is also applied to mobile, specifically simulating a “slow 4G” connection at approximately 1.6 Mbps download, 750 Kbps upload, and 150ms round-trip time. Desktop simulates a faster broadband connection.
This means that when Lighthouse tests your mobile score, it is not asking “how does this page perform on a good phone with a good connection?” It is asking “how does this page perform on an average phone with an average mobile connection?” That is a much harder standard to meet.
The same page, served to a desktop browser with no throttling, will naturally score higher because it has more processing power and network capacity available.
The Most Common Reasons the Gap Is Large
1. Render-Blocking JavaScript and CSS
When a browser encounters a JavaScript file or CSS file in the <head> of a page, it pauses rendering until that file is downloaded and processed. On desktop with a fast connection and a powerful processor, this pause is short. On mobile with a throttled connection and slower CPU, that same pause is much longer.
Fix: Use your caching or asset optimization plugin to defer non-critical JavaScript and move render-blocking resources later in the load order. Minify CSS and JS to reduce file sizes.
Dev Note: Instead of relying on a complex plugin to guess what scripts to defer, you can control your script execution order using a simple code snippet. If you have some programming experience or a child theme set up, adding this code to your functions.php file will automatically defer non-essential scripts while protecting critical elements (like menus or sliders) from breaking by listing their handles in the exclusion array:
add_filter('script_loader_tag', function($tag, $handle, $src) {
// List script handles here to exclude them from deferral if they break functionality
$exclusions = array('jquery-core', 'main-slider', 'custom-form-script');
if (in_array($handle, $exclusions) || is_admin()) {
return $tag;
}
return str_replace(' src', ' defer="defer" src', $tag);
}, 10, 3);
2. Large, Unoptimized Images
Images that are not properly sized, compressed, or formatted have a disproportionate impact on mobile performance. A 2MB hero image that loads acceptably on desktop becomes a serious bottleneck on a throttled mobile connection.
Fix:
- Convert images to WebP format, which is typically 25% to 35% smaller than JPEG at equivalent quality.
- Use responsive images with srcset so mobile devices download appropriately sized images, not desktop-sized ones.
- Implement lazy loading for images below the fold (
loading="lazy"). - Ensure your largest above-the-fold image has an explicit
fetchpriority="high"attribute.
3. Largest Contentful Paint (LCP) Issues
LCP measures how long it takes for the largest visible element on the page, usually a hero image or large heading, to render. On mobile with CPU and network throttling, LCP is almost always worse than desktop.
Fix:
- Preload the LCP image using
<link rel="preload" as="image" href="hero.webp">. - Avoid using CSS background images for LCP elements, as these cannot be preloaded as effectively as
<img>elements. - Ensure your server responds quickly (Time to First Byte under 600ms).
Dev Note: Adding a preload tag manually requires editing your theme’s header.php or using a plugin like “Head, Footer and Post Injections” to add code to the
<head>without touching theme files. If your LCP element is a page builder’s background image rather than an<img>tag, it needs a different approach to preload correctly.
4. Cumulative Layout Shift (CLS) on Mobile
CLS measures how much the page layout shifts as it loads. On mobile, elements that load slowly or out of order can cause more visible shifts because the viewport is narrower and elements stack vertically.
Fix:
- Always specify explicit width and height attributes on images and video elements.
- Reserve space for embeds (iframes, ads) with known dimensions.
- Avoid inserting content above the fold after the initial render.
5. Total Blocking Time (TBT) and JavaScript Execution
TBT measures how long the main thread is blocked by long JavaScript tasks. On mobile with CPU throttling, JavaScript that runs in 50ms on desktop might take 200ms on mobile. Page builders, sliders, animation libraries, and third-party scripts are common culprits.
Fix:
- Audit your active plugins and remove anything not actively adding value.
- Load third-party scripts such as analytics, chat widgets, and social embeds asynchronously or defer them until after the main content loads.
- Load scripts only on the pages that need them, not sitewide.
Dev Note: Asset CleanUp is a free plugin with a visual interface that lets you disable scripts per page without writing code, and its free tier covers most single-site needs. If you also want this bundled with caching and more automated rule-based loading, Flying Press is a paid option that adds that layer, though it requires more initial configuration to set up correctly.
6. Font Loading
Custom web fonts add HTTP requests and can block text rendering if not handled correctly. On mobile with a slower connection, this effect is amplified.
Fix:
- Host fonts locally rather than loading from Google Fonts (eliminates a third-party request).
- Use
font-display: swapso text renders immediately in a fallback font while the custom font loads. - Subset fonts to include only the characters your site actually uses.
Dev Note: Hosting fonts locally means downloading the font files and uploading them to your server, then updating your CSS to reference them directly instead of Google Fonts. OMGF (Optimize My Google Fonts) is a free plugin that automates this process for most sites without requiring manual file handling.
A Practical Fix Sequence
Rather than addressing everything at once, work through this sequence:
- Fix obvious image issues first. Convert all images to WebP, add lazy loading, and ensure above-the-fold images are appropriately sized and preloaded. This alone often produces a meaningful LCP improvement.
- Enable caching and asset optimization. Defer JavaScript, minify CSS and JS, and enable browser caching. Verify the changes did not break any functionality.
- Audit and reduce third-party scripts. Open the network panel in Chrome DevTools and sort requests by size and initiator. Identify which third-party scripts are loading and whether they are necessary. Analytics scripts should load async; anything optional should be deferred or removed.
- Address LCP specifically. Run PageSpeed Insights and look at the LCP element identified. Ensure it is an
<img>tag withfetchpriority="high", hosted on your own domain, and served from a fast origin. - Fix CLS. Add explicit dimensions to all images. Check your Lighthouse report for the CLS contributors and address each one.
Acceptable Gaps and Realistic Targets
A perfect 100 on mobile is extremely rare on real-world sites with content, images, and plugins. These are realistic targets for a well-optimized WordPress site:
| Metric | Target |
|---|---|
| Mobile Performance Score | 80 to 95 |
| Desktop Performance Score | 95 to 100 |
| LCP (Mobile) | Under 2.5 seconds |
| CLS | Under 0.1 |
| TBT (Mobile) | Under 200ms |
Our benchmark baseline setups routinely clock in at 97 desktop and 84 mobile. A gap of 13 points reflects the inherent difficulty of the mobile throttled environment. That mobile score still represents excellent real-world performance.
What Not to Do
Do not optimize exclusively for Lighthouse. Some developers apply techniques that improve the score without improving real user experience. Loading critical CSS inline, for example, can game LCP without actually making the page feel faster to users. Optimize for real users first; the score follows.
Do not sacrifice functionality for score. Disabling animations, removing plugins, or stripping content to chase a higher number is counterproductive if it degrades the experience your site is supposed to deliver.
Do not measure once and stop. Scores change. Plugin updates, theme changes, new content with large images, new third-party scripts, all of these can affect performance. Check your scores after any significant site change.
The gap between mobile and desktop Lighthouse scores is not a mystery. It is a direct consequence of how the tool simulates mobile conditions. Closing the gap requires addressing the specific factors that hurt performance under CPU throttle and slow network: image size and format, JavaScript blocking, render-critical resource loading, and third-party script management.
Most of these fixes are achievable on any WordPress site. The difference between a score in the 40s and one in the 80s is almost always a handful of concrete, addressable issues and not an inherent limitation of the platform.