Speed and mobile for local sites

A tenant in a Bristol car park has water coming through the ceiling of the flat she just left and a phone in her hand. She taps the first plumber she sees and waits. If the page is still white after a few seconds, or the number is under a cookie banner, she goes back and taps the next one. For a local business, speed and mobile usability are the difference between a tap and a call, and they are also what Google measures when it judges how your page performs.

Google reads the phone version of your site

Google's mobile-first indexing documentation says it uses the mobile version of a site's content, crawled with its smartphone agent, for indexing and ranking. The phone version is the page, as far as Google is concerned.

So anything your mobile layout hides or drops, a services list collapsed away, an address only in the desktop footer, is content Google may never index. Google's guidance is to keep the same content on mobile and desktop so both can rank for the same terms, and to let it fetch the mobile page and its images, scripts and stylesheets. A responsive site, one layout that reshapes itself to the screen, is the simplest way to satisfy both.

The three numbers Google measures, and what "good" means

Google's page experience guidance says its core ranking systems look to reward content that provides a good page experience, and the measurable part of that is the Core Web Vitals, three numbers taken from real visits by Chrome users. According to web.dev, Google's own developer site, "good" means a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, each measured at the 75th percentile of visits, so three visits in four have to clear the bar. An earlier metric, First Input Delay, was retired in 2024 and replaced by Interaction to Next Paint, per web.dev; any tool still reporting FID is out of date.

In plain terms, for a local page:

• Largest Contentful Paint is how long until the biggest thing in the first screen, usually your hero photo or headline, is visible. Slow hosting and oversized images are the usual causes.
• Interaction to Next Paint is how quickly the page responds to a tap. Heavy scripts such as chat widgets and booking embeds are the usual causes.
• Cumulative Layout Shift is how much the page jumps while loading. The classic local failure is a call button that moves as a banner loads above it, so the tap lands on something else.

The same guidance is explicit that relevant content comes first and page experience doesn't override it, so treat these as a floor to clear rather than a contest to win. Search Console's Core Web Vitals report shows what real visitors experienced over recent weeks, which is what counts; a one-off speed test is a single run from one place, which is what you use to find the cause.

Make the call button reachable with a thumb

Mobile usability failures are a short, well-known list: a missing viewport tag, so the page renders at desktop width and has to be pinched; text too small to read; tap targets too small or too close together; and content wider than the screen, so the page scrolls sideways. A mobile test reports each one by the element responsible.

Tap target size has named sources rather than a Google rule. The W3C's WCAG 2.2 guidelines set a minimum of 24 by 24 CSS pixels at the AA level, with an exception for targets with enough space around them, and Apple's Human Interface Guidelines recommend 44 by 44 points. Build your primary buttons to the larger of the two.

For a local page the button that matters is the one that starts a call. Do four things to it:

1. Make the phone number a link with the tel: prefix, so a tap dials rather than copies.
2. Put it in the first screen, and keep a fixed bar at the bottom of the page with call, directions and hours, where a thumb rests.
3. Keep it clear of anything that slides in: cookie banners, chat bubbles, pop-ups. Google's page experience guidance asks whether a page avoids intrusive interstitials that cover its content, and a call bar under a pop-up fails that test and the customer's.
4. Link the address to map directions and put the hours next to it in text, not in an image.

The fixes that usually matter on a local site

Local sites share a small set of causes, and they are cheaper to fix than they look.

1. Images. Photos uploaded straight from a phone are the biggest cause of a slow first paint. Resize them to the width they are displayed at, compress them, and give every image width and height attributes so the layout doesn't shift while they load.
2. Third-party scripts. Chat widgets, review carousels, booking embeds and embedded maps each load their own code before the page can respond. Keep the ones that earn calls, load them after the main content, and replace an embedded map with a static image that links to directions.
3. Theme bloat. Page builders load every feature whether the page uses it or not. Trim unused fonts and extras, or switch to a lighter theme.
4. Hosting. Cheap shared hosting makes every page slow before a single image loads. Turn on caching, use a content delivery network if your host offers one, and measure before and after.

Fix one cause at a time and re-measure, so you know which change moved the number.

What to take away

• Google indexes and ranks the mobile version of your page, so anything your phone layout hides is hidden from Google too.
• Core Web Vitals are three numbers from real visits, and web.dev's thresholds for "good" are the floor to clear; relevant content still comes first.
• The call button should be a tel: link in the first screen, large enough for a thumb, and clear of banners and pop-ups.
• Images, third-party scripts, theme bloat and hosting cause most local speed problems; fix one at a time and re-measure.

Next

Your details are consistent, your markup is clean and your page works on a phone; now see how assistants choose who to recommend in How AI assistants pick local businesses.