Performance
A fast website on mobile: how to measure it and what slows it
People looking for a local business usually do it on a phone, often on the move and on mobile data. If the site is slow, they go back and tap the next result. A site that “looks fine” on a phone isn't the same as one that works on a phone. This guide explains how Google measures speed, how to check it yourself in five minutes, what slows a site down and what to fix first.
Why it matters for a local business
A local business website has a very specific job: whoever opens it should know within a few seconds what you do, where you are, whether you're open and how to contact you. That person isn't browsing for fun; they're usually comparing two or three options with the phone in their hand. If your page is slow to show anything, the back button is closer than your phone number.
Phones are also the worst technical scenario: slower processors than a computer, variable connections and a small screen. A site that runs fine on the office computer can take three times as long on a mid-range phone with patchy coverage.
Google takes it into account too. It indexes sites based on their mobile version and uses Core Web Vitals as one of its page experience signals. They aren't what counts most for ranking — content and relevance matter more, as the local SEO guide explains — but between two similar results, a poor experience doesn't help.
How Google measures speed: Core Web Vitals
Google sums up the loading experience in three metrics, the Core Web Vitals. It measures them from real visits by Chrome users who share usage statistics, and for each one it takes the 75th percentile: the page passes if at least three out of four visits meet the threshold.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How long the largest element on screen takes to appear, usually the main photo or headline | ≤ 2.5 s | 2.5–4 s | > 4 s |
| INP (Interaction to Next Paint) | How long the page takes to react when you tap a button, a menu or a field | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | How much the content moves around while loading | ≤ 0.1 | 0.1–0.25 | > 0.25 |
What they mean in practice
LCP is the feeling of “it's loaded”. INP replaced an earlier metric (FID) in March 2024 and measures whether the site responds smoothly or freezes for a moment every time you tap something, typical of pages with lots of code. CLS is what happens when you go to tap a button and it moves because an ad or an image loaded above it: annoying, and it causes wrong taps.
A fourth metric is useful for diagnosis, although it isn't one of the three core ones: TTFB, how long the server takes to start responding. If it's above roughly 0.8 seconds, the problem starts with the hosting before the page.
How to check it yourself
You don't need to code to know whether your site performs well. There are three free Google tools and one manual test.
PageSpeed Insights
Open pagespeed.web.dev, paste your site's address and look at the mobile tab. You'll see two blocks that are worth not mixing up:
- At the top, field data (“what your real users are experiencing”): it comes from real visits over the last 28 days. This is what counts for Google. If your site gets little traffic, there won't be enough data and it won't appear.
- Below, lab data (Lighthouse): a simulated test run at that moment on a mid-range phone and a slow connection. The 0 to 100 score comes from here. It's useful for finding problems even without traffic, but it varies from run to run.
- Under the score, the list of “diagnostics” shows which files weigh the most and what's blocking the load. It's the starting point for fixes.
Search Console
If your site is set up in Google Search Console, the “Core Web Vitals” report groups your pages into good, needs improvement and poor, separately for mobile and desktop, using real data. It's useful to see whether a problem affects the whole site or only one type of page, and to confirm that a fix has worked (it takes a few weeks to show, because the data covers 28 days).
The phone-on-mobile-data test
Turn off wifi, open your site on your own phone on mobile data, in a private tab so it doesn't use the cache, and count. If after three seconds you can't tell what business it is and how to call, neither can the customer. Then try to do what a customer would: call, check opening hours, open directions, book. Every thing that's hard to find is a customer lost.
Don't obsess over scoring 100 in the lab test. What matters is that the real-user data is green and the site works well on an ordinary phone.
What usually slows it down
On most small business websites, slowness comes from a handful of recurring causes:
- Huge images: a photo straight from a phone weighs 3 to 8 megabytes and is 4,000 pixels wide. On a phone screen it's shown at around 400 to 800 pixels, and it should weigh tens or a few hundred kilobytes.
- Homepage carousels: they load five large images to show one, add code to move them, and almost nobody gets past the first.
- Background video: heavy, it uses up the customer's data, and on many phones it doesn't even play or shows as a still image.
- Too many plugins: on sites built with WordPress and similar, each plugin can add its own files to every page, whether used or not.
- Third-party widgets: live chat, social buttons, counters, ad pixels and heavy cookie banners. Each downloads and runs its own code, and they're usually what ruins INP.
- Embedded maps and videos: an embedded Google map or YouTube video downloads hundreds of kilobytes of code even if nobody touches it.
- Fonts: loading four families with six weights each is noticeable. Two families with a couple of weights are enough.
- Cheap, overloaded hosting: if the server takes a second to start responding, nothing else makes up for it.
How to fix it, in order of impact
You don't need to rebuild the site to improve it a lot. This order usually gives the most result for the least effort:
1. Images
It's almost always the first thing and the most noticeable.
- Modern format: WebP or AVIF weigh much less than JPG or PNG at the same quality, and all current browsers support them.
- Real size: resize to what's displayed. A full-width photo on a phone rarely needs more than 1,200 to 1,600 pixels wide, and the site can serve several versions so each screen downloads its own (srcset and sizes attributes).
- Declared width and height: every image should state its dimensions so the browser reserves the space. It's the simplest way to avoid layout jumps (CLS).
- Lazy loading: images further down should only load when the user gets near them (loading="lazy"). The main image at the top, on the other hand, shouldn't be lazy-loaded: it's the one that sets the LCP and should get priority.
2. Third parties
Take stock of everything the site loads from other services and ask whether each one is used:
- Map: instead of the embedded map, a static image of the map with a link that opens Google Maps or the maps app. It's more useful to the customer, because it opens directions straight away.
- Video: show a thumbnail with a play button and load the player only when tapped.
- Chat: if you don't answer it in real time, a WhatsApp button or a contact link does the same without loading code on every visit.
- Pixels and tags: remove the ones for campaigns you no longer run.
3. Server and caching
Make the server respond quickly and stop the browser downloading again what it already has:
- Page caching: if the site is generated on every visit (like WordPress without caching), a caching system or pre-generated pages cut response time to a fraction.
- Browser caching: images, styles and fonts should be sent with a long expiry so the second visit is almost instant.
- Compression: the server should compress text (gzip or Brotli) and use HTTP/2 or HTTP/3.
- CDN: a content delivery network serves files from a point close to the visitor. For a business with customers in a single city and a server in Europe, it helps but isn't essential.
4. Fonts and code
Host fonts on your own server, load only the weights you use and make sure text shows in a system font while the final one arrives (font-display: swap). Remove plugins you don't use and avoid visual page builders that generate lots of code for simple things.
What someone looking for you on a phone needs to see
Speed is half of it. The other half is having what matters one tap away and usable with a thumb:
- A call button that dials directly (a tel: link), visible without scrolling, and another to message if you answer on WhatsApp or email.
- The address linked to Maps, so it opens directions, plus a note on how to get there or where to park if useful.
- Opening hours, with today's easy to see, plus bank holidays and special closures.
- The menu, prices or services as text, not a PDF you have to download and zoom, nor a photo of the paper menu.
- Text of at least 16 pixels with good contrast, readable in sunlight without zooming.
- Large, well-spaced buttons and links. The WCAG 2.2 accessibility standard sets a minimum of 24 by 24 pixels; for main buttons it's better to be around 44 to 48 pixels.
- Nothing covering the screen on arrival: newsletter pop-ups or huge cookie banners that make you hunt for the “x”.
Forms people can fill in on a phone
A contact or booking form is where most customers are lost on mobile. A few simple rules:
- Ask for the minimum: name, phone or email and the message. Every extra field reduces submissions.
- Use the right field type so the phone shows the right keyboard: numeric for phone, with @ for email.
- Turn on autocomplete so the phone fills in name, phone and email with one tap.
- Visible labels above each field, not just grey text inside that disappears when typing.
- Fields with text of 16 pixels or more: on iPhone, if it's smaller, the page zooms in by itself when the field is tapped and throws the view off.
- A clear message on sending, confirming it arrived and when you'll reply.
If the form is for bookings, the online bookings guide explains which system to choose and how to avoid bookings you can't serve.
Checklist
Go through this with your site on a phone, on mobile data, and with PageSpeed Insights open:
- The real-user data in PageSpeed Insights or Search Console is green on mobile (LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1).
- No image weighs more than about 200 to 300 KB, and they're in WebP or AVIF.
- Images have width and height set, and the ones further down are lazy-loaded.
- There's no carousel or background video on the homepage.
- The map and videos don't load until tapped.
- Only the plugins, widgets and pixels you use are left.
- The server responds in under a second and files are served with caching.
- Calling, opening directions and seeing opening hours take one tap from the first screen.
- Text is readable without zooming and buttons can be hit with a thumb without missing.
- The form fills in with autocomplete and confirms submission.
It's much easier to build a fast site than to speed up a slow one. AMG Design sites start from pages generated ahead of time, with no plugins and images optimised at publish, and they're checked against these metrics before handover.
Frequently asked questions
What PageSpeed score should my website have?
The 0 to 100 score is a lab test and varies from run to run. What matters to Google is the real field data: LCP, INP and CLS in green. Above 90 on mobile is very good, but a site scoring 75 with green real-user data doesn't have a problem.
Why doesn't PageSpeed Insights show real data for my site?
Because field data comes from real Chrome visits and there need to be enough of them over the last 28 days. Sites with little traffic don't have it. In that case, go by the lab test and by testing on your own phone.
Does website speed affect Google rankings?
Yes, but only a little compared with content and relevance. Core Web Vitals are one of the page experience signals. Where speed shows most is in the customers who leave before the page loads.
How much should an image on a website weigh?
A large homepage photo, between 100 and 300 KB in WebP or AVIF; thumbnails, tens of KB. If an image weighs more than 1 MB, it can almost certainly be reduced without any visible difference.
Does an embedded Google map slow my website down?
Yes: it downloads a fair amount of code even if nobody uses it. An image of the map with a link to Google Maps is lighter and more useful, because it opens directions in the phone's maps app.
Can my WordPress site be fast?
It can, with good hosting, a caching system, few plugins, a lightweight theme and optimised images. What makes it slow isn't usually WordPress itself but piling up plugins and visual page builders.