Core Web Vitals: what each metric measures and how to fix it
LCP, INP and CLS measure different failures with different causes. Knowing which metric is failing tells you almost exactly where to look.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Define role-named tokens before building any component.
- Components render data; they do not fetch it or hold global state.
- Without a staffed contribution route, teams fork and never return.
- Adoption rate matters; component count does not.
Tokens before components
Start with the primitives: colour, spacing, type scale, radius, elevation and motion, defined once as named tokens and referenced everywhere. Name them by role rather than by value so a theme change does not require renaming everything.
Keep the primitive set small. A spacing scale of eight values that people use consistently beats a scale of thirty they round off arbitrarily.
Components as contracts
A good component has a narrow, documented interface and no knowledge of where it sits. It receives data and callbacks; it does not fetch its own content or reach into global state.
Document every state — default, hover, focus, active, disabled, loading, error, empty. The states nobody designs are the states that get improvised inconsistently across the product.
Governance and the escape hatch
Decide who may add a component and how. If the process is slow, teams will fork, and the fork will not come back. Publish the route, staff it, and make additions reviewable rather than gated indefinitely.
Provide a documented way to build something outside the system for a genuine deadline, clearly marked, with a route back in. Systems without an escape hatch do not prevent divergence; they hide it.
Measure adoption, not inventory
Component count measures supply. What matters is demand: the proportion of production screens built from system components, the number of one-off components created per sprint, and how long a team waits for something new.
Those three numbers tell you whether the system is winning. A library with thirty components in wide use is healthy; two hundred components at low adoption is a museum.
Getting the first version adopted
New systems fail at adoption more often than at design. The most reliable route is to build the system out of components that already exist in production rather than designing an idealised set nobody has asked for.
Pick the two or three most-used components, consolidate their variants, and migrate one real page. That gives a working proof, a migration pattern others can copy, and immediate evidence that the system produces something shippable.
Then let demand drive expansion. Components teams ask for get used; components built speculatively usually do not.
Frequently asked questions
Only when it is genuinely shared across several products with independent release cycles. For a single product, keeping it in the same repository removes versioning overhead and speeds up iteration.
Some component workbench is very useful for developing and reviewing components in isolation, and it doubles as living documentation. The specific tool matters less than having one.
Shared tokens exported from the design tool into code is the most reliable mechanism. Beyond that, regular review sessions where designers and engineers look at the built components together catch drift early.
