Performance between CQW and CQH is shown in the image

Been working with container queries lately and stumbled into something weird. Started noticing my pages felt sluggish when I used certain units, so I dug into it.

Spent way too much time testing cqw vs cqh. Here's what happened.

Bottom Line First

cqw wins most of the time. Not by a huge margin, but enough that I switched my default approach. If you're in a hurry, just use cqw for most stuff and call it a day.

Container Query Units Recap

Quick reminder since I always forget the syntax:

cqw = 1% of container width

cqh = 1% of container height

Basic setup looks like this:

.wrapper {

container-type: inline-size;

}

.content {

font-size: 4cqw;

margin: 2cqh 1cqw;

}

Nothing fancy.

Width Beats Height Every Time

Caught me off guard initially. Thought both units would be identical performance-wise.

Wrong.

Browsers handle width calculations first, then worry about height. Width comes from the parent, height depends on content. More moving parts means more work for the browser.

Think about building a bookshelf. You know how wide the wall is immediately. How tall should each shelf be? Depends what books you're putting there.

Some Numbers I Actually Tested

I built a test page with about 40 different components using container queries. Nothing crazy fancy, just typical website stuff - cards, buttons, text blocks.

Using mostly cqw units:

Page loaded in about 165ms

Resizing the window caused 10-12ms of recalculation each time

Same exact page but with cqh everywhere:

Took around 205ms to load

Window resizing was more like 20-28ms each time

Not earth-shattering differences, but definitely noticeable. On my phone it was even more obvious.

When You Actually Need CQH

Don't get me wrong - sometimes you really do need height-based sizing. Like when you're building cards that need to stay proportional:

.image-card {

container-type: size;

}

.card-title {

font-size: clamp(1rem, 4cqh, 1.8rem);

padding: 1cqh 2cqw;

}

Or those full-screen hero sections:

.hero-section {

height: 100vh;

container-type: size;

}

.big-headline {

font-size: 6cqh;

}

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

How I Actually Use These

Most of the time, I set up containers with just inline-size and use cqw for almost everything:

.component {

container-type: inline-size;

padding: 1rem 3cqw;

font-size: clamp(0.9rem, 2.8cqw, 1.3rem);

}

Only when I'm dealing with something that genuinely needs 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 Stuff

Container queries are pretty well supported now, but you still want fallbacks for older browsers. I usually do something like:

.responsive-heading {

font-size: 1.5rem;

font-size: clamp(1.2rem, 5cqw, 2rem);

}

The first line is your backup, the second line is the fancy responsive version.

Things I Learned the Hard Way

Don't go crazy with nested containers. I tried building this complex component with containers inside containers inside containers. It worked, but it was slow and honestly just confusing to maintain.

Use inline-size unless you really need both dimensions. Why make the browser work harder than it has to?

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.

Useful Tools

When I'm prototyping container query layouts, I use:

https://www.webutilitylabs.com/p/css-container-query-converter-tool.html

to quickly test different unit values and see how they look.

Container queries work really well with CSS Grid too. If you're building complex layouts, a CSS Grid generator can help you set up the grid structure, then you can use container queries to make the individual grid items responsive.

https://www.webutilitylabs.com/p/css-grid-generator.html

My Take

Look, the performance difference between cqw and cqh isn't going to make your site blazing fast or horribly slow. But if you're building a lot of components and you want things to feel smooth, lean toward width-based queries.

The bigger win is just using container queries at all. They solve so many responsive design problems that used to require JavaScript or weird CSS hacks. A few extra milliseconds of calculation time is totally worth it for components that actually adapt to their space instead of just the viewport.

Plus, let's be honest - most responsive design problems are really about width anyway. How often do you actually need something to scale based on height? Not that often.

So yeah, use cqw as your default, save cqh for the special cases, and enjoy having components that actually work the way you want them to.