Web Performance

Key Points

• The LCP element is whatever is biggest in the first viewport: ~three-quarters of the time an image (hero, product photo, carousel slide), otherwise a heading or text block. DevTools’ Performance panel and PageSpeed Insights name the exact element , always identify it before optimising anything.
• LCP decomposes into four sequential parts, and the fix depends on which dominates: TTFB (server slow) → resource load DELAY (browser discovered the image late) → resource load TIME (image big/far) → render delay (element ready but blocked from painting).
• Load delay is the classic frontend loss: an image referenced only in CSS (background-image), injected by JavaScript, or lazy-loaded is invisible to the preload scanner and starts downloading seconds late. Fixes: a real <img> in the HTML, <link rel="preload">, fetchpriority="high" , and NEVER loading="lazy" on the LCP image.
• Load time fixes are the image-optimisation playbook: modern formats (AVIF/WebP), responsive srcset sizes so phones do not download desktop pixels, compression, and a CDN close to users. Next.js <Image priority> bundles most of this , that is exactly what its priority prop is for.
• Render delay: the image arrived but render-blocking CSS, a synchronous script, or client-side rendering (an SPA shell waiting for its JS bundle before showing ANYTHING) holds the paint. Server-side rendering of above-the-fold content is largely an LCP strategy.
• Text-LCP pages fail differently: web fonts. font-display: swap shows fallback text immediately (protects LCP, risks a layout shift when the real font lands), preloading the font file narrows the window.

Key Points

• Three phases add up to each interaction’s latency: input delay (main thread busy, your handler cannot even START), processing time (the handler itself runs), presentation delay (rendering the resulting frame). Any of the three can be the problem.
• The browser paints nothing while the main thread is busy , a 500ms synchronous handler means half a second of frozen page. The 200ms budget is for the FEEDBACK frame, not the completed work: show the pressed state now, finish the work after.
• Input delay is caused by OTHER long tasks: hydration, analytics, a rendering storm from a previous interaction. That is why INP problems often are not in the handler the user blames , the thread was already jammed when the tap landed.
• Fix pattern one, break up long tasks: yield to the main thread inside big loops so input can be handled between chunks , await scheduler.yield() (Chrome 129+/Firefox 142+, not yet Safari , fall back to setTimeout(0)), and requestAnimationFrame for paint-aligned updates.
• Fix pattern two, do less on interaction: paint feedback first, defer the heavy part (startTransition in React marks the expensive state update as interruptible), move pure computation to a Web Worker, debounce per-keystroke work.
• Fix pattern three, render less: presentation delay grows with DOM size and render cost , a keystroke that re-renders a 5,000-row list will miss 200ms no matter how fast the handler is. Virtualise, memoise, narrow the update.

Key Points

• The score multiplies how MUCH of the viewport shifted by how FAR it shifted , a footer nudging 2px is noise; the whole article dropping 300px because a banner appeared is a failing score in one event.
• Cause #1, media without reserved space: an <img> with no width/height collapses to zero, then shoves everything down when pixels arrive. Fix: always set width and height attributes (the browser derives aspect-ratio and reserves the box) , unsized images affect roughly two-thirds of mobile pages.
• Cause #2, injected content: ads, cookie banners, promos inserted ABOVE existing content. Fix: reserve a fixed slot (min-height) whether or not it fills, overlay instead of insert, or add space only below the viewport.
• Cause #3, web fonts: fallback and web font metrics differ, so the swap reflows the page. Fixes: font-display: optional (no swap after first paint), preloading the font, and size-adjust/f-mods on the fallback , next/font does this metric-matching automatically.
• Cause #4, late-hydrating or client-only UI that pops in above the fold (skeletons that are a different height than the content they become count too , match skeleton dimensions to the real thing).
• Only unexpected shifts count: expansion the user triggered (accordion click) is exempt within 500ms, and transform/opacity animations never shift layout , animate those, not top/left/height.

Key Points

• Lab (Lighthouse, WebPageTest, DevTools): deterministic-ish, runs anywhere including CI and pre-production, gives film strips and traces to debug WITH , but it is one synthetic device/network, nobody interacts (so INP is nearly invisible), and nothing below the fold or post-load is exercised.
• Field (CrUX, or your own RUM via the web-vitals library): the real distribution across devices, networks, and behaviour , this is what Google ranks on. Costs: you need traffic, and CrUX aggregates over a trailing 28-day window, so a fix takes weeks to fully reflect.
• PageSpeed Insights shows both stacked on one page: CrUX field numbers on top (when the URL/origin has enough traffic), a fresh Lighthouse lab run underneath , the fastest way to see whether they disagree.
• Disagreements are diagnostic: lab good + field bad → real users are on slower devices or hit post-load problems (scroll CLS, interaction INP) the lab never sees. Lab bad + field good → your audience skews fast; fix it anyway, but calmly.
• Search Console’s Core Web Vitals report groups your URLs by pass/fail from CrUX , the practical to-do list, and the place ranking impact becomes visible.
• Serious teams run their own RUM (web-vitals library posting to an analytics endpoint) , same metrics as CrUX but real-time, segmentable by page, device, and release, with attribution data CrUX does not expose.