Hotel WD переходит на Cloudflare Edge Cache: гости получают сайт за миллисекунды
Сегодня мы объявляем о техническом достижении, над которым работали несколько недель. Все клиентские сайты отелей в Hotel WD теперь обслуживаются через глобальную edge-сеть кэша Cloudflare. Это значит, что ваш сайт отеля доходит до браузера посетителя примерно за 50 миллисекунд вместо 800. Ускорение в 17 раз. И это включено в тариф, за который вы уже платите — без отдельного счёта от Cloudflare.
Архитектура edge-кэша Cloudflare: origin-сервер, глобальная edge-сеть и браузер гостя, с потоком cache HIT и TTFB, падающим с 800мс до 47мс.
Гостеприимство в цифровой плоскости — это игра малых чисел. Когда путешественник вбивает "boutique hotel Manhattan" в Google и просматривает результаты, он тратит лишь несколько секунд на каждую из первых трёх позиций перед кликом. Если ваш сайт грузится дольше двух секунд, такой путешественник обычно уходит и переходит к следующему листингу. Google замечает это поведение и со временем понижает медленные сайты в выдаче. Медлительность не просто упускает сегодняшнюю бронь — она постепенно подъедает органический трафик следующего месяца.
Скорость страницы для нас — не функция комфорта. Это инженерная дисциплина, которая напрямую переводится в выручку. Поэтому мы называем эту работу Искусством миллисекунд. Как часовой мастер, настраивающий каждый анкер, мы потеем над каждой миллисекундой — потому что 200мс могут стать разницей между бронированием и отказом на трёх тысячах посетителей.
Инфраструктура, которую мы выбрали при создании Hotel WD, не была выбором по умолчанию. Мы построили на Next.js App Router — одном из самых быстрых и SEO-дружественных современных веб-фреймворков — и настроили его специально под отельную сферу. Логика проста:
Next.js рендерит страницы на стороне сервера и отправляет готовый HTML в браузер гостя. Без ожидания загрузки и парсинга тяжёлых JavaScript-бандлов. Благодаря этому отельные сайты на Hotel WD регулярно набирают 95+ баллов Lighthouse.
Но одного Next.js было недостаточно. Наш origin-сервер живёт в одном дата-центре; гость, открывающий ваш сайт, может быть в Нью-Йорке, Лондоне или Сингапуре. Сама географическая дистанция — это задержка. Тут на сцену выходит Cloudflare.
Cloudflare for SaaS — это корпоративный уровень, который Cloudflare предоставляет мульти-арендным SaaS-платформам, как наша. Та же сеть, которая стоит за многими крупнейшими брендами, с которыми вы взаимодействуете ежедневно. Hotel WD зарегистрирован как SaaS-провайдер, что значит, что каждый кастомный домен клиента автоматически распределяется по edge-серверам Cloudflare в более чем 330 городах по всему миру.
Что это означает на практике? Копия вашего сайта лежит в дата-центре Cloudflare, ближайшем к каждому гостю. Путешественник из Майами попадает на edge Майами, из Лондона — на edge Лондона, из Токио — на edge Токио. Где бы ни находился наш origin-сервер, гость подключается к географически близкому узлу.
Новый поток запросов выглядит так:
В прежней архитектуре каждый запрос путешествовал до сервера: запрос к базе данных, рендер страницы, генерация HTML. Это занимало в среднем около 800мс. В новой архитектуре этот расчёт выполняется один раз, когда страница кэшируется; следующая тысяча посетителей получают кэшированную копию мгновенно.
Проектируя это, мы думали не только о скорости. Есть второй инженерный выигрыш, не менее важный: наш origin-сервер дышит легче.
В предыдущей конфигурации, когда популярный отельный сайт получал десять тысяч посетителей в день, каждый запрос доходил до origin: запрос к базе, рендер страницы. Кампания, вирусный пост в соцсетях или всплеск Google Hotel Ads мог нагрузить сервер, удлинить время отклика и в худшем случае показать страницы ошибок нескольким невезучим гостям.
В новой edge-архитектуре Cloudflare картина меняется полностью:
Это спокойствие, рождённое поглощением широкого потока посетителей — тот род корпоративной надёжности, который означает, что успех вашего бизнеса никогда не упирается в потолок инфраструктуры.
Техническая сторона миграции — наша забота; результаты — то, что мы делим. Конкретные результаты того, что вышло в продакшен сегодня:
Время загрузки страницы. На всех клиентских сайтах с кастомным доменом время до первого байта (TTFB) упало с ~800мс до диапазона 50–80мс. Для гостя на мобильном 4G это значит, что страница теперь ощущается заметно мгновенно.
Умная инвалидация кэша. Когда вы сохраняете изменение в админке отеля — правка описания, новый номер, обновление цены — наша система отправляет сигнал "purge" в Cloudflare на фоне. Этот сигнал немедленно стирает устаревшую копию с edge. Следующий посетитель видит свежий контент. Мгновенные обновления без потери скорости.
Конфликты владелец-кэш решены. Наша логика кэша распознаёт пользовательские сессии. Когда владелец отеля смотрит свой сайт, он видит админ-бейджи вроде "Редактировать"; анонимный гость, открывший тот же URL в тот же момент, видит публичную кэшированную версию. Эксклюзивный для владельца UI никогда случайно не утекает в публичный кэш. Двойная безопасность.
Ручная кнопка "Очистить кэш". Мы добавили маленькую кнопку в шапку панели управления. Если что-то закэшированное на edge выглядит устаревшим и вы хотите очистить прямо сейчас — например, старая акция всё ещё показывается — один клик опустошает edge-кэш вашего отеля. Не нужно звонить в поддержку.
Автоматическое управление SSL/TLS-сертификатами. Cloudflare for SaaS автоматически выпускает и обновляет SSL-сертификаты для каждого кастомного домена клиента. Единственное, что ваш клиент делает — добавляет одну CNAME-запись в свою DNS-панель. Сертификаты больше не то, о чём им нужно думать.
Этот последний пункт может быть самым важным с точки зрения экономики клиента. Cloudflare for SaaS включён во все тарифы Hotel WD. Без дополнительной платы, без отдельной подписки, без счёта по использованию.
Большинство SaaS-провайдеров либо оставляют edge-кэширование вам (откройте свой аккаунт Cloudflare, оплатите свой счёт), либо ограничивают его уровнями "Pro" или "Enterprise". Мы считаем, что каждый клиентский сайт заслуживает инфраструктуру корпоративного уровня. Маленький бутик в Бруклине и крупная сеть резортов во Флориде должны встретить одинаковую быструю инфраструктуру, когда миллисекунды имеют значение.
Пока вы клиент Hotel WD, ваш отельный сайт доставляется через edge-сеть Cloudflare в более чем 330 городах. Мы ведём аккаунт, обновления сертификатов, конфигурацию edge-кэша, защиту от DDoS и управление трафиком — всё за кулисами.
Краткая техническая сводка для любопытных читателей из нашей инженерной команды. Стратегия кэширования, которую мы реализовали в этом проекте, не однослойная; это трёхуровневая система:
unstable_cache (внутренний кэш БД приложения). Результат запроса к базе данных страницы отеля помечается ID отеля и доменом. TTL — 7 дней, но с инвалидацией по тегам становится недействительным мгновенно при любом действии сохранения. Вызов revalidateTag('hotel:id:abc123', 'max') стирает все связанные записи кэша.Cache-Control от origin, потому что Next.js по умолчанию выдаёт no-store для динамических страниц; мы переопределяем это через Cloudflare Cache Rule.max-age=0; браузер ревалидирует каждый раз. Поэтому когда клиент перезагружает страницу после действия сохранения, он сразу видит свежий контент — старая версия не остаётся заблокированной в браузере.Мы решили несколько тонкостей в архитектуре. Next.js для RSC-стриминга прикрепляет к ответам следующий заголовок Vary: vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch, Accept-Encoding. Политика кэша Cloudflare кэширует только Vary-заголовки с Accept-Encoding; любые другие значения вызывают MISS. Решение: Cloudflare Response Header Transform Rule, которая упрощает этот заголовок, оставляя только Accept-Encoding.
Вторая тонкость: когда владелец отеля смотрит свой собственный сайт, он видит UI, специфичный для владельца, например "Редактировать". Возвращать ему кэшированную публичную версию было бы неправильно. Мы написали правило обхода на основе cookie: любой запрос с cookie session-token обходит edge-кэш и идёт прямо на origin. Владельцы всегда видят свежий контент; анонимные посетители получают кэшированную быструю версию.
При сохранении все три слоя инвалидируются вместе. Когда вы сохраняете поле в админ-панели отеля, на стороне сервера запускается функция revalidateHotel(hotelId, customDomain). Эта функция сбрасывает теги кэша Next.js и также отправляет запрос purge_cache к API Cloudflare. Purge на стороне CF спроектирован как best-effort — даже если purge не удался, поток сохранения не ломается; в худшем случае устаревший контент остаётся до истечения TTL.
Как упоминалось ранее, сигнал Core Web Vitals от Google — один из его факторов ранжирования. Сайт, кэшированный на edge и открывающийся с TTFB менее 100мс, естественным образом поднимается в органическом поиске. Насколько именно поднимется — зависит от вашей отрасли, конкурентной плотности и контентной стратегии — но со стороны скорости вам больше нечего делать.
На этой неделе мы инвестировали не только в инфраструктуру, но и в визуальную сторону. Azure Coastal — наша новая премиум-тема, разработанная для прибрежных отелей и бутик-резортов. Беленая средиземноморская эстетика, тонкая чёрная верхняя панель, центрированная корона логотипа, кинематографичный hero с морским пейзажем и вызывающий доверие чип рейтинга — всё в одном. Результат месяцев работы дизайнеров, и он принёс фантастические результаты на первых клиентских сайтах.
Для клиентов, которые хотят увидеть новую тему: Showcase-страница Azure Coastal
Ваш отельный сайт — это цифровое лобби вашего гостя. Открывая дверь лобби, вы не заставляете гостя ждать ни секунды; то же верно и в цифровой плоскости. Страница, открывающаяся мгновенно, говорит гостю в самую первую секунду: "мы относимся к этому серьёзно".
Мы завершили миграцию на Cloudflare for SaaS edge. Все клиенты Hotel WD — включая новые регистрации — на этой инфраструктуре. Единственное, что вам нужно делать — продолжать пользоваться своим отельным сайтом. Скорость и корпоративное спокойствие уже обеспечены.
Скорость страницы — это не функция комфорта, это бронирование. Hotel WD заставляет каждую миллисекунду считаться.
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.
