Hotel WD migre vers le cache edge de Cloudflare : atteindre vos clients en millisecondes
Aujourd'hui, nous annonçons un jalon d'ingénierie sur lequel nous travaillons depuis plusieurs semaines. Tous les sites hôteliers clients sur Hotel WD sont désormais servis via le réseau global de cache edge de Cloudflare. Cela signifie que votre site web hôtelier atteint le navigateur d'un visiteur en environ 50 millisecondes au lieu de 800. Une accélération de 17×. Et c'est inclus dans la formule que vous payez déjà — pas de facture Cloudflare séparée.
Architecture du cache edge Cloudflare : serveur d'origine, réseau edge mondial et navigateur du client, avec flux cache HIT et TTFB passant de 800ms à 47ms.
L'hôtellerie côté digital est un jeu de petits chiffres. Quand un voyageur tape "boutique hotel Manhattan" sur Google et parcourt les résultats, il ne consacre que quelques secondes à chacun des trois premiers avant de cliquer. Si votre site met plus de deux secondes à se charger, ce voyageur quitte généralement la page et passe au listing suivant. Google remarque ce comportement et, avec le temps, classe les sites lents plus bas. La lenteur ne fait pas seulement perdre la réservation de ce soir — elle érode aussi le trafic organique du mois prochain.
La vitesse de page n'est pas pour nous une fonctionnalité de confort. C'est une discipline d'ingénierie qui se traduit directement en chiffre d'affaires. C'est pourquoi nous appelons ce travail l'Art des Millisecondes. Comme un horloger ajustant chaque échappement, nous transpirons sur chaque milliseconde — parce que 200ms peuvent faire la différence entre une réservation et un rebond sur trois mille visiteurs.
L'infrastructure que nous avons choisie en construisant Hotel WD n'était pas un choix par défaut. Nous avons bâti sur Next.js App Router — l'un des frameworks web modernes les plus rapides et compatibles SEO — et l'avons réglé spécifiquement pour l'hôtellerie. Le raisonnement est simple :
Next.js rend les pages côté serveur et envoie le HTML prêt au navigateur du client. Pas d'attente pour télécharger et analyser de lourds bundles JavaScript. Grâce à cela, les sites hôteliers fonctionnant sur Hotel WD obtiennent régulièrement des scores Lighthouse de 95+.
Mais Next.js seul ne suffisait pas. Notre serveur d'origine vit dans un seul centre de données ; le client qui ouvre votre site pourrait être à New York, Londres ou Singapour. La distance géographique seule représente de la latence. C'est là que Cloudflare entre en jeu.
Cloudflare for SaaS est le niveau entreprise que Cloudflare propose aux plateformes SaaS multi-clients comme la nôtre, le même réseau qui alimente bon nombre des plus grandes marques avec lesquelles vous interagissez quotidiennement. Hotel WD est enregistré comme fournisseur SaaS, ce qui signifie que chaque domaine personnalisé client est automatiquement distribué sur les serveurs edge de Cloudflare dans plus de 330 villes à travers le monde.
Qu'est-ce que cela signifie en pratique ? Une copie de votre site est hébergée dans le centre de données Cloudflare le plus proche de chaque client. Un voyageur depuis Miami atteint le edge de Miami, un de Londres le edge de Londres, un de Tokyo le edge de Tokyo. Où que se trouve notre serveur d'origine, le client se connecte à un nœud géographiquement proche.
Le nouveau flux de requête ressemble à ceci :
Sous l'ancienne architecture, chaque requête voyageait jusqu'au serveur : interrogation de la base de données, rendu de page, génération HTML. Cela prenait environ 800ms en moyenne. Dans la nouvelle architecture, ce calcul s'exécute une seule fois lorsqu'une page est mise en cache ; les mille visiteurs suivants obtiennent la copie cachée instantanément.
En concevant ceci, nous ne pensions pas seulement à la vitesse. Il y a une seconde victoire d'ingénierie tout aussi importante : notre serveur d'origine respire mieux.
Dans la configuration précédente, quand un site hôtelier populaire recevait dix mille visiteurs par jour, chaque requête atteignait l'origine : interrogation de la base de données, rendu de page. Une campagne, un post viral sur les réseaux sociaux, ou un pic Google Hotel Ads pouvait stresser le serveur, allonger les temps de réponse et, dans le pire des cas, servir des pages d'erreur à quelques clients malchanceux.
Dans la nouvelle architecture edge Cloudflare, le tableau change complètement :
C'est le calme produit par l'absorption d'un large flux de visiteurs — le genre de fiabilité de niveau entreprise qui signifie que le succès de votre activité n'est jamais limité par la capacité d'infrastructure.
Le côté technique de la migration est notre problème ; les résultats sont quelque chose que nous partageons. Les résultats concrets de ce qui a été publié aujourd'hui :
Temps de chargement de page. Sur tous les sites clients avec un domaine personnalisé, le temps jusqu'au premier octet (TTFB) est passé de ~800ms à une plage de 50–80ms. Pour un client en 4G mobile, cela signifie que la page semble désormais notablement instantanée.
Invalidation intelligente du cache. Lorsque vous enregistrez un changement dans le panneau admin de l'hôtel — un ajustement de description, une nouvelle chambre, une mise à jour de prix — notre système envoie un signal "purge" à Cloudflare en arrière-plan. Ce signal efface immédiatement la copie obsolète du edge. Le visiteur suivant voit un contenu frais. Mises à jour instantanées sans sacrifier la vitesse.
Conflits propriétaire-cache résolus. Notre logique de cache reconnaît les sessions utilisateur. Quand le propriétaire de l'hôtel consulte son propre site, il voit des badges admin comme "Modifier" ; un client anonyme consultant la même URL au même moment voit la version publique cachée. L'interface exclusive au propriétaire ne fuit jamais accidentellement dans le cache public. Double sécurité.
Bouton manuel "Purger le cache". Nous avons ajouté un petit bouton dans l'en-tête du panneau d'administration. Si quelque chose cachée au edge semble obsolète et que vous voulez le nettoyer immédiatement — par exemple, une ancienne promotion s'affiche encore — un clic vide le cache edge de votre hôtel. Pas besoin d'appeler le support.
Gestion automatique des certificats SSL/TLS. Cloudflare for SaaS émet et renouvelle automatiquement les certificats SSL pour chaque domaine personnalisé client. La seule chose que votre client fait est ajouter un seul enregistrement CNAME dans son panneau DNS. Les certificats ne sont plus quelque chose auquel ils pensent.
Ce dernier point peut être le plus important du point de vue de l'économie client. Cloudflare for SaaS est inclus dans toutes les formules Hotel WD. Pas de frais supplémentaire, pas d'abonnement séparé, pas de facture additionnelle basée sur l'usage.
La plupart des fournisseurs SaaS soit vous laissent le edge caching (ouvrez votre propre compte Cloudflare, payez votre propre facture) soit le réservent aux niveaux "Pro" ou "Enterprise". Nous croyons que chaque site client mérite une infrastructure de niveau entreprise. Une petite boutique à Brooklyn et une grande chaîne de resorts en Floride devraient avoir accès à la même infrastructure rapide quand les millisecondes comptent.
Tant que vous êtes client Hotel WD, votre site web hôtelier est livré via le réseau edge Cloudflare dans plus de 330 villes. Nous gérons le compte, les renouvellements de certificats, la configuration du cache edge, la protection DDoS et la gestion du trafic — tout en coulisses.
Un bref résumé technique pour les lecteurs curieux de notre équipe d'ingénierie. La stratégie de cache que nous avons mise en place dans ce projet n'est pas mono-couche ; c'est un système à trois niveaux :
unstable_cache (cache DB dans l'application). Le résultat d'une requête de base de données pour une page d'hôtel est étiqueté avec l'ID de l'hôtel et le domaine. TTL est de 7 jours, mais avec l'invalidation basée sur les tags, il devient invalide immédiatement à toute action de sauvegarde. Un appel revalidateTag('hotel:id:abc123', 'max') efface toutes les entrées de cache liées.Cache-Control de l'origine car Next.js produit no-store par défaut pour les pages dynamiques ; nous écrasons cela avec une Cloudflare Cache Rule.max-age=0 ; le navigateur révalide à chaque fois. Ainsi, lorsqu'un client recharge la page après une action de sauvegarde, il voit immédiatement du contenu frais — l'ancienne version ne reste pas verrouillée dans le navigateur.Nous avons résolu quelques subtilités dans l'architecture. Next.js, pour le streaming RSC, attache le header Vary suivant aux réponses : vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch, Accept-Encoding. La politique de cache de Cloudflare ne met en cache que les Vary headers avec Accept-Encoding ; toute autre valeur provoque un MISS. La solution : une Cloudflare Response Header Transform Rule qui simplifie ce header en ne laissant que Accept-Encoding.
Une deuxième subtilité : lorsque le propriétaire de l'hôtel consulte son propre site, il voit une UI spécifique au propriétaire comme "Modifier". Lui retourner une version publique cachée serait incorrect. Nous avons écrit une règle de bypass basée sur les cookies : toute requête portant un cookie session-token contourne le cache edge et va directement à l'origine. Les propriétaires voient toujours du contenu frais ; les visiteurs anonymes obtiennent la version rapide cachée.
À la sauvegarde, les trois couches s'invalident ensemble. Lorsque vous enregistrez un champ dans le panneau d'administration de l'hôtel, la fonction côté serveur revalidateHotel(hotelId, customDomain) s'exécute. Cette fonction efface les tags de cache Next.js et envoie également une requête purge_cache à l'API Cloudflare. La purge côté CF est conçue best-effort — même si la purge échoue, le flux de sauvegarde ne se brise pas ; dans le pire des cas, le contenu obsolète reste jusqu'à l'expiration du TTL.
Comme mentionné précédemment, le signal Core Web Vitals de Google est l'un de ses facteurs de classement. Un site caché au edge qui s'ouvre avec un TTFB sous 100ms monte naturellement dans la recherche organique. L'ampleur de cette montée dépend de votre secteur, de la densité concurrentielle et de votre stratégie de contenu — mais côté vitesse, il ne vous reste plus rien à faire.
Cette semaine, nous avons investi non seulement dans l'infrastructure mais aussi dans le côté visuel. Azure Coastal est notre nouveau thème premium conçu pour les hôtels côtiers et resorts boutique. Esthétique méditerranéenne chaulée, barre supérieure noire fine, couronne de logo centrée, hero cinématographique de paysage marin et badge de notation rassurant — tout en un. Fruit de mois de travail de design, il a produit des résultats fantastiques sur les premiers sites clients.
Pour les clients qui veulent voir le nouveau thème : Page showcase Azure Coastal
Votre site web hôtelier est le lobby digital de votre client. Quand vous ouvrez la porte du lobby, vous ne faites pas attendre le client une seule seconde ; il en va de même côté digital. Une page qui s'ouvre instantanément dit au client, dès la première seconde, "nous prenons cela au sérieux".
Nous avons terminé la migration vers le edge Cloudflare for SaaS. Tous les clients Hotel WD — y compris les nouvelles inscriptions — sont sur cette infrastructure. La seule chose que vous avez à faire est de continuer à utiliser votre site hôtelier. La vitesse et le calme de niveau entreprise sont déjà pris en charge.
La vitesse de page n'est pas une fonctionnalité de confort — c'est une réservation. Hotel WD fait compter chaque milliseconde.
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.