Responsive design

Responsive design is the practice of building one website whose layout rearranges itself to suit the screen it is being viewed on. The same pages, the same addresses and the same content, laid out as a single column on a phone and as several columns on a monitor. It has been the normal way to build a website for well over a decade, which is why nobody sells it as a feature any more.

In short

• One site that rearranges itself to fit the screen it opens on.
• The standard way sites are built, and has been for over a decade.
• Google judges your site by its mobile version.
• Responsive is about layout. It says nothing about speed.

What it replaced

For a few years around 2010 the accepted answer to phones was a second website, usually at an address beginning with m. It had its own pages, its own content and its own set of problems: two things to update, two sets of addresses for search engines to reconcile, and a shorter mobile version that inevitably omitted the thing somebody was looking for.

The alternative was to let one layout adapt. A flexible grid rather than fixed widths, images that scale to their container, and rules in the stylesheet that apply only above or below certain widths. That combination is what the term describes, and it won because it removed the second site rather than because it looked better.

Anything built on a current platform inherits this without a decision being made. The question worth asking a supplier is not whether a site will be responsive. It is what the site looks like on a five-year-old handset.

Adapting is not the same as working

This is the distinction that costs businesses the most, and it is easy to miss because a site can pass the obvious test and still fail the real one.

A layout can rearrange perfectly and still be miserable to use, which is the difference between a responsive site and a decent user experience.

• Text sized for a monitor becomes small enough to need zooming.
• Links sit close enough together that a thumb hits the wrong one.
• The menu collapses into an icon nobody presses.
• A form asks for a date through a control designed for a mouse.

The columns stacked correctly, and the page still does not work.

Three checks catch most of it, and none of them needs a tool.

• Read a paragraph at arm’s length without zooming.
• Tap every important button once, with a thumb rather than a finger.
• Fill in your own contact form on a phone, all the way to the confirmation screen.

Most sites fail at least one. The third is where the failures get expensive.

Google sees the phone version

Search engines settled this argument some time ago. The mobile version of your site is the version Google reads when deciding what your pages are about. That has a consequence people do not expect. Content that appears on the desktop layout but is absent from the mobile one may simply not count, because the mobile one is the version being read. Sites that trimmed their mobile layout to keep it short have occasionally trimmed away the text that was doing the ranking, then spent months looking for the cause somewhere else.

Collapsing content into tabs or an accordion is a separate case and a safe one. The text is still in the page, and Google treats it as present.

The safe rule is that both layouts carry the same content, the same headings and the same structured markup. They may present it differently. They should not disagree about what is there.

Responsive says nothing about speed

A site can be flawlessly responsive and painfully slow, and this catches people out because the two get discussed together.

Responsiveness is a layout property. Speed is a question of what the page actually downloads, and by default a phone frequently receives exactly what a desktop receives. The same photograph, sized for a wide monitor, arrives on a handset that will display it at a fraction of the width. The same scripts run, on a processor that is slower, over a connection that may be shared or metered.

Serving smaller images to smaller screens, deferring what is not needed immediately, and being disciplined about third-party scripts is separate work with a separate payoff. None of it is guessed at either. Google publishes the measurements as Core Web Vitals, taken from real visits rather than from a test in a lab.

Words you will hear

• Breakpoint. The width at which the layout changes arrangement.
• Media query. The rule in the stylesheet that applies styling only within a range of screen widths.
• Viewport. The visible area of the page in the browser, and the name of the tag that tells a phone not to pretend it is a desktop.
• Mobile-first. Designing the narrow layout first and adding to it, rather than designing wide and cutting down.
• Fluid. Sized in percentages of the available space rather than in fixed pixels.
• Tap target. Anything meant to be pressed, and the size of it.
• Adaptive. An older approach serving one of several fixed layouts. Related, less flexible, and largely out of use.

Testing it honestly

The office phone is the worst possible test device, because it is usually newer than the ones your customers own and it is on the office connection. Dragging a browser window from wide to narrow on a computer is a fast way to find layouts that break, and it is not sufficient on its own, since it reproduces neither touch nor a slow connection. Browser developer tools will simulate a throttled network, which gets closer. An old handset borrowed from somebody in the building gets closest of all.

The same discipline applies to anything else you send to a phone, though an email template has to survive a harsher set of rules than a browser imposes.

What you are looking for is not whether it fits. It is whether somebody standing up, holding a bag, on a connection that comes and goes, can get to the thing they came for. Ask one person outside your business to find your opening hours on their own phone while you watch and say nothing. Thirty seconds of that will tell you more than any report, and it will usually tell you something about your website that you did not want to know.