Расширенный прогрев
Временные окна, многорегиональный прогрев, рендеринг в браузере/SSR и мобильные user agent’ы.
12 min read
Четыре возможности для настроек, которые не охватываются обычным ежечасным сканированием HTTP. Все они ограничены планом — если какой-либо из них отсутствует в вашей форме, он не включается в вашу подписку.
Окна теплого графика
По умолчанию активный warmer запускает новый запуск каждый интервал автозапуска круглосуточно. Окна расписания ограничивают это выбранными вами часами.
За пределами окна запланированные автозапуски пропускаются. Запуск вручную, триггеры развертывания и действия по очистке и разогреву CDN по-прежнему работают — расписание управляет окном, а не warmer в целом.
Почему вам это нужно
- Сильно согрейтесь перед пиком. Набирайте темп за несколько часов до самого загруженного периода, чтобы к моменту остановки пробок все было жарко.
- Отключитесь на ночь. Сохраните бюджет запроса и загрузку источника, когда никто не посещает.
- Защитите окна обслуживания. Не допускайте нагревания во время резервного копирования, миграции или пакетных заданий.
- Соблюдайте редакционный ритм. В новостях часто бывает жарко перед утренним чтением.
Формат JSON
Поле теплого расписания принимает объект JSON с часовым поясом и списком окон:
{
"timezone": "Europe/Amsterdam",
"windows": [
{ "days": [1, 2, 3, 4, 5], "startHour": 8, "endHour": 20, "intensity": 1 }
]
}| Поле | Значение |
|---|---|
timezone | Название часового пояса IANA, например Europe/Amsterdam, America/New_York или UTC. Окна оцениваются в этой зоне, поэтому переход на летнее время осуществляется за вас. |
windows | Список временных окон. Пробежки разрешены внутри любого из них. |
days | Дни недели, к которым относится окно, где 1 — понедельник, а 7 — воскресенье. |
startHour | Час открытия окна: 0–23. |
endHour | Час закрытия окна: 0–23. |
intensity | Относительное усилие согревания за окном. 1 нормально; более низкое значение нагревает мягче. |
{
"timezone": "Europe/Amsterdam",
"windows": [
{ "days": [1, 2, 3, 4, 5], "startHour": 6, "endHour": 10, "intensity": 1 },
{ "days": [1, 2, 3, 4, 5, 6, 7], "startHour": 0, "endHour": 5, "intensity": 0.3 }
]
}Убедитесь, что окно достаточно широкое, чтобы закончить
Если полный проход занимает три часа, а ваше окно — два, прогоны будут сокращены, а последующие URL-адреса никогда не будут активированы. Либо расширьте окно, либо поднимите предел скорости, либо сузьте область действия warmer.
Tip
Оставьте поле пустым, чтобы оно согревалось круглосуточно. Это правильный выбор для большинства сайтов — добавляйте окна только в том случае, если у вас есть конкретная причина.
Многорегиональное потепление
Большинство CDN кешируют независимо в каждой точке присутствия. Страница, полученная из Европы, заполняет европейский пограничный узел — она ничего не дает посетителю в Сингапуре, который попадает на другой POP, который никогда не обслуживал эту страницу.
Многорегиональное потепление запускает warmer от выбранного регионального экземпляра сканера, поэтому географически распределенные кеши фактически заполняются там, где находится ваша аудитория. Он задается с помощью поля Регион сканирования и является возможностью бизнес-плана.
Когда вам это нужно
- У вас значимый трафик на более чем одном континенте.
- Ваш CDN кешируется по POP или по регионам, а не глобально.
- Вы предоставляете локализованный контент из региональных источников.
- Вы запускаете настройку с несколькими CDN, поведение которой зависит от географического положения.
Если почти все ваши посетители находятся в одной стране, один регион — это нормально, а наличие нескольких регионов увеличивает затраты без выгоды.
Потепление из большего числа регионов увеличивает количество запросов
Каждый регион отправляет свои собственные запросы, поэтому покрытие трех регионов примерно утроит объем запросов — как по вашему источнику, так и по бюджету URL-адресов вашего плана. Соответствующим образом определите пределы ставок.
Выбирайте регионы исходя из своей фактической аналитики, а не стремлений. Прогрев региона, который генерирует два процента вашего трафика, редко стоит тройного увеличения бюджета запроса.
Потепление браузера/SSR
Простая выборка HTTP извлекает HTML, возвращаемый сервером. Для большинства сайтов это именно то, что кешируется, и это все, что вам нужно.
Некоторые стеки отличаются. Если интересующий вас уровень кеша заполняется только после полного рендеринга — интерфейс с большим количеством JavaScript или фреймворк, кеш которого заполняется при полной навигации, а не при необработанном запросе — простая выборка не принесет ничего полезного.
Прогрев браузера/SSR использует реальный движок браузера для правильной загрузки страницы. Это возможность бизнес-плана, включенная в warmer.
| Используйте простое HTTP-потепление, когда… | Используйте подогрев браузера, когда… |
|---|---|
| Ваш сервер возвращает полный HTML | Страница собрана на стороне клиента |
| CDN или кеш страниц хранят ответ. | Кеш заполняется только после полного рендеринга. |
| Вам нужна максимальная пропускная способность за небольшие деньги | Правильность важнее объема |
| Большинство статических и традиционных сайтов CMS | Маршруты в стиле приложения SSR/ISR, которые не заполняются |
Нагрев браузера гораздо тяжелее
Рендеринг страницы в браузере требует гораздо больше времени и ресурсов, чем ее получение. Используйте его выборочно для маршрутов, которые действительно в нем нуждаются, и сохраняйте легкое потепление HTTP для всего остального. Не переводите весь большой warmer в режим браузера, не снизив предел скорости.
Практический тест: сначала запустите обычный HTTP warmer. Если Состояние кеша показывает, что эти маршруты все еще холодны, а остальная часть вашего сайта улучшается, стоит попробовать прогреть браузер.
Мобильное утепление
Если ваша CDN меняет свою кешированную копию в зависимости от пользовательского агента или вы обслуживаете отдельные мобильные шаблоны, прогрев только с помощью настольного агента оставляет посетителей с телефона в холодном кеше — обычно большую часть вашего трафика.
Включите Теплую мобильную версию, чтобы также сканировать с помощью мобильных пользовательских агентов. В планах, которые это позволяют, вы также можете предоставить свои собственные мобильные пользовательские агенты для точного контроля.
- Важно, если ваш ключ кеша включает пользовательский агент или класс устройства.
- Важно, если вы обслуживаете отдельную мобильную тему или субдомен
m.. - В этом нет необходимости, если вы предоставляете одинаковый адаптивный HTML-код для всех устройств — одна кешированная копия уже обслуживает всех.
Note
Увеличение количества вариантов для ПК и мобильных устройств примерно удваивает объем запросов, поскольку каждый URL-адрес извлекается под обоими агентами. Проверьте ограничения скорости и спланируйте бюджет, прежде чем включать его на большом сайте.
Пользовательские агенты пользователя
Поле Пользовательские агенты позволяет точно указать, с какими строками агентов будут отправляться запросы. Причины, по которым вы можете:
- Ваш CDN использует в своем кеше определенные строки агента, и вам необходимо точно их сопоставить.
- Фильтр ботов блокирует неизвестных агентов, и вы внесли в список разрешенных определенный агент.
- Вы хотите, чтобы теплые запросы идентифицировались в журналах вашего сервера, чтобы отделить их от реального трафика.
Tip
Хорошей практикой является использование отличительного, идентифицируемого пользовательского агента для обогрева. Благодаря этому трафик Cache Rocket становится очевидным в вашей аналитике и журналах доступа, а его легко исключить из отчетов.