Why Your Booking Site Is Slow (And What to Fix First)

The short answer: Booking sites are usually slow for four reasons, in this order: oversized property photography, a pile-up of third-party scripts, a booking engine widget loaded on every page, and hosting chosen on price. Measure against Google’s published Core Web Vitals thresholds of 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint and 0.1 for Cumulative Layout Shift, using real-visitor field data rather than a stopwatch. Fix the images first.

Your booking site feels fine. You open it every day on a desktop, on office fibre, with every file already sitting in your browser cache. It appears instantly.

Your guest is standing in a car park on a three-year-old Android with two bars of 4G, comparing you against a Booking.com listing that has already loaded. That is the version of your site that decides whether you get the booking, and it is a different website entirely.

This post is about closing that gap. It covers how speed is actually measured, the handful of things that genuinely slow serviced accommodation sites down, and the order to fix them in.

One thing you will not find here is a figure telling you how much revenue a second of load time is worth. Those numbers circulate widely and they are almost always borrowed from a study of a large retailer with different traffic, a different basket size and a different audience. What your speed is worth depends on your site. What we can be precise about is the target, because Google publishes it.

What “slow” actually means

Google measures page experience through three metrics known collectively as Core Web Vitals. Each has a published threshold for a “good” result.

Largest Contentful Paint (LCP) measures loading. It marks the moment the biggest thing on screen, usually your hero photograph, finishes rendering. Google’s guidance is that LCP should occur within 2.5 seconds of the page starting to load.

Interaction to Next Paint (INP) measures responsiveness. It captures the delay between a guest tapping something, such as a date in your availability calendar, and the page visibly responding. Google’s target is 200 milliseconds or less.

Cumulative Layout Shift (CLS) measures visual stability, which is the technical name for the page jumping about while it loads. Google’s target is 0.1 or less.

Two details matter more than the numbers themselves.

First, all three are assessed at the 75th percentile of page loads, segmented across mobile and desktop. Three quarters of your visits have to clear the bar, not the average visit. Averages hide the guest on bad signal, and the guest on bad signal is exactly the one you are losing.

Second, these are thresholds, not scores. Getting LCP from 4 seconds to 2.4 seconds moves you from failing to passing. Getting it from 2.4 to 1.9 is pleasant and changes nothing about how Google classifies the page.

Measure before you touch anything

There are two kinds of speed data, and operators routinely act on the wrong one.

Field data is collected from real Chrome users who visited your site, over a rolling 28-day window. It reflects real phones, real networks and real caches. It is the truth.

Lab data is a simulation run on demand from a data centre with a throttled connection. It is useful for diagnosis because it is repeatable and it tells you which files are heavy. It is not a measure of what your guests experience.

Run your homepage and your busiest apartment page through Google PageSpeed Insights. If a field data section appears at the top, read that first and treat the lab score below it as a to-do list rather than a verdict. If no field data appears, your site does not yet have enough Chrome traffic for Google to report on, which is itself worth knowing.

Then open the Core Web Vitals report in Google Search Console. PageSpeed Insights tests one URL at a time. Search Console groups every URL on the site into passing and failing buckets, which is how you discover that your homepage is fine and all forty apartment pages are not.

If you want a plain-English walkthrough of the wider setup a direct booking site needs before any of this reporting means much, our free short-let marketing cheat sheet covers the foundations in the order they are worth building.

The things that actually slow SA sites down

1. Property photography, by a wide margin

Serviced accommodation sites are photograph-heavy by nature, and photography is where nearly all the weight sits. The typical failure is uploading straight from the camera or the photographer’s delivery folder: a 4,000 pixel wide JPEG, three or four megabytes, displayed in a card that is 600 pixels wide on a phone.

The guest downloads all of it. Twelve times, on a gallery page.

What to do:

• Export at display size. If the largest the image is ever shown is 1,600 pixels wide, do not ship 4,000.
• Use a modern format. WebP and AVIF produce visibly identical photographs at a fraction of the file size of JPEG.
• Serve different sizes to different screens. Responsive images let a phone download the phone-sized file rather than the desktop one.
• Lazy-load below the fold. Images the guest has not scrolled to yet should not compete for bandwidth with the hero image they are staring at.
• Do not lazy-load the hero image. It is your LCP element. Loading it late is the one place lazy-loading actively hurts.

This step alone usually moves the numbers more than everything else on this list put together.

2. Script pile-up

Every site accumulates tags. A tag manager, an analytics snippet, a chat widget, a cookie consent banner, a heatmap recorder, a remarketing pixel from a campaign that ended eighteen months ago, a review badge, a font service.

Each one is a separate connection, a separate download and, frequently, a separate piece of JavaScript running on the main thread while your guest is trying to tap a date. Script weight is the usual cause of a poor Interaction to Next Paint score.

Open the site with your browser’s network inspector, or ask whoever maintains it for a list of everything loading. Then be ruthless. Anything nobody has looked at in six months comes off. Anything remaining loads after the page has rendered, not before.

3. The booking engine widget

Most operators embed a third-party booking engine or availability calendar. It is a large piece of software, and it is often loaded on every single page of the site, including the blog, the about page and the contact form, where nobody will ever use it.

Load it only where it is needed. Where it sits below the fold, load it when the guest scrolls towards it. Where a full engine is not required on a page, a simple “check availability” entry point that hands off to the engine keeps the weight off pages that do not need it.

If you are still deciding what to embed in the first place, our guide to PMS integration and the hospitality tech stack covers how these pieces fit together.

4. Fonts and render-blocking CSS

Custom fonts have to be downloaded before text can be painted in them. Handled badly, the guest stares at a blank block where your headline should be. Handled well, a fallback font appears immediately and swaps when the real one arrives.

The fix is unglamorous: limit yourself to two font families and only the weights you actually use, self-host or preload them, and set the font display behaviour so text renders immediately in a fallback.

5. The platform underneath

Some sites are slow because of what they are built on rather than what has been put on them. A WordPress install on budget shared hosting, running twenty-eight plugins and rendering every page from scratch on every request, has a floor below which no amount of image optimisation will take it.

That is a rebuild conversation rather than a tuning conversation, and it is worth being honest about which one you are in. We have written about what a rebuild actually involves in Anatomy of a Serviced Apartment Website Rebuild.

Layout shift is the one nobody looks at

Loading speed gets the attention. Layout shift causes the complaints.

Cumulative Layout Shift measures how much the page moves after content has appeared. You have experienced it. You go to tap a date, an image finishes loading above it, everything jumps down, and you tap the wrong thing. On a booking calendar that is not an annoyance, it is a lost booking.

The three usual causes:

• Images and embeds without dimensions. The browser does not know how much room to leave, so it leaves none and shoves everything down when the file arrives. Setting width and height attributes fixes it.
• Late-injected banners. Cookie notices, promotion bars and announcement strips that appear above content which has already rendered push the whole page down.
• Font swapping. If the fallback font is a very different size to the real one, every line of text reflows when the swap happens.

None of these are difficult. They are simply invisible to anyone testing on a fast connection, because on fast connections everything arrives at once and nothing has time to shift.

The order to fix things in

If you do nothing else, do these in this order:

1. Compress and correctly size every image on the site. Cheapest fix, largest effect.
2. Set width and height on every image and embed. An afternoon of work that usually fixes CLS outright.
3. Strip dead scripts and defer the survivors. Free, and it is the main lever on responsiveness.
4. Stop loading the booking engine where nobody books.
5. Sort out fonts.
6. Then, and only then, argue about hosting.

Re-measure after 28 days, because both PageSpeed Insights field data and the Search Console report work on a rolling 28-day window. A fix made on Monday will not appear on Tuesday, and operators regularly conclude that a change did nothing when in fact they looked too soon.

What speed will not fix

Speed is a floor, not a ceiling. A fast site with unclear pricing, no trust signals and a five-step booking form will still lose bookings. It will just lose them faster.

If your numbers are already inside Google’s thresholds and enquiries are still thin, the problem is further down the page. Start with hospitality website UX that converts, and if the site has never really performed, why your serviced apartment website isn’t getting bookings works through the other usual suspects.

If you would rather see the whole picture before you start pulling things apart, download the cheat sheet. It walks through the marketing and website foundations an operator needs, in the order they are worth building.

Frequently Asked Questions

How fast should my booking site be?

Use Google’s published Core Web Vitals thresholds rather than a stopwatch. A page is classified as good when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less, measured at the 75th percentile of real page loads and split between mobile and desktop. Mobile is where operators fail, so check that first.

Does site speed affect my Google rankings?

Page experience is one of many signals Google uses, and Core Web Vitals form part of it. It is not a tie-breaker that outweighs relevance, so a fast page about the wrong thing will not outrank a slower page that answers the query properly. Treat speed as a qualifier rather than a ranking strategy, and put your SEO effort into the fundamentals covered in SEO for serviced apartments.

Why does PageSpeed Insights give me a different score every time I run it?

The score at the bottom of the report is lab data, generated by simulating a page load on a throttled connection. Small variations in that simulation move the score, which is why it fluctuates. The field data at the top, drawn from real Chrome visitors over the previous 28 days, is far more stable and is the number worth tracking.

Should I rebuild the site or optimise the one I have?

Optimise first. Images, scripts and layout shift are cheap to fix and account for most of the problem on most sites. If you have done all of that and the site still cannot get inside the thresholds, the platform itself is the constraint and further tuning is throwing good time after bad. That is the point at which a rebuild becomes the cheaper option.