The Australian tourism website is a product that has to do two contradictory things at the same time. It has to seduce. That means big, high-quality photography of the experience — the wave, the wine, the sunset, the rainforest. It also has to load in under three seconds on a 4G connection in regional Victoria where the customer might actually be when they're researching the booking. Those two requirements pull in opposite directions, and most tourism websites we audit have chosen the wrong side of the trade-off.

The dominant view in the industry — repeated at every tourism marketing conference for the last decade — is that photography sells the booking. That's correct. The mistake is in the next step. Operators conclude that more, bigger, higher-resolution photography is better. Photography sells the booking when it loads. A 12MB hero image on a page that takes seven seconds to render isn't selling anything. The customer left at second four.

I'll give you the case for big photography first, because it's strong. Then the structural fixes that let you keep the photography and still load fast.

The case for image-heavy tourism sites

Tourism is a category where photography is the product preview. The customer cannot try the experience before paying for it. They're booking a $400 day tour, or a $3,500 lodge stay, or a $9,000 adventure expedition based largely on what they see on the screen.

Reviews matter. Pricing matters. Itineraries matter. But the emotional decision — the moment a customer thinks "I want that" — happens looking at photography. A great photograph of dolphins off Byron Bay sells a Byron Bay marine experience in a way that no amount of copy can. A composed shot of a couple at a fire pit at a Tasmanian lodge sells the lodge in a way the room description doesn't.

The industry's photography investment is, in principle, correct. Hiring a professional photographer for two days of operator shoots is one of the best ROI marketing investments most operators make. The mistake is in how that photography ends up being delivered to the customer.

Where it goes wrong

The standard tourism website failure mode looks like this.

The photographer delivers 200 photographs at full resolution — usually 4000–6000 pixels wide, 8–15MB each as exported JPEGs. The web team picks the best 60 and uploads them to the CMS. Squarespace, WordPress, Webflow, doesn't matter — the platform automatically generates a few resized versions and serves them.

The "automatic resizing" is where the problem starts. Most CMS platforms downscale, but they don't compress aggressively. A hero image that ends up displayed at 1600 pixels wide on desktop will be served at 1600 pixels wide. The resized file is around 600KB–1.2MB depending on the image. There are typically 4–8 of these large images on the homepage, plus 15+ on a typical experience page.

The result is a tourism homepage that weighs 8–18MB and loads in 6–11 seconds on a 4G connection. On a typical regional Australian connection in the Otways or the Whitsundays — both places customers might be researching from — that's closer to 11–15 seconds.

The customer doesn't wait 15 seconds. The customer doesn't wait 8 seconds. Google's published research, which we've seen replicated on Australian tourism sites we work with, shows that mobile users leave at around 3 seconds of loading time. By second five, more than half the traffic has bounced. By second eight, the page might as well not exist.

So the operator paid $4,000 for photography that, on the device the customer is using, the customer never sees. The desktop preview in the office looked great. The mobile experience in the field looks like a blank page that eventually has photographs on it.

What's actually slow

There are four contributors to slow mobile load on a typical tourism site.

Uncompressed JPEGs

The biggest single offender. A photograph exported at quality 85 from Lightroom is around 1MB. The same photograph exported at quality 75 with MozJPEG compression is around 300KB. Visually indistinguishable. Two-thirds of the file size gone.

For tourism photography specifically, where the images are heavily styled and high-contrast, you can usually go further — quality 70 in WebP format produces files around 150–220KB that look identical to the eye on a mobile screen. Eight times smaller than the Lightroom export.

The CMS-generated resized versions don't do this. They downscale, they don't recompress optimally. The platform serves what it has. The operator never sees the comparison.

Wrong image format

JPEGs were the right format in 2010. In 2026, WebP is supported in every browser and produces 25–35% smaller files at equivalent visual quality. AVIF goes further — typically 40–50% smaller than JPEG — and is supported in every major browser.

The reason most tourism sites don't use these formats is that the CMS doesn't support them automatically. Squarespace serves JPEGs because that's what Squarespace serves. WordPress with a basic plugin set serves JPEGs. The operator has no idea there's a better format.

Images loaded that are never seen

The standard tourism homepage has 6–12 hero images in a slideshow or gallery. Maybe two of them are ever actually scrolled to. The remaining ten load immediately on page open because the browser doesn't know which ones will be needed.

This is what lazy loading solves — images below the fold don't load until the customer scrolls toward them. The HTML attribute is one word: loading="lazy". It's been supported in every browser since 2020. Most CMS-based tourism sites don't use it because the template wasn't written with it.

The impact is significant. A tourism homepage with 18 images can typically defer 12–14 of them with lazy loading, dropping initial page weight from 12MB to around 3MB. The page renders in a third of the time. The customer sees the first three photos immediately and the rest as they scroll.

One image, every size

The mobile user is looking at a 390-pixel-wide screen. The desktop user is looking at a 1440-pixel-wide screen. Most tourism sites serve the same image to both. The mobile user is downloading four times more data than they need.

Responsive images — the HTML <picture> element or the srcset attribute — let the browser pick the right size for the device. A 2400-pixel-wide image for desktop. A 800-pixel-wide image for mobile. Different files, served from the same source. Mobile load weight drops by 60–75% on the same page with no change in visual quality.

Again, most CMS platforms don't generate the responsive image set properly. They generate "thumbnail, medium, large" — not the device-targeted sizes that responsive image markup needs. The operator never knows.

What good looks like

A tourism website built for performance hits the following targets:

Total page weight under 1.2MB on mobile homepage
LCP (Largest Contentful Paint) under 2.5 seconds on a throttled 4G connection
First three images visible above the fold load in under 1.5 seconds
CLS (Cumulative Layout Shift) under 0.1 — no images popping the page around as they load
Lighthouse Performance score above 85 on mobile

These aren't aspirational. They're achievable on an image-heavy tourism site with the right delivery setup. We hit them routinely on the operator sites we build, with no compromise on the visual quality of the photography.

The recipe is:

Source files at 2400px wide, exported at quality 80 from Lightroom, ready to be processed by the website's image pipeline
An automated image pipeline (we typically use next/image on Next.js, or sharp on simpler stacks) that generates WebP and AVIF versions in 4–6 size variants
A responsive <picture> element for every gallery and hero image, served via a CDN
Lazy loading on every image below the fold, including a low-quality blurred placeholder so the layout doesn't shift when the real image loads
A single, properly sized hero image above the fold rather than a 6-image slideshow

That last point is structural. The slideshow above the fold is the legacy pattern from 2014 tourism websites. It performs worse than a single great image with confidence. Customers don't stay on the page to watch a hero slideshow rotate. They look at the first image, decide whether to engage, and either scroll or leave. The slideshow imposes load cost for almost no behavioural benefit.

The Squarespace and WordPress problem

If your site is on Squarespace, you have limited control over any of this. Squarespace serves WebP automatically on newer themes but not always at the right size, doesn't support AVIF, and doesn't expose a granular responsive image API. The platform-imposed performance ceiling on Squarespace for image-heavy tourism sites sits around Lighthouse 60–70 on mobile no matter what you do.

WordPress is more flexible. Plugins like ShortPixel or Imagify can compress and convert your media library to WebP. The default WordPress responsive image markup is reasonable. With a tuned setup you can usually get a WordPress tourism site to Lighthouse 75–85 on mobile. The trade-off is the maintenance load — plugins need updating, settings drift over time.

A custom-coded site, particularly one on Next.js with Vercel's image optimisation, gets you Lighthouse 90+ as a default. The image pipeline is built in. The responsive markup is generated for every image automatically. The format negotiation between WebP and AVIF happens server-side per device. The operator doesn't have to think about it.

This isn't an argument that every tourism operator needs a custom site. It's an argument that performance is a function of platform plus implementation, and there's a real ceiling on image-heavy tourism sites built on consumer-grade CMS platforms.

What this means for your photography budget

The conclusion most operators reach when they read about image optimisation is "I should compress my photos before uploading". That's correct but it solves the wrong half of the problem.

The real fix is in the delivery infrastructure. The photographer should keep delivering the highest-quality source files. The website should be doing the compression, the format conversion, the responsive sizing, and the lazy loading automatically. If you have to think about it photo-by-photo, your platform is doing it wrong.

The right test for whether your site's image handling is set up properly is: take a 6000px wide source JPEG. Upload it to the CMS. Open the page that displays it on a mobile device. The file that arrives should be 1600–2000px wide, in WebP or AVIF, around 150–300KB. If it's larger than that, the pipeline is broken.

The honest bottom line

Tourism websites should be image-heavy. The argument that you should strip photography to load fast is wrong. The argument that fast loading and image-heavy presentation are mutually exclusive is also wrong.

What you actually need is a website that handles image delivery properly — modern formats, responsive sizing, lazy loading, real CDN delivery. Most consumer CMS platforms don't do this without significant plugin work. Custom builds do it by default. The right answer depends on your operation's scale and the value of the conversion you're trying to win.

If your tourism website currently loads in more than 4 seconds on mobile, you're losing customers at the point where photography is supposed to be selling them. The fix isn't fewer or worse photos. The fix is a delivery pipeline that lets the photos do their job.

If you'd like an honest look at where your current site is losing visitors to load time, book a free audit. We'll measure the page weight, identify the biggest image culprits, and tell you whether the fix is a configuration change or a structural rebuild.

Tourism Sites: Image-Heavy Without Killing Mobile Load (2026)