Fast On The Phone In A Driveway: Speed For Trade Websites

A trade website is not read on a desk. It is opened on a phone, in a driveway, in a basement, in a car park, on one bar of signal, by somebody who has three other tabs open and no patience. That is the environment the site has to work in, and it is nothing like the office where it was signed off.

The test that matters

Before any of the technical detail, change how the site gets judged.

Most trade websites are approved on a large screen, on office broadband, with the browser cache warm from the twelve times the owner has already looked at it. Under those conditions almost any site feels fine, which is why almost every owner is surprised when they are told their site is slow.

The honest test takes two minutes. Take a mid-range phone, not the newest one in the company. Turn off the wifi. Open the site from a search result rather than from a bookmark, so nothing is cached. Count how long it takes before the phone number is visible and tappable.

That number is the only performance metric that matters commercially, because until it happens, the page is doing nothing at all.

What the measurements are actually saying

There are three widely used measurements and they map onto three things a real person experiences.

Largest Contentful Paint is roughly when the main thing on the screen appears. On a trade site that is usually the hero heading or image. Until that happens the visitor is looking at a blank or half-built page and deciding whether to go back.

Interaction responsiveness is whether the page reacts when tapped. A page that has painted but is still busy running scripts feels broken in a specific and infuriating way: the button is there, you tap it, nothing happens.

Cumulative Layout Shift is whether things move around while loading. This is the one that costs taps. A thumb aims at a call button, an image finishes loading above it, the button moves down, and the tap lands on something else.

Google’s own documentation on these measurements is worth reading once, and its page experience guidance is clear about how they sit alongside content quality: useful content is the main thing, and these are part of how a page is assessed. The reason to care, though, is not ranking. It is that each one describes a way a real visitor gives up.

Where the weight actually is

Open any slow trade website and the breakdown is nearly always the same.

Images, first and worst

On most trade sites the images are larger than everything else combined, and the hero image alone often accounts for most of that.

The common causes are all mundane. A photo straight from a phone camera at full resolution, uploaded and then resized by the browser to fit a 400px-wide slot, so the visitor downloads several megabytes to see a few hundred kilobytes worth of pixels. A gallery of thirty full-size images, all loading at once, on a page where the visitor will look at four. A background image chosen for a desktop hero, served at that size to a phone.

The fixes are equally mundane and enormously effective: serve images at the size they are actually displayed, in a modern format, and let anything below the fold load lazily. That is it. That is usually the difference between a site that is slow and a site that is fine.

Third-party scripts, second

Chat widgets, review carousels, tracking pixels, tag managers that load five more things, booking embeds, social feeds, font services, heat-mapping tools. Each one is a request to a server you do not control, and several of them block the page from finishing.

The uncomfortable truth is that most trade sites carry several of these and use none of them. The chat widget nobody staffs. The tracking pixel from a campaign that ended two years ago. The review widget showing four reviews that could have been text.

Every one of those has a cost, and the cost is paid by the person in the driveway.

Builder overhead, third

A page builder ships a general-purpose runtime: the code required to render any page anybody might build, whether or not this page uses it. Add a plugin for a slider, another for forms, another for galleries, and each brings its own code and its own stylesheet, loaded on every page regardless of need.

This is not an argument that a builder site cannot be improved. Compressing images, removing unused plugins and cutting third-party scripts will help any site. It is an argument that there is a floor, and that the floor is higher than where a purpose-built page starts.

Hosting, fourth and usually blamed first

Hosting matters, and it is rarely the main problem. A site that takes eight seconds to become usable on a phone does not do so because the server took an extra hundred milliseconds to respond. It does so because four megabytes of images and six third-party scripts came after that response.

Move hosting when hosting is the problem. Check the other three first.

What a fast trade page looks like

The pattern is consistent across trades and it is not complicated.

The critical content is in the HTML. The heading, the phone number, the service area and the main call to action exist in the markup rather than being rendered by a script. If a script fails, which happens on flaky connections more often than anybody assumes, the page still does its job.

One hero image, or none. Sized for the viewport it is shown in, in a modern format, with dimensions declared so the layout does not jump when it arrives.

No carousel. Sliders are the most reliably counterproductive component in trade web design: they are heavy, they move content out from under a thumb, and visitors rarely see past the first slide. Show the first slide as a static section and delete the rest.

Fonts that do not block. Two families at most, loaded so that text is readable while they arrive rather than invisible until they have.

Everything below the fold loads lazily. Galleries, maps, embeds, video. None of that should compete with the first paint.

Third-party scripts audited quarterly with one question per script: what does this do, and who looked at its output this month? Anything without an answer comes off.

Layout shift, the underrated one

Layout shift gets less attention than raw speed and costs more on a phone.

The sequence is familiar to everybody, even if they have never named it. The page appears, you reach for a button, an image or a banner finishes loading above it, everything slides down, and your tap lands on the wrong thing. On a trade site, the wrong thing is frequently a different service page, and the visitor is now somewhere they did not intend to be, annoyed.

The causes are few and fixable:

• Images without width and height declared, so nothing is reserved for them.
• Banners, cookie bars and promotional strips inserted above existing content after load.
• Fonts that swap between fallback and final at different sizes, reflowing the text around them.
• Embedded widgets that arrive late and push everything down.

Reserving space for anything that will arrive later fixes nearly all of it. This is a build-time decision rather than a maintenance task, which is why it tends to be either right or persistently wrong.

What speed is actually worth here

The general case for speed is well established, and web.dev’s material on why speed matters covers the research. For a trade business the argument is narrower and blunter.

Your visitor has a problem and a list of companies. They are on a phone in a bad place with a weak signal. If your page has not become useful in the time they are willing to give it, they press back and open the next result. Nothing about the quality of your work, your pricing or your reviews enters into it, because none of that has rendered yet.

That is not a marginal effect that shows up in aggregate analytics. It is the whole of the loss, invisible, one visitor at a time.

The secondary argument is about who you lose. A slow site loses hardest exactly where the margins are best: emergency work, where the visitor is most impatient, and rural service areas, where connections are worst. The jobs a slow site quietly forfeits are not a random sample.

The things owners ask for that cost the most

Most performance damage on a trade site is requested rather than inflicted. These are the five requests that cost the most, and what to do instead.

“Can we have a video background?” A looping video behind a heading is among the heaviest things a page can carry, and on a phone it often does not play at all, leaving a poster image that could have been the design in the first place. Use a still. If the video genuinely says something, put it further down the page behind a play button.

“Can we add live chat?” Live chat is excellent when somebody staffs it and corrosive when nobody does. It also loads a third-party script on every page. If enquiries arrive faster than they can be answered, the honest fix is a short form with a stated response time, which weighs nothing.

“Can we show our reviews?” A review widget pulls in a script, a stylesheet and a set of web fonts in order to display four sentences. The sentences can be text on the page, styled to match the site, at no cost. The widget’s only advantage is the badge, and the badge is not worth half a second.

“Can we embed a map?” An interactive map is one of the most expensive components on the web and almost nobody pans it. A static image of the area, or a plain list of the towns you cover with a link out to directions, does the job for a fraction of the weight.

“Can we have a slider on the home page?” Already covered above, and worth repeating because it is the most persistent request in trade web design. The second slide is seen by very few people, and it costs everybody the load time.

None of these are refusals for their own sake. Each has an alternative that does the same job for the visitor, and the alternative is the one that still works on a bad connection.

What to do about the site you already have

If a rebuild is not on the table this year, there is still a great deal available.

Start with a list rather than a project. Open the network panel, sort by size, and write down the top ten items on the home page and on the busiest service page. That list is the work, in priority order, and it is usually shorter than expected.

Then take the items in three passes. The first pass is deletion: anything nobody uses comes off, which requires no technical skill beyond knowing what the business actually does. The second pass is images: every one resized to what it is displayed at and compressed. The third pass is the structural items, dimensions on images and lazy loading below the fold, which usually needs whoever maintains the site.

Measure before and after with the same phone on the same connection, from a cold start, and write down both numbers. That comparison is the argument you will need the next time somebody proposes adding a widget.

The order to fix things

If a site is slow today, this is the order that gets the most improvement for the least work.

1. Resize and compress every image. Particularly the hero. This alone is often most of the problem.
2. Delete third-party scripts nobody uses. Chat widgets, old tracking, social embeds, review carousels.
3. Remove the carousel. Replace it with its first slide.
4. Declare dimensions on images and reserve space for late-arriving elements. Fixes layout shift.
5. Make below-the-fold media load lazily.
6. Cut unused builder plugins. Every one removed is code no longer shipped.
7. Then, and only then, look at hosting.

Steps one to three are usually available in an afternoon and usually produce the bulk of the gain.

Keeping it fast

Websites get slower on their own. Somebody adds a booking widget, somebody uploads a gallery of full-size photos, a campaign adds a tracking script and nobody removes it when the campaign ends. A year later the site that launched fast is not.

Two habits prevent it.

Somebody owns the weight. Whoever maintains the site should check page weight when something is added, and should have the standing to say that an embed is not worth its cost. On a managed plan that is part of the arrangement; on a self-managed site it has to be somebody’s job or it is nobody’s.

Images go through a process. Photos from a job should never go straight from a phone to a page. They should be resized and compressed on the way, and that should be automatic rather than a discipline somebody has to remember at five o’clock on a Friday.

The standard to hold

Not a score. A sentence.

On a mid-range phone, on a poor connection, from a cold cache, the visitor can see what you do, where you work, and how to reach you, quickly enough that they do not go back to the results.

Every decision about the site can be checked against that sentence, including the ones that are really design decisions: the full-screen video, the animated intro, the map embedded above the fold, the font that takes a second to arrive. None of those are wrong in principle. They are wrong when they arrive before the phone number does.