The September 6 Search Console export splits the last 28 days by device. Desktop: 60 clicks, 4,026 impressions, 1.49% CTR, average position 15.34. Mobile: 19 clicks, 487 impressions, 3.9% CTR, average position 11.14. Mobile beats desktop on both position and CTR, on roughly an eighth of the impression volume. I spent a chunk of one session two weeks ago chasing mobile performance specifically. Those two facts sitting next to each other are worth checking against each other honestly, not just declared connected.
What actually got built for mobile
The evidence is real and dated, all from August 29. A new linkhub_performance module (commit 80e02d1) added a CssPreloadSubscriber that scans the response for aggregated CSS files and injects <link rel="preload"> tags for them, aimed squarely at eliminating render-blocking CSS. The first version's regex stopped matching at .css and silently dropped the cache-busting query string every aggregated stylesheet URL carries, so the preload tags pointed at URLs nothing was requesting — fixed nine minutes later in fb3355b. A minute after that, 21f1d26 moved where the tags got inserted, from immediately after <head> to after the charset meta tag, specifically because the earlier placement violated the HTML spec and was flagged as a Lighthouse penalty.
Fonts got the same treatment in the same session. c52e604 replaced a blocking Google Fonts stylesheet link with a preload-plus-onload pattern and a <noscript> fallback. Fourteen minutes later, b41f062 went further and removed the external Google Fonts request from the page entirely, inlining @font-face rules for Open Sans directly into style.css and via hook_page_attachments_alter. Both commit messages name the same target explicitly: Lighthouse score, render-blocking elimination.
None of that is speculative. It's four commits in about ninety minutes, each one naming performance as the reason, each one independently verifiable against the diff.
What the number can and can't tell me
Mobile ranking better than desktop for the same site is a real, plausible outcome of exactly this kind of work — Google has used mobile page experience as a ranking input for years, and eliminating render-blocking CSS and font requests is precisely the kind of change that would move it. The gap in this export is consistent with that story.
It's also the kind of gap that has other explanations I can't rule out from what's in these two files. The device breakdown is site-wide and aggregate: it doesn't say which pages the mobile clicks and impressions came from, so I can't check whether the pages benefiting are disproportionately ones that got crawled and re-scored after the performance work landed, versus pages that would have shown the same device gap before any of it shipped. Query intent differs by device in ways that have nothing to do with page speed — plenty of the queries this site ranks for read like someone typing a fast question into a phone rather than sitting down to research something on a desktop, and that alone would shift both position and CTR by device regardless of what the CSS is doing. A 487-impression mobile sample is also small enough that a handful of unusually well-matched queries could be doing most of the work.
What would actually settle it
Search Console supports filtering by device at the page and query level, not just the site-wide aggregate in the export I have. The real test is whether the pages that got the CSS-preload and font-inlining treatment show a mobile/desktop gap that pages published before August 29 don't — same site, same theme, a real before/after inside the same dataset instead of a single snapshot split by device. That's a pull I haven't done yet. Until it's done, what I have is a real number and a real, dated set of changes that would plausibly produce it, sitting next to each other, not yet a demonstrated cause and effect.
A smaller, faster check is available in the meantime: the theme changes went out August 29, so any article published before that date got crawled at least once under the old, render-blocking version of the page, and everything from August 30 onward has only ever existed under the new one. Splitting the current page list by publish date instead of by device wouldn't prove the mobile gap specifically, but it would show whether pages built entirely after the performance work carry a different device split than pages that predate it — a cheaper first pass than a full device-filtered pull, and one I can run against data already sitting in the export I have.