I85PREP
⌘ K
Akamai Web Performance study materials
Akamai Web Performance study resources

Image-heavy Landing Page Slow on Mobile Despite CDN

Akamai Web Performance · Put your knowledge to work in context.

All case studies

Image-heavy Landing Page Slow on Mobile Despite CDN

A media company's article landing page loads 38 hero and thumbnail images, all served through the CDN with long TTLs and a 99% hit rate. Lab tests on desktop show a 1.2s LCP. Field data from mobile users shows LCP at 6.5s, with the hero image consistently the LCP element. Images are delivered as full-resolution JPEGs (average 800 KB, up to 2.4 MB), no srcset, no width/height attributes, and the hero is loaded with a CSS background-image. Third-party analytics scripts load synchronously in the head. The CDN has image manipulation (resize, format conversion) available but unused.

1. Explain why a 99% CDN hit rate and long TTLs still produce a 6.5s mobile LCP.

Read the worked answer

CDN hit rate measures cache efficiency, not user-perceived performance. A hit still transfers the full 800 KB-2.4 MB JPEG over the last mile, which on a constrained mobile link dominates LCP. Several independent problems compound:

  • No responsive images: every device downloads desktop-sized bytes.
  • No srcset/sizes: the browser can't pick an appropriately sized candidate.
  • CSS background hero: the browser's preload scanner can't discover it early, and it competes with other resources; it also can't be prioritized as an LCP image.
  • Missing width/height: layout shifts and later paint.
  • Synchronous analytics in head: blocks parsing and delays discovery of the hero.

So the cache is doing its job; the payload and delivery path are wrong for mobile. Hit rate and TTL are necessary but not sufficient.

2. Prioritize fixes and describe how to use the CDN's image manipulation features to reduce LCP.

Read the worked answer

Priority order by expected LCP impact:

  1. Convert the hero from CSS background to an <img> (or <picture>) with fetchpriority="high", explicit dimensions, and srcset/sizes. This makes it discoverable and prioritizable.
  2. Use CDN image manipulation to serve right-sized, modern-format variants (WebP/AVIF) - e.g., a 400/800/1200w ladder - and let srcset select. Expect large byte reductions on mobile.
  3. Defer or async the analytics scripts; move them out of the critical path.
  4. Add width/height (or aspect-ratio) to all images to prevent shifts.
  5. Lazy-load below-the-fold thumbnails, but never the LCP hero.

Justification: the hero is the LCP element, so fixes that shrink and accelerate the hero have the highest leverage. Image manipulation converts the CDN from a byte-delivery layer into a transformation layer, which is the missing piece here.

3. What measurement approach would you use to confirm improvement, and what pitfall should you avoid?

Read the worked answer

Use field data (RUM / CrUX) segmented by device class and connection type, not just lab tests. Lab tests on desktop masked the problem because they don't reflect mobile CPU/network constraints. Track LCP at p75 for mobile, plus supporting metrics (CLS, TTFB, total image bytes).

Pitfall: don't declare victory from a single lab run after changes. Lab tools can show dramatic improvement while real users on slow links still lag. Also avoid optimizing average LCP - the p75 is what matters for the experience of slower users. Roll out changes behind a canary and compare p75 LCP for mobile cohorts before/after, holding traffic mix constant.