Performance

Core Web Vitals and what we actually optimize

Core Web Vitals measure parts of the real user experience that are easy to damage with careless implementation.

Core Web Vitals measure parts of the real user experience that are easy to damage with careless implementation.

Largest Contentful Paint

LCP is heavily affected by what appears in the first viewport. Large hero images, render-blocking fonts, slow server responses, and unnecessary client-side rendering can all push the main content later. We improve LCP by making the critical content available early, controlling image size, and avoiding scripts that compete with the first render.

Interaction to Next Paint

INP reflects how responsive the page feels when a person interacts with it. Large JavaScript bundles and long-running tasks can make simple actions feel delayed. Keeping most content server rendered helps because the browser has less application code to execute.

Cumulative Layout Shift

CLS measures unexpected movement. Images without dimensions, late font swaps, injected banners, and unstable components can all move content after the page appears. We reserve space for media, keep responsive rules predictable, and avoid inserting layout-changing elements after initial render unless the feature truly requires it.

We do not optimize metrics in isolation

A low LCP does not matter if the page is unusable. A perfect CLS score does not matter if the content is weak. The goal is a site that feels immediate, stable, and responsive while still doing its actual business job.

The metrics map back to architecture

We do not treat Core Web Vitals as three isolated numbers to chase. Each metric points toward recurring implementation decisions. LCP usually makes us inspect the first viewport, image loading, fonts, server response, and whether JavaScript is delaying meaningful content. INP makes us inspect how much work runs in the browser and what happens when the user interacts. CLS makes us inspect whether the layout had enough information to reserve its final shape.

That is why our performance work starts before Lighthouse. A server-first route, a controlled hero image, a primary font with sensible loading behavior, and a narrow client bundle create a better baseline than a heavy page that needs extensive remediation later.

LCP is often an image or priority problem

On image-heavy sites we use next/image, responsive sizes, modern formats, and selective priority loading. One of our repos goes further by configuring generated image widths, quality levels, AVIF and WebP support, and a long optimized-image cache lifetime. Those controls matter because a visually identical hero can have radically different loading cost depending on the source and priority decisions behind it.

The first image is allowed to be important. The fifth image should not compete as if it were.

INP is where JavaScript restraint shows up

A page can look finished while the main thread is still busy parsing, hydrating, and executing code. That is why we keep interactive islands small. A navigation effect may use one passive scroll listener. A modal owns its own state. A gallery owns its key handlers. Most content does not become client-side state at all.

Our JavaScript budget exists because responsiveness is easier to protect when less code needs to run.

CLS rewards knowing the final layout early

Static image dimensions, aspect ratios, stable font behavior, and deliberate viewport sizing all reduce unexpected movement. Full-height sections also need care on mobile because browser chrome changes the visible viewport. We use modern viewport units and minimum-height fallbacks where the design calls for a screen-filling composition.

The detailed reasoning is in Why full-screen sections are harder than writing 100vh.

Field data still matters

Lab tools are useful because they give us reproducible conditions and detailed traces. Real users have different phones, networks, browser extensions, cache states, and interaction patterns. We use synthetic testing to find technical problems, then keep the larger goal in view: the page should feel fast, stable, and responsive under the conditions customers actually use.

From explanation to proof

Where this connects to the work

The performance library explains why our technical scores tend to be unusually strong without treating the score itself as the product.