Responsive Web Design Best Practices

A responsive website is one site that rearranges itself to suit whatever screen it's on. For a local business that matters a great deal, because people often find you on a phone: from a Google search, a map listing or a link someone sent them. Your own analytics will tell you the split for your site, and for many small businesses it leans heavily towards mobile.

Google also looks at the mobile version of a site when it decides how to index and rank it. So a site that works beautifully on a laptop but awkwardly on a phone is weaker where it counts. These are the practices I follow on every build.

Design the phone layout first

Start with the smallest screen and add to it as space allows. Designing for a phone first forces you to decide what matters, because there's only room for the essentials.

I design and build every page at 390 pixels wide before anything else, which is about the width of a typical modern phone held upright. Once that layout works, wider screens get more columns, larger images and more breathing room. Going the other way, shrinking a desktop design down, usually ends with cramped text and important things pushed far down the page.

Use flexible layouts, not fixed widths

Layouts should stretch and reflow rather than being built to one exact width. Let the content decide where the layout changes, not a list of device sizes.

Modern CSS makes this straightforward. Grid and flexbox let columns wrap when they run out of room, and a maximum width on the main content keeps lines from getting too long on a big monitor. Breakpoints, the widths where the layout changes, belong wherever the content starts to look wrong, not at the size of one particular phone or tablet. New devices come out every year, and a layout built around content copes with all of them.

Keep text readable without zooming

Nobody should have to pinch to read a paragraph. Set body text large enough to read comfortably at arm's length, and never stop people zooming if they want to.

• Text size. I use at least 16 pixels for body text. Form fields need it too: on iPhones, a field with smaller text makes the browser zoom in when someone taps it, which is jarring.
• The viewport tag. Every page needs <meta name="viewport" content="width=device-width, initial-scale=1"> so phones render it at their real width.
• Never block zoom. Settings that stop people zooming in make a site harder to use for anyone with low vision. Leave zoom alone.

Make every tap target easy to hit

Fingers are much less precise than a mouse pointer. Buttons and links need to be big enough, and far enough apart, that people hit the one they meant.

I make tap targets at least 44 by 44 pixels, with space between neighbours. A few small details make a big difference on a phone:

• Phone numbers as tap-to-call links.
• Addresses that open in the phone's maps app.
• Form fields with the right type, so an email field brings up a keyboard with the @ sign and a phone field brings up the number pad.
• Autocomplete turned on for names, emails and addresses, so people can fill a form in a few taps.

Serve images at the right size

A phone shouldn't download an image sized for a 27-inch monitor. Send each screen an image close to the size it will display, in a modern format.

Images are usually the heaviest part of a page, so this is where most of the speed is won or lost. Responsive image markup lets the browser choose between several sizes of the same picture. Modern formats such as WebP and AVIF are much smaller than old JPEGs at the same quality. Images further down the page can load lazily, only when someone scrolls near them. The main image at the top should not be lazy-loaded, because it's the first thing people see.

Every image should also have its width and height set. That lets the browser reserve the space before the image arrives, so the text doesn't jump around while the page loads.

Mind the browser bars on phones

Mobile browsers show and hide their address bars as you scroll, which changes the height of the screen. Layouts that fill the screen need to allow for that, or buttons end up hidden behind the bar.

The older way of saying "full screen height" in CSS doesn't account for those bars on many phones. Newer units, such as the dynamic viewport height, do. I use them for any section designed to fill the screen, so a call to action at the bottom of the first screen is actually visible.

Show the same content on every screen

A phone layout should rearrange content, not remove it. If something is worth saying on a laptop, it's worth saying on a phone.

Hiding sections on mobile to make the page shorter is tempting, but those visitors miss things they may have come for, and search engines judge the site on the mobile version. If a page feels too long on a phone, it's usually too long everywhere, and the fix is better writing rather than hidden content.

Respect the settings people choose

Phones let people choose larger text, less motion or a dark appearance. A good responsive site notices those choices and goes along with them.

The one I'm strictest about is reduced motion. Some people get dizzy or distracted by moving elements, and they can ask their device for less of it. Every animation I build checks for that setting and switches to a still version when it's on. Layouts should also hold together when someone has turned their text size up.

Test on real phones before launch

Desktop browser tools are a good first check, but they aren't a phone. Before a site goes live, try it on at least one real iPhone and one real Android phone, on mobile data as well as wifi.

Things that only show up on a real device include slow-loading fonts, buttons that sit under a thumb awkwardly, sticky bars that cover content and forms that fight with the keyboard. My own checklist before launch:

• Read every page on a phone, one-handed.
• Fill in and send every form.
• Tap every phone number, email link and map link.
• Turn the phone sideways and check nothing breaks.
• Load the site on mobile data and note anything that feels slow.

If a site passes all of that, it's ready for the people who'll actually use it, most of whom will be holding a phone.