Responsive web design — how much traffic really comes from phones, and what follows for the layout

The instruction "design for the phone first" appears in every proposal and rests on a figure almost nobody checks. The previous version of this text informed readers that "in Poland as much as 60% of web traffic comes from mobile devices, and globally this percentage reaches 70%".

We checked both at source. Neither is true, and the first is reversed: in Poland it is the desktop that has over sixty per cent, not the phone.

How much mobile traffic there actually is

The StatCounter measurement for August 2026 looks like this:

In Poland: desktop 61.33%, mobile 37.91%, tablet 0.76%. Not "over 60% mobile" — the reverse: it is the desktop that has over sixty per cent.

Worldwide: mobile 49.36%, desktop 49.11%, tablet 1.54%. Roughly half and half, not seventy per cent.

And the interesting part only appears once several markets are put side by side:

Poland is the most desktop-heavy market of the six, and the gap to Germany reaches fourteen percentage points. Germany is the only market in this table where phones come out ahead — and only just.

It is also worth noticing that on four of the six rows the desktop leads, and that France and Switzerland lean the same way as Poland, only more mildly. So Poland is not the exception in Europe — Germany is.

The practical point is that advice copied from a foreign guide can simply be wrong for a Polish company. A text written for the German market, where phones are ahead, will advise differently from the data for your own country.

That is exactly the mechanism by which "60% of traffic is mobile" ended up in our own article: somebody once copied a figure without checking which market it came from.

Where these figures come from and what they do not cover. StatCounter measures page views across a network of over a million sites, more than three billion views a month. Three caveats have to travel with the result, because without them the number sounds harder than it is: no statistical weighting is applied, so the sample reflects a partner network rather than a population; bot filtering is imperfect and the firm says so itself; and the data is subject to corrections for 45 days after publication. This is a sample of a large network, not a census.

One reservation concerns our own old claim. It was about online shops, while StatCounter measures all traffic. Sectors do differ, and retail can be more mobile than average. But that explains at most the size of the gap, not its direction — and we gave the direction opposite to the measured one.

Why the desktop wins in Poland. StatCounter does not explain this and we will not pretend that it does. Our working reading, based on what we see with clients: decision-making and purchasing traffic in business services happens during working hours, at a desk. If you sell to businesses, designing a site for the phone alone means giving up the majority of the market that makes the decision.

This is not an argument against serving phones. It is an argument against treating them as the only case.

What "mobile first" actually means

The phrase made a career and changed meaning along the way. It is worth reclaiming, because in its original form it is useful and in its common form it leads to the error described above.

Originally, mobile first was a design method based on constraint: start with the narrowest screen, because the least fits there, so you are forced to settle what matters most. Then, moving upward, you add what there is room for. The value of the method lies in forcing a hierarchy, not in preferring phones.

In common use it became shorthand for "we design for the phone, the desktop will work itself out". And that is the version which, on the Polish figures, means designing for thirty-eight per cent of the traffic and leaving the majority to chance.

The difference is practical. The first method produces a site that looks considered on a desktop, because the hierarchy was settled where space was tightest. The second produces a site that looks like a stretched phone: one column in the middle, enormous spacing and two-thirds of the screen empty.

If you sell to businesses, ask the agency one question and listen for which version they describe: "how will this site use a wide screen?" An answer of "it will be centred" means you are buying the shorthand.

Why "three breakpoints cover 95% of devices" is not true

The second claim in the previous version was that three breakpoints — 768, 1024 and 1200 pixels — cover 95% of devices. That figure can be checked too.

Mobile screen resolutions in Poland, August 2026: 414×896 is 15.86%, then 393×873 with 7.65%, 384×832 with 7.27%, 360×800 with 7.04% and 390×844 with 6.99%.

The top three come to 30.78% together. The top five — about 45%. To reach ninety-five per cent you have to go a long way into the tail.

This is the one claim in this article that does not move with the market: the Polish top three come to 30.78% and the European to 32.14%, the same magnitude although Poland is 61% desktop and Europe about 51%. It is not a national quirk. It is what a device market looks like.

The distribution is long-tailed and the conclusion from it is the exact opposite of the original claim: there are no three device categories to design for. There is a continuous spectrum of widths, in which every popular value is worth a few per cent.

Designing for breakpoints therefore means a layout that is correct at a few points on the axis and accidental between them. And "between them" is most of your visitors.

It is also worth adding that the list of resolutions ages faster than the site does. The values at the top change with every generation of handsets, so a layout tied to particular numbers needs reviewing every year or so — and usually nobody does it, because nothing looks broken. A layout defined by a continuous function needs no such review, because it knows no particular resolution.

What follows: fluid, rather than per-device

There is one technical conclusion and it has a name: fluid scaling. Instead of defining a few thresholds at which the layout jumps, you define a function that changes sizes continuously along with the width of the window.

This site works exactly that way, and it is our own example rather than theory. Its typography is described by twenty-nine `clamp()` declarations, which scale sizes from 360 to 2560 pixels of width — from the narrowest phone to a 4K display. Fixed pixel values are banned outright by our design guidelines, not merely discouraged.

Three things this gives you, worth knowing because they translate into the conversation with an agency:

The layout is correct across the whole axis, not at three points. A phone 393 pixels wide and a phone 414 pixels wide do not get two different versions of the same page, just the same one, proportionally fitted. In Poland those two widths are, incidentally, the two most common — 414×896 with 15.86% and 393×873 with 7.65%, 23.51% between them, nearly a quarter — and under breakpoint thinking they would sit inside the same bucket and be treated as identical.

There is no performance overhead. Fluid scaling is done natively by the browser while it calculates styles. It is not a script that has to load and run.

No extra work arrives with every new device. Breakpoints have to be added whenever a popular width appears that nobody anticipated. A continuous function has nothing to add.

Breakpoints still have their use — but for changes of layout, not of size: when three columns are to become one, and a horizontal menu a drawer. Those are qualitative decisions and there are a handful of them. Text size, spacing and image proportions change continuously.

Three tests you can run on your own phone in a quarter of an hour

No tools, no technical knowledge and no need to ask the agency. We pass all three ourselves, which is why we can recommend them.

The thumb-zone test. Take the phone in one hand, the way you hold it on a train. Can the most important button — call, send an enquiry, order — be pressed with your thumb without shifting your grip? Elements in the top corners are outside natural reach in one-handed use, and that is precisely where agencies most often put the phone number and the menu.

The tables and wide-content test. Find a table, a price list or a chart on the site. Swipe sideways. Correctly, the table itself scrolls and the page stays put. Incorrectly, the whole page moves, a horizontal bar appears at the bottom, and the text runs off the screen. On our site wide content has its own scrolling, and that is a rule written into our guidelines, not an accident.

The zoom-lock test. Try to pinch-zoom the page. If you cannot, somebody has disabled zooming — usually with a single parameter in the code, added "so the layout does not break". For somebody with poor eyesight that is a barrier, not an inconvenience. Our own viewport tag sets the width to the device width and the initial scale to one, with no zoom lock — you can check that on us with the same gesture.

If any test comes out badly, you have something concrete to raise with the agency instead of a feeling that "something is off on mobile".

Images — the largest line in the mobile bill

If a site is slow on a phone, in the overwhelming majority of cases the cause is neither the layout nor the code but the photographs. The mechanism is simple and worth knowing, because it lets you ask the right question.

The same file for every screen. A photograph prepared for a 2560-pixel display and sent unchanged to a phone 393 pixels wide is several times more data than can be shown. The browser downloads all of it and then shrinks it on the fly — you are paying, in transfer, for pixels nobody will see.

The fix is mechanical, not editorial. The server prepares several sizes of every image and the browser picks the right one itself, knowing the screen width and the pixel density. This requires no editorial decisions and no different layout — it is a configuration that somebody either did or did not do.

Format matters too. Newer compression formats produce noticeably smaller files than classic JPEG at the same quality, and browsers that do not support them are given a fallback. That, too, is a setting rather than an artistic decision.

What you cannot see and what costs most: the image in the header, which loads first and is usually the largest on the page. It decides how long a visitor waits before seeing anything at all — and it is the one to measure first.

So the question for the agency is not "is the site responsive" but "are images served at a size matched to the screen". These are two different things, and the first is often satisfied without the second.

When responsiveness is not enough

There are situations in which fitting the width is not enough and a separate design decision is needed, rather than another breakpoint.

Comparison tables and price lists. Ten columns will not fit on a phone in any layout. What is needed is a different form of the same information — cards instead of rows, a choice of two items to compare, collapsible sections. That is redesigning the content, not the styles.

Multi-step forms. A form that fits one screen on a desktop becomes, on a phone, a long scroll with the keyboard covering half the view. Splitting it into steps is sometimes the only answer, and it has to be planned rather than forced through styling.

Long lists and search. On a wide screen a filter can sit beside the results. On a narrow one it has to hide somewhere, and that changes the path — a decision about what matters more, not about how many pixels a column has.

The common denominator: these are decisions from the sketch stage, not the coding stage. What the wireframe settles, and what cannot be cheaply undone afterwards, we describe separately.

How to read a proposal containing the word "responsive"

Almost every proposal contains it and it almost never means the same thing twice. Four questions settle what you are actually buying.

Does "responsive" mean fitting the width, or redesigning the layout? That is the difference between a change of styles and a different version of the page. A table that turns into cards on a phone is a redesign and should be a separate line in the quote.

Are wide screens in the price, or only narrow ones? A proposal describing "the mobile version" often says nothing about what happens above a thousand pixels — which is, to repeat, sixty-one per cent of Polish traffic.

How many breakpoints, and what for? A good answer names the moments at which the layout should change qualitatively: when three columns become one, when the menu collapses. A bad answer recites a list of device resolutions.

Who checks the result, and on what? "Tested on devices" without naming them usually means: in a browser window narrowed with a mouse. That is not the same as a phone in your hand, because an emulator has no thumb, no keyboard covering half the screen and no slow connection.

And one thing worth asking for at handover: that the agency walks through the route to contacting you, in front of you, on their own phone. Not on a desktop, not in an emulator. Three minutes, and it produces more than the whole documentation.

And if your traffic really is mobile

The figures at the start of this text are an average for a whole country. Your site is not an average, and there are sectors where the proportion looks quite different — local services, food, retail, anything looked up while out and about.

So the only sensible next step is to check your own data rather than adopt somebody else's number. It takes a few minutes in any analytics tool: traffic split by device category, a window of at least three months, with your own traffic excluded. A shorter window shows a season or a campaign, not a structure.

Three things worth looking at while you are there, because they change the conclusions:

The distribution across the day. If phones dominate in the evening and desktops during working hours, you probably have two different audiences doing two different jobs — and different things should be easiest for each.

The difference between traffic and conversion. It happens that phones bring most of the visits and a minority of the enquiries. That does not always mean the site is broken on mobile; more often it means the decision is made elsewhere. How to read such a gap without drawing a false conclusion from it, we describe in the text on conversion rate.

Where they come from. Traffic from search, from campaigns and from social media has a different device mix. If you are planning a campaign, its channel will shift that proportion regardless of what today's statistic shows.

The conclusion is the same in every case: serve both ends of the axis properly. The "mobile or desktop" argument only makes sense when the budget stretches to one of them — and then the real question is where the decision is made, not where there are more visits.

What this text does not settle

How to measure your own site's speed. Responsiveness and performance are two different things, though frequently confused. We describe the measurement in the text on testing.

Accessibility. A zoom lock is one barrier, but the whole field has its own requirements and its own text.

How to judge a visual design. The heuristics, the standard and the questions to ask are in the text on UX and UI.

What a rebuild costs. The bill depends on whether the layout changes or only the styles — and that is settled earlier. The full breakdown is in the cost section.

Where these figures come from

• Device share, August 2026 — StatCounter Global Stats, Poland: desktop 61.33%, mobile 37.91%, tablet 0.76%. Switzerland: 55.30% / 42.88% / 1.82%. France: 52.98% / 44.59% / 2.43%. Europe: 50.67% / 47.12% / 2.21%. Germany: 47.38% / 50.89% / 1.74%. World: 49.11% / 49.36% / 1.54%.
• StatCounter's methodology — page views across a network of over a million sites, more than 3 billion views a month, with no statistical weighting, with bot filtering the firm itself describes as imperfect, and a 45-day correction window. A partner-network sample, not a census, and that is how we present it here.
• Mobile screen resolutions in Poland, August 2026 — StatCounter: 414×896 — 15.86%, 393×873 — 7.65%, 384×832 — 7.27%, 360×800 — 7.04%, 390×844 — 6.99%. Top three together 30.78%, top five about 45%. For comparison, the European top three come to 32.14% (StatCounter, Europe) — the same magnitude in markets with different device splits.
• Our 29 `clamp()` declarations and the 360–2560 pixel range — checked in this service's code on 16 September 2026, not asserted. The same goes for wide content having its own scrolling and the viewport tag carrying no zoom lock.
• The reading of why the desktop leads in Poland is ours, not the source's. StatCounter reports shares, not causes.
• What is not here: the previous version of this text stated that more than 60% of traffic to Polish online stores comes from phones and that the figure reaches 70% globally, that mobile-friendly sites achieve 67% higher conversion, that a rebuild costs PLN 3,000–8,000 and pays back within three to six months, that three breakpoints cover 95% of devices, that Amazon loses 1.6 billion dollars a year for each second of delay, and that "responsive CSS is 70% change management and 30% technology". The first two contradict the measurement; the rest had no source. All removed.