Hotel WD Migrates to Cloudflare Edge Cache: Reaching Your Guests in Milliseconds
Today we're announcing an engineering milestone we've been building toward for weeks. Every customer hotel site on Hotel WD is now served through Cloudflare's global edge cache network. That means your hotel website now reaches a visitor's browser in roughly 50 milliseconds instead of 800. A 17× speedup. And it's included in the plan you already pay for — no separate Cloudflare bill.
Cloudflare edge cache architecture: origin server, global edge network and the guest browser, with cache HIT flow and TTFB dropping from 800ms to 47ms.
Hospitality on the digital side is a game of small numbers. When a traveler types "boutique hotel Manhattan" into Google and scans the results, they spend only a few seconds glancing at each of the top three before clicking. If your site takes more than two seconds to render, that traveler typically bounces and goes to the next listing. Google notices that behavior and ranks slow sites lower over time. Slowness doesn't just lose tonight's reservation — it slowly erodes next month's organic traffic too.
Page speed is not a comfort feature for us. It is an engineering discipline that maps directly to revenue. That's why we call this work the Art of Milliseconds. Like a watchmaker tuning each escapement, we sweat every millisecond — because 200ms can be the difference between a booking and a bounce across three thousand visitors.
The infrastructure we picked when building Hotel WD wasn't a default choice. We built on Next.js App Router — one of the fastest, most SEO-friendly modern web frameworks — and tuned it specifically for hospitality. The reasoning is simple:
Next.js renders pages on the server and ships ready HTML to the guest's browser. No waiting for heavyweight JavaScript bundles to download and parse. Because of this, hotel sites running on Hotel WD routinely land 95+ Lighthouse scores.
But Next.js alone wasn't enough. Our origin server lives in a single data center; the guest opening your site might be in New York, London, or Singapore. The geographic distance alone is latency. That's where Cloudflare comes in.
Cloudflare for SaaS is the enterprise tier Cloudflare provides to multi-tenant SaaS platforms like ours, the same network that powers many of the largest brands you interact with daily. Hotel WD is registered as a SaaS provider, which means every customer's custom domain is automatically distributed across Cloudflare's edge servers in 330+ cities worldwide.
What does that mean in practice? A copy of your site sits in the Cloudflare data center closest to each guest. A traveler from Miami hits the Miami edge, one from London hits the London edge, one from Tokyo hits the Tokyo edge. Wherever our origin server is, the guest connects to a node geographically near them.
The new request flow looks like this:
Under the old architecture, every request traveled all the way to the server: database queried, page rendered, HTML generated. That took roughly 800ms on average. Under the new architecture, that calculation runs once when a page is cached; the next thousand visitors get the cached copy instantly.
While designing this we weren't only thinking about speed. There's a second engineering win that matters just as much: our origin server is breathing easier.
In the previous setup, when a popular hotel site received ten thousand visitors a day, every single request reached the origin: database queried, page rendered. A campaign push, a viral social post, or a Google Hotel Ads spike could strain the server, lengthen response times, and in the worst case serve error pages to a few unlucky guests.
In the new Cloudflare edge architecture the picture changes completely:
This is the calm produced by absorbing a wide visitor stream — the kind of enterprise-grade reliability that means your business success is never bottlenecked by infrastructure capacity.
The migration's technical side is our problem; the outcomes are something we share. The concrete results of what went live today:
Page Load Time. Across every customer site with a custom domain, time-to-first-byte (TTFB) dropped from ~800ms to a 50–80ms range. For a guest on mobile 4G, that means the page now feels noticeably instant.
Smart Cache Invalidation. When you save a change in the hotel admin panel — a description tweak, a new room, a price update — our system fires a "purge" signal to Cloudflare in the background. That signal wipes the stale copy from the edge immediately. The next visitor sees fresh content. Instant updates without sacrificing speed.
Owner-Cache Conflicts Solved. Our cache logic recognizes user sessions. When the hotel owner views their own site they see admin badges like "Edit"; an anonymous guest viewing the same URL at the same moment sees the cached public version. Owner-only UI never accidentally leaks into the public cache. Two layers of safety.
Manual "Purge Cache" Button. We added a small button to the manage panel header. If something edge-cached looks stale and you want it cleared right now — say an old promotion is still showing — one click flushes the edge cache for your hotel. No need to call support.
SSL/TLS Certificate Management Is Automatic. Cloudflare for SaaS automatically issues and renews SSL certificates for every customer custom domain. The only thing your customer does is add a single CNAME record in their DNS panel. Certificates are no longer something they think about.
This last point may be the most important from a customer-economics perspective. Cloudflare for SaaS is included in every Hotel WD plan. No extra fee, no separate subscription, no usage-based add-on bill.
Most SaaS providers either leave edge caching to you (open your own Cloudflare account, pay your own bill) or gate it behind "Pro" or "Enterprise" tiers. We believe every customer site deserves enterprise-grade infrastructure. A small boutique in Brooklyn and a large resort chain in Florida should meet equal, fast infrastructure when milliseconds matter.
For as long as you're a Hotel WD customer, your hotel website is delivered through Cloudflare's 330+ city edge network. We handle the account, the certificate renewals, the edge cache configuration, the DDoS protection, and the traffic management — all behind the scenes.
A short technical summary for the curious readers from our engineering team. The cache strategy we implemented in this project is not single-layer; it is a three-tier system:
unstable_cache (in-app DB cache). The result of a hotel page's database query is tagged with hotel ID and domain. TTL is 7 days, but with tag-based invalidation it becomes invalid immediately on any save action. A revalidateTag('hotel:id:abc123', 'max') call wipes all related cache entries.Cache-Control header because Next.js produces no-store by default for dynamic pages; we override that with a Cloudflare Cache Rule.max-age=0; the browser revalidates every time. So when a customer reloads the page after a save action, they immediately see fresh content — the old version doesn't get locked in the browser.We solved a few subtleties in the architecture. Next.js, for RSC streaming, attaches the following Vary header to responses: vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch, Accept-Encoding. Cloudflare's caching policy only caches Vary headers with Accept-Encoding; any other values cause a MISS. The fix: a Cloudflare Response Header Transform Rule that simplifies this header to leave only Accept-Encoding.
A second subtlety: when a hotel owner views their own site, they see owner-specific UI like "Edit". Returning a cached public version to that user would be wrong. We wrote a cookie-aware bypass rule: any request carrying a session-token cookie bypasses the edge cache and goes straight to origin. Owners always see fresh content; anonymous visitors get the cached fast version.
On save, all three layers invalidate together. When you save a field in the hotel admin panel, the server-side revalidateHotel(hotelId, customDomain) function runs. That function busts the Next.js cache tags and also fires a purge_cache request to the Cloudflare API. CF-side purge is best-effort by design — even if purge fails, the save flow doesn't break; in the worst case, stale content remains until TTL expires.
As mentioned earlier, Google's Core Web Vitals signal is one of its ranking factors. A site that is edge-cached and opens with sub-100ms TTFB rises naturally in organic search. How much of a rise depends on your industry, competitive density, and content strategy — but on the speed side, there's nothing left for you to do.
This week we invested not just in infrastructure but on the visual side too. Azure Coastal is our new premium theme designed for coastal hotels and boutique resorts. Whitewashed Mediterranean aesthetic, slim black top bar, centered logo crown, cinematic seascape hero, and trust-building rating chip — all in one. The product of months of design work, and it has produced fantastic results on the first customer sites.
For customers who want to see the new theme: Azure Coastal showcase page
Your hotel website is your guest's digital lobby. When you open the lobby door you don't make the guest wait a single second; the same is true on the digital side. A page that opens instantly tells the guest, in the very first second, "we take this seriously."
We've completed the migration to Cloudflare for SaaS edge. Every Hotel WD customer — including new sign-ups — is on this infrastructure. The only thing you need to do is keep using your hotel site. Speed and enterprise-grade calm are already taken care of.
Page speed isn't a comfort feature — it's a reservation. Hotel WD makes every millisecond count.
Tahir Dinç
I have been working in the digital field since 1999. I still hold the position of Digital Marketing Manager at Türk SEM. I have also been involved in tourism-related activities since 2005.