Speed and Mobile Conversion: The Working Guide

Speed and mobile are one subject, not two. The visitor most likely to leave is on a phone, on an ordinary network, meeting a page built and tested on a desktop. The working programme has four parts: measure real-visitor field data rather than office tests, take the large wins first, which are almost always images and third-party scripts, lay every key page out for thumbs, type and one-handed decisions, and make paying on a phone a matter of wallets and autofill rather than keystrokes. The measures that anchor the speed half are the Core Web Vitals thresholds documented by the Chrome team on web.dev: Largest Contentful Paint at 2.5 seconds or under, Interaction to Next Paint at 200 milliseconds or under, and Cumulative Layout Shift at 0.1 or under. This bench is the map.

Your tests flatter you: a fast connection, a cached page, a recent phone. Field data, collected from real visits over the past weeks and surfaced through PageSpeed Insights and the Chrome UX Report, describes the phones and networks your customers used. The bench's guide to measuring speed with field data covers reading it without either panic or complacency. Until field data exists, a throttled lab test on a mid-range profile is the honest substitute. Every other guide in this bench assumes that measurement basis, because speed work aimed at a flattering test optimises the test, while speed work aimed at field data optimises the visit your customers actually had.

On most small stores the largest, cheapest speed gain is image weight: correctly sized, compressed, modern-format product and hero images, loaded in the order the visitor needs them. The bench devotes its longest practical guide to images for that reason. The second win is the script budget: every app, chat tool, review widget and tag pays rent in load and responsiveness, and the audit in the third-party script budget prices each one against the job it does. Theme choice sets the floor under both, covered in theme speed. Work in that order and most stores find their field numbers transformed before any exotic optimisation is needed.

A fast page that fights the thumb still loses. Product information, price, delivery and the buy action must sit where one hand can reach and read them, at type sizes that do not require pinching, on tap targets a fingertip cannot miss. The bench covers the craft in mobile layout, judges the sticky bars that compete for the small screen in sticky bars and mobile chrome, and works through browsing, lists and filters in mobile browsing. The standard is unforgiving and simple: anything the visitor must do to buy should be doable one-handed, on a moving bus, with the sun on the screen.

The checkout is where every earlier friction is forgiven or charged. On a phone, typing a card number, an address and a discount code is the most expensive interaction in the business, so the bench's guide to paying on a phone treats wallets, express payment and clean autofill as conversion features, not conveniences. Address lookup, sensible keyboards per field, and errors that help rather than scold complete the picture. Judge this work on the mobile checkout completion step in your funnel, split by device, because the blended checkout rate will hide a mobile problem behind desktop health for quarters at a time.

Speed arguments inside a business end when the cost is priced from its own numbers: the traffic arriving on slow templates, the step rates those templates produce, and the orders a realistic improvement represents, stated as an illustration rather than a promise. The bench's guide to pricing the cost of slow pages builds that calculation honestly. The same honesty applies in reverse: not every slow page deserves engineering, and a page nobody buys from can be slow in peace. The vitals thresholds from the web.dev documentation give the programme its targets, LCP 2.5 seconds or under, INP 200 milliseconds or under, CLS 0.1 or under, but the queue of work is set by your funnel and your field data, in that order.

Separate lite sites and revived AMP projects promise speed by subtraction and usually deliver a second site to maintain, a poorer version of the offer, and a fresh set of inconsistencies for visitors who cross between versions. The verdict guide, lite versions and AMP, sets out the reasoning and the narrow exceptions. The durable route is less glamorous: one responsive site, images under discipline, scripts on a budget, a theme chosen partly for its weight, and field data reviewed monthly so the gains are defended as new tools and content arrive. Speed decays by accretion, not by catastrophe, and a monthly glance at the same numbers is what keeps this bench's work from quietly expiring.