Mobile Web Performance
debt(d5/e7/b7/t9)
Closest to 'specialist tool catches it' (d5). The detection_hints list Lighthouse, PageSpeed Insights, WebPageTest, and Chrome DevTools — all specialist tools requiring deliberate invocation. Mobile performance issues don't surface during normal desktop development or default linting; a developer must explicitly run a mobile audit or enable CPU/network throttling to see the problem.
Closest to 'cross-cutting refactor across the codebase' (e7). The common_mistakes span JS bundle architecture (code-splitting), image pipelines, lazy loading, and interaction model (hover vs. touch). Fixing a site-wide mobile performance deficit touches asset delivery strategy, build tooling, image handling, and component design across the entire codebase — well beyond a single-file fix and typically requiring sustained multi-team effort.
Closest to 'strong gravitational pull' (b7). Mobile performance applies broadly to the entire web context (applies_to: web). Addressing it shapes architectural decisions in every work stream: how JS is bundled and split, how images are served, how interactions are designed, and how rendering is prioritised. Every new feature must be evaluated against mobile constraints, making this a persistent, shaping constraint on development.
Closest to 'catastrophic trap — the obvious way is always wrong' (t9). The misconception field states exactly this: a fast desktop experience is assumed to mean a fast mobile experience, but mobile CPUs execute JavaScript 4-5x slower. A site scoring 95 on desktop Lighthouse can score 35 on mobile. This is the canonical case of the obvious approach (test on desktop, ship) being systematically and silently wrong for the majority of users.
Also Known As
TL;DR
Explanation
Mobile constraints differ from desktop: CPU is 4-5x slower (script execution is the bottleneck), RAM is limited (50-300MB browser budget), connection is high-latency even on 4G (100-200ms RTT vs 5ms wired), and battery drains on JS execution. Optimisation priorities: minimise main-thread JS (defer, lazy load, web workers), reduce layout thrashing (batch DOM reads and writes), use CSS animations over JS (GPU composited), compress images aggressively (AVIF, WebP), preconnect to third-party origins, and keep Time to Interactive under 5 seconds on a mid-range device.
Common Misconception
Why It Matters
Common Mistakes
- Testing only on desktop or flagship phones — use Chrome DevTools throttling or real mid-range devices.
- Large JavaScript bundles — 500KB of JS takes 5+ seconds to parse and execute on mid-range mobile.
- No image compression — images are 50-80% of mobile page weight.
- Hover-dependent interactions — mobile has no hover state; use touch events or tap targets.
Code Examples
// Bundle served to all devices — 2MB JS:
// webpack output: bundle.js 2.1MB
// Mobile mid-range (Moto G5): 12 seconds to parse
// Battery drain: high
// Result: 40% bounce rate on mobile// Code splitting + lazy loading:
// Critical bundle: 80KB (loads immediately)
import('./checkout').then(m => m.init()); // 150KB loaded only on checkout
import('./admin').then(m => m.init()); // Never loaded for regular users
// Defer non-critical JS:
<script defer src="analytics.js">
// Respect user's data-saver preference:
if (!navigator.connection?.saveData) {
loadHeroVideo();
}
// Test with throttling:
// Chrome DevTools: Network > Slow 4G, CPU > 4x slowdown