Last year I audited a client’s site that scored 92 on desktop PageSpeed Insights and 38 on mobile. Same site. Same content. Same server. The owner couldn’t understand why mobile was so different. “Isn’t it the same page?” he asked.
It’s not. And that gap between desktop and mobile performance is where most site owners are losing visitors, rankings, and money without realizing it.
Mobile devices account for 60%+ of web traffic in most niches. In some industries, it’s over 75%. But mobile browsers are working with slower CPUs, less memory, and flaky network connections. The page your desktop loads in 2 seconds might take 6-8 seconds on a mid-range Android phone over a 4G connection. And that’s the phone most of your visitors are using. Not the latest iPhone. A $200 Samsung phone that’s 2 years old.
Google has been mobile-first indexing since 2019. Your mobile performance IS your performance in Google’s eyes. If your mobile Core Web Vitals are bad, your desktop scores don’t save you.
Why Desktop-Fast Doesn’t Mean Mobile-Fast
The performance gap between desktop and mobile comes from three fundamental differences that no amount of WordPress optimization can completely eliminate. But understanding them helps you make smarter decisions.
CPU Processing Power
A desktop processor is 3-5x faster than a mobile processor at executing JavaScript. That animation library that takes 50ms to parse on your laptop? It takes 200ms on a phone. Multiply that across 15 scripts and you’re looking at seconds of difference in JavaScript execution time alone.
This is why JavaScript is the number one mobile performance killer. Every kilobyte of JavaScript costs more on mobile than on desktop. Not just in download time, but in the CPU time needed to parse, compile, and execute it.
Network Conditions
Desktop users typically have stable broadband connections with 50-200Mbps speeds and latency under 20ms. Mobile users? Average 4G connections deliver 15-30Mbps with latency of 50-100ms. And that’s when they have a good signal. Walk into a building, get on a crowded subway, or step into a rural area and those numbers get much worse.
Every HTTP request, every DNS lookup, every TLS handshake is amplified on mobile. A resource that takes 20ms to fetch on desktop might take 200ms on mobile. When your page makes 80 requests, that overhead adds up fast.
Thermal Throttling
Here’s one most people don’t think about. When a mobile CPU works hard, the phone heats up. When it heats up, the OS reduces CPU speed to prevent overheating. So that heavy JavaScript that already takes longer on mobile? Halfway through execution, the phone throttles the CPU and it takes even longer.
I’ve measured this on real devices. A page that takes 3 seconds to become interactive when the phone is cool takes 5+ seconds after the phone has been in someone’s pocket or sitting in the sun. This is why lab tests on a fresh phone don’t always match real-world experience.
Mobile-Specific Testing
You can’t test mobile performance on your desktop browser and call it done. You need to test under real mobile conditions.
Chrome DevTools Throttling
Open Chrome DevTools, go to the Performance tab, and enable CPU throttling (4x slowdown) and network throttling (Slow 3G or Fast 3G). This simulates what a mid-range phone experiences.
I test every client site with these settings:
Network: Fast 3G (about 1.6Mbps download, 750Kbps upload, 150ms latency)
CPU: 4x throttle
These conditions are harsher than what most mobile users experience, but that’s intentional. If your site performs well under these conditions, it’ll perform well for most real-world users. Test under good conditions and you’re only optimizing for users who don’t need the optimization.
Lighthouse Mobile Audit
Run Lighthouse in Chrome DevTools with the “Mobile” preset selected. Pay attention to these specific metrics:
Performance Score: Aim for 70+. Getting above 90 on mobile is hard for content-rich sites with ads. Be realistic.
Total Blocking Time (TBT): This measures how long JavaScript blocks the main thread. If TBT is over 300ms, you have too much JavaScript executing during page load.
Largest Contentful Paint (LCP): Should be under 2.5 seconds. On mobile, the biggest factor is usually image size and server response time.
Cumulative Layout Shift (CLS): Should be under 0.1. Mobile devices have smaller viewports, so even small shifts feel bigger to users.
Real Device Testing
Nothing replaces testing on a real phone. I keep two test devices: a current-year iPhone and a 2-3 year old mid-range Android (usually a Samsung Galaxy A series). The Android is the more important test because it represents the majority of global mobile users.
Connect your phone to your computer, open Chrome on the phone, and use chrome://inspect on your desktop to access DevTools for the mobile browser. This gives you real device performance data, not simulation.
If you don’t have test devices, Google’s PageSpeed Insights uses real Chromium browsers on real hardware. The “Origin Summary” data at the top of the report is actual field data from real users. That’s more valuable than any lab test.
Touch Targets and Mobile CLS
Mobile has specific layout issues that don’t appear on desktop.
Touch Target Sizing
Google recommends touch targets (buttons, links, form fields) be at least 48×48 CSS pixels with at least 8 pixels of spacing between them. This isn’t just usability, it’s a Core Web Vitals factor.
When touch targets are too small or too close together, users accidentally tap the wrong thing. They hit back. They tap again. Each accidental tap triggers a page load, wastes time, and frustrates your visitor. I’ve seen heatmaps where the most-tapped area on a mobile page was the wrong link because it was too close to the target link.
Mobile-Specific CLS Problems
Layout shifts hit harder on mobile because the viewport is narrow. A 200-pixel shift on a 1440px desktop screen is annoying. The same shift on a 375px phone screen pushes content halfway off the page.
Common mobile CLS culprits:
Cookie consent banners that push content down. Use a bottom-mounted banner that overlays content instead of pushing it. Or better yet, use a banner that loads with the page instead of popping in after 2 seconds.
Ad slots that load late. If you run ads, reserve the exact space for each ad slot using CSS min-height. When the ad eventually loads, it fills the reserved space without shifting anything.
Web fonts that cause text to reflow. On mobile, a font swap can shift entire paragraphs. Use font-display: swap with proper size-adjusted fallback fonts that match the web font’s metrics closely.
Images without dimensions. Always set width and height attributes on images. CSS aspect-ratio works too. Without these, the browser doesn’t know how tall an image will be until it downloads, causing everything below it to jump.
Navigation that expands on load. If your mobile menu starts collapsed and then JavaScript expands it, or if a search bar slides in after page load, that’s a layout shift. Load these elements in their final state.
AMP: Dead or Alive?
I’ll be direct. I don’t recommend AMP anymore, and I haven’t for the past few years.
AMP (Accelerated Mobile Pages) was Google’s project to create lightweight versions of web pages. It worked by restricting what HTML, CSS, and JavaScript you could use and serving cached pages from Google’s servers.
The speed was real. AMP pages loaded fast. But the tradeoffs killed it for most sites:
Google removed the AMP ranking advantage. AMP pages no longer get preferential treatment in search results. The “Top Stories” carousel is open to any page that meets Core Web Vitals thresholds. This was the main reason people adopted AMP, and it’s gone.
AMP limits your design and functionality. No custom JavaScript (only AMP components). Limited CSS (inline only, under 75KB). No third-party scripts unless there’s an AMP component for it. For a blog, maybe workable. For anything with interactive features? Forget it.
Maintenance burden. Running AMP means maintaining two versions of every page: your regular version and the AMP version. That’s double the testing, double the potential for bugs, and a constant source of content sync issues.
What to do instead: Build a fast mobile site. Seriously. If your site passes Core Web Vitals, you get every benefit AMP used to provide, without any of the restrictions. Focus on the techniques in this chapter and the rest of this course. A well-optimized WordPress site can match or beat AMP speeds.
Mobile Image Optimization
Images are typically 50-70% of a mobile page’s total weight. On a phone with a 375px-wide screen, you don’t need the same 1200px image you serve to desktop.
Responsive Images
WordPress has handled responsive images automatically since version 4.4. When you upload an image, WordPress creates multiple sizes. The srcset attribute in the HTML tells the browser which size to download based on the viewport.
But “automatic” doesn’t mean “optimal.” Check your theme’s registered image sizes. Many themes register sizes that don’t match common mobile viewports. I’ve seen themes that generate a 768px “medium” image as the smallest size. For a phone that’s 375px wide, you’re still downloading an image twice as large as needed.
Add a custom image size that matches your mobile content width:
add_image_size('mobile-content', 400, 0, false);And make sure your theme’s content images include this size in the srcset.
The Picture Element for Art Direction
Sometimes you don’t just need a smaller image. You need a different crop. A wide hero image that works on desktop might show a tiny, unrecognizable subject on mobile. The <picture> element lets you serve completely different images based on screen size:
<picture>
<source media="(max-width: 768px)" srcset="hero-mobile.webp">
<source media="(min-width: 769px)" srcset="hero-desktop.webp">
<img src="hero-desktop.webp" alt="Description" width="1200" height="600">
</picture>I use this for hero images and feature images on client sites. The mobile version is cropped tighter on the subject and saved at a smaller file size. The difference in load time is noticeable.
WebP and AVIF on Mobile
Modern image formats make a bigger difference on mobile because the bandwidth savings are more impactful on slower connections. A 200KB JPEG that converts to an 80KB WebP saves 120KB. On a fast desktop connection, you barely notice. On a 4G connection with 150ms latency, that’s a meaningful improvement.
AVIF compresses even better than WebP, about 20-30% smaller for equivalent quality. But encoding AVIF is slower, so it’s best for static images that can be pre-generated rather than dynamically converted on the fly.
Reducing JavaScript Execution Time
This is the single biggest thing you can do for mobile performance. JavaScript is the most expensive resource type on mobile, and most WordPress sites load way too much of it.
Audit Your JavaScript
Open Chrome DevTools with mobile throttling enabled. Go to the Coverage tab (Ctrl+Shift+P, type “coverage”). Reload the page. You’ll see every JavaScript file with a percentage showing how much of the code was actually used during page load.
I’ve tested client sites where 70-80% of the loaded JavaScript was never executed during the initial page load. That’s hundreds of kilobytes of code the phone had to download, parse, and compile for nothing.
Specific Reductions
Defer non-critical scripts. Any JavaScript that isn’t needed for above-the-fold content should have the defer attribute. This includes analytics, chat widgets, social sharing buttons, and comment systems. Let the page render first, then load the extras.
Remove unused jQuery plugins. Many WordPress themes and plugins still load jQuery plus their own scripts. If a plugin loads a jQuery slider but your page doesn’t have a slider, that’s wasted JavaScript. Use the Asset CleanUp or Perfmatters plugin to conditionally disable scripts on pages that don’t need them.
Delay third-party scripts. Chat widgets, analytics, retargeting pixels, and social scripts don’t need to load immediately. Delay them until user interaction (scroll, click, mouse move). This removes them from the critical loading path entirely.
Inline critical JavaScript. If you have a small script that’s needed for above-the-fold functionality (like a mobile menu toggle), inline it instead of loading it as a separate file. Eliminates one HTTP request.
On one client site, I reduced JavaScript from 780KB to 210KB by removing unused code, deferring non-critical scripts, and replacing two heavy libraries with lightweight alternatives. Mobile Lighthouse performance score went from 41 to 78.
The Mobile Performance Checklist
I run through this on every client project. It takes about an hour and catches the most common mobile issues:
Test on real mobile conditions. Chrome DevTools with 4x CPU throttle and Fast 3G network. Not just desktop Lighthouse.
Check LCP on mobile. Identify the largest element in the mobile viewport. Is it an image? Make sure it’s properly sized, in WebP/AVIF format, and has fetchpriority="high".
Check CLS on mobile. Scroll through the page on a throttled connection. Do elements jump? Reserve space for ads, images, and dynamic content.
Count JavaScript files. How many scripts load on mobile? Can any be deferred, delayed, or removed?
Check touch targets. Are buttons and links at least 48×48 pixels? Is there spacing between tappable elements?
Verify responsive images. Do images serve appropriately sized versions for mobile? Check the rendered size vs. the downloaded size in DevTools.
Test font loading. Do web fonts cause visible text reflow? Use font-display: swap with size-adjusted fallback fonts.
Check viewport meta tag. Make sure you have <meta name="viewport" content="width=device-width, initial-scale=1">. Without this, mobile browsers render the page at desktop width and scale it down.
Progressive Web App Features
PWAs (Progressive Web Apps) add native-app features to websites: offline access, push notifications, home screen icons, background sync. For blogs and content sites, most of these are overkill.
But two PWA features are worth considering:
Service worker caching. A service worker can cache your site’s static assets (CSS, JavaScript, images) so repeat visits load almost instantly, even on bad connections. For a site with returning visitors, this is a real speed win. The first visit is the same, but every visit after that feels instant.
Web App Manifest. Adding a manifest.json lets mobile users “install” your site to their home screen. It loads without browser chrome (no URL bar), feels like a native app, and launches faster. For sites with loyal audiences (newsletters, tools, reference sites), this improves the experience.
I wouldn’t recommend going full PWA for a typical blog. The implementation complexity isn’t worth it. But adding basic service worker caching through a plugin like PWA for WP takes 10 minutes and makes repeat visits noticeably faster.
Real Mobile Results
Numbers from actual client projects:
Tech blog (200 posts, 15 plugins): Mobile score went from 34 to 72. Main fixes: deferred JavaScript (-350KB), mobile-optimized images (-400KB total), removed two unused plugins. Mobile bounce rate dropped 22%.
Local business site (12 pages, 8 plugins): Mobile score went from 51 to 89. Main fixes: replaced page builder with native blocks, added responsive image sizes, delayed chat widget until scroll. Average mobile session duration increased 40%.
WooCommerce store (800 products, 28 plugins): Mobile score went from 28 to 61. Main fixes: reduced JavaScript execution by 60%, served WebP images, added proper image dimensions to product grids. Mobile conversion rate increased 15%.
These aren’t lab results. They’re production sites with real traffic and real business outcomes. Mobile performance directly affects how people use your site and whether they buy, subscribe, or come back.
The key insight from all three projects: JavaScript reduction had the biggest impact on mobile scores. Image optimization had the biggest impact on actual load times. Both matter, but if you’re going to prioritize, start with JavaScript on mobile.
Chapter Checklist
- [ ] Test your site with Chrome DevTools mobile throttling (4x CPU, Fast 3G)
- [ ] Run Lighthouse with the mobile preset and note TBT, LCP, and CLS scores
- [ ] Identify your LCP element on mobile and confirm it’s optimized
- [ ] Check for mobile-specific CLS issues (cookie banners, ads, font loading)
- [ ] Audit JavaScript with the Coverage tab and note unused percentage
- [ ] Defer or delay all non-critical JavaScript
- [ ] Verify responsive images serve appropriate sizes for mobile viewports
- [ ] Check all touch targets are at least 48×48 pixels
- [ ] Test on a real mid-range Android device if possible
- [ ] Set explicit width/height or aspect-ratio on all images
Chapter Exercise
Pull up your site in Chrome DevTools with mobile throttling enabled (4x CPU slowdown, Fast 3G). Run a Lighthouse mobile audit and note your scores. Then open the Coverage tab and reload. Identify the three largest JavaScript files with the highest unused percentage. For each one, determine if it can be deferred, replaced, or removed. Make the changes, re-run Lighthouse, and document the before and after scores. Aim for at least a 15-point improvement in the Performance score.