CSS Optimization: Is Using Declarations Just Once (UDJO) Still Effective Today?

Published on Oct 13, 2026, filed under development, css, maintainability, performance, optimization. (Share this post, e.g., on Mastodon.)

CSS optimization is a deceptive topic. On the one hand, it feels like something simple that we should already have all the tooling for—especially when it comes to minification. On the other hand, the idea that we already exploited “everything” there is around CSS optimization can be considered naive. Such a claim looks hard to defend for a language that evolves almost daily.

In this article, I’d like to pick a technique that’s at least 18 years old—“UDJO,” using declarations just once. (Aware of an older source? Please let me know!)

The technique is inspired by the principle of DRY, “don’t repeat yourself,” in that it works by identifying and reducing (if not eliminating) declaration repetition.

So if there’s something like display: flex, and it appears two or more times, it gets reconciled in one rule:

.example {
  display: flex;
}

…

.sample {
  display: flex;
}

becomes

…

.example,
.sample {
  display: flex;
}

The outcome of the technique depends—on how intelligently the deduplication is done and how long the selectors are. Intelligence determines if UDJO leads to an actual maintainability advantage—can the change of a declaration really be done to all the selectors attached?—, and the selector length influences how big file size savings are.

If you're interested, DRY CSS describes the mechanics in more detail. The question here is: Is UDJO still effective and still relevant today?

Better Deduplication Through Tooling

When we try to answer this question, we end up with a problem: When sites are complex and their style sheet declarations have not been de-duplicated before, UDJO requires a lot of work.

To save some time, I took this to build tooling for this work. While it didn’t seem like it would immediately be as comprehensive as manually going through and testing style sheets, it seemed realistic enough that a tool could catch some unnecessary repetition.

Skipping ahead, I created CSS Dedup—not only to identify repetition, but also to deduplicate what could safely be optimized (CSS Dedup has some documentation on this but in essence, deduplication affects selector locations, which, as per the cascade, influences what rules are being applied). This, then, gives us some data:

Is There Anything to Deduplicate in Modern CSS?

For a first batch, I picked 20 “random” websites to analyze. I then used CSS Dedup to check what the file size changes would be if we deduplicated what seemed provably safe, and also what seemed probably safe, but only if it led to file size savings.

I picked those two options to provide the “natural” result of deduplication, but also the one site owners may be most interested in to reduce repetition but also decrease transfer size. After all, UDJO as a CSS optimization technique can improve both maintainability and performance.

Here are the findings:

Important note: These values cannot be used to tell CSS quality—they depend on selector length and also on verifying if deduplication, in the respective case, actually leads to better maintainability. Also note that this leaves out changes after compression—this was not part of the experiment but would be fair to test, too.

What can we tell from this?

• In all of the 20 cases, we’re able to reduce declaration repetition.
• In 18 cases, reducing declaration repetition leads to a file size increase (due to selector repetition and selectors being longer than the declarations saved).
• However, in all cases, declaration repetition can be reduced in a manner that also reduces file size (by virtue of only deduplicating style sheets that lead to such savings).

For the question whether UDJO still works today, this should be a yes—it works as well as to even come with file size savings.

Maybe you’re curious, too, about what the situation looks like in our field, among web developers. Let’s take some samples on this, too:

UDJO in the Field

This analysis picks 10 websites of our peers:

What does this data show?

• Just as with organizations, on every site there’s some declaration repetition safe to remove.
• In 5 cases (50% compared to 90%), reducing repetition leads to a file size increase.
• Yet in all cases again, repetition can also be reduced in a way that leads to file size savings.

It would be valuable to expand this analysis to take more samples and investigate the differences across samples, but there may be something to web professionals using shorter selectors so as to be able to benefit even more from UDJO.

On the Effectiveness of UDJO as a CSS Optimization Technique

As mentioned at the beginning, UDJO’s effectiveness generally depends on the kind of repetition (and if and how it can be applied as intelligently as to lead to maintainability benefits) as well as on the length of selectors (given that the method leads to more selector repetition).

This can be managed, however: While tools like CSS Dedup make no difference between declaration use cases (and are therefore blunt), it is possible to configure them so as to reap the performance benefits.

As the data taken for this article suggest, file size savings may be achieved in most cases. Considering that this is based on safe changes, this means a performance optimization vector that comes for free—especially when applied to minified output.

For anyone interested in CSS optimization in general, in CSS maintainability options, or in CSS performance, UDJO should probably be part of the overall approach to CSS. But since the technique has been niche and since tooling is new (try and test CSS Dedup!), I invite more peers to review, test, and explore this vector. It seems hard to argue that we reached the ceiling of CSS optimization.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m an engineering lead, guerrilla philosopher, and indie publisher. I’ve worked as a technical lead and engineering manager at various companies (e.g., Google); I’m an active web and tool developer (code optimization, digital defense), a contributor to web standards (like HTML, CSS, WCAG), and a book author (O’Reilly, Frontend Dogma).

I love trying things—in web development and engineering management, but also in politics and philosophy, where I hold to one idea in particular: that we can only be well if we take good care of everyone. Here on meiert.com I talk about some of my perspectives and experiences. (Interpret charitably but be critical—and share feedback and advice that makes my work better.)