Why is my vacation rental website slow?

Probably not as fast as it feels to you. You look at your site on a laptop, on good Wi-Fi, with everything already saved in your browser. Most guests see it for the first time on a phone, on a cell signal, while comparing you with a few other tabs.

The quickest way to check is Google PageSpeed Insights, or the free website check on this site, which uses the same Google test. Look at the mobile score. Google runs it on a simulated phone with a slower connection, which is closer to what guests actually get.

Here's how real the gap can be. Comal Inn's homepage scores 100 on desktop, but on a phone it was scoring 64 to 71, with the main content taking 5.4 to 6.3 seconds to show up. The photos weren't the problem. The page was waiting on three separate CSS files and six font files before it could draw its text. I moved the CSS into the page itself and cut the fonts down to one file each. The next phone test scored 99, with the main content showing in 1.9 seconds.

Then the next two runs scored 71 and 69, with nothing changed in between. PageSpeed loads your page once on a fast connection and then estimates how a slow phone would do, so small timing differences can swing the score a lot. One great run doesn't mean the job is done, and one bad run doesn't mean it's broken. Run it several times and look at the range.

The range told me there was more to fix. The last big difference between Comal Inn and this site was Google Analytics. Comal Inn told phones to download Google's 176 KB analytics script at the very start, alongside the page. This site waits until the page has finished loading. I gave Comal Inn the same setup, and the next three phone tests scored 100, 94 and 87, up from around 70, with the page starting to show in about a second. Analytics still counts nearly every visit and click. It just waits its turn. If your site gets enough visitors, PageSpeed also shows a section from real Chrome users over the last month. That's the data Google actually uses, and it matters more than the lab score.

PageSpeed reports a handful of measurements. Three of them, LCP, INP and CLS, are what Google calls Core Web Vitals. Google looks at the 75th percentile of real visits, so most of your guests need a good experience, not just the lucky ones on fast Wi-Fi.

Here's what those numbers looked like on Comal Inn's homepage, before and after the last fix:

For a lodging website, LCP is the one to watch. On almost every property homepage, the largest thing on the screen is the main photo. If that photo is huge, fix it first.

You'll also see Total Blocking Time in the lab test. It's how long the page is frozen while code runs, and it's the best clue to a slow INP. Widgets and plugins are the usual cause. My Comal Inn speed note walks through two real rounds of fixing it.

It's rarely one thing. It's usually a few of these at once:

1. Photos straight off a phone or camera. One of the most common problems. One photo can weigh more than the rest of the page combined.
2. A hero video. A big video at the top has to load before the page feels ready.
3. Widgets and add-ons. Chat boxes, review feeds, Instagram feeds, maps and booking calendars from other companies, each with its own code.
4. Tracking scripts loaded too early. Analytics and ad tags that download at the same time as the page, when they could wait until it has loaded.
5. A heavy theme or page builder. Code for every feature the theme offers, loaded on every page, used or not.
6. Slow or cheap hosting. The server takes a long time to send the first byte, before anything else can start.
7. Too many fonts. Every font and weight is another file to download before text looks right.
8. Files that block the first paint. Stylesheets and scripts the browser must download before it can draw anything at all.

In my audit of a two-cabin rental, the homepage weighed 6.5 MB and scored 37 on a phone. It had large photos in older formats, a background video in the header, two video players loading before anyone pressed play, and four tracking tools. Nothing was broken. It had just never been trimmed.

Comal Inn's homepage was a different kind of slow. The photos were already small. The problem was everything the phone had to download before it could show any text:

A photo from a modern phone or camera is often 3 to 8 MB. That's great for printing and terrible for a website. When it goes on a page as-is, every guest downloads the full file, even though their screen only shows a small version of it.

Here's a real one from Comal Inn:

Straight off the phone · 4,032 × 3,024 JPG4.8 MB

Resized for a phone screen · 828 × 621 WebP96 KB

On a phone, those two look the same. One takes a fraction of a second on a cell signal. The other can take several seconds, and that's just one photo. Most property homepages have ten or more.

What good photo handling looks like:

1. Resize to the size it shows at. A phone needs a photo around 800 to 1,200 pixels wide, not 4,000. A big desktop screen might need 1,600 to 2,000.
2. Use a modern format. WebP and AVIF are much smaller than JPG at the same quality, and every current browser supports them.
3. Serve different sizes to different screens. Phones get the small version, desktops get the big one. Next.js does this for you, and so do good WordPress image plugins.
4. Lazy-load photos further down the page. They load as a guest scrolls toward them, not all at once.
5. Never lazy-load the main photo. It's the one guests are waiting for. It should load first.
6. Set a width and height on every photo. The page saves the right amount of space, so text doesn't jump when the photo arrives. That's what keeps CLS low.

Comal Inn's photos are uploaded at full size, and the site turns each one into smaller AVIF or WebP versions for each screen. You keep one great original. Guests get a photo sized for them.

Everyone loves a video at the top of the homepage. The river, the porch swing, the fire pit at night. It can work. It just has to be done carefully, because a video is usually the heaviest thing a site can load.

How to add one without slowing everything down:

1. Keep it short and silent. A 10 to 20 second loop with no sound. Remove the audio track completely. Nobody hears it, and it's extra weight.
2. Compress it hard. Export it at the size it shows at, as MP4, and make the file as small as it can be while still looking good. For a background loop, a few megabytes is a sensible ceiling.
3. Give it a poster image. A still photo that shows instantly while the video loads. Google counts the poster or the first frame, whichever shows first, as your LCP, so a fast poster keeps your score healthy.
4. Make it muted and set to play inline. iPhones only autoplay videos that are muted or have no sound, and “plays inline” keeps it from jumping to full screen.
5. Think about phones separately. Many sites show just the poster photo on phones, or a smaller version of the video. A phone on a cell signal is where a video hurts most.
6. Add a pause button. Moving content that plays for more than a few seconds should have a way to stop it. It's an accessibility rule, and some guests find motion distracting.

And skip the embedded YouTube player at the top of the page. It's heavier than it looks. Google's own example shows the YouTube player at about 540 KB, compared with 3 KB for a lightweight stand-in that loads the real player only when someone presses play. If you want a YouTube video further down the page, that stand-in, called a facade, is the way to do it.

People ask which platform is fastest. The honest answer is that the platform matters less than what's built on it. Here's how the common options compare for a small property.

I moved comalinn.com off WordPress, and it was the right call for us. That doesn't make it the right call for everyone. If you edit your own site every week and a WordPress setup you know works for you, a cleanup will often get you most of the speed for a fraction of the cost of a rebuild.

A lot of popular WordPress themes are built to do everything: sliders, mega menus, animations, shop pages, portfolio grids, a dozen layouts. That's why they sell. The catch is that the code for all of it often loads on every page, whether your site uses it or not.

Page builders, the drag-and-drop tools for laying out pages, add their own layer on top. Then come the plugins, one for a gallery, one for reviews, one for a popup, one for a form, each with its own code. That's theme bloat, and it's the most common reason a WordPress site is slow.

How to avoid it:

1. Choose a lightweight theme. Look for one built for speed, with features you turn on as you need them, not everything switched on out of the box.
2. Be picky with plugins. If a plugin does one small thing, ask whether you really need it. Delete the ones you've stopped using, don't just deactivate them.
3. Use caching. A caching plugin or a host that caches for you saves a ready-made copy of each page, so WordPress doesn't rebuild it on every visit.
4. Handle images properly. An image plugin that resizes, converts to WebP and lazy-loads photos below the fold covers most of the photo work.
5. Skip the slider. One great photo usually beats a slideshow, and it's far lighter.
6. Test after every change. Run PageSpeed before and after adding a plugin. If the score drops, you know exactly why.
7. Keep everything updated. Updates fix security holes, and they often fix speed problems too.

You don't need to fix any of this yourself. But these questions will tell you a lot about where your site stands:

1. What’s my phone score, and what’s my LCP? Ask for the mobile numbers, not desktop. Desktop almost always looks better.
2. What is the LCP element on my homepage? Usually the main photo. It should load first, at the right size, and never be lazy-loaded.
3. Are photos resized and served as WebP or AVIF? Phones should get phone-sized photos, not the original files.
4. What loads before the page is ready? Chat widgets, feeds and maps can usually wait until someone scrolls or taps.
5. When does Google Analytics load? It can wait until the page has finished loading. You may miss a few people who leave in the first second, but it won’t slow the page down.
6. How many plugins are installed, and which ones do we still use? For WordPress. Every unused plugin is weight and risk.
7. Is the site cached and on a CDN? A CDN keeps copies of your site close to your guests, so pages arrive faster.
8. Can we retest after every change? Speed slips a little at a time. A quick test after each new feature catches it.

Or start with the free website check. It runs the same Google phone test, shows how heavy your homepage is and checks where your Book buttons go, in about 30 seconds.