Frontend Development Fundamentals, Part 3: Shipping It

Parts 1 and 2 covered building blocks and architecture. Neither matters much if the result is slow to load or unusable for a chunk of your visitors. This post closes the series with the checks worth running before anything ships.

Performance: measure the moments users feel

Core Web Vitals give you three numbers worth caring about, because they map to things a person actually notices:

• LCP (Largest Contentful Paint) — how long until the main content is visible
• INP (Interaction to Next Paint) — how long a click or tap takes to respond
• CLS (Cumulative Layout Shift) — whether the page jumps around while loading

The highest-leverage fixes are usually boring: set explicit dimensions on images so the layout doesn't shift when they load, defer non-critical JavaScript instead of blocking the initial render, and preload the fonts and hero image the page actually needs on first paint.

<link rel="preload" as="image" href="/hero.avif" />
<img src="/hero.avif" width="1200" height="600" alt="…" />

Chasing a Lighthouse score in the abstract is less useful than fixing the one metric that's actually failing for real users — check field data (from something like the Chrome UX Report) before optimizing against lab data alone.

Accessibility: the checks that catch the most

A full WCAG audit takes time, but a short list catches most real-world failures:

• Every interactive element is reachable and operable by keyboard alone (no onClick on a <div> with no tabindex or keyboard handler)
• Color contrast meets 4.5:1 for body text, 3:1 for large text
• Images have meaningful alt text, or empty alt="" if they're purely decorative
• Form inputs have associated <label> elements, not just placeholder text
• Focus is visible — never outline: none without a replacement focus style

Most of these are cheap to fix when caught early and expensive to retrofit once a component is used in forty places. Running an automated check (axe, Lighthouse) in CI catches the mechanical failures; only manual keyboard and screen-reader testing catches the rest.

Shipping is a checklist, not a feeling

"It works on my machine" and "it feels fast" are both unreliable signals. What holds up is a short, repeatable checklist run before every release: real device testing on a mid-range phone over a throttled connection, a keyboard-only pass through the main flows, and a look at field performance data after deploy — not just before.

That's the series: the platform's building blocks, the architecture that organizes them into an application, and the checks that make sure it actually reaches people. None of it is exotic — it's the same handful of fundamentals, applied consistently.