Web loading speed: why every second is costing you bookings in Tenerife

Your customer is on a café terrace in Costa Adeje. They've just searched "restaurant near me with paella". Your business shows up third. They tap your link. They wait 1 second, 2 seconds, 4 seconds. They hit back and tap the next one. You've just lost that booking without knowing it happened.

Loading speed is a silent filter that many sites fail: according to HTTP Archive's Web Almanac 2025, only 45% of WordPress sites pass Core Web Vitals on mobile (worldwide data, not just Tenerife; Web Almanac 2025, CMS chapter). And the numbers on what failing costs are brutal.

What the data says

What Google and Akamai studies say about load time and conversion:

• Every extra 100 milliseconds of load time can cost an online shop up to 7% of its conversions (Akamai, 2017)
• 53% of mobile visits are abandoned if a page takes more than 3 seconds to load (Google, 2016)

For a south-Tenerife restaurant in high season, every visitor who leaves because the site is slow is a table that was one tap away from booking. A fast site stops losing them, without spending another euro on advertising.

A word on reading these figures: they come from studies of mobile sites in general and of online retail, not of restaurants in Tenerife. But the mechanism is the same: the longer it takes for something useful to appear on screen, the more people leave before they see it.

Why Tenerife is a special case

Your customer here isn't browsing from an office on fibre. The reality on the island:

• Saturated 4G in tourist zones — Las Américas, Los Cristianos, Costa Adeje in August: lots of people connected at once in the same areas, and the connection is slower and patchier than at home
• Older phones — the tourist browsing on a phone that's a few years old, with roaming data
• Distance to the server — if your hosting is in Madrid or Frankfurt, every request has to travel to the mainland or central Europe and back, and that adds time before anything starts loading

A site that feels instant on your laptop with fibre WiFi can take a lot longer on a phone that's a few years old, on 4G in Playa de las Américas on a Saturday at 9pm. If your only reference is testing on your phone at home, you're not measuring what your customer lives.

How do you test your website's speed for free?

Three free tools, 5 minutes each:

1. PageSpeed Insights (pagespeed.web.dev) — paste your URL, get mobile + desktop score with Core Web Vitals (LCP, INP, CLS). Aim green on all three.
2. WebPageTest.org — pick the test location it offers that's closest to the Canaries and a mobile profile on a slow 4G connection. You get the load time on a deliberately throttled connection, closer to what your customer has.
3. Chrome DevTools → Lighthouse — in Chrome, open the developer tools, go to the Lighthouse tab, choose mobile and run the analysis. Tells you exactly what to optimise.

Your target: LCP of 2.5 s or less on mobile, web.dev's "good" threshold. Above 4 s, web.dev rates it flatly as "poor" (web.dev, LCP).

What are Core Web Vitals, and what scores do you need?

Core Web Vitals are three metrics Google uses to sum up whether a site feels fast and stable to the people using it. These are the "good" thresholds published on web.dev (web.dev, Web Vitals):

• LCP (Largest Contentful Paint): 2.5 seconds or less. How long the largest element on screen takes to appear, usually the main photo or the headline. It's your "has it loaded yet?".
• INP (Interaction to Next Paint): 200 milliseconds or less. How long the site takes to react when you tap a button, open a menu or type in a form. If you tap "Book" and nothing happens for a moment, that's a bad INP. Scrolling doesn't count.
• CLS (Cumulative Layout Shift): 0.1 or less. How much the content "jumps" while it loads. The classic: you go to tap "See menu", a banner appears at the top, everything shifts down and you tap something else.

One important detail: they aren't judged on a single visit. web.dev recommends looking at the 75th percentile of real visits, with mobile and desktop measured separately. In other words, to pass, at least three in four visits need a good experience. That's why a site that's fine on your WiFi but poor on your customers' 4G doesn't pass.

On its pages about LCP, INP and CLS, web.dev also sets the point where each metric "needs improvement" and where it becomes "poor". The three thresholds together:

How to test your site with PageSpeed Insights, step by step

1. Go to pagespeed.web.dev and paste your site's address. Start with the home page, then repeat with the page that matters most: the menu, bookings or rooms.
2. Look at the mobile result first. That's where conditions are worst and where the tourist on roaming data is.
3. The top block is real-user data: it comes from the Chrome User Experience Report and covers the previous 28 days (PageSpeed Insights documentation). That's where you see whether you pass Core Web Vitals: all three need to be "good" at the 75th percentile.
4. If there isn't enough data for that page, PageSpeed Insights shows data for your whole domain, and if there isn't enough of that either, it shows no real-user data. That's normal for small sites. You're left with the lab diagnosis.
5. The bottom block is the lab diagnosis: a Lighthouse simulation of a mid-range phone on a mobile network. The 0-100 score comes from here: 90 or above is good, 50 to 89 needs improvement, below 50 is poor.
6. Scroll down to the diagnostics and find which element is your LCP. It's often the main photo, and then you know where to start.
7. Run the test two or three times. Lab results vary a little from run to run; don't draw conclusions from a single result.
8. Take a screenshot before you change anything, so you can compare after each change.

A real data point on why mobile rules: on the Santos Barbertop website, a barbershop in San Isidro and my first client, 9 in 10 clicks from Google came from mobile in its first three months. That site scores 99-100 in Lighthouse on desktop, but the test that really matters is the one on its customers' phones.

What to do depending on what you see

• LCP orange or red: check, in this order, the photo or video at the top (weight, format, lazy loading), sliders that load several photos to show one, and your hosting's response time.
• High CLS: images without width and height set, cookie or offer banners pushing content down, booking or review widgets that resize as they load, and fonts that swap halfway through loading.
• High INP: too much JavaScript. Plugins, chats, tracking pixels and third-party widgets keeping your customer's phone busy right when they want to tap something.
• Fine in the lab but poor with real data: your customers browse in worse conditions than the simulation, on weaker connections or slower phones. The fix is the same: slim the site down.

Why is your website slow? The 5 things that slow down most sites

1. Unoptimised images — usually the first thing to check. As a practical rule of thumb (not an official standard): no 4MB photos on your site, WebP format, around 1600px wide at most, and lazy loading for images that aren't visible when the page opens.
2. Autoplay video — if your hero is a background video, it needs to be on a CDN, compressed, with a poster image while it loads
3. WordPress plugins — many plugins add their own JavaScript and CSS to every page. If you have, say, 30 active, review them: as a rule of thumb, anything you don't use goes. Undisciplined WordPress tends to be slow.
4. Google Fonts — loading 6 weights across 3 fonts slows everything. Rule of thumb: 2 fonts, 2-3 weights at most.
5. Cheap shared hosting — the cheapest plans share a server with lots of other sites. One under attack and the rest crawl.

Concrete fixes you can ask for this week

1. Compress and resize every photo. WebP, at the size it's shown on screen, not the size it came off the camera.
2. No lazy loading on the main photo. Lazy loading is for images further down. Putting it on the top one delays exactly what the visitor wants to see first.
3. Width and height on every image, so the browser reserves its space and nothing jumps.
4. Remove what you don't use: plugins, widgets and scripts from campaigns that ended months ago.
5. One chat only. If you have the WhatsApp button, the generic chat widget is surplus. How to set WhatsApp up properly is in the WhatsApp Business guide.
6. Map on tap. A map image with a "Get directions" button that opens Google Maps weighs far less than an embedded interactive map.
7. Menu in HTML, not PDF. A multi-megabyte PDF is another brake for a customer on mobile data; I explain it in why your PDF menu is losing you diners.
8. Caching and a CDN if your hosting allows it, so pages and images are served from a server close to the visitor.

Why Astro and Next.js are fast by design

WordPress builds the page on every visit: PHP processing, database queries, plugins running. Astro and Next.js (in static mode) build the HTML once at deploy. When a visitor lands, the server just sends an already-ready HTML file. Much faster, no trick.

That's why every site I deliver at Teide Digital is built on Astro or Next.js, not WordPress. Not technical preference — your customer on saturated 4G isn't waiting 6 seconds.

That doesn't mean a WordPress site can't be fast: with few plugins, good hosting and properly handled photos, it can pass. If you're deciding, I have an honest comparison in WordPress vs Astro (in Spanish).

Common mistakes when measuring speed

• Measuring only from the office computer. Your customer isn't there.
• Measuring once and drawing conclusions. Repeat and compare.
• Obsessing over 100. What matters is passing all three metrics, not a perfect score.
• Measuring only the home page. The menu, booking page or room gallery can be heavier than the home page.
• Testing with a warm cache or while logged in. You see the site already loaded; a new customer doesn't. Use an incognito window or, better, PageSpeed Insights.
• Forgetting what isn't yours. The booking engine, review widget or third-party chat count towards your page's speed too.

Hypothetical example: a slow restaurant website

An invented example to illustrate the process. A restaurant in Los Cristianos has a background video on its home page, a gallery of photos straight off the camera, two different chat widgets and an embedded Google map. PageSpeed Insights flags LCP and INP in red on mobile.

The logical order of work: swap the video for a compressed photo with width and height set, remove lazy loading from that photo and keep it for the gallery, drop one of the chats, replace the map with an image linking to Google Maps, and test again. I can't tell you how many more bookings it would get, because that depends on many things. What you can check is whether the metrics turn green.

Conclusion

Speed isn't technical vanity. It's the difference between the customer who books and the one who leaves before you knew they existed. Test your site today on pagespeed.web.dev — if it takes more than 3 s to load, you're losing visits: Google found that 53% of mobile visits are abandoned beyond that point (Google, 2016).

My goal is for every site I deliver to pass Lighthouse in the green; Santos Barbertop's scores 99-100 on desktop. If you want me to audit yours, I'll record a free 2-3 minute video analysis.

And if you're starting a new site, have a look at Plan Teide Esencial: a custom website of up to 5 pages, with hosting and domain included.

Frequently asked questions

My PageSpeed score is 60. Is that bad?

It's in the "needs improvement" band (50 to 89). More than the score, check whether you pass all three Core Web Vitals with real-user data and, if there's no real-user data, which element the diagnosis flags as your LCP and what it suggests fixing.

Why doesn't PageSpeed show me real-user data?

Because that data comes from real Chrome visits and a minimum volume is needed. On small sites it's normal not to have it. Use the lab diagnosis and repeat it after each change.

Will a fast site push me up in Google?

I'm not going to promise you that. Speed helps the people who arrive stay and book, which is what pays the bills. Other things carry weight for showing up in local searches, and I explain them in local SEO in Tenerife.

How often should I test?

After every significant change (a new plugin, a video, a booking widget) and, at the very least, before high season starts.