Why Your Site Is Fast on Your Laptop and Slow on a Phone

You open your site on your desk in the morning and everything works. The page arrives before your finger leaves the mouse. That afternoon a customer taps the same page from her truck in Mont Belvieu and stares at a white screen while the search result she came from waits behind her thumb. She backs out. You never hear from her.

The site did not break. It was slow on her phone for the same reasons it will be slow on the next one, and none of them show up on the machine you built the site on.

01Your Laptop Is Not the Customer's Phone

The laptop you tested on has ten times the processor of the mid-range Android she is holding, and it has been sitting on a wired or full-signal connection for hours. Her phone is a two-hundred-dollar device from two years ago running a browser with fifteen tabs open, a battery below thirty percent, and one bar of LTE at the edge of a warehouse. The same page has to render on both, and the phone has to do it with a tenth of the processor, a fraction of the memory bandwidth, and a signal that drops packets every few seconds.

The people who buy from you are almost never on your setup. For a service business in the Baytown area, most first-time visits arrive on a phone, on a cell connection, from a Google Maps or Search tap. The person searching for a plumber is not at a desk.

02What Loads When Somebody Taps Your Link

When she taps the link her phone starts a chain nobody watches. The domain resolves. The server sends the HTML. The HTML tells the browser to fetch a stylesheet, a font file, two more fonts, a slideshow script, a chat widget, a cookie banner, an analytics tag, a tracking pixel for the ad platform you tried last spring, and eight images sized for the desktop version. Every one of those is a separate request over her spotty connection, every one waits its turn, and the page cannot show anything readable until enough of them have arrived.

On your laptop this happens too, but the browser cached most of it on your last visit and the connection carries the rest in the time it takes the mouse to move. On her phone, nothing is cached, and the connection is the bottleneck rather than the processor.

03The Tab You Had Open Counted

The other thing that hides the problem: you never load the site cold. You visit it from the address bar with the previous session still in memory, from a browser that has already fetched the fonts and the icons a dozen times this week. The first paint you see is not the first paint a customer sees. Open a private window on the phone in your pocket and try it. If you have never done that on the road, the drive to lunch is a good place to start.

04The Images Doing Most of the Damage

A homepage often ships four to six megabytes of images that a phone screen shows at a fraction of the original size. The camera on a modern phone shoots at four thousand pixels wide; a homepage hero on a phone displays at maybe four hundred. If nobody told the site to send the smaller version, it sends the big one, and the phone spends three seconds decoding a picture the screen will crop away.

This is the single biggest fix on most small business sites, and it is also the one that never shows up when the site is tested on office wifi. The bytes are the same; the wait is not.

05The Scripts You Forgot Were There

Every plugin, chat bubble, review widget, and marketing pixel that got added to the site to try is still loading, and each one blocks the phone until it finishes. The abandoned A/B test script from last year is running on every page today. The heat-map tool the previous developer installed is fetching a two-hundred-kilobyte library before the phone can render the menu. Some of these were paid for and forgotten; most were free and added on a whim. All of them are being downloaded by every customer who taps your link.

A quick audit tends to find between four and nine of these on a small business site, and removing them costs nothing.

06The Check We Run Before a Build Goes Live

On every site we ship, we open the page on a two-year-old Android on a throttled connection before the domain switches over. Not the browser's phone-emulator, which uses your desktop's processor and reports numbers nobody's customer sees. A real handset, tethered to a slow cell profile, held in a hand. If the page reads inside two seconds on that setup, it reads for the person tapping a Maps pin in a parking lot. If it does not, we do not move the domain until it does.

07How to See It the Way Your Customers See It

You do not need a developer to check this. Open Chrome on your phone, tap the three-dot menu, choose New Incognito Tab, and type your domain in. That skips the cache and shows you what an arriving visitor sees. If you can, do it once on wifi and once with wifi off. If the wifi version is fast and the cell version is a slideshow, you have found what a stranger tapping the ad has been finding.

The other free tool is Google's own PageSpeed Insights. It runs your page on a simulated mid-range phone and hands back a number and a list. Ignore the score and read the list. The line that says image files are larger than they need to be is worth more than the rest of the report combined.

08What to Do About It This Week

If you own the site and can only do one thing, ask whoever built it to compress the images and switch on the newer image format the browser already supports. That fix alone typically cuts a homepage's weight in half and stops the phone from throwing away four seconds decoding pictures nobody sees at full size.

If you cannot get hold of them, or the answer is a quote for a rebuild, take the free PageSpeed report to whoever manages your site and hand them the line about images. It is a two-hour job on almost every platform, and it is the difference between a customer who reads your services page and a customer who backs out to the next result.