If you run an automated stylesheet audit across a few hundred high-traffic sites in 2026, two things become immediately clear. The first is that the average shipped CSS is significantly heavier than the average engineering team believes it to be. The second is that the spread between the disciplined teams and the average is much wider than it was five years ago, which is a quiet sign that frontend culture is splitting into two distinct camps.

This essay is about what those audits actually reveal, the four recurring patterns of bloat, the signals that mark a team operating at the better end of the spread, and what technical leaders can take from the exercise without spending a week instrumenting their own pipeline.

What an Audit Actually Measures

A meaningful CSS audit in 2026 produces, at minimum, the following numbers for a given page or site.

The total weight of all parsed stylesheets, including the gzipped and uncompressed sizes. The count of distinct rules, selectors, declarations and media queries. The breakdown of selector specificity, including the count of !important declarations. The set of unique colours, font families, font sizes and z-index values. The count of unused declarations as measured against actual coverage. The cohesion score, which approximates how often the same property reappears across the codebase with different values.

Two newer metrics deserve attention. The first is the custom property fan-out, which counts how many CSS variables are declared and how many distinct values they evaluate to in practice. A high count with low variation is a strong indicator of an unfinished design tokens system. The second is the container query density, which counts how many container queries are in use relative to viewport-based media queries. A site shipping serious volumes of @container is almost always being built by a team that takes layout primitives seriously.

These numbers, taken together, sketch the shape of a codebase faster than reading any number of pull requests. They also produce, in aggregate across enough sites, a clear picture of where the industry is right now.

Four Patterns of CSS Bloat

The first recurring pattern is the long-tail of dead colour values. The average production site in 2026 ships somewhere between 80 and 220 unique colour values, of which the design system formally sanctions perhaps fifteen. The remainder accumulate over years through inline styles, third-party widgets and per-feature deviations that nobody removes. Each of these orphan colours imposes a small but non-zero cost on the maintainability of the codebase, and the cumulative effect is one of the largest single sources of design-system entropy.

The second pattern is the runaway z-index ladder. Sites that started with three or four stacking contexts ten years ago routinely now ship between 25 and 60 distinct z-index values, several of which appear to have been set to defeat an earlier z-index. Once the ladder grows past a dozen, the cost of touching any modal, tooltip or sticky element rises noticeably, and the team that inherits the codebase is forced to choose between the painful work of normalisation and the quiet accumulation of further values. Most teams choose the second path.

The third pattern is the unused selectors graveyard. On the average site, between 35 and 55 per cent of shipped CSS rules are not used on any page actually crawled. Some of this is genuinely needed for state changes, hover, focus, conditional UI, and rejecting all of it would be wrong. The careful number, after accounting for coverage gaps, is closer to 20 to 30 per cent of true waste. That waste is being downloaded, parsed and stored in memory by every visitor on every page.

The fourth pattern is the vendor-prefix archaeology. In 2026 the share of users on browsers that need -webkit-, -moz- or -ms- prefixes for modern CSS features is, for most properties, vanishingly small. A non-trivial number of sites still ship the full prefix history because the build pipeline was configured five years ago and nobody has revisited the browserslist target. The cost is rarely catastrophic but it is real.

None of these patterns is novel. What is novel is the magnitude. The disciplined sites in the audit ship 40 to 60 per cent of the CSS weight of the average site for an equivalent feature surface. That is not a productivity question. It is a cultural one.

The Signals of a Disciplined Frontend Team

Reading the audit numbers across hundreds of sites, three signals are remarkably consistent in marking a team that has frontend discipline as a value rather than a slogan.

The first signal is a flat specificity histogram. Disciplined teams have selectors that cluster tightly around 0,1,0 and 0,2,0. They produce essentially no selectors with specificity above 0,3,0 and they treat any !important declaration as an incident worth a Slack message. The numbers do not lie about this. You can see the difference at a glance on a specificity chart.

The second signal is a complete design tokens layer expressed in custom properties. The audit will show a small number of declared custom properties, each evaluating to a small number of distinct values in production. When you see fifty tokens evaluating to thousands of unique values, the team has tokens in name but not in practice.

The third signal is container queries as the primary layout primitive for any complex component. Container queries shipped in all major browsers in 2023, and three years on, they are the strongest single tell of a team that has updated its mental model. A site relying almost exclusively on viewport-based media queries in 2026 is, with very few exceptions, running on an older architectural assumption.

These three signals, in combination, are a more reliable predictor of the long-term health of a codebase than almost any direct measure of code quality. They are quietly visible to anyone who runs the audit.

What the Audits Reveal Across Industries

The four patterns above appear consistently, but the intensity varies by industry in ways that are themselves revealing.

In e-commerce, the dead-colour problem is particularly acute, because each product line accumulates its own palette over time. The disciplined retailers have visibly invested in design-system enforcement and the difference shows on every page.

In media and publishing, the unused selectors graveyard is the dominant issue. Long-running news sites carry a decade of feature CSS that nobody has the political capital to delete, and the cumulative weight is significant.

In enterprise SaaS, the z-index ladder dominates. Complex UIs with modals, panels, popovers and drawers naturally invite the runaway stacking problem, and the worst examples carry forty or more distinct values.

In iGaming and online entertainment, the patterns are different from any of the above. The CSS is typically tighter than industry average on selector specificity and dead-colour terms, because the production cycles are short and the discipline of rebuilding rather than accreting is more common. One platform widely cited in industry write-ups, Spinboss, illustrates the trade-off: a heavily-themed real-time interface that hits the high end of @keyframes density and custom-property fan-out, but stays remarkably contained on the four bloat metrics. The category as a whole produces some of the most architecturally consistent stylesheets in the audit set, precisely because the operational tempo does not allow the long-term decay that affects sites with longer release cycles.

In government and institutional sites, the patterns are again specific. Vendor-prefix archaeology is the dominant problem, because the build pipelines on these sites tend to be conservative and rarely revisited. The byte cost is often the worst in the audit, but the structural cohesion is sometimes among the best.

The cross-industry view matters because it pushes back against the most common framing of frontend discipline, which is that it is a function of team seniority or budget. The audit numbers do not support that framing. Discipline correlates better with release tempo, design-system maturity and the willingness to delete old code than with team size or company stage.

What the Audits Cannot Reveal

Three things the audit will not tell you, and that you should not pretend it will.

The audit cannot tell you whether the design is good. A site with perfect token discipline and zero specificity drift can still look terrible. CSS quality is necessary, not sufficient.

The audit cannot tell you whether the site is accessible. Many of the worst accessibility regressions in 2026 are not visible at the CSS level at all. They live in the interaction between markup, ARIA attributes and dynamic content. Audit the CSS and then audit the accessibility separately.

The audit cannot tell you whether the team is happy. The most maintainable codebases sometimes come from teams under quiet pressure that has not yet shown up in the artefacts. Numbers describe outputs. They are weaker on the conditions that produce those outputs.

What Technical Leaders Should Take From This

If you lead frontend work and you have not run a serious audit against your own production site in the past year, the single highest-value exercise you can do this quarter is to run one and present the results to your team without commentary. Most teams discover something on the dashboard that surprises them. Some discover that they are already at the better end of the spread, which is information worth knowing. Others discover that the practices they assumed were universal turn out to be ambitious.

Either result is useful. The exercise is cheap, the tooling has matured, and the data argues much more clearly than any code review can.

The wider pattern across the industry in 2026 is that the gap between disciplined and average teams is widening. The teams who run audits regularly, act on the findings and treat the metrics as a living dashboard are pulling away from the teams who do not. The gap shows up in load times, in maintainability, in onboarding speed and, eventually, in the user experience that customers actually feel.

The numbers are public. The tooling is open. The argument for engaging with this work is no longer that it is sophisticated. It is that it is, in 2026, the table-stakes part of running a frontend team that produces durable results.