Developer/FrontendWebMobile/CoreWebVitals/CaseStudies/smashing-magazine-core-web-vitals-case-study

Smashing Magazine's Core Web Vitals Case Study

Problem + constraints

In 2021, Smashing Magazine — itself a web-performance publication, which raised the stakes on getting this right publicly — set out to pass Core Web Vitals on mobile. Their starting position wasn't a typical bloated site: the site was statically generated (no server-side rendering delay), everything needed for the initial paint was inlined, and it was served from Netlify's CDN, so there were no obvious "big wins" like removing SSR latency or moving to a faster host. Their two weak metrics were LCP (Largest Contentful Paint, too slow on mobile) and CLS (Cumulative Layout Shift, the metric with the most room for improvement). The constraint that made this a real case study rather than a rewrite: they wanted to keep custom web fonts and images rather than stripping the site down to plain text, which is the easy but unrepresentative way to pass Core Web Vitals.

Solution

Two concrete, non-obvious moves stand out:

Changed which element counts as LCP, not just how fast it loads. The article header originally had the author's photo positioned above the headline — meaning the image was the LCP element, and images are inherently slower to become "the largest contentful paint" than text, since they require a network round-trip and decode step the browser's text renderer doesn't. Smashing swapped the layout so the headline sits above the author image, and bumped the mobile headline font size slightly. This didn't just move pixels around — it changed which DOM node the browser measures LCP against, from a slow-loading image to text that's available the instant the HTML/CSS parses.
Used prefers-reduced-data to skip custom web fonts on the initial render for users who signal a data constraint, falling back to system fonts instead — trading a small amount of visual polish for faster first paint on exactly the connections where it matters most, without removing custom fonts for everyone.

Neither change touched infrastructure (already fast: static + CDN) or removed content — both were front-end layout and CSS decisions specifically targeted at which element the browser measures, not just raw asset weight.

What to steal

Audit which DOM element is actually your LCP candidate before optimizing asset weight. Compressing an image that's already fast to decode won't move LCP if a slower-loading image elsewhere in the layout is the one the browser is actually measuring. Chrome DevTools' Performance panel and PageSpeed Insights both name the LCP element directly — check it before guessing.
Reordering DOM/visual hierarchy is a legitimate LCP lever, not just a compression or caching one. If a page's "biggest" element by area is naturally slow to load (an image, an embed), consider whether text can legitimately be the largest element instead, rather than only chasing image-loading speed.
prefers-reduced-data is an underused progressive-enhancement lever for anything font- or asset-heavy: it lets a site keep richer defaults for most users while degrading gracefully for users who've explicitly signaled a data constraint, rather than a blanket "ship the lightest possible version to everyone" tradeoff.
Being already static + CDN-hosted didn't make them exempt from Core Web Vitals problems — infrastructure speed and perceived metric speed (which element the browser counts, and how much it visually shifts) are separate problems that need separate fixes.

Engineering Lens

The instructive part of this case study isn't the specific fixes — it's the diagnostic step before them: they didn't start by compressing images or trimming JavaScript, they started by asking which element is the browser actually scoring us on. That's a transferable habit for any perceived-performance metric: profile what's being measured before optimizing what seems slow, since the two aren't always the same DOM node.

Sources