I spend a great deal of time looking at tourism digital experiences, not from the perspective of a CTO or infrastructure architect, but as a technology enthusiast and tourism operator interested in why certain experiences feel alive while others remain static and constrained.
Again and again, the same contradiction shows. Tourism relies heavily on imagery, movement, and atmosphere to communicate value, yet many tourism websites still behave like basic document servers delivering pages with a number of supporting images.
This gap is rarely explained by a lack of creative ambition or design skill. Nor the lack of available imagery. In practice, it almost always traces back to something more fundamental: the way storage is conceived, implemented, and largely taken for granted.
The silent assumption: “storage just works”
In most tourism web projects, storage is not designed as a deliberate component. It is assumed to be a built‑in feature of the chosen platform. With e.g. WordPress, images are uploaded into a folder and served alongside pages. With no‑code or website builders, media handling is abstracted even further. Sometimes a CDN is introduced later, typically as a performance fix rather than as part of the original design.
And there is no semantic connection between the images and the content. The result is a form of “dumb storage.” Files are stored and retrieved successfully, but important questions are left unanswered, such as:
- how assets are accessed at scale
- how delivery behaves under concurrent load
- how authorization and visibility are handled
- how performance changes as usage grows
This approach works well enough for modest, page‑oriented sites. The limitations only become apparent once imagery and video move from a supporting role to the centre of the experience.
This is the math most tourism websites quietly ignore
A single high‑quality tourism image today typically weighs around 2 MB after sensible compression. That figure represents a reasonable trade‑off between visual clarity and performance. But cannot be used "as is", so in practice, desktop versions are usually accompanied by mobile‑optimised variants and one or more thumbnails. Taken together, these representations amount to roughly 3 MB per image.
At small scale, this does not feel problematic. A site with a few dozen images raises no concerns. Even several hundred images may appear straightforward to manage. The challenge emerges when imagery becomes dynamic rather than static.
Once a site begins (context aware) drawing from a pool of hundreds or thousands of images—covering destinations, seasons, campaigns, or moods—the asset base quickly reaches several gigabytes. Storage capacity itself remains inexpensive, but access patterns become far more demanding.
Now assume the site performs as desired by a smaller operator:
- up to 100 visits per day
- roughly 100 images dynamically selected per session
- around 3 MB per image
Which results in about 30 GB of image traffic per day, or close to a terabyte per month. At that point, the underlying question becomes unavoidable: was the website stack ever designed to support this level of sustained, image‑centric usage, or was it implicitly built for brochure‑level presentation?
For object‑based storage systems, this level of traffic is routine. For traditional CMS hosting models, it is often where hidden constraints begin to influence system behaviour.
Why image‑centric tourism experiences break classic stacks
An image‑centric experience is not achieved by simply adding more images to existing pages. It introduces a different technical profile. Assets are requested concurrently and often in large numbers. Rendering is expected to be progressive. Content is selected conditionally by device type, geography, seasonality, or campaign context. Video is increasingly streamed in segments rather than delivered as a single download.
In this environment, storage becomes part of the runtime execution path.
Traditional WordPress‑style environments struggle with this shift. Page rendering competes with asset delivery for server resources. Worker pools introduce blocking under parallel load. File‑system IO degrades as concurrency increases. Authorization models remain coarse and inflexible. Cache efficiency falls as content becomes more dynamic.
What follows is rarely outright failure. Instead, teams respond by exercising restraint. Layouts are simplified, motion is reduced, image usage is limited, and experimentation becomes risk‑averse. Over time, infrastructure quietly defines what feels possible.
Dumb storage ignores who should see which image
A further limitation appears when access control is considered. Tourism imagery is rarely intended to be universally visible.
It often includes:
- personal images for customers only
- trade‑only or partner content
- geo‑specific visuals
Modern object storage platforms enable selective exposure through mechanisms such as time‑limited access URLs, object‑level authorization, and a clear separation between metadata management and asset delivery.
Many CMS‑centric setups, by contrast, default to uploading assets once and exposing them everywhere. When control is required, duplication becomes the workaround. This approach becomes fragile and difficult to manage long before performance is visibly affected.
The performance cliff: exponential vs. near‑linear scaling
The impact of these design choices becomes most visible as usage grows. As monthly image and video traffic approaches hundreds of gigabytes or a terabyte, perceived performance begins to diverge sharply.
In traditional CMS hosting environments, response times tend to degrade exponentially. Worker exhaustion, memory contention, and IO saturation reinforce one another, so relatively small increases in load can produce disproportionate slowdowns.
Object‑based storage systems behave differently. Assets are immutable and increasing traffic primarily translates into higher bandwidth consumption rather than internal contention. Latency remains comparatively stable as demand grows.
This distinction determines whether an image‑centric experience continues to function smoothly as it becomes popular, or whether it deteriorates under the weight of its own success.
Why the blob‑storage performance claim holds (Azure focus)
These observations are grounded in the design of modern object storage systems. Azure Blob Storage, for example, exposes metrics that clearly separate server‑side processing latency from end‑to‑end delivery time. Under normal operating conditions, block blob reads typically complete with server‑side latency measured in tens of milliseconds. When paired with say Azure Front Door, edge‑cached assets are often delivered with time‑to‑first‑byte well below 100 ms.
This separation exists because object storage is built to handle high degrees of parallel access without shared state. Provided access patterns remain object‑centric rather than emulating file systems, scalability is primarily a function of distribution rather than contention.
The same architectural principles apply across hyperscalers. Azure, AWS, and Google Cloud all optimise object storage for immutable assets, high cache‑hit ratios, and predictable latency at scale—characteristics that traditional web hosting stacks were never designed to provide.
Why this conversation is often avoided in tourism tech
Despite its relevance, storage rarely features prominently in tourism technology discussions. Addressing it directly requires acknowledging that modern websites are no longer simple collections of pages. It requires thinking in terms of asset concurrency, growth curves, and access semantics. It also requires accepting that imagery is not secondary content, but the primary product being delivered.
In practice, many conversations remain focused on templates, editors, and incremental optimisation. Storage stays implicit, largely unexamined, and therefore unchanged.
My position, clearly stated
From a tech evangelist’s perspective, the conclusion is straightforward. Tourism’s digital presence is not constrained by branding or creative ambition. It is constrained by the way storage performance and access control are treated as secondary concerns.
The move from a website that merely contains images to a genuinely image‑led, dynamic experience does not begin with a CMS change. It begins with a shift in how storage is understood, designed, and discussed.
Until that shift occurs, tourism websites will continue to undersell experiences that are, in reality, far richer than what the screen ever manages to convey.