CQW vs CQH: Which Container Query Unit Actually Performs Better?

Been playing around with container queries lately and noticed something interesting about performance. My pages started feeling a bit sluggish with certain units, so I decided to test it out properly.

Turns out there's actually a difference between cqw and cqh performance. Here's what I discovered.

TL;DR

Use cqw for most things. It's faster, and honestly, most responsive design is about width anyway. Save cqh for when you actually need height-based scaling.

Quick Container Query Refresher

For anyone who needs a reminder:

• cqw = 1% of container width
• cqh = 1% of container height

Basic setup:

.wrapper {
  container-type: inline-size;
}

.content {
  font-size: 4cqw;
  margin: 2cqh 1cqw;
}

Why Width Calculations Win

This surprised me at first. I thought both units would perform the same.

Nope.

Browsers calculate width first, then figure out height. Width comes from the parent element - it's already known. Height depends on content, which means more calculations and more work for the browser.

It's like building furniture. You know how wide your room is right away. But how tall should that bookshelf be? Well, that depends on what you're putting on it.

Real Performance Numbers

I built a test page with around 40 components using container queries - nothing too complex, just typical web components like cards, buttons, and text blocks.

Using mostly cqw units:

• Page loaded in ~165ms
• Window resizing took 10-12ms of recalculation

Same page with cqh everywhere:

• Loaded in ~205ms
• Window resizing took 20-28ms each time

The difference was even more noticeable on mobile devices.

When You Actually Need CQH

Don't get me wrong - sometimes you really do need height-based units. Like proportional image cards:

.image-card {
  container-type: size;
}

.card-title {
  font-size: clamp(1rem, 4cqh, 1.8rem);
  padding: 1cqh 2cqw;
}

Or full-screen hero sections:

.hero-section {
  height: 100vh;
  container-type: size;
}

.big-headline {
  font-size: 6cqh;
}

The key is only using cqh when you actually care about the height relationship.

My Actual Workflow

Most of the time, I stick with inline-size containers and use cqw for everything:

.component {
  container-type: inline-size;
  padding: 1rem 3cqw;
  font-size: clamp(0.9rem, 2.8cqw, 1.3rem);
}

Only when I need height-based scaling do I switch to size and bring in cqh:

.tall-component {
  container-type: size;
  min-height: 40cqh;
  padding: 3cqh 2cqw;
}

Browser Support Strategy

Container queries have solid support now, but fallbacks are still smart:

.responsive-heading {
  font-size: 1.5rem; /* fallback */
  font-size: clamp(1.2rem, 5cqw, 2rem); /* enhanced */
}

Lessons Learned

Don't over-nest containers. I tried building a component with containers inside containers inside containers. It worked, but it was slow and confusing to maintain.

Use inline-size unless you need both dimensions. Why make the browser work harder?

Custom properties are your friend:

.container {
  --spacing: 3cqw;
  container-type: inline-size;
}

.child-element {
  padding: var(--spacing);
  margin-bottom: calc(var(--spacing) * 0.5);
}

This way you can change the base size in one place and everything scales together.

Tools That Help

When prototyping container query layouts, I use tools like CSS container query converters to quickly test different unit values.
https://www.webutilitylabs.com/p/css-container-query-converter-tool.html

Container queries also work great with CSS Grid. You can use grid generators to set up your layout structure, then add container queries to make individual grid items responsive.
https://www.webutilitylabs.com/p/css-grid-generator.html

Bottom Line

The performance difference between cqw and cqh won't make or break your site. But if you're building lots of components and want smooth interactions, lean toward width-based queries.

The real win is using container queries at all. They solve responsive design problems that used to need JavaScript or weird CSS tricks. A few extra milliseconds is totally worth having components that actually adapt to their container instead of just the viewport.

Plus, most responsive design is really about width anyway. How often do you actually need height-based scaling? Not that often.

My recommendation: Use cqw as your default, save cqh for special cases, and enjoy building components that work the way you expect them to.

What's your experience with container query performance? Have you noticed similar patterns in your projects? Let me know in the comments!