Your website is fast on your laptop. That's not the test.

A few weeks back I sat at Iron and Clay waiting for a client. I had ten minutes, so I pulled out my phone and tried to load his website. I knew the site well. I'd designed an earlier version of it. On my laptop it loaded in 1.4 seconds and I was proud of it.

On my phone's data downtown Kenora, at the back of the cafe where the signal drops to two bars, his homepage took eleven seconds to render the hero image. The fonts loaded last. The "book a quote" button moved twice while I was trying to tap it. I closed the tab before the page finished.

I realized I'd been using the wrong thing for years as my primary test.

The website that loads in 1.4 seconds on my MacBook on my home wifi is not the website your customer is loading. Your customer is in a truck with one bar. Or in line at Tim's. Or on a dock at the cottage at the edge of the wifi's range. The phone in their hand is doing the work. And in most cases, it's failing.

What Google actually sees on mobile

Google has been ranking websites on mobile-first performance since 2019. When Google decides where you show up in search, it's not looking at how fast your site loads on a laptop. It's looking at how fast it loads on a mid-range Android phone, on a slow connection, in a real-world test.

The scoring system uses three numbers, called Core Web Vitals:

• Largest Contentful Paint (LCP). How long it takes for the main image or block of text on your homepage to fully render. Google wants under 2.5 seconds. Over 4 seconds is a fail.
• Interaction to Next Paint (INP). How quickly your site responds when someone taps a button or scrolls. Google wants under 200 milliseconds.
• Cumulative Layout Shift (CLS). How much the page jumps around while it loads. You go to tap a button, the page shifts, you tap an ad instead. Google penalizes that hard. They want a score under 0.1.

All three are measured on real Chrome users hitting your site from the real world. Not from a test you ran. Not from your laptop. From the phones of the people who actually visit you. Sites that fail these scores quietly drop in local search rankings. Not all at once. They just slowly stop showing up in the local pack and the AI Overviews. Most owners never connect the dots, because the drop happens over months.

The four reasons Kenora websites are slow on phones

I audit Kenora business sites every week. Almost every slow site I find is slow for one of four reasons.

Reason 1: A hero image that's 6 MB

Most local sites have a beautiful, high-resolution hero photo at the top of the homepage. It looks great on a 4K monitor. The file is sometimes 5 to 8 megabytes. On a phone with two bars of service that file takes ten seconds to download before anything else on the page can finish. The fix is to compress and resize the image so it's under 300 KB. The visual difference is minor. The speed difference is enormous.

Reason 2: Twelve different fonts

A common pattern on small business sites: one font for the headlines, a different font for the subheadings, a third font for the body text, and a fourth font for buttons. Each font has multiple weights (bold, light, italic). Each weight is a separate file the phone has to download before the text can render. Some sites end up loading fifteen font files. The fix is to use one or two font families, at no more than three weights each. You'll save several seconds of load time.

Reason 3: Tracking and chat widgets

The Facebook pixel, Google Analytics, a chat bubble, a Calendly embed, a heatmap tool, a pop-up email capture. Each is third-party JavaScript the phone has to fetch from a different server before the page becomes interactive. I've seen Kenora sites with eight tracking scripts on every page. Keep what you actually use. Kill the rest. Load anything non-essential after the main page renders.

Reason 4: Builders that ship bloat

Some builders are great at the design experience but ship enormous amounts of code in the background. Wix, Squarespace, and certain WordPress themes can add 500 KB of CSS and 1 MB of JavaScript to every page, even if your homepage is just text and one photo. The fix usually means rebuilding on a leaner platform. Worth checking before you commit to a redesign.

The 30-second mobile test you can run right now

Don't take my word for it. Run the test on your own site.

1. On your phone, open a Chrome incognito window. (This bypasses your cache so you're seeing what a first-time visitor sees.)
2. Connect to LTE or 5G, not your home wifi. If you have a way to throttle to "slow 4G" in the browser dev tools, even better.
3. Type your website address. Start a timer the moment you hit "go."
4. Stop the timer when the page is fully loaded and you can scroll without the layout jumping.
5. Note the time.
6. Try to tap your main call-to-action button (book a quote, get a free estimate, call now). Did it respond instantly, or was there a delay? Did the page shift while you were trying to tap?
7. Now run the same test on a competitor's website. Note the time.

If your site took longer than 4 seconds, you have a problem. If your call-to-action button was slow to respond or jumped while you were tapping, you have a different problem. If your competitor was faster than you, the problem is urgent.

This whole exercise takes two minutes. Most Kenora business owners have never done it.

Free tools that tell you what's wrong

Once you know your site is slow, the next question is why. Three free tools, five minutes each.

• PageSpeed Insights (pagespeed.web.dev) is Google's own tool. It gives you a mobile score out of 100, the three Core Web Vitals numbers, and a prioritized fix list. The "Opportunities" section will literally tell you "your hero image is 4.2 MB, here's how to compress it."
• GTmetrix (gtmetrix.com) shows you a frame-by-frame video of your page loading on a phone. You see exactly what your customer sees in the first three seconds. That waterfall view changes how owners think about speed.

Run both. The combined report is enough to walk into a developer's office (or send to your web person) with a specific, prioritized fix list.

The pattern across Kenora

Most Kenora business sites I audit fall into three buckets. Sound familiar?

Bucket 1: Fast enough

Site loads in under 3 seconds on a phone, looks the same after loading as it did during loading, buttons respond instantly. This is rare locally. Maybe one in five sites.

Bucket 2: Slow but fixable

4 to 7 seconds to load, one or two obvious issues (giant hero image, too many trackers, font bloat). Most Kenora sites are here. A few hours of focused work moves them to bucket 1. (This is the kind of thing the Managed Presence system catches and fixes every month so it never compounds.)

Bucket 3: Structurally slow

8+ seconds to load on a phone, page jumping all over the place, buttons that don't respond. Usually a builder problem or a years-old theme that was never designed for mobile. A redesign is the right call. (I've written before about why redesigns are healthy and how to know when it's time.)

If you're in bucket 1, congratulations. Keep doing what you're doing. If you're in bucket 2, the speed gap is costing you bookings every week and you can fix most of it in a Saturday afternoon. If you're in bucket 3, the website itself is the problem and no amount of tweaking will get you to the speed that Google and your customers expect.

The soft pitch

If you want to know exactly where your site stands across all three Core Web Vitals, on real mobile devices, with a prioritized list of what to fix this month, that's part of what the Kenora Visibility Audit covers. We run your site through the same tools above, we name the worst three issues, and we tell you whether you're in bucket 1, 2, or 3. Three business days. Four-page report. No sales call. Just the report.

If you don't have time to keep checking on this stuff yourself, Managed Presence is the standing arrangement that catches speed issues, image bloat, broken trackers, and mobile failures before they cost you customers. From $13 a day. Built in Kenora.

---

Your website is fast on your laptop. That has never been the question. The question is whether it's fast on the phone on the side of the road, on the dock at the cottage, or anywhere the signal drops to two bars. That's the test. That's the only test that matters now.