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 также перестаёт получать прямой трафик, что снижает и расходы на трафик, и экспозицию. Именно эта разгрузка удерживает сайт на ногах, когда кампания, всплеск новостей или репост в соцсетях внезапно обрушивают поток посетителей.
Автоматическая оптимизация изображений: AVIF и WebP
Оптимизация изображений — это переключатель для всего аккаунта или для одного правила доставки. Edge конвертирует изображения JPEG и PNG в WebP, а если для аккаунта выбран WebP + AVIF — в AVIF и WebP, и каждый браузер получает формат, который он принимает; браузеры, не принимающие ни один из них, получают изображение в исходном формате. При WebP + AVIF ответ приходит с того же URL, с Vary: Accept; при одном WebP браузеры, принимающие WebP, перенаправляются на копию .webp. В обоих случаях URL изображений в вашем HTML остаются прежними. В полном размере только что сконвертированное изображение уходит лишь тогда, когда оно меньше оригинала. Если конвертация не удалась, edge отдаёт вместо него исходное изображение. Обработка списывается из месячной квоты.
Формат выбирается один раз для аккаунта: WebP или WebP + AVIF. По нашему замеру 5 октября 2026 года на оптимизаторе изображений CDN.com.tr новостное фото JPEG размером 262 025 байт уходит как 86 936 байт AVIF, а скриншот PNG на 105 078 байт — как 27 942. Медиатека остаётся как есть. Все замеры — в нашем руководстве «AVIF или WebP», а проверка формата изображений покажет, что отдают ваши страницы сегодня. Как в целом устроены выбор формата, изменение размера и кеширование, объясняет руководство по CDN для изображений.
Безопасное кэширование динамического контента
Кэширование нужно не только для статических файлов. Многие страницы, которые ощущаются динамичными — списки категорий, страницы товаров, тексты статей — меняются лишь раз в несколько минут и могут микрокэшироваться с коротким 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 или WebP + AVIF. JPEG и PNG конвертируются на edge; исходные файлы остаются нетронутыми.
Проверьте, что кэш работает
Загрузите страницу и проверьте заголовки ответа на статус кэша (HIT/MISS) и возраст (age). Повторный запрос к тому же URL должен вернуть HIT, отданный с edge. Используйте отчёты панели, чтобы наблюдать, как растёт коэффициент попаданий по мере прогрева edge.
Делайте purge при изменении контента
После деплоя или редактирования контента очистите (purge) затронутые URL — или всё сразу — через панель или purge API, чтобы посетители сразу получали новую версию, а не ждали истечения TTL.
Примеры сценариев
Новостной или блог-сайт отдаёт изображения, CSS и JavaScript с edge с длинными TTL, резко снижая трафик на origin и сокращая время загрузки страниц для читателей вдали от 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 или AVIF исходные файлы изображений?
Нет. Конвертация происходит в пути доставки, а сохранённые оригиналы не затрагиваются. Браузеры, принимающие AVIF или WebP, получают сконвертированную копию, остальные — изображение в исходном формате, а если конвертация не удалась, edge отдаёт оригинал. URL изображений в вашем HTML остаются прежними.
Что произойдёт, если мой origin-сервер выйдет из строя?
Всё, что уже закэшировано на edge, продолжает отдаваться посетителям в течение окна TTL, поэтому кратковременный сбой origin не обязательно выводит статический контент офлайн. Запросы к некэшированным или устаревшим объектам всё же потребуют origin, что ещё одна причина держать TTL щедрыми для стабильных ресурсов.
Нужно ли переносить файлы, чтобы использовать CDN?
Не в модели Pull. Вы сохраняете существующий origin-сервер и меняете только DNS, чтобы edge оказался перед ним, забирая и кэшируя контент по требованию. Push-хранилище опционально и полезно, когда вы хотите, чтобы edge отдавал медиа вообще без origin.