Open PageSpeed Insights, run your WordPress site, and you will almost always see the same thing: a comfortable green desktop score sitting next to a yellow or red mobile one. The gap is real, it is consistent, and it is not a bug in the test. But not every gap means the same thing. Some of it is unavoidable physics. The rest is your stack telling you exactly where it is overweight. The job of this article is to help you tell those two apart so you stop optimizing things that don't move and start fixing the things that do.

The test throttles two things at once, and they multiply

The mobile profile in Lighthouse (the engine behind PageSpeed Insights) is not just "the same test on a smaller screen." It applies two independent handicaps that desktop never sees.

A 4x CPU slowdown that emulates a mid-range Android phone in the class of a Moto G4 — a device deliberately chosen to represent the slower half of real-world hardware, not a flagship.
A "Slow 4G" network of roughly 1.6 Mbps download, 750 Kbps upload, and 150ms round-trip latency.

The reason these two produce a 40-point swing rather than two small ones is that they hit different resources and then compound. The CPU throttle punishes work measured in execution time — JavaScript parsing, hydration, main-thread tasks. The network throttle punishes work measured in bytes and round trips — images, fonts, third-party requests. A script that parses in 50ms on a laptop takes around 200ms on the throttled mobile CPU; a hero image that arrives in 150ms on desktop fiber takes the better part of a second over Slow 4G. Stack those delays end to end and the score gap is the sum.

This is also why mobile-specific work is genuinely different from "general performance work." Shaving desktop milliseconds rarely touches the two bottlenecks that define the mobile number.

JavaScript is where WordPress mobile scores go to die

If you only fix one category, fix this one. Because parse-and-execute cost scales directly with CPU speed, JavaScript is the single biggest reason a WordPress site that looks fine on desktop collapses on mobile.

The usual culprits are predictable:

Page builders. Elementor, Divi, and WPBakery ship substantial JavaScript and CSS to render layouts the browser then has to assemble. On a 4x-throttled CPU, that work that felt instant on desktop becomes hundreds of milliseconds of blocked main thread.
Sliders, carousels, and animation libraries. Slider Revolution, lottie animations, and parallax effects are interaction-heavy and main-thread-heavy — exactly the wrong profile for a slow mobile CPU, and a frequent cause of poor Interaction to Next Paint (INP).
Stacked third-party tags. Analytics, heatmaps, chat widgets, and ad scripts each add execution and network cost. They are roughly free on desktop and expensive on mobile.

The practical moves, in order of payoff: defer or delay non-critical scripts (most caching plugins like WP Rocket and the free FlyingPress offer "delay JavaScript until interaction"), dequeue scripts on pages that don't use them — there is no reason to load a contact-form library on every post — and treat every third-party tag as something you must justify keeping. If you run a heavy page builder and your mobile INP is poor, the script-delay setting is usually the highest-leverage toggle you have.

The other half of the gap: image and font delivery

Where the CPU throttle owns JavaScript, the network throttle owns your Largest Contentful Paint (LCP) — which on most WordPress sites is the hero image or the first in-content image. Over Slow 4G, an oversized image is the difference between a 1.4-second desktop LCP and a 3-second mobile one.

What actually helps:

Serve smaller files to small screens. WordPress generates a srcset automatically, but it only helps if your theme emits sensible sizes values. A phone should never download a 1600px-wide hero.
Switch formats. AVIF and WebP cut image weight 30–50% over JPEG at equal quality. Plugins like ShortPixel, Imagify, or Converter for Media handle the conversion and serving; many managed hosts and Cloudflare's Polish do it at the edge.
Prioritize the LCP image and lazy-load nothing above the fold. Add fetchpriority="high" to the hero and make sure your lazy-load plugin is not deferring the very image that defines LCP — a classic self-inflicted wound.

Fonts cause the quieter problems. A web font that blocks rendering produces invisible text (FOIT) and, when it finally swaps in, a layout shift that is far more noticeable on a 360px-wide screen than on a wide desktop. Set font-display: swap, self-host rather than calling Google's servers (an extra connection on a latency-bound network), preload only the one critical weight, and subset to the characters you actually use.

Is your gap normal or pathological?

This is the question that should drive your decisions, and the answer is mostly determined by your theme.

Lightweight, performance-first themes — GeneratePress, Kadence, Astra in a clean configuration, or a well-built block theme on the default Twenty Twenty-Five — typically land mobile scores within 10–15 points of desktop. That gap is the physics described above. It is normal. Chasing it to zero is wasted effort.

Visual, do-everything themes and full page-builder sites — Divi, Avada, and heavy Elementor builds — routinely sit 30–45 points below their desktop score. That gap is pathological: it is the theme's own JavaScript and CSS volume dominating a throttled mobile load. No amount of image tuning closes a gap that is caused by the framework rendering the page.

If you are in the second camp and mobile matters, you have an honest two-way choice. Aggressively optimize the existing build (script delay, unused-CSS removal, critical CSS) for a medium gain at medium effort, or migrate to a lightweight theme for a large gain at large effort. There is no third option where Divi quietly becomes featherweight.

Trust the field data, not the lab gauge

One score from one PageSpeed run is a lab simulation — a single synthetic device on a single synthetic network. It is useful for diagnosis but it is not what Google ranks on.

Google ranks on field data: the Core Web Vitals collected from real Chrome users via the Chrome User Experience Report (CrUX). If your site has enough traffic, that data appears at the top of the PageSpeed report, and it is split by mobile and desktop. Even better, Search Console's Core Web Vitals report shows your mobile URLs bucketed into Good / Needs Improvement / Poor — the mobile buckets are the metric Google actually uses. If that report shows most mobile URLs in Good, your mobile performance is fine no matter how unflattering a single lab score looks.

The bar you are actually clearing

Mobile will not match desktop, and it does not need to. The goal is crossing the ranking-relevant thresholds, not achieving parity:

LCP — Good under 2.5s, Poor over 4s
INP — Good under 200ms, Poor over 500ms
CLS — Good under 0.1, Poor over 0.25

A site with mobile LCP at 2.3s and desktop at 1.4s has already won; further tuning has diminishing returns. A site at mobile LCP 3.5s is in Needs Improvement, and the same fix that feels optional becomes high-value because it can flip the page into Good. Diagnose your gap, decide whether it is physics or your stack, then spend your effort only where it crosses a threshold.

WordPress Performance: Why Mobile Numbers Lag Desktop