Проблема: «Поездка во Франкфурт»
При создании электронной коммерции в регионе MENA, особенно в Египте, становится ясно, что стандартные практики веб-производительности не всегда достаточны. Высокая сетевая задержка, нестабильные соединения 4G и географическая удаленность от основных европейских дата-центров (где трафик обычно маршрутизируется через Франкфурт или Лондон у таких провайдеров как AWS/GCP) означают, что традиционное серверное рендеринг может привести к катастрофическому времени до первого байта (TTFB) около 800 мс или более.
В нашем старом архитектурном решении каждый раз при запросе пользователем страницы продукта (например, зарядного устройства мощностью 20 Вт) запрос отправлялся из Каира во Франкфурт, запрашивал базу данных, генерировал HTML и возвращался обратно. Даже оптимизированные запросы к базе данных не могли преодолеть физические ограничения сети – только сама сеть вносила задержку примерно в 150 мс туда и обратно. При нагрузке наше время TTFB колебалось между 800 мс и 1,2 секунды. Для электронной торговли, где каждая дополнительная сотня миллисекунд задержки снижает конверсию, это было неприемлемо.
Решение: устаревшие данные с повторной проверкой на краю сети
Чтобы добиться мгновенной загрузки страниц, нам пришлось обслуживать HTML непосредственно с узлов края сети, расположенных максимально близко к пользователю. Однако электронная торговля требует динамических данных (цены, уровни запасов). Мы решили эту проблему, используя комбинацию кеширования на краях сети и стратегию управления кешем "stale-while-revalidate" (SWR).
Переопределение заголовков Cache-Control
Вместо того чтобы блокировать запрос пока страница генерируется на удаленном сервере, мы инструктируем наш CDN немедленно предоставлять пользователю устаревшую версию HTML, одновременно асинхронно обновляя страницу в фоновом режиме для следующего пользователя.