Marketing metrics answer the demand question: how do people find the product, what does it cost to bring them in, and are they worth more than they cost? SEO is the part of that question a frontend team is genuinely on the hook for — a chunk of it is frontend work — so it makes a natural bridge from performance metrics to growth ones. Here's the set, from the markup you own to the economics of a customer.

Product metrics answer a different question from "is the frontend fast?" — they ask whether the product delivers value: do people show up, do they reach the aha moment, do they come back, and do they stick around. Almost all of it is measured in the browser by frontend event tracking, but the numbers describe the product, not the frontend's health. Here's the set that actually changes decisions.

Most people install Claude Code, talk to it like a chatbot, and stop there. The difference between that and a genuine force multiplier is a small amount of configuration: a file that tells it your conventions, a couple of hooks that enforce quality automatically, and one skill that encodes a workflow you'd otherwise re-type every day.

There are more kinds of software test than anyone can keep straight — unit, integration, contract, snapshot, mutation, smoke, load, chaos. This post walks through each one, what it actually buys you, and whether it earns its place in a real codebase.

The first load of a Next.js app is a document — HTML down the wire, parsed, hydrated. But once the app is interactive, open your Network tab and you'll notice it never asks for a document again. Instead you see a trickle of odd little requests: some are GETs that return something that isn't HTML, and some are POSTs to the page you're already on, streaming a response back. Those POSTs are the part that looks weird, and they're the reason this post exists.

You type a domain, hit Enter, and a second later you're clicking around a working app. That second is deceptively busy. Between the keystroke and the first working button there's a DNS lookup, a couple of cryptographic handshakes, a streamed HTML document, a fan of parallel downloads, a serialized React tree, and a reconciliation pass that stitches JavaScript onto server-rendered markup without throwing any of it away.

A design system that starts on the web rarely fits mobile directly. This post shows what still works on mobile, what doesn't, and how to keep one source of truth (one place that stores each design decision) for both.

"Rendering" is one of those words that means three different things depending on who you ask. Before we walk the timeline, it helps to separate the layers:

1. The rendering API — the actual function you call (ReactDOM.render, createRoot, renderToString…) to turn a component tree into DOM or HTML.
2. The rendering strategy — where and when the HTML is produced: in the browser, on a server per-request, at build time, etc.
3. The hydration model — how a server-produced HTML page becomes interactive on the client. The post is organized around layer 2 (strategies), because that's where the chronological and simple-to-complex story is richest — but each strategy is tagged with all three: an At a glance box names its rendering API and hydration model too. There's also a short section near the end that lists the API methods on their own, since "render a component" can literally mean those. Each strategy also has a Metrics table in web-vitals shorthand (TTFB, FCP, LCP, TBT, INP, CLS) — every acronym in this post is spelled out in the Glossary at the end.

One honest caveat up front: chronology and complexity mostly line up, but not perfectly. Islands and streaming SSR landed around the same time, for example. I've ordered primarily by conceptual complexity and noted the rough dates as we go.

Every framework, HTTP client, and browser hides the protocol behind a few convenient calls — so most developers never see the request that actually goes over the wire. This post pulls back that curtain: the communication model, the methods, the status codes, and the headers you've been using all along without knowing it.

Debugging a React single-page application (SPA) and debugging a Next.js App Router app are different sports, and the whole difference comes down to one thing: where your code runs. This is a recipe-oriented reference for the questions that keep coming up — where your logs went, how to see backend calls, how to observe React Server Components (RSC), and which logging options and tools are worth reaching for.