Andrea Verlicchi

Making the web faster and more user-friendly

Should we stop using the word "Responsive" for design?

Back in 2010, Ethan Marcotte coined the term Responsive Web Design. Since then, we've used "responsive" to describe a website that adapts its layout to the viewport size. Fluid grids, flexible images, media queries.

A pensive developer looking at screens showing responsive websites and adaptive apps, wondering about the terminology.
Should we use "adaptive" for layouts and "responsive" for performance?

For a while, we tried to separate it from "adaptive" design. Back then, "adaptive" websites had a bit of a bad reputation because they usually relied on server-side device detection and user-agent sniffing to serve completely different HTML and CSS to the browser (remember Aaron Gustafson's book?). Because UA sniffing was brittle and prone to breaking, the web community wanted to distance itself from it. Ethan's responsive model served the exact same code to everyone, letting the browser do the work. "Responsive" won the vocabulary war, and "adaptive" became a word associated with outdated, server-detected layouts.

But fast-forward to today, and these terms have split in ways that are causing real confusion.

The mobile definition of "adaptive" (Android and iOS) #

If you look at modern mobile app development — both Android and iOS — the word "adaptive" is the standard.

Google heavily uses it for Android app design. With the rise of foldable phones and tablets, apps can't just stretch to fit. They need to completely restructure. In their guide on adaptive layouts, the focus is entirely on "adaptive" layouts (changing layout structures based on breakpoints and fold states), while "responsive" concepts (like fluid sizing) are just seen as a foundation.

Apple follows a similar logic. In their Human Interface Guidelines for Layout, they frame layout adjustments around the concept of "Adaptability" rather than "Responsiveness." They guide developers to build interfaces that adapt seamlessly to different devices, screen sizes, and orientations using size classes and adaptive structures.

So, in the mobile app world, adapting to screen sizes is consistently called adaptive design.

The web performance definition of "responsiveness" #

At the same time, in the web performance space — where I spend a lot of time — the word "responsive" has taken on a completely different meaning.

When performance engineers say they want to make a page "responsive," they aren’t talking about viewports or media queries at all. They are talking about interactivity. Specifically, how fast the browser reacts to user inputs.

With Google's Interaction to Next Paint (INP) metric, "responsiveness" is measured in milliseconds. If a user taps a button and the page freezes for 300ms, the website has poor responsiveness.

The terminology collision #

This has created a confusing mess.

If a product manager says: "We need to make this website more responsive." What do they mean?

We are using the exact same word to mean "adapts to screen size" and "reacts fast to user input."

And this confusion is only going to grow. If you talk to developers who just entered the industry, or if you ask an AI coding agent to "make this UI more responsive", what will they actually do? Will they start writing @media rules in CSS, or will they fire up Chrome DevTools to profile main thread blocking times? Honestly, either path is a valid interpretation of the word.

A proposal: Split the terminology #

Maybe it's time to let the word "responsive" go, at least when we talk about screen sizes.

What if we started using "adaptive" for everything related to layout adjustment (both on the web and in native apps), and reserved "responsive" purely for web performance?

Under this model:

To put it in simple terms, if I had to explain this concept to my mother, I would say that a layout adapts to screen sizes, not that it "responds" to them. It is just a much more natural way to describe it.

It feels cleaner, more logical, and it solves the vocabulary overlap. But is the web community ready to drop Ethan Marcotte's 2010 definition? Or is "responsive design" too deeply engraved in our brains?

I'm curious to hear what you think. Does this distinction make sense, or is it too late to change? Feel free to reach out and let me know!