Open your site on a phone and try to place an order or send an enquiry using only your thumb, on the move, on mobile data. That exercise takes three minutes and usually uncovers more problems than any automated report.
Mobile traffic has been the majority for years. On most sites we review it sits between 60 and 78 percent. Design, however, is still often produced and approved on a large monitor, with the mobile version checked hastily at the end. The result is familiar: the site looks great in the presentation and performs mediocre where the real customers are.
What responsive design means in practice
Responsive design is not simply fitting the content onto the screen. That is the minimum. Real adaptation means priorities get reordered on a small screen.
On desktop you have horizontal space and can show a filter sidebar, three product columns and an eight item menu. On a phone the same content stacked vertically requires ten scrolls before anything useful appears.
A good mobile version is therefore not a shrunken desktop version but a different arrangement of the same information. The most important thing goes first. Secondary material folds into accordions. Whatever serves nobody disappears.
Mobile first is not a slogan
The mobile first approach means design starts at the narrowest screen and expands upward. The reason is practical: when you start at 375 pixels wide you are forced to decide what genuinely matters. When you start at 1440 and shrink, you drag everything along and try to cram it in.
What Google checks
Since Google indexes primarily with the mobile version, this is a condition rather than a recommendation. The search engine sees your site the way a phone user sees it.
The main technical criteria are a handful.
Content must be identical across versions. If the mobile version hides part of the text or lacks the same structured data, that content effectively does not exist for indexing.
Core Web Vitals are measured on mobile devices. LCP, the time to render the main element, should be under 2.5 seconds. CLS, visual instability, under 0.1. INP, interaction responsiveness, under 200 milliseconds.
No horizontal scrolling. An element that extends beyond the screen width is a classic problem, usually caused by a fixed pixel width or a large table.
Tap targets are large enough and adequately spaced. The guidance is roughly 44 by 44 pixels minimum.
Text is readable without zooming. Body type below 16 pixels on a phone triggers browser zoom and a broken layout.
For measurement use PageSpeed Insights and the Core Web Vitals report in Search Console.
Where mobile customers are lost
Session recordings show recurring patterns.
Popups that cannot be dismissed. The close button is small, off screen, or appears with a delay. The user gives up and leaves.
Forms that are not adapted. The phone field opens an alphabetic keyboard. The keyboard covers the field being filled. There is no autofill. Dates are typed manually rather than picked from a calendar.
Price below the fold. On a product page the image fills the screen and the visitor has to scroll to see the price. This is among the most expensive mistakes in online stores.
Too long a path to action. Five scrolls to the order button on a phone is a lot. A sticky button that stays visible usually solves it.
Heavy images. A 3 megabyte photo on mobile data means waiting and abandonment. Modern formats such as WebP and AVIF cut file size substantially at the same visual quality.
Slow loading from scripts. Every additional tracking tool, chat widget, banner and plugin adds weight. Check what you actually use and remove the rest.
A practical checklist
| Check | How to do it | Priority |
|---|---|---|
| Horizontal scrolling | Open on a phone and swipe sideways | High |
| Button size | Try tapping with a thumb, not a fingernail | High |
| Price and CTA above the fold | Open a product page without scrolling | High |
| Keyboard type per field | Tap a phone field and an email field | Medium |
| Dismissing popups | Try closing it one handed | High |
| Image weight | DevTools, Network tab | Medium |
| Text readability | Read a paragraph outdoors in sunlight | Medium |
| Speed on mobile data | Throttle the browser to 4G | High |
This list takes about half an hour and covers most typical problems.
Images, fonts and speed
Images are the most common source of weight. Three measures solve nearly everything: a modern format, correct sizes per screen via srcset, and lazy loading for everything below the fold. The hero image is not lazy loaded, because it is usually the LCP element.
Fonts matter more than they seem. Every additional font file is a separate request. Two weights of one family are usually enough. Set an appropriate loading behaviour so text is not invisible for several seconds.
Third party scripts are often the biggest load. A chat widget, a heatmap tool, pixels for several ad platforms, a cookie banner. Each looks light on its own, but together they make the difference between 2 and 6 seconds. Defer them and remove those you do not actively use.
Responsive design for an online store
Stores have several specific pressure points.
Filters cannot sit in a sidebar on a phone. The standard solution is a button that opens filters full screen, with a visible result count and an apply button.
The product gallery must support swiping and pinch to zoom. Arrows designed for a mouse work poorly with a thumb.
Cart and checkout are critical. Every unnecessary field reduces completed orders. Guest checkout, address autofill, and a clearly displayed total including shipping before the final step.
There is more in our online store checklist and our online stores service.
Separate mobile version or responsive site
The verdict is settled. A separate mobile subdomain like m.example.com creates double maintenance, a risk of content divergence and extra work with redirects and canonicals. There is almost no case today where that approach is justified.
A responsive site with one codebase and different rules at different widths is the standard. Very complex applications sometimes use adaptive serving from the server, but that requires more resource and is rare.
A separate app is a different question. It does not replace the mobile site and makes sense only with repeat usage by loyal customers. See our article on business mobile apps.
Cost and where to start
If the site is fairly new and built on a modern foundation, mobile optimisation is usually a matter of settings: images, scripts, arrangement of key pages. That is a few days of work.
If the site is eight years old, with fixed widths and layered patches, rework often costs more than a new front end. In such cases it is more sensible to plan a redesign with responsiveness built in from the start. See also our article on redesign and migration.
WEBPROGRESS quotes individually after reviewing the specific site, with an answer within 24 hours.
Frequently asked questions
How do I check whether my site is mobile friendly
Fastest with a real phone rather than only the browser emulator. The emulator shows dimensions but not real speed, keyboard behaviour or the feel of tapping. Supplement it with PageSpeed Insights on mobile and the usability report in Search Console.
Does mobile speed affect Google rankings
Yes, though less directly than commonly claimed. Core Web Vitals are a ranking factor, but with less weight than content relevance. The indirect effect matters more: a slow site loses visitors before they see the content, and that shows up in every other signal and in revenue.
Should content be hidden on mobile
Not if it is important. Hiding text that exists on desktop means it will not count for indexing. Folding content into an accordion is acceptable, as long as it is present in the code and opens with one tap.
What is a reasonable speed threshold on mobile
As a working reference, LCP under 2.5 seconds on a 4G connection and total time to interactive under 4 seconds. Values above 5 seconds cause noticeable losses. The absolute numbers matter less than the direction: measure, fix, measure again.
How should the cookie banner behave on a phone
It must be dismissable one handed, must not cover the whole screen, and must not block content until handled unless legally required. Defer its loading so it does not affect LCP. There is more on the requirements in our article on GDPR and cookies.
Conclusion
Mobile optimisation is where most of a site's revenue is decided, because that is where most of the visitors are. The work is not complex, but it requires looking at the site from the position of a person holding a phone with limited patience.
If your mobile traffic is high while mobile conversion lags, write to us through contact. We review the site, deliver a prioritised fix list and prepare an individual quote within 24 hours. See also our services for web development, hosting and SEO.
