Responsive design: how a website adapts to phones

Sites used to get a separate mobile version on a subdomain such as m.site.kz. Today the standard approach is responsive design: one site, one address, one codebase, with the layout changing according to screen width. The menu collapses into a burger, three columns of cards become one, large illustrations are swapped for lighter ones.

Mobile-first is an approach where the page is designed and built for a narrow screen first, then expanded for tablets and desktops. A narrow screen forces you to decide what matters: what is truly important, which button is the main one, what you can do without. Expanding a simple layout is easier than squeezing an overloaded one.

In practice, mobile-first affects the content too, not just the layout. A long paragraph that takes three lines on a desktop becomes a full screen of solid text on a phone. So it is better to write copy for the main sections short from the start and move details into expandable blocks or separate pages.

The first thing responsiveness cannot work without is the viewport tag in the page code: <meta name="viewport" content="width=device-width, initial-scale=1">. Without it, a mobile browser renders the page on a virtual canvas as wide as a desktop screen (MDN gives 980px as an example) and shrinks it — the text gets tiny and rules for narrow screens never apply.

A breakpoint is the screen width at which the layout changes. Good practice is to place breakpoints where the content breaks, not at the sizes of specific phone models: there are too many devices and their sizes keep changing. Between breakpoints a fluid grid does the work: widths are set in percentages and fractions rather than fixed pixels.

A mouse cursor is precise; a finger is not. That is why buttons and links on phones need a large enough tap area (touch target) and space between them. Official guidelines give the reference points:

In our experience, the most frequent trouble spots are social media icons in the footer, close buttons on pop-ups and links inside small print: they look small, and their tap area has to be extended with padding, even if the icon itself stays small.

An image made for a wide monitor weighs just as much on a phone but is shown several times smaller. Responsive images solve this: the browser picks a file of the right size by itself.

• The srcset and sizes attributes give the browser several widths of one image — it downloads the one that fits
• The <picture> element lets you show a different crop on phones: for example, a close-up instead of a wide panorama
• Modern formats such as WebP and AVIF are usually lighter than JPEG and PNG at the same quality
• Every image has its width and height set — so the page does not jump while the image loads
• Images below the first screen load lazily (loading="lazy")
• Text is set at a size that reads without zooming, and lines do not run off the edge of the screen

A similar rule applies to text. Font sizes and spacing are easier to set in relative units (rem, percentages, viewport units) — that way they scale with the screen and respect the user’s settings if they have enlarged the system font. A headline that looks striking at 72 pixels on a desktop has to shrink on a phone, or a single word will fill the whole line and start breaking awkwardly.

Device Mode in Chrome DevTools is handy for a quick check, but it does not replace a real phone: an emulator cannot convey what a finger tap feels like, how the on-screen keyboard behaves, the quirks of mobile Safari or a slow mobile network. Before launch, walk through the page by hand on at least one iPhone and one Android phone.

The most common bug we see when auditing other sites is horizontal scrolling: a single element (a table, a long link, a wide image or an animated block) turns out wider than the screen, and the whole page starts sliding sideways. The second most common is forms where the on-screen keyboard covers the input field or the submit button.