Skip to content

Performance · 13 Sept 2026 · 3 min

I Changed My Typography CSS and Cut My Vercel Build Time in Half

After replacing Tailwind Typography with shadcn/typeset, my Vercel builds became consistently faster. I dig into the architectural difference between a build-time plugin and static CSS, and why it might matter.

Recently, I replaced Tailwind's @tailwindcss/typography plugin on my personal site with shacdn/typeset.

I wasn't doing it for performance. I just preferred the way Typeset approaches long-form content.

Then I deployed the change to Vercel.

My build time dropped from roughly 1 minute 50 seconds to around 53 seconds.

That's about 110 seconds down to 53 seconds, or roughly a 52% reduction.

At first, I assumed it might just be a particularly fast deployment. But after running several more builds, the lower build times persisted.

Vercel build times

Five builds before and after the change. Lower is faster.

  • @tailwindcss/typography
  • shadcn/typeset

That made the result much more interesting.

Same job, different approach

From the component side, both solutions look almost identical.

With Tailwind Typography:

<article className="prose">
  {content}
</article>

With Typeset:

<article className="typeset">
  {content}
</article>

The difference is mostly in how those styles become part of the application.

Tailwind Typography is a plugin:

@import "tailwindcss";
@plugin "@tailwindcss/typography";

That means it participates in Tailwind's build pipeline. The plugin is loaded and its typography rules are processed as part of CSS compilation.

Conceptually:

plugin
    ↓
plugin execution
    ↓
style generation
    ↓
Tailwind compilation
    ↓
CSS

Typeset takes a simpler approach.

It's CSS that lives directly in the project:

@import "tailwindcss";
@import "./typeset.css";

Conceptually:

typeset.css
    ↓
CSS compilation
    ↓
CSS

That difference is what caught my attention.

Less work in the build pipeline

The interesting comparison isn't really Tailwind Typography versus shadcn Typeset.

It's more like: build-time plugin vs static CSS

Typeset removes a layer of indirection.

Instead of loading a plugin that participates in generating typography styles during the build, the styles already exist as CSS.

That doesn't automatically mean Tailwind Typography is slow. Modern build tools are fast, and one plugin shouldn't necessarily have a dramatic impact.

But build systems are cumulative.

Every plugin, transform, loader, and code-generation step adds some amount of work. Most of the time, we don't notice the individual cost.

Sometimes you only notice it when you remove something.

Did Tailwind Typography really cause the difference?

This is where I still want to be careful.

The reduced build time has now been consistent across multiple deployments, so it no longer looks like a one-off result.

But that still doesn't prove that @tailwindcss/typography accounts for every second of the improvement.

A Vercel build includes more than CSS compilation:

  • dependency installation
  • framework compilation
  • Tailwind and PostCSS processing
  • type checking
  • static generation
  • caching

Removing a dependency can affect several of those stages.

So I wouldn't say:

Tailwind Typography makes builds 57 seconds slower.

What I can say is:

After replacing Tailwind Typography with shadcn/typeset, my Vercel builds consistently became significantly faster.

The architectural difference gives a plausible explanation: I replaced a build-time plugin with static CSS.

Exactly how much of the improvement comes from that change would require profiling the individual build stages.

Why I prefer Typeset anyway

Performance wasn't the reason I switched, and it still isn't the main reason I prefer Typeset.

I like that the styles live in my project.

If I want to change the spacing, I edit the CSS.

If I want to understand how something works, I read the CSS.

There is less abstraction between my content and the styles affecting it.

For something as stable as article typography, that feels like a good trade.

The bigger lesson

This ended up being less about typography and more about dependencies.

We usually think about dependency cost in terms of bundle size or runtime performance.

But some dependencies cost us during the build instead.

They register plugins. They transform files. They generate code. They participate in compilation.

Those costs are easy to ignore because users never see them.

Developers do, on every deployment.

In my case, replacing: package + plugin + configuration with: a CSS file was followed by consistently faster Vercel builds.

I'm still hesitant to attribute the entire improvement to one plugin without profiling the build itself.

But it has changed the question I ask when adding tooling to a project:

What is this dependency costing me at build time?