Frontend
easy
mid
Building fully responsive apps
Beyond layout: responsive means adapting layout, content, interactions, media, and performance to the device. Mobile-first fluid layouts, container queries for components, responsive images, touch vs pointer handling, and shipping less to constrained devices.
6 min read·~10 min to think through
"Fully responsive" is broader than media queries — it means the app adapts every dimension to the device: layout, content, interaction, media, and the payload itself.
1. Responsive layout
- Mobile-first, fluid by default — flex/grid,
%/fr/rem,clamp(),minmax(auto-fit). - Container queries so components respond to their space, not the viewport — essential for true reusability across layouts.
- A small, content-driven set of breakpoints.
<meta viewport>,box-sizing: border-box.
2. Responsive content
- Show/hide or reprioritize content by viewport — but don't hide critical content from mobile users; reorganize, don't amputate.
- Truncate, collapse, or progressively disclose dense content on small screens.
- Navigation adapts: full nav → hamburger/bottom-nav.
3. Responsive interaction
- Touch vs pointer — touch targets ≥ ~44px; never depend on hover (use
@media (hover: hover)). - Gestures (swipe) on touch, keyboard affordances on desktop.
- Respect
prefers-reduced-motion,prefers-color-scheme,prefers-contrast.
4. Responsive media
srcset/sizesand<picture>— don't ship a 2000px image to a 375px phone.aspect-ratio+ dimensions to prevent layout shift.loading="lazy"for offscreen media; modern formats (AVIF/WebP).
5. Responsive performance — the part people forget
A "responsive" app that ships 3MB of JS to a low-end Android isn't responsive in any meaningful sense.
- Adaptive loading — lighter experiences on slow networks / low-end devices (
navigator.connection,deviceMemory). - Code-split, lazy-load, defer non-critical work.
- Test on real low-end devices and throttled networks, not just a resized desktop window.
6. Verify
- Real devices across the range, landscape/portrait, accessibility zoom (200%+), slow 3G, and assistive tech.
The principle
Responsiveness is device empathy: the experience should be excellent on a flagship phone and a three-year-old budget Android on a flaky connection. Layout is just the most visible 20% of it.
Follow-up questions
- •Why are container queries important for 'fully' responsive components?
- •What does responsive performance / adaptive loading mean?
- •Why is hiding content on mobile usually the wrong call?
- •How do you handle touch vs pointer interactions?
Common mistakes
- •Equating responsive with just media-query layout.
- •Hiding important content from mobile instead of reorganizing it.
- •Shipping desktop-sized JS and images to low-end mobile devices.
- •Testing only by resizing a desktop browser window.
Performance considerations
- •Adaptive loading ships less code/media to constrained devices. Responsive images avoid wasted bytes. aspect-ratio prevents CLS. The perf budget is part of responsiveness — a slow experience isn't a responsive one.
Edge cases
- •Low-end devices on slow networks.
- •Landscape on short viewports; foldables; ultra-wide.
- •Accessibility zoom to 200%+ breaking fixed layouts.
- •Hover-dependent UI on touch devices.
Real-world examples
- •A component using container queries to render compact in a sidebar, full in a main column.
- •Adaptive loading serving a lighter bundle on save-data / low deviceMemory.
Senior engineer discussion
Seniors expand 'responsive' to five axes — layout, content, interaction, media, performance — and emphasize container queries and adaptive loading as what 'fully' implies. They frame it as device empathy and insist on testing real low-end hardware on real networks, not a resized desktop window.
Related questions
Frontend
Hard
6 min