Why Your Website Is Slow on a Phone at Seven Mile Beach

A visitor is standing outside your restaurant on West Bay Road. It’s 12:40, they’re hungry, and they’re deciding between you and the place across the car park. They tap your website. The screen goes white. They wait. They wait a bit longer. Then they hit back and tap the other one.

That’s the whole story. There’s no analytics report for it: they never became a visit you could count. It shows up as a session that lasted three seconds, indistinguishable from a wrong click.

What made it slow wasn’t your wifi. It was theirs — a roaming connection borrowed from a US carrier, off a tower behind the beach, shared with everyone else on that stretch of sand at lunchtime. Your site is judged on the worst connection your customer happens to have, and you almost never see it yourself.

“It loads fine for me” is the most misleading sentence in web design

It’s also usually true, which is what makes it dangerous.

When you open your own site, four things are working in your favour that your customer doesn’t have. Office fibre or home broadband. A recent phone or a desktop. A browser that cached the logo, the fonts and the hero image the last twenty times you looked. And you know where everything is, so you don’t wait for the page to settle to read it.

Strip those away and you get the real experience: an older Android on a roaming plan, arriving cold with nothing cached, on a page that downloads every byte before it shows anything useful. That gap is the difference between a page that feels instant and one that feels broken — and only one of those two people is your customer.

What actually makes a page slow on a phone

Slowness is rarely one dramatic problem. It’s usually several ordinary ones stacked on each other. In rough order of how often they turn up:

• The hero image. Someone dropped in a photo straight off a camera, at full resolution, as the banner. That file is several megabytes, going to a screen a few hundred pixels wide. Resized to the size it’s actually displayed at and saved as WebP or AVIF, it’s a fraction of the weight and looks identical on the phone. More often than not, this one change does the most.
• Fonts loading late. The text is there, but the browser holds it back — or shows a fallback — until a font file downloads from a third-party server. The page looks blank or flickers, then reflows when the real font arrives.
• Page builders shipping code for features you don’t use. A builder has to be ready for anything: sliders, tabs, parallax, pop-ups, counters. So it loads the machinery for all of it on every page, whether that page uses one feature or none.
• Third-party scripts. The chat widget, the booking embed, the review carousel, two analytics tags, the Facebook pixel someone installed in 2019 and forgot. Each is a request to a server you don’t control, at a speed you can’t influence.
• Autoplaying video. A background video of waves is beautiful on your monitor. On roaming data it’s a several-megabyte download competing with the text your customer came to read — and they may be paying for it by the megabyte.

None of these are exotic, and they rarely turn up alone. Fixing one while the others stay is how a site ends up feeling exactly as slow as before.

Core Web Vitals, in plain words

Google publishes a set of measurements called Core Web Vitals. They exist because “fast” was too vague to be useful — everyone claimed it, nobody could check it. Two of them matter most here.

LCP — Largest Contentful Paint

How long until the main thing on the page appears, usually the hero image or the headline. Not when the page starts loading, and not when everything finishes. Google’s published threshold for “good” is 2.5 seconds or less, measured for the visitor on the visitor’s connection, not for you on yours.

CLS — Cumulative Layout Shift

How much the page jumps around while it loads. You’ve felt it: you go to tap “Menu”, an image loads above it, everything slides down, and you tap “Book a Table” instead. The usual causes are images without dimensions in the code, embeds that arrive late, and fonts swapping in and changing a paragraph’s height.

Worth being clear about the limits. Core Web Vitals are one input among many in how Google ranks pages, and a slow site can still outrank a fast one on relevance. We won’t tell you that fixing LCP moves you up the results, because we can’t know it. The honest case for speed is simpler: the customer outside your door doesn’t wait.

Why Cayman is a harder test than most places

Most web performance advice is written for a business whose customers sit at desks. Ours mostly don’t.

Roaming data. Many of the people looking up a restaurant, a watersports operator or a dive shop here are visitors on a foreign SIM. Roaming connections tend to be slower and higher-latency than local ones, some plans throttle data, and some people are trying not to use much of it.

Coverage that isn’t uniform. Signal varies more than people expect once you’re off the main roads — inside a concrete building, on a busy beach, out in East End, on a boat. Your customer is often exactly where coverage is worst.

The decision is made standing up. In a lot of markets the customer researches at home in the evening. Here, a great many decisions — where to eat, who to call about the air conditioning, which storage place to ring — get made on a phone, outdoors, with limited patience. There’s no second visit. The tab closes and that’s the end of it.

Cruise days compress it further. When ships are in, George Town gets a surge of people making fast decisions on unfamiliar networks, all at once — peak load on your website and on the cell towers together.

Why we don’t use page builders, and what that has to do with weight

The roughly 24 client sites we run are custom WordPress themes. No Elementor, no Divi, no WPBakery. That isn’t a claim that page builders are bad software — they’re impressive, and they solve a real problem for people who need a site without a developer.

The trade-off is structural. A builder is a general-purpose tool, so it ships a general-purpose payload: CSS for every layout it can produce, JavaScript for every widget it offers, and markup that wraps your content in nested containers so it stays draggable. Your page uses a fraction of that; the browser downloads the lot anyway. A hand-built theme ships only the CSS and JavaScript that page needs — no slider on the page, no slider code sent. That’s why the difference shows up on the slow connection and not on your office wifi, where both feel instant.

The honest counterpoint: a badly built custom theme can be just as heavy as a builder, and a carefully pruned builder site can be decent. The tool doesn’t guarantee the outcome; it decides how much work a good one takes.

What you can check yourself in two minutes

You don’t need a developer to find out whether you have a problem. Do this on your own phone, not your computer.

The test

1. Open your site in a private or incognito tab. That clears the cache advantage, so you’re closer to what a stranger sees.
2. Turn wifi off. Mobile data only. Better still, walk outside, or somewhere with one or two bars.
3. Count out loud. One, two, three. If you can’t read the headline and see the main image by three, a visitor with less patience than you has already gone.
4. Watch for the jump. Try to tap a menu link the instant you see it, and note whether it moves out from under your thumb.

Then do the same on a competitor’s site, back to back. That tells you more than any score, because it’s the comparison your customer is running in real time.

The fixes, roughly in order of return

If the test went badly, this is the order usually worth working in, and most of it is not a rebuild. If you’ve been told the problem is your hosting: server response time is worth measuring, but if the server answers quickly and the page is still slow, the weight is in what the page sends.

1. Compress and resize every image, starting with the hero. Serve none larger than it’s displayed, in WebP or AVIF, with width and height in the markup so nothing shifts as they load.
2. Remove third-party scripts you can’t name a purpose for. Go through the list. Anything you can’t explain, delete. Old pixels and abandoned tools are pure cost.
3. Reconsider the chat widget. If it hasn’t produced a conversation in months, it’s a load penalty with no return. If it has, load it after the page is usable.
4. Drop the autoplay video, or use a still frame. Keep the video further down the page, where someone can choose to play it.
5. Host fonts yourself and limit how many you load. Two weights of one family is nearly always enough.
6. Only then consider the theme. If the page is still heavy after all that, the weight is structural, and you’re looking at a build rather than a tune-up.

One more thing while you’re in there, because the same work pays twice: keep the important facts in real text, not baked into an image. Opening hours, address, phone number, prices. A menu saved as a JPEG is invisible to a search engine and to an AI assistant, and heavy besides. Structured data helps too — the kind of markup a restaurant page should carry:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Example Restaurant",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 West Bay Road",
    "addressLocality": "George Town",
    "addressRegion": "Grand Cayman",
    "postalCode": "KY1-1000",
    "addressCountry": "KY"
  },
  "telephone": "+1-345-555-0100",
  "servesCuisine": "Caribbean",
  "priceRange": "$$",
  "url": "https://example.ky/",
  "menu": "https://example.ky/menu/",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
      "opens": "11:30",
      "closes": "22:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Friday", "Saturday"],
      "opens": "11:30",
      "closes": "23:00"
    }
  ]
}
</script>

That block is a handful of bytes. It doesn’t make the page faster, but it means the facts a customer needs can be read by things that aren’t a human holding a phone.

Questions we get asked

My site scores 95 on Google’s test. Isn’t that fine?

Probably, but check what you tested. Those tools report mobile and desktop separately, and desktop scores run much higher. A lab test also uses a simulated connection, not a roaming phone on a busy beach. Treat the score as a smoke alarm, not a verdict.

Do I need to rebuild my whole site?

Usually not, and anyone who says otherwise before looking is selling. Image compression, removing dead scripts and dropping an autoplay video are the bulk of the gain on most sites, and none of them touch the underlying build. A rebuild earns its keep when the platform itself is the weight, or when speed is one item on a longer list of problems.

Will a faster site get me more customers?

We can’t put a number on that, and we won’t pretend to. The mechanism is all we can honestly offer: a page that doesn’t load can’t sell anything, and every second a customer waits is a second they can spend tapping back. What that’s worth depends on how many people find you on a phone — your analytics can tell you, we can’t guess.

Does this affect whether AI assistants recommend me?

Partly, and less directly than people assume. Speed isn’t the main factor — what matters more is whether your information is readable at all: real text rather than images, clear opening hours, structured data, a page that doesn’t hide its content behind scripts. That work overlaps with the speed work, which is why they get done together. The limits matter: AI answers are non-deterministic, they vary by phrasing, location and date, and nobody can promise you a place in one. In a session recorded on 21 August 2026, ChatGPT named Uncle Liu and Coconut Room when asked where to eat on Seven Mile Beach — one session, one date, asked one way. Tomorrow it may answer differently.

I’m a trade, not a restaurant. Does any of this matter to me?

Same problem, different moment. Someone’s air conditioning has failed, it’s August, and they’re searching on a phone while sweating. They call whoever answers first. If your site takes long enough to show a phone number that they give up, the number they call belongs to someone else. The urgency is higher, if anything — they’re not browsing, they’re solving something.

Where to start

Do the two-minute test first. It costs nothing and it tells you more about your actual customer than any dashboard will.

If you want a second opinion with the numbers attached, we run a free checker at toctoc.ky/seo-checker. Put in your address and it scores your Core Web Vitals alongside your SEO and how readable your site is to AI assistants, and it now drafts an llms.txt as well. No account, no sales call attached.

Then go and stand outside your own front door with your phone, on mobile data, and load your site the way a customer would. It’s an uncomfortable two minutes. It’s also the only test that counts.

If the fixes turn out to be structural rather than a matter of compressing a few images, that is the work we do: website design and development in Grand Cayman, built as custom themes without page builders, and custom web development when the site has to do more than load quickly.