I have a confession that will make every photographer reading this wince: most independent hotels I audit are sitting on gorgeous, professionally shot photography and serving it in the worst possible way. A 6,000-pixel-wide, 11-megabyte JPEG straight out of the camera, dropped into the page builder, never touched again. The photo is stunning. The page takes nine seconds to paint on a phone over hotel-lobby Wi-Fi. The guest is already back on an OTA app.
So this post is the actual pipeline I run, start to finish, when a property hands me a folder of raw images. No theory. The resize math, the compression settings, the naming convention, the alt-text rules, and the order I do them in so I never redo work. If you do nothing else from this post, steal the naming convention. It is the cheapest win on the list.
Why this is a revenue problem, not a tech problem
Let me frame the stakes before we get into pixels, because “image optimization” sounds like something you delegate and forget.
Page speed is a confirmed Google ranking factor, and on hotel sites images are almost always the single heaviest thing on the page. Your hero, your room gallery, your spa carousel. When those are unoptimized, your Largest Contentful Paint (the moment the big visual finishes loading) goes to pieces, and that is exactly the metric Google watches. Slow pages rank worse and convert worse. For an independent hotel already fighting to outrank the OTAs on its own name, handing back free speed is a gift you cannot afford. I dig into that ranking fight in why your hotel ranks below OTAs for your name.
And it is not just classic search anymore. AI answer engines and image-heavy results lean on clean file structure, descriptive alt text, and fast-loading assets to understand and surface your property. If you care about showing up when a traveler asks an assistant for “boutique hotels near the marina,” your visual assets are part of that signal. That whole world is what our AI visibility (AEO/GEO) work is built around.
The cruel math: a single 8 MB hero image that should be 250 KB is wasting roughly 7.75 MB per visit. At 5,000 visits a month that is about 38 GB of needless transfer, slower pages for every one of those guests, and a worse Core Web Vitals score dragging the whole domain. The fix is a one-time afternoon of work plus a repeatable process.
Step 1: Cull and rename before you touch a single pixel
Everyone wants to start with compression. Wrong. The first thing I do is rename, because renaming a 4 MB master is the same effort as renaming a 250 KB export, and if you rename last you will inevitably forget half of them.
My file-name rules are boringly strict, and that is the point:
- All lowercase, hyphens between words, no spaces, no underscores.
deluxe-king-room-balcony-view.jpg, neverDSC_4471.jpgorDeluxe King Room.jpg. - Describe the subject, then the differentiator, then the location.
rooftop-pool-sunset-key-west.jpgtells Google, image search, and future-you exactly what this is. - No keyword stuffing.
best-cheap-luxury-hotel-key-west-pool-deal.jpglooks like spam to a crawler and reads like spam to you in six months. - Number variants cleanly.
lobby-fireplace-01.jpg,lobby-fireplace-02.jpg. Zero-padded so they sort correctly.
Here is the thing nobody tells you: descriptive file names are as much for your own sanity as for SEO. When a media library has 400 files and they are all named IMG_2231, updating the spa page becomes an archaeology dig. When they are named like sentences, you find the right photo in two seconds. The SEO lift is real but modest. The operational lift is enormous.
I rename in bulk with a quick batch tool, but honestly even doing it by hand in the file explorer beats leaving camera junk in place.
Step 2: Resize to the size you will actually display (times two)
This is where most of the file weight disappears, and it is pure waste before you even get to compression. You do not need a 6,000-pixel image to fill a slot that renders at 1,600 pixels.
My rule of thumb is export at roughly 2x the largest size the image will ever display at, to keep it crisp on retina and high-density phone screens, and no larger. Here is the cheat sheet I keep taped to my process:
| Image role | Largest display width | Export width (2x) | Target file size |
|---|---|---|---|
| Full-bleed hero | 1,600 px | 2,400 px | 150-300 KB |
| Room / gallery photo | 1,000 px | 2,000 px | 100-200 KB |
| Thumbnail / card | 400 px | 800 px | 30-70 KB |
| Logo / icon (use SVG) | n/a | vector | under 15 KB |
| Blog inline image | 800 px | 1,600 px | 80-150 KB |
A few honest caveats. Those target sizes are guidelines, not laws of physics. A busy, detail-rich photo (think a market scene) needs more bytes to look clean than a simple shot of a calm pool at dusk. Hit the target where you can; protect quality where the photo demands it.
The real magic is responsive images, where you do not serve one size to everyone. You export several widths and let the browser pick based on the device. A phone gets the 800px version, a desktop gets the 2,400px version. Done right, your phone visitors download a fraction of what desktop visitors do. If your site is on a modern platform, this is often handled for you. If it is on an older builder, it may not be, and that is worth checking, because it is one of the biggest mobile-speed wins available. We sort this kind of thing out inside book-direct CRO, where shaving seconds off the booking path directly moves conversion.
Step 3: Pick the right format
Format choice is where you claw back another big chunk of weight for free. My defaults:
- Photographs: AVIF first, with a WebP fallback, and a JPEG fallback under that. AVIF is typically 20-40 percent smaller than WebP at the same visual quality on rich photography. WebP is the safety net. JPEG is the floor that every browser and every crawler can read.
- Logos, icons, simple line graphics: SVG. It is vector, so it scales infinitely, stays razor sharp, and is usually tiny.
- Anything needing transparency: WebP or AVIF over PNG almost always. Reach for PNG only when you genuinely have no better option, because PNG photos are enormous.
If your platform lets you upload one master and auto-generates AVIF and WebP versions on the fly, lean on it. That is the dream. If not, you can generate the formats yourself and serve them with a picture element so the browser grabs the best one it supports.
Step 4: Compress with intent (and actually look at the result)
Now we compress. The mistake here is treating it as a single slider you crank to “small.” Compression is a negotiation between file size and the moment a guest notices the photo looks degraded.
For JPEG and the lossy formats, I work in a quality range of 72 to 82 for hero and gallery photography. Below about 70 you start seeing mushy gradients in skies and walls, exactly the smooth areas a hotel photo is full of. Above 85 you are paying for bytes no human eye will ever appreciate. I find the lowest setting where I cannot tell the difference at full screen, then I stop.
My non-negotiable rule: always eyeball the compressed version at full size before you ship it. Compression artifacts love to hide in skies, skin tones, and the smooth painted walls of a clean hotel room. A number in a dialog box does not tell you your sunset now has banding stripes across it. Your eyes do.
Two more easy wins people skip:
- Strip EXIF metadata on export. Camera data, GPS coordinates, and editing history ride along inside the file and add weight for zero visible benefit, plus you may not want the world knowing the exact GPS of a private villa.
- Batch it. Whatever tool you use, set up a preset (size + format + quality + strip metadata) and run the whole folder through it at once. The pipeline only saves you time if it is repeatable.
Step 5: Write alt text like a human describing the photo
Alt text is the step everyone either skips or robotically stuffs, and both are wrong. Alt text exists first for accessibility, so a guest using a screen reader understands what is in the frame. Google reads it too, which is the SEO bonus, but accessibility is the job.
My rules:
- Describe what is genuinely in the photo, for someone who cannot see it. “Rooftop pool at sunset overlooking Key West harbor” beats “hotel pool.”
- Include the hotel or location naturally, where it fits. Do not force it into every single image. A few well-placed mentions read as natural; the same phrase on all 200 photos reads as spam.
- Never start with “image of” or “picture of.” Screen readers already announce it is an image. You are wasting the listener’s time.
- Decorative-only graphics get empty alt text (
alt="") so assistive tech skips them entirely. A background texture or a divider line does not need narration.
Good alt text also feeds image search and the AI answer engines that increasingly describe and recommend properties. It is a quiet contributor to the same visibility goals behind our content and reputation work, and it pairs with the broader on-page foundation in the hotel SEO 2026 starter guide.
The whole pipeline is worthless if you skip the boring last mile. Renaming, alt text, and a compression preset are not glamorous, but they are the difference between a photo that ranks and loads and one that just sits there as dead weight slowing your booking page.
The full pipeline, in order
Here is the sequence on one card, because order matters and doing it backwards means redoing work:
- Cull the folder down to the keepers. Fewer, better photos beat a bloated gallery.
- Rename every file with the lowercase-hyphen-descriptive convention.
- Resize to roughly 2x display width, exporting multiple widths for responsive serving.
- Choose format: AVIF or WebP for photos, SVG for graphics, with fallbacks.
- Compress in the 72-82 quality range, strip EXIF, eyeball every result at full size.
- Write alt text that describes the frame, with location worked in naturally.
- Upload and re-test Core Web Vitals to confirm the page actually got faster.
That last step is the one that separates people who think they optimized from people who did. Run the page through a speed test before and after. If your Largest Contentful Paint did not drop, something in the chain did not stick, often a builder quietly serving the original full-size file instead of your optimized one.
Why this matters for the OTA fight
Here is the connective tissue. Every second you shave off your page load, every sharp-but-light image, makes your direct site a little more competitive against the booking giants. You will not make the OTAs disappear, and you should not try to. They are a real distribution channel. But a fast, beautiful, well-tagged direct site lets you win back a healthier share of bookings at full margin instead of handing 15-25 percent commission on every one. That is the math I walk through in the book-direct math post, and it is the whole reason a “boring” task like image compression earns a place in your strategy.
Optimized visuals also feed the broader picture: faster pages help your core hotel SEO, clean assets and alt text help your local SEO and Google Business Profile, and the speed improvements compound with everything else on the site. It is one afternoon of setup for a process you reuse forever.
If you want a set of fresh eyes on your current image weight and Core Web Vitals, or you would rather hand the whole pipeline to someone who runs it every week, book a free intro call and I will tell you honestly where your photos are costing you bookings and where they are already pulling their weight.