More than 60% of web traffic now comes from mobile devices. For most small businesses the number is even higher — closer to 75% for local search. If your site does not work well on a phone, three out of four visitors are having a bad experience before they know what you sell.

Responsive design is the discipline that fixes this. But "responsive" in 2026 means more than "the layout reflows". Here is what it actually takes to build a site that feels right on every screen.

Mobile first is not a slogan

I design every project starting from the smallest viewport — usually 360 px wide, the smallest realistic Android screen. Only after the mobile layout works do I scale up.

Why this matters: a layout that works on 360 px will work on every bigger screen with minor adjustments. A layout built for desktop first almost always falls apart on mobile, because decisions made with plenty of horizontal space cannot survive the squeeze.

Mobile first forces clarity. If a headline does not fit in two lines on a phone, it is probably too long. If a nav needs five items, one of them is probably unnecessary. If a form has eight fields, your users will abandon it.

The three breakpoints I actually use

Most projects do not need elaborate breakpoint systems. I ship almost everything with just three:

  • Small (default, mobile): 0–767 px
  • Medium (tablet / small laptop): 768–1279 px
  • Large (desktop): 1280 px and up

Tailwind's default md: and lg: breakpoints line up with this naturally. Adding a fourth only makes sense when there is a real design change at that size — not just slightly different padding.

Touch is different from mouse

This is where a lot of "responsive" sites fail. The layout adapts but the interactions do not.

Things I make sure of on every build:

  • Tap targets at least 44 × 44 px. Apple's human interface guidelines are not optional. Smaller than that and people miss.
  • Enough spacing between tappable elements. Two links 6 px apart is a rage-tap generator.
  • No hover-only interactions. Phones have no hover. If a menu only reveals on hover, it does not exist on mobile.
  • Momentum scrolling that respects the user. No hijacked scroll, no fake "click to advance" sliders.
  • Forms that use the right keyboard. type="email" on email fields, type="tel" on phone fields, inputmode="numeric" where useful.

These are small details individually, but together they are the difference between a site that feels like a real app and one that feels like a desktop page crammed onto a phone.

Images at the right size

Serving a 2000 px desktop image to a 375 px phone wastes bandwidth and slows the first paint. On every project I generate multiple sizes and let the browser pick:

<img
  src="/hero-800.avif"
  srcset="/hero-400.avif 400w, /hero-800.avif 800w, /hero-1600.avif 1600w"
  sizes="(min-width: 1280px) 1200px, 100vw"
  alt="…"
  loading="lazy"
  decoding="async"
/>

The phone downloads ~50 KB. The desktop downloads ~200 KB. Nobody downloads the wrong thing.

Typography that scales

Fixed font sizes make life miserable on both small and large screens. I use a responsive type scale with clamp():

h1 { font-size: clamp(2rem, 5vw + 1rem, 4.5rem); }
p  { font-size: clamp(0.95rem, 0.5vw + 0.8rem, 1.0625rem); }

Text shrinks smoothly on mobile and grows on ultrawide screens without breakpoints. Line length stays readable because the container max-width is also capped (around 70 characters per line is the sweet spot).

Test on real devices

Simulators are useful for rapid iteration, but they miss things: scroll momentum, keyboard behavior, 100vh quirks on iOS Safari, Android notch handling, sticky headers that collapse on scroll, address bar show/hide. I keep a cheap mid-range Android and an older iPhone on my desk and test every site on both before launch.

This is how White Sail Split ended up handling mobile booking flows differently from desktop: real-device testing surfaced a quirk in how iOS Safari treats position: sticky with a keyboard open, and we adjusted the layout.

Landscape and large screens still matter

One underrated case: landscape on phones, especially tablets. A lot of "responsive" sites stretch awkwardly to fill the extra width and waste it. I cap content at a readable max-width (usually 1280 or 1440 px) and add padding on either side. The result on a 27-inch monitor is a site that looks intentional, not overstretched.

The payoff

A site built responsively does not need a separate mobile version. It is one codebase, one design system, one source of truth, that works everywhere. Maintenance is easier, performance is better, and the visitor experience is consistent no matter how they arrived.

If your current site feels broken on mobile and you want an honest assessment of what it would take to fix, email info@tonibarisic.com or reach out via the contact form. See some recent fully-responsive builds in the portfolio.