Study reveals Webflow sites have 256% more classes than Webstudio

Do a lot of classes negatively affect you? Yes, absolutely.

Simply put, more classes correlate with harder maintainability and slower websites.

While classes can be pivotal in reusing styles, they are also highly problematic and misused.

In this post, I’m going to share:

1. The data from the study and how the study was carried out
2. The problem with classes
3. How each problem is definitively solved on Webstudio

The data

When I switched to Webstudio, I noticed I was using far less tokens than I was using classes in Webflow.

Tokens are similar to classes, but have some technical differences we'll discuss.

How much less? I didn’t know so I started analyzing Webflow and Webstudio sites.

How the study was carried out

I'll show you step by step how I did this.

1. Five newest free templates

I went to the Webflow and Webstudio marketplaces, filtered by free templates, and opened the newest five.

I skipped one of the first five Webflow templates as it had an outlier skewing the numbers against them. This one template had 335 classes for just six sections which was over 4x the average.

2. Focus only on sections

I deleted anything that wasn’t a section such as the navigation and footer. I did this because those are reused on every page and I wanted to get an idea of classes/tokens per section. This multiple can help us estimate classes per page or even site.

3. Copy the Page Wrapper

I copied the Page Wrapper div which typically consisted of the following structure:

4. Inspect the object

When copying in Webflow and Webstudio, you get a JSON object of all the contents. I was only interested in extracting the classes/tokens.

4.1 I pasted into this Clipboard Inspector to get a plain text representation of the data.

4.2 I pasted the plain text into VSCode and searched using the following regular expressions (regex) to extract each class/token.

• Webstudio regex: "type":"token".*?"name":"([^"]+)"
• Webflow regex: "type":"class","name”:”([^”]+)”

This yields the total number of unique classes/tokens on that page.

5. Calculate the ratio

I divided the total number of classes/tokens by the number of sections.

If there were 10 sections and 100 classes/tokens, that would equate to 10 per section.

The results

I calculated the results including and excluding default tokens.

On Webflow, styles for h1 through h6, sections, containers, lists, list-items, and links are handled via a "special" global class which the copy object doesn't contain. However, on Webstudio, those elements are styled via regular tokens which are included in the copy object.

Including default tokens

• Webflow: 11.5 classes/section
• Webstudio: 4 tokens/section

This means:

• Webstudio sites use 65.22% fewer tokens/section compared to Webflow.
• Webflow sites use 187.5% more classes/section compared to Webstudio.

Excluding default tokens

• Webstudio drops from 4 to 3.24 tokens per section.

This means:

• Webstudio sites use 71.83% fewer tokens/section compared to Webflow.
• Webflow sites use 255.56% more classes/section compared to Webstudio.

Raw data

Here are the results from each template by platform:

Classes are killing our productivity

Classes, in the realm of visual development, are painful to work with.

While they unlock a form of reusability, they drag down our productivity, maintainability, and website performance.

Here are the exact problems visual developers will run into and how Webstudio solved each one.

Problem 1: Every style requires a class

Wait, we just said classes are for reusing styles. I need to use classes for one-off styles?

Yes.

Every time you apply a style, even if you're styling the one footer on your site, you need a class.

Having a class for every single item clutters the design system.

Webstudio's Solution

Imagine having a special switch on every instance that when activated, you are applying styles to just that instance, without naming anything.

It's called the Local Style Source.

Anytime you apply styles, by default they only affect that single instance. No tokens needed here.

Whether you are just adjusting the text to be center-aligned, or designing an entire one-off section, Local Styles is the go-to.

If you want to convert those local styles into a Token to reuse elsewhere, you can with the "Convert to Token" button.

Local Styles significantly reduces design system bloat; however, it's not the only trick we have up our sleeves.

Problem 2: Combo classes

99% of the time, combo classes cause huge maintainability issues (I'll touch on that 1% momentarily).

If you don't already know, here's the problem...

You apply a class called text-center. Then you want to set the text-wrap to balance. So you create a new class called text-balance.

Then on another heading you want to just use text-balance without text-center. Guess what, text-balance won't show up in the dropdown because it's married to text-center. That's because it was created with text-center already in the class list so now it can only be defined in that exact order.

Instead, you have to remove all existing classes, define your new class by itself, then add all the classes back.

Maintenance nightmare.

This is entirely why best practice in Webflow is not "deep stacking", or applying too many classes to one item.

According to Client First, the standard for building in Webflow, "The problem of [Deep Stacking] becomes extreme when making edits at lower breakpoint levels. We have even less editing control as we edit breakpoints outside the base breakpoints."

To make matters worse, classes can't be rearranged due to this chaining. So if you decide to make the text aligned left, you have to remove all existing classes to remove that first one.

Yes, matters are a lot worse now.

I mentioned combo classes are useful 1% of the time. In cases where you have variants, commonly prefixed withis- like is-button-secondary, combo classes enable "restricting" those variations to the base class. I.e., because is-button-secondary was defined after button, there is no "risk" of using is-button-secondary by itself.

Webstudio's solution

Tokens are always independent of other tokens. Thus, you can define them in any order and rearrange them.

If two or more tokens specify the same style, the last one (furthest to the right) is the most specific one, meaning that style will apply.

Local is always the most specific.

To address variants, we are planning to implement container queries.

Problem 3: Classes are used for single styles

Let's say there are three cards like this that have uneven headings due to one spanning multiple lines:

One way of fixing this is by setting a minimum height on each heading.

The "class" way of doing this entails creating a class called "Card Heading" and applying one style to it — min-height.

However, classes primarily should be used to group multiple styles.

Webstudio's solution

On any instance, you can define CSS variables which will then be available on that instance and every child. Therefore, not all variables need to be global.

If there is one style you need to reuse on one part of the site, define that one style as a CSS variable, and access it on the child instances.

An exception to the rule of using CSS variables for single styles is if there are many instances (roughly 5+). That's because if you decide to add a second style, you'll need to manually add it to each instance, but if a token is present, you can just add new styles to that token.

Problem 4: Navigator labels require classes

In order to name an item in the navigator, it requires a class.

Want to label your sections like section_about or section_hero? That will be two classes, even if you don't apply styles.

This means your live site will output these classes in the HTML even though they are intended for only the builder.

Webstudio's solution

Navigator labels are independent of tokens.

You can freely rename any navigator label by double-clicking or using a shortcut. In fact, it’s Craft guidelines (Craft is the standard for building in Webstudio), to give all Boxes a custom label.

In most cases, navigator labels should be different from tokens.

• Navigator labels are more human-driven
• Navigator labels are typically more specific than tokens. For example, the token might be called Card, but the implementation of that card is a testimonial, which is a good name for the navigator label.

Problem 5: Classes cause bloat and slower performance

Webflow's implementation of classes increases the size of the resources to load the page and therefore hurts performance. There are many reasons for this. Let's lightly touch on them.

For starters, combo classes mean more text, which translates to bigger files the browser needs to download.

.brand-boilerplate-components--container.brand-boilerplate-components--cc-notification_bar {
    width: 97%;
}

Look how much text is there just to get one style declaration! This is a real declaration on Webflow's site, and there are many more like it.

Secondly, all instance labels require classes, which, to be fair, doesn't add too much bloat; however, it's rather frustrating as instance labels are entirely intended for the builder.

<section class="section_logos">

The class section_logos doesn't have any styles, but is in the DOM in order to label it in the builder.

Next is the big one: styles aren't atomized. The following two declarations are exactly the same:

.logo-left {
    padding-left: 50px;
}

.logo-right {
    padding-left: 50px;
}

There must be a better way...

Webstudio's solution

Webstudio atomizes CSS which reduces CSS by around 72% in most cases.

This means that Webstudio outputs CSS with one style declaration per class like this:

.csmivb {
    background-color: #fff;
}
.cu6yur2 {
    padding-left: 20px;
}

This algorithm allows classes to be reused, significantly reducing the amount of CSS, ultimately leading to a faster-loading website.

Generally speaking, there are somewhat of a finite amount of styles you’ll use on your website, so as the website gets bigger, the CSS file does not grow proportionally – in fact, its growth slows down as the site gets bigger as it doesn’t need to continue creating classes for styles you’ve already used.

This is one of the large differences between tokens and classes.

Of course, there is still the need to output some static class to target with custom code. You can do this by using the class field in the Settings Panel where you can also set the ID and other properties.

For more information, see atomic styles configuration doc and a short video demo comparing tokens and classes.

Be thrifty with tokens

On Webstudio, tokens have a minimal impact on the CSS file size. Once a site gets to around 20-25 KB the growth of the file exponentially slows down.

However, just because tokens have a minimal impact on the CSS file size doesn't mean they should be used willy-nilly.

While tokens improve consistency and build speed, using more than you have to can actually slow you down and hurt maintainability.

Every time I want to create a token, I ask myself if there is a way to do it without creating one. If not, no problem, I’ll create the token. But clearly, there are many scenarios where there is a better way.

Farewell to classes in visual development.