Outline a strategy to improve LCP and CLS for blog article pages
Pinpointing LCP/CLS via render, not generic tips.
Fix LCP with server speed, resource hints, critical CSS; fix CLS with explicit sizes and font-display.
What's really being asked
This tests your grasp of the rendering pipeline and whether you can diagnose specific Core Web Vitals instead of reciting generic checklists. Interviewers want to see you distinguish loading performance from visual stability, identify the actual LCP element, and sequence fixes by impact. Senior candidates should tie metrics to user experience and business outcomes.
The full answer
Structure the strategy into LCP and CLS tracks. For LCP, start with server response time because the clock starts at TTFB; optimize hosting or edge caching to get under 600 ms. Eliminate render-blocking resources by inlining critical CSS and deferring non-critical JavaScript. Use preconnect for third-party origins and preload for the LCP image if it is discoverable early. Optimize the LCP image with responsive srcset, modern formats like AVIF or WebP, and explicit width and height attributes. For CLS, reserve space for ads, embeds, and dynamic recommendations using aspect-ratio CSS or min-height containers. Stabilize web fonts with font-display swap or optional and preload font files. Avoid injecting banners or modals above existing content after paint.
The mistakes people make
Lazy loading the LCP hero image directly delays the metric you are trying to improve. Answering with only a CDN and caching ignores the critical rendering path, render-blocking scripts, and font loading. Proposing to remove all third-party scripts without a measurement plan is weak; senior engineers should audit with Chrome DevTools or Lighthouse and prioritize by impact. Confusing CLS with purely CSS issues while ignoring dynamically injected content is another red flag.
What usually comes next
Be ready to contrast Lighthouse lab data with field data from the Chrome User Experience Report. The interviewer might ask how to handle an LCP element that is a CSS background image, or how to manage CLS during route transitions in a single-page app. Another follow-up is balancing font-display swap, which prevents invisible text but can cause a flash of unstyled text that shifts layout.
A concrete example
Imagine a blog article where the LCP element is a hero image. The current page loads a 2 MB JPEG via a synchronous CSS background-image rule and uses a web font that swaps in after 1.5 seconds, causing a 0.15 CLS. Move the hero image to an img tag with fetchpriority high, convert it to a 200 KB AVIF with srcset, and add width and height attributes. Inline critical above-the-fold CSS, defer the rest, and preload the font with font-display optional. Add a min-height container for the sidebar ad slot so insertion does not shift article text. These changes directly target the 2.5 second LCP and 0.1 CLS thresholds.
Interview question
For a blog page whose LCP is a hero image and CLS stems from a late web font and dynamic sidebar ad, which strategy is most effective?
- a.Set fetchpriority high on the hero image, inline critical CSS, preload the font with font-display optional, and reserve min-height for the ad containerCorrect
- b.Move the hero image to a CSS background, add a CDN, and inject the ad only after user interaction
- c.Lazy-load the hero image, defer all CSS, and remove the sidebar ad
- d.Upgrade hosting only, convert the image to WebP, and use font-display swap without preloading
Why? this is the answer
The correct strategy fixes the rendering path by prioritizing the LCP image, removing render-blocking CSS, stabilizing fonts, and reserving space for injected content. Option D is tempting because it includes legitimate optimizations, but it ignores render-blocking resources, omits font preloading, and fails to reserve space for the ad, so CLS remains unaddressed.
Just read this? Test yourself on what you have been reading.
Read the original → web.dev
- #performance
- #core-web-vitals
- #front-end
- #lcp
- #cls
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on performance — each one lists the topics its interview covers.
See open roles