How to make a website mobile friendly

How to make a website mobile friendly: start with the small screen, with readable text without zoom, tap targets of at least 44 px and no sideways scrolling. The desktop comes second, as a variant of a layout already proven in portrait.

The viewport is the first check

Without a viewport meta tag, a phone assumes a width of 980 px and shrinks everything: text turns microscopic and buttons overlap. The fix is one line, in the head of every page, before any stylesheet.

Never use user-scalable=no or maximum-scale=1: they block zoom and break WCAG 2.2 criterion 1.4.4 (Resize Text), which asks for text scalable to 200% without loss of content.

Four measurements that decide whether the site holds

Images and fonts: weight shows on a mobile network

A 2400 px image served to a 390 px phone costs bandwidth and decode time with no visual benefit. The fix is srcset with sizes, plus loading="lazy" on everything below the first screen. For fonts, font-display: swap avoids invisible text during loading. Both techniques are covered in responsive images with srcset and font-display and CLS.

The menu is where the visit is lost

A desktop menu with ten items, squeezed into 390 px, becomes an unreadable line of text. On mobile you need an explicit button, a full-screen panel, closing on Esc and focus returning to the button. The technical detail is in mobile navbar in React; ready-made blocks are in navbar blocks.

How to measure it in ten minutes

Lighthouse in mobile mode simulates a CPU four times slower and a 4G network: a harsh but repeatable estimate. The command below collects three runs and reports the median, which is steadier than a single pass.

npx @lhci/cli autorun --collect.url=https://example.com --collect.numberOfRuns=3

There are three thresholds to watch: LCP under 2.5 seconds, CLS under 0.1, INP under 200 ms. How to enforce them in CI is in Lighthouse CI thresholds; for interaction the reference is INP explained. The figure that counts is still the field data in Search Console, because the lab never sees the user's phone.

Accessibility and duties: what the law says

In Italy, legge 9 gennaio 2004, n. 4, article 3, requires accessible websites for public administration; directive (EU) 2016/2102 of 26 October 2016 extends the same duty to bodies providing public services, with EN 301 549 as the technical reference. For a private company the contractual duty starts when it sells to the public sector, but the WCAG 2.2 criteria remain the useful technical measure for anyone. An accessible site is also easier to index, because the structure a screen reader needs is the structure a search engine reads.

Where this guide stops

Chrome DevTools emulation is no substitute for a real device: Safari on iOS handles the address bar differently, and cheap Android phones perform in ways no simulated profile reproduces. If your audience includes older devices, test on a physical phone before release at least once.

Where to start today