VJOURNAL

Company newsGlobal DeskAugust 27, 2026

Mobile version of a website: eight places it breaks most often

Opening the site on your own phone and scrolling is not a check: your phone is newer, the connection faster, and you know where to tap. Eight places a mobile version breaks most often.

VITON13 conceptual editorial illustration accompanying Mobile version of a website: eight places it breaks most often

Answer in brief

Opening the site on your own phone and scrolling is not a check: your phone is newer, the connection faster, and you know where to tap. Eight places a mobile version breaks most often.

3 sources
Your phone is newer than average and you know where to tap — your own walkthrough is not a check.
The tappable area has to be noticeably larger than the button looks.
An element wider than the screen must scroll inside itself rather than drag the page.

More than half of visits come from phones, and checking happens on a desktop

A site owner looks at their site on a large screen, with fast internet, a mouse and a warm cache. Their visitor is usually on a phone, on a train, using one hand.

Because of that an entire class of faults stays invisible for months. Not because they are hard to find, but because nobody looks from the side where they exist.

It is made worse by the mobile version almost always being built second. The wide-screen layout first, then squeeze it down for phones. The squeezing is exactly where things break.

Below: eight places that break most often, in order of frequency, and a way to check your own site in half an hour that finds real problems rather than confirming it looks fine.

Why looks fine is not a check

The commonest way of checking is opening the site on your own phone and scrolling. It catches only crude layout faults and misses everything else.

Your phone is not an average phone. It is newer, the screen is larger, the connection is faster, and half the site is already cached from previous visits.

And crucially: you know where to tap. You are not hunting for a button, reading labels, or wondering what will open. Those three things are exactly what a stranger's mobile experience consists of.

A real check is completing a specific task end to end: find a price, submit an enquiry, place a call. And timing how long it took.

Check separately over mobile data rather than home wifi. The speed difference can be fivefold, and half the problems are visible only that way.

Buttons: size and hitting them

The commonest fault and the cheapest to fix.

A finger is not a cursor. The tappable area has to be noticeably larger than the button looks: a square of roughly a centimetre a side is the guide. A link the height of one line of text does not meet it.

The second trouble is buttons placed flush against each other. Two neighbouring elements with no gap means people regularly hit the wrong one, and do not always notice.

The third is a button under the browser bar. The bottom of a phone screen belongs to the interface, and an element pinned to the bottom ends up half hidden.

And a fourth, less obvious one: a phone number that does not dial when tapped. Writing the number as plain text and not making it a link means forcing somebody to select and copy it one-handed.

Forms: where enquiries are lost

A form on a phone is where most of the people who made it to the end of the journey fall away.

Every extra field costs more than on a desktop: typing is awkward, the screen is small, everything around is distracting. Ask exactly what you need to call somebody back.

Check which keyboard opens on each field. A phone field should bring up the numeric keyboard, an email field the one with the at sign, not the ordinary one. That is one line of markup and a noticeable difference in comfort.

Watch what happens when the keyboard covers half the screen. Often the field being typed into ends up underneath it, and the person is typing blind.

And check that the submission confirmation is visible without scrolling. If the thank-you message appears above the viewport, people will not see it and will press the button a second time.

Tables, price lists and anything wide

The second commonest source of faults and the first in consequences if you have a catalogue.

A six-column table does not fit a phone by any means. There are two options: give it horizontal scrolling inside its own container, or rebuild it as cards where each row becomes a block.

What cannot be done is leaving it as it is. Then the whole page scrolls, and somebody trying to see the right-hand edge of the table drifts sideways along with the menu and the header.

The same goes for wide images, code blocks and embedded maps. Any element wider than the screen has to scroll inside itself rather than dragging the page along.

It takes one gesture to test: swipe sideways anywhere on a page. If the page moved, you have an element breaking it.

Popups

On a desktop a popup covers part of the screen. On a phone it covers all of it.

Hence a rule worth treating as hard: a popup on a phone must close on the first attempt, via a close button of adequate size, and must not reappear in the same session.

Popups that appear immediately on arrival are the most damaging. Somebody coming from search has not yet worked out whether they are in the right place and is already having to dismiss something. A proportion simply leave.

A category of its own is consent and notification prompts stacking on top of each other. Two dialogues at once on a small screen means the content is not visible at all.

A practical compromise: show the offer not immediately, but after somebody has scrolled halfway or spent at least half a minute on the page.

Text: size, line length, contrast

Three things that look like taste and decide whether anyone reads.

Size: small text on a phone does not get read, it gets pinched larger, and that is irritating. Body text should be no smaller than on a desktop, rather than the reverse.

Line length: on a narrow screen lines come out short on their own, but the side margins are often made too wide. Text needs room, but not at the cost of half the screen.

Contrast: pale grey on white looks elegant on a good monitor indoors and disappears on a phone in sunlight. It has to be checked outdoors, not at a desk.

And do not disable zooming. Some sites switch off pinch-to-zoom for the sake of layout stability — for people with poor eyesight that makes the site unusable.

What specifically slows a phone down

Mobile speed differs not in degree but in kind: the bottlenecks are different ones.

Images. What is displayed at a thousand pixels on a wide screen needs half that on a phone. If the site serves everyone one file, the phone downloads what it cannot use.

Third-party scripts. Chats, counters, review widgets, maps. Each is imperceptible on a powerful computer and together they add up to seconds of waiting on an average phone.

Fonts. If text waits for a font to download, somebody spends several seconds looking at empty space. It is configured in one line, and that line is almost always forgotten.

And everything loading at once. Whatever sits below the first screen should load on scroll. On a desktop the difference is barely visible; on a phone it is decisive.

How to check properly

Four methods, cheapest to most accurate.

Shrink the browser window on a desktop to phone width. Catches crude layout faults in a minute, but nothing about fingers or speed.

Device mode in the browser. Closer to the truth: it emulates screen size, pixel density and touch instead of a mouse. A good way to test forms and button targets.

Your own phone on mobile data. The only way to see real speed. With the cache cleared — open the site in a private window.

And somebody else's phone, preferably older than yours. The most honest check of all, and it regularly reveals what nothing else does.

Responsive layout or a separate mobile site

A question that used to be contested and now has a clear answer.

A separate mobile site on its own address is an outdated solution. It means two sets of pages, two sets of text, and a permanent risk that they diverge.

A responsive layout is one set of pages that rearranges to screen width. One address, one text, one job when updating.

Search engines judge a site by its mobile version: that is the one treated as primary. Which means content you hid on phones for compactness may not exist for search at all.

The practical consequence: do not hide text and links on the mobile version. Collapsing them into expandable blocks is fine; removing them entirely is not.

A half-hour checklist

Take a phone, switch off wifi, and work through the points.

Open the site in a private window and time how long until content appears.

Find the price of any service without using the site's own search.

Submit an enquiry to the end and wait for the confirmation.

Tap the phone number and check the dialler opens.

Swipe sideways on several pages and see whether the page itself moves.

Open a page with a table or price list and try to read the right-hand edge.

And take the site outside on a sunny day. Half the contrast problems are visible only there.

Practical checklist

  • Open the site in a private window over mobile data and time it.
  • Find the price of any service without using the site's own search.
  • Submit an enquiry to the end and wait for confirmation.
  • Tap the phone number and confirm the dialler opens.
  • Swipe sideways and see whether the whole page moves.
  • Check which keyboard opens on the phone and email fields.
  • Take the site outside on a sunny day and check the contrast.

Questions and answers

Is shrinking the browser window enough to test with?

No. A shrunken window catches crude layout faults and shows nothing about finger targets, field keyboards or real speed. Device mode in the browser is closer to the truth, and genuine speed is visible only on a phone over mobile data.

How large should buttons be on a phone?

The tappable area should be roughly a centimetre square, and noticeably larger than the button appears. A link the height of one line of text does not meet that, and two elements flush against each other produce constant mis-taps.

What should be done with wide tables on mobile?

Either give the table horizontal scrolling inside its own container, or rebuild it as cards where each row becomes a block. Leaving it as it is means the whole page drifts sideways along with the menu and the header.

Can content be hidden on phones?

Collapsing it into expandable blocks is fine; removing it entirely is not. Search engines judge a site by its mobile version, and text that is absent on phones may not exist for them at all. The same applies to internal links.

Is a separate mobile site needed?

No, that is an outdated solution: two sets of pages and text inevitably diverge. A responsive layout gives one address, one text and one job when updating, and it rearranges to screen width automatically.