Pull и Push: два способа наполнить edge
В модели Pull cdn.com.tr запрашивает каждый объект с вашего существующего origin при первом обращении, затем кэширует его на edge на заданный вами TTL; на origin вы ничего не меняете, кроме DNS. В модели Push вы загружаете ресурсы в хранилище cdn.com.tr, и edge отдаёт их напрямую оттуда, что идеально, если вы вообще не хотите держать origin-сервер онлайн. Большинство клиентов начинают с Pull, потому что он не требует миграции, а затем переносят тяжёлые медиа в Push или Object Storage. Обе модели используют одни и те же правила кэширования, инструменты purge и отчётность.
Правила кэширования, TTL и ключи кэша под вашим контролем
Настоящая работа CDN — решить, что безопасно кэшировать и на какой срок, и именно это открывает панель. Вы задаёте TTL по пути или расширению файла, выбираете, учитывать ли заголовок Cache-Control origin или переопределить его, и контролируете, какие query-параметры и cookie входят в ключ кэша, чтобы /list?page=2 и /list?page=3 кэшировались раздельно, а трекинг-параметры не дробили кэш. Правильный ключ кэша превращает низкий hit ratio в высокий, а отчёты делают это видимым, так что вы настраиваете, а не гадаете.
Разгрузка origin и shielding
Каждый запрос, отвеченный с edge, — это запрос, который ваш origin никогда не увидит, поэтому загруженная контентная страница, которая раньше засыпала ваш сервер сотнями обращений к изображениям и ресурсам, сводится к горстке запросов к origin за окно TTL. Поскольку посетители резолвятся на edge, а не на IP origin, origin также перестаёт получать прямой трафик, что снижает и расходы на трафик, и экспозицию. Именно эта разгрузка удерживает сайт на ногах, когда кампания, всплеск новостей или репост в соцсетях внезапно обрушивают поток посетителей.
Автоматическая оптимизация изображений с WebP
Изображения обычно самая тяжёлая часть страницы, а отправка полноразмерных файлов JPEG или PNG каждому посетителю тратит трафик и замедляет отрисовку. cdn.com.tr может прозрачно конвертировать подходящие изображения в WebP на edge и отдавать более лёгкую версию браузерам, заявляющим о поддержке, а браузеры без поддержки получают нетронутый оригинал. Вам не нужно переэкспортировать медиатеку или менять HTML; оптимизация происходит в пути доставки, а экономия сразу видна в весе страницы и времени загрузки.
Безопасное кэширование динамического контента
Кэширование нужно не только для статических файлов. Многие страницы, которые ощущаются динамичными — списки категорий, страницы товаров, тексты статей — меняются лишь раз в несколько минут и могут микрокэшироваться с коротким TTL, чтобы поглощать трафик, оставаясь свежими. cdn.com.tr позволяет кэшировать такие ответы с правилами, исключающими залогиненные сессии и персонализированные пути, так что анонимные посетители обслуживаются с edge, а собственная корзина или страница аккаунта пользователя всегда идёт на origin. Результат — скорость уровня CDN на страницах, которые большинство платформ оставляют без кэша.
Измерение результата: hit ratio и время загрузки
Нельзя улучшить то, чего не видно, поэтому панель показывает коэффициент попаданий в кэш, объём байт, отданных с edge против origin, и статус кэша по каждому ответу. Здоровый, преимущественно статический сайт должен достигать высокого hit ratio после прогрева кэша; низкий коэффициент обычно указывает на то, что ключ кэша включает изменчивый cookie или query-параметр, что затем можно исправить в правилах. Наблюдение за этими цифрами после каждого изменения замыкает цепочку между конфигурацией и реальной скоростью, которую ощущают ваши посетители.
Как настроить, шаг за шагом
Добавьте домен в аккаунт CDN
В панели откройте раздел доменов, добавьте свой хост (например, www.example.com) и выберите, будет ли cdn.com.tr работать как Pull origin относительно вашего существующего сервера или как Push-цель, в которую вы загружаете файлы. Для большинства сайтов Pull — самый быстрый старт: миграция файлов не требуется.
Направьте DNS на edge
Обновите CNAME (или apex-запись, если DNS размещён у нас), чтобы трафик резолвился на edge cdn.com.tr, а не на IP вашего origin. После распространения изменений каждый запрос сначала попадает на edge-узел и по возможности отдаётся из кэша.
Настройте правила кэширования
Задайте TTL по пути или расширению: длинные TTL (дни) для версионированных ресурсов вроде /assets/*.css, /*.js, изображений и шрифтов; короткие или обходные правила для /cart, /checkout или всего, что содержит сессионный cookie. Вы можете учитывать заголовок Cache-Control с origin или переопределить его из панели.
Включите оптимизацию изображений
Включите автоматическую конвертацию в WebP, чтобы изображения JPEG и PNG перекодировались и отдавались в более лёгком формате браузерам, которые его поддерживают, при этом оригинал сохраняется как запасной вариант. Обычно это существенно снижает вес изображений без изменения исходных файлов.
Проверьте, что кэш работает
Загрузите страницу и проверьте заголовки ответа на статус кэша (HIT/MISS) и возраст (age). Повторный запрос к тому же URL должен вернуть HIT, отданный с edge. Используйте отчёты панели, чтобы наблюдать, как растёт коэффициент попаданий по мере прогрева edge.
Делайте purge при изменении контента
После деплоя или редактирования контента очистите (purge) затронутые URL — или всё сразу — через панель или purge API, чтобы посетители сразу получали новую версию, а не ждали истечения TTL.
Примеры сценариев
Новостной или блог-сайт отдаёт изображения, CSS и JavaScript с edge с длинными TTL, резко снижая трафик на origin и сокращая время загрузки страниц для читателей по всему миру.
Во время флэш-распродажи страницы товарных списков микрокэшируются, а статические ресурсы кэшируются полностью, так что внезапный всплеск трафика поглощается на edge, а не перегружает origin магазина.
Поставщик распространяет установщики и пакеты обновлений через Push-хранилище на edge, быстро доставляя большие файлы пользователям и защищая origin от всплесков трафика.
Часто задаваемые вопросы
Как узнать, был ли запрос отдан из кэша?
Каждый ответ содержит заголовок статуса кэша со значением HIT (отдано с edge) или MISS (получено с origin), а также значение age. Загрузите URL дважды: второй запрос к кэшируемому ресурсу должен вернуть HIT. Отчёты панели также агрегируют это в общий коэффициент попаданий в кэш.
Будет ли кэш отдавать устаревший контент после обновления сайта?
Кэшированные объекты живут только до истечения TTL, но ждать не обязательно. Очистите (purge) изменённые URL или всю зону через панель или purge API сразу после деплоя, и edge подтянет свежие копии при следующем запросе, продолжая отдавать всё остальное из кэша.
Можно ли кэшировать страницы, использующие cookie или query-строки?
Да, с контролем. Вы решаете, какие cookie и query-параметры входят в ключ кэша, так что важные создают отдельные кэшированные варианты, а трекинг-параметры игнорируются. Сессионные или залогиненные запросы можно настроить на полный обход кэша, чтобы персонализированный контент всегда доходил до origin.
Меняет ли конвертация в WebP исходные файлы изображений?
Нет. Конвертация происходит в пути доставки. Ваши сохранённые оригиналы не затрагиваются; edge генерирует и отдаёт вариант WebP браузерам, которые его поддерживают, а для остальных возвращается к оригинальному формату.
Что произойдёт, если мой origin-сервер выйдет из строя?
Всё, что уже закэшировано на edge, продолжает отдаваться посетителям в течение окна TTL, поэтому кратковременный сбой origin не обязательно выводит статический контент офлайн. Запросы к некэшированным или устаревшим объектам всё же потребуют origin, что ещё одна причина держать TTL щедрыми для стабильных ресурсов.
Нужно ли переносить файлы, чтобы использовать CDN?
Не в модели Pull. Вы сохраняете существующий origin-сервер и меняете только DNS, чтобы edge оказался перед ним, забирая и кэшируя контент по требованию. Push-хранилище опционально и полезно, когда вы хотите, чтобы edge отдавал медиа вообще без origin.