Skip to content
Website speedMobileCall to actionTrade businessAI website

Why a trade business website should load in under two seconds and ask for one thing

T. Krause11 min read

Is a slow website losing you customers? Test it in five minutes with your phone and Google's free tool, then fix the causes in order, cheapest first.

Miniature diorama of a cleaning company's storefront shaped like an upright smartphone with one glowing orange door and a stopwatch beside it

Picture a commercial cleaning company with five staff and a website from 2019. The owner's nephew built it. It has a slideshow of stock photos at the top, a page for each service, a news section that stopped in 2020 and a contact form at the bottom that asks for eleven pieces of information. On the owner's office computer, over the fibre connection, it looks fine.

The people who decide whether to hire the company do not look at it there. A facilities manager opens it on a phone between meetings. A restaurant owner opens it at 11pm after the last table has left. They wait for the slideshow. Some of them stop waiting.

The owner sees none of this. Analytics, if installed, shows visitors. It does not show the visitors who left before the page appeared, because those never counted.

Below is a five-minute test for your own site, and the order in which to fix what it finds.

What the figures say about slow websites and lost customers

Two figures come up in every conversation about mobile speed, and both are old.

The first is Google's. Its study "The Need for Mobile Speed", published in September 2016, reported that 53 percent of mobile site visits are abandoned if pages take longer than three seconds to load. The data came from Google Analytics on about 3,700 mobile sites worldwide in March 2016. You will often see the figure credited to Akamai, whose 2017 State of Online Retail Performance report repeats it with a footnote to Google. It is ten years old and was never about small service businesses. I know of no newer measurement of the same kind, so treat it as an order of magnitude.

The second is from Google's mobile page speed benchmarks of February 2018. The average mobile landing page took about 15 seconds to load fully. Google tested the landing pages of 11 million mobile ads over a 4G connection in January 2018, across all industries. That was eight years ago. Many of the small-business sites I open on a phone still stall on a hero video, but that is my observation and nobody's measurement.

There is a current figure too. The HTTP Archive's Web Almanac 2025, published in January 2026 from July 2025 data, found that 48 percent of websites pass all three of Google's speed measures on mobile. Roughly half do not.

None of these numbers tells you how many customers your site is losing. Five minutes with your own phone tells you whether it is slow.

How to test your website speed

Start with the phone in your pocket, because that is what your customers use. Then let Google's tool put numbers on what you saw.

The phone check, on mobile data

  1. Turn Wi-Fi off, so the phone loads over mobile data.
  2. Open a private tab, which Chrome calls incognito. It ignores saved copies of the page, so you see what a first-time visitor sees.
  3. Type in your address and count the seconds until you can read the headline and see the phone number.
  4. Tap the phone number or the main button straight away. Does the page respond on the first tap?
  5. Watch for anything that jumps while the page settles.

Do it again somewhere with poor signal, a basement or a car park. If you reach three and are still looking at an empty box, you know the result before any tool confirms it.

PageSpeed Insights, step by step

PageSpeed Insights is Google's free speed test. It runs in the browser and needs no account.

  1. Go to pagespeed.web.dev.
  2. Enter the page your customers land on. Usually that is the homepage. If your Google Business Profile links to a different page, test that one afterwards.
  3. Run the analysis and check that the Mobile view is selected, not Desktop.
  4. Read the top section first. It shows data from real visitors over the previous 28 days and says whether the page passed the Core Web Vitals assessment.
  5. If that section is empty, Google has too few visits to report on. That happens with small sites and is not a fault. Scroll down to the lab test.

The lab test loads your page on a simulated mid-range phone on a mobile network and gives a performance score out of 100. Google's PageSpeed Insights documentation, as I read it in October 2026, counts 90 or above as good, 50 to 89 as needing improvement and anything below 50 as poor. The score matters less than the "Largest Contentful Paint" line, which is a time in seconds. Results vary between runs, so run it three times and take the middle one.

The three Core Web Vitals in plain words

Google judges the experience on a page by three measures called Core Web Vitals. The "good" thresholds below are from web.dev, Google's developer documentation, where I checked them on 10 October 2026.

  • Largest Contentful Paint, LCP for short, should be 2.5 seconds or less. It is the time until the biggest thing on the screen has appeared, usually the main photo or the headline. Until then your visitor is looking at half a page.
  • Interaction to Next Paint, or INP, should be 200 milliseconds or less. It is how quickly the page responds to a tap. When it is poor, the visitor taps "Call", nothing happens, and they tap again.
  • Cumulative Layout Shift, or CLS, should be 0.1 or less. It is a score for how much the page moves while it loads, with no unit. When it is poor, the visitor reaches for your phone number, a banner pushes in, and they hit something else.

A page passes when each of the three is in the good range for at least three in four page loads. Google scores mobile and desktop separately. According to web.dev, INP joined the set in March 2024 and replaced an older measure called First Input Delay, which is why older guides list a different third metric.

We aim for two seconds on our own sites rather than 2.5. A page that only just passes in the office fails in a car park with poor signal.

What to fix first

The order goes by effect for effort. The first three fixes cost nothing and fit into a week. The fourth needs a web designer. The fifth costs money, so it waits until the test still fails after the other four. Retest after each step and you will see what it bought you.

1. Oversized images. The Web Almanac 2025 found that on 76 percent of mobile pages the largest element on screen is an image, and that element is what LCP measures. A heavy photo therefore drags down the most important number directly. It is also a fix you can do yourself for free, which is why it goes first. To spot it, save a photo from your own site to a computer and look at the file size. A size in megabytes means it came straight off a phone camera. A 4 MB photo of a finished floor, shown 400 pixels wide, still downloads all 4 MB. PageSpeed Insights lists such images in its findings with the possible saving. You, or whoever updates the site, can resize each photo to the width it is shown at and compress it with a free browser tool such as Squoosh before uploading.

2. A video or slideshow at the top. Second, because the fix is a deletion. A video that autoplays at the top sits exactly where LCP is measured and delays everything beneath it. It says nothing a single good photo would not say. It ranks behind images only because someone has to agree to lose it. In the phone check you see it as a grey box or a spinner where the first screen should be. On a site builder you can swap the header for one photo yourself. On a custom-built site it is a short job for your web designer.

3. Third-party scripts and widgets. A chat window, an embedded map, a social feed, a second analytics tool. Each loads code from someone else's server before your page is finished. Switching one off is free, but a single widget usually brings less than the main photo did, and you have to decide which ones you can live without. That makes it third. This is where you improve the other two vitals. Busy scripts make the page slow to respond to taps, which is INP, and late-loading banners make it jump, which is CLS. The sign is a page you can see but cannot use for a moment. PageSpeed Insights lists third-party code in its findings. Switch off whatever nobody has used in a year, in the builder's list of plugins or through your web designer. Keep the cookie banner for as long as anything on the site needs consent.

4. Fonts. Four font weights from an outside server are four more downloads before the text looks right. The gain is smaller than with the first three, and the change needs someone with access to the site's template, so it is fourth. You notice it when text arrives late, or appears in one typeface and flips to another a second later. Ask your web designer for two weights at most, with the font files served from your own site.

5. Hosting, or the page builder itself. Last, because it is the only fix that costs money and days, and because a faster server does little for a page that is still too heavy. Where PageSpeed Insights has real-visitor data, it shows Time to First Byte, the wait before the server sends anything at all. web.dev, checked in October 2026, puts a good value at 0.8 seconds or less. On a phone the sign is a blank white screen for a moment, even on pages with no large photos. Ring your host first and ask about a faster plan. If that does not move the number, the builder and its plugins are the likely cause and you are looking at a rebuild. Make that decision after steps one to four, not before.

One call to action

Speed gets the visitor into the room. The second question is what the site asks them to do once they are there.

I know of no current count of how many small-business sites leave that question open. What I can describe is what I see when I open them on a phone: no button, no single obvious next step. The visitor arrives, reads, and has to work out for themselves whether to call, email, fill in a form or give up. Working things out is effort, and the next search result is a swipe away.

The fix is to decide what one thing you want from a visitor and to ask for it everywhere, in the same words. For the cleaning company, that is probably "Get a quote for your premises". Not "Contact us", which is a category rather than an action. Not "Learn more", which promises reading. One button, at the top of every page and again at the bottom, that leads to the shortest possible path to a conversation.

The form behind that button matters as much as the button. I could not trace any figure for how much a shorter form helps back to its source, so take the next point as an assumption: every extra field is a chance to stop. A form that asks for name, phone and "what do you need cleaned" in three fields, one at a time, gets filled in. An eleven-field form that asks for a company registration number and a preferred invoice format before anyone has spoken gets abandoned more often.

What this looks like for the cleaning company

Rebuilt, the site has one page that matters and a few that support it. The homepage says what the company cleans, where, and for whom, in the first screen. Under that sentence sits the one button. The photos are of real jobs, compressed to a size a phone can load on a train. There is no slideshow. The contact form asks three questions and sends the answer to a phone that someone is holding, because a form that lands in an inbox checked on Fridays wastes the two seconds you just earned.

Run the test again and the mobile score should be in the green. The visitors who arrive now see a page, and the page asks them for one thing. What happens to that enquiry in the next five minutes is the next leak, and replying to an enquiry within five minutes is its own subject.

Speed as the first step, on purpose

We rebuild the website first, before any other part of the system, for a simple reason. Every other employee sends people to the site. Reactivated customers click a link to it, and ads send paid traffic to it. If the site loses some of them before it has appeared and asks the rest for nothing, everything upstream is working to fill a room with no door.

A fast site closes the first leak only. It gets the visitor as far as the call button, and if nobody picks up, the effort was wasted. Counting your missed calls for one week shows how large that second leak is.

The AI website employee is the version of this rebuild that comes as part of the system: under two seconds on a phone, one call to action, a form that asks one thing at a time and hands the enquiry to the follow-up employee. If you want to see how the two-second site fits with the rest of the sequence, the calculator shows what each leak costs in your own numbers.

The cleaning company's nephew did a reasonable job in 2019. The site just has to open on a phone in a car park in under two seconds, and ask for one thing. That is the whole brief.