Software teams generate an ocean of numbers — commits, tickets, story points, lines of code — yet the thing we actually care about, performance, stubbornly resists measurement. This post is about that gap: why individual output is so easy to misjudge, what signals are worth watching, and how to measure teams without corrupting the very behavior you want.
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.
A tour of the metrics that describe how software teams actually perform — grouped by what they measure: delivery, reliability, productivity, frontend performance, quality, and agile process. What each one means, when it's useful, and how it goes wrong.
For anything users load in a browser, "how fast is it?" is really three questions — loading, interactivity, and visual stability — and the frontend has its own metric stack for each, plus the accessibility and client-side reliability signals that live right next to performance. Here's the set a frontend team actually owns, in one place.