The tips for optimising your website for mobile users that matter most in 2026 are these: run one responsive site with the same content for every device, make it quick on an ordinary phone and measure that with Google’s Core Web Vitals, design forms and buttons for a thumb, and test on real phones. The rest of this article explains each and shows how to check your own site. Everything here applies equally to a customer portal or an internal web application that people use on their phones.
One responsive site with the same content
A responsive site is a single set of pages whose layout rearranges itself to fit the screen. It has replaced the older practice of keeping a separate mobile site at its own address. Google’s documentation recommends responsive design “because it’s the easiest design pattern to implement and maintain”.
There is a second reason. Google states that it “uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking”. Anything you leave out of the mobile layout to save space is, as far as search is concerned, not on your site. Shorten the layout if you need to, by folding sections away behind headings, but keep the content.
The basic checks are quick:
- no page scrolls sideways on a phone;
- text can be read without zooming;
- images shrink to fit the screen;
- wide tables either scroll inside their own box or rearrange into a list, so that they do not push the whole page wider.
If you still have a separate mobile site, or a desktop site that phones display in miniature, fixing that comes before anything else in this article.
Measure speed with Core Web Vitals
Core Web Vitals are three measurements Google uses to describe how a page feels to real visitors.
| Measure | What it tells you | Google’s “good” level |
|---|---|---|
| Largest Contentful Paint (LCP) | How long before the main content appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page reacts when someone taps or types | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the page jumps about while it loads | 0.1 or less |
A page passes when at least 75 per cent of real visits meet each level, and phones are assessed separately from desktop computers. INP became a Core Web Vital on 12 March 2024, replacing an older measure called First Input Delay. If a report or an audit you have been given still quotes First Input Delay, it is out of date.
Two free tools show the figures:
- PageSpeed Insights. Enter an address and it reports the experience of real Chrome users over the previous 28 days, alongside a laboratory test of the page with suggestions for improving it.
- The Core Web Vitals report in Google Search Console. This groups your pages into Good, Need improvement and Poor, with mobile and desktop shown separately.
A site with few visitors may have no real-user figures. In that case rely on the laboratory test and on your own testing with a phone.
On search rankings, Google is measured in what it claims. Its documentation says that Core Web Vitals are used by its ranking systems, and also that good results do not guarantee a place at the top. The stronger argument for speed is the visitor who gives up waiting.
What usually makes a mobile page slow
- Oversized images. A photograph saved for a large monitor and sent to a phone is the commonest waste. Serve each image at the size it will be shown, in a modern format such as WebP or AVIF, and state its width and height so the page does not jump when it arrives.
- Third-party scripts. Chat widgets, advertising and tracking tags, embedded videos and social media buttons all run code on the visitor’s phone. In our experience they are the most frequent cause of a poor INP figure. List every one, and remove any that nobody can justify.
- Too much JavaScript. A page that is mostly text and pictures should not need a large amount of code before it responds to a tap.
- A slow server. If the system behind the page takes two seconds to answer, very little of the 2.5 seconds is left for everything else, and no amount of work on the page will make it feel quick. This is common in portals and web applications that depend on a database, and the cure lies in the slow software itself.
- Pop-ups. A panel that covers the page as it opens is irritating on a small screen. Google advises against intrusive interstitials and suggests banners that take up only a small fraction of the screen.
Make it easy to use with a thumb
Buttons and links. The accessibility standard WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels at level AA. Google’s guidance on web.dev recommends about 48 pixels, with about 8 pixels between neighbouring targets. Work to the larger figure wherever you can.
Forms. Most of what a business wants from a mobile visitor arrives through a form, so forms deserve the most care.
- Ask for as little as possible.
- Tell the phone what each field is for, so that it shows the right keyboard for an email address or a telephone number and offers to fill in the visitor’s name and address.
- Put each label above its field and each error message beside the field it refers to.
- Set the text in form fields to at least 16 pixels. Smaller text is hard to read, and iPhones zoom the page in when such a field is tapped.
Contact details. Make telephone numbers tap-to-call links, and link addresses to a map.
Navigation. Decide which few tasks people really do on a phone and put those first. For a customer portal that might be checking an order, approving a quotation or uploading a photograph. The full menu can sit behind a button.
No reliance on hovering. Anything that appears only when a mouse pointer rests on it is invisible to someone using a touch screen.
Zoom left alone. Do not switch off pinch-to-zoom. People with poor eyesight depend on it.
Test on real phones
The device preview in a desktop browser is useful for checking layout. It tells you little about speed or about how the page feels in the hand. For that, use real devices:
- a mid-priced Android phone that is a few years old, as well as a recent iPhone;
- on mobile data, away from the office Wi-Fi;
- outdoors at least once, where weak contrast between text and background shows up.
Your analytics will show what share of visits comes from phones and which screen sizes are common. Compare how often mobile and desktop visitors finish what they started, whether that is an enquiry, an order or a sign-in. A large gap points to something specific that is harder on a phone.
Then watch somebody do it. Ask a customer or a colleague to complete the main task on their own phone while you say nothing. Our article on user-centred design describes how to run that kind of session.
A ten-minute check, and when a website is not enough
- Run PageSpeed Insights on your home page, your busiest page and your enquiry or sign-in page. Note the mobile results for LCP, INP and CLS.
- On your own phone, using mobile data and one hand, complete the task you most want visitors to complete.
- Open the Core Web Vitals report in Search Console and look for mobile pages marked Poor.
Take what you find to whoever maintains the site and ask which problems are cheap to fix. Images and unused scripts usually are.
A well-built responsive site or web application meets most business needs on a phone. If yours must work without a signal for long periods, or connect to equipment, compare the options in our article on native apps and web apps before assuming you need an app.