Как очистить кэш CDN, не сломав сайт

Почему edge всё ещё отдаёт старый файл

Когда посетитель запрашивает файл, ближайшая edge-точка проверяет, есть ли у неё действительная копия. Если есть — она отвечает сразу, не обращаясь к вашему серверу; в этом весь смысл CDN и причина, по которой ваш сайт быстрый. Как долго копия считается «действительной», определяют заголовки кэширования, которые ваш источник отдал, когда edge впервые забрал файл, чаще всего Cache-Control: max-age.

Поэтому, когда вы загрузили новую версию, а видите старую, ничего не сломано. Вы поменяли файл на источнике, но edge всё ещё находится внутри окна, на которое вы сами велели ему хранить предыдущую копию. Выходов три: подождать истечения, очистить кэш сейчас или опубликовать под новым URL, чтобы устаревшему нечего было отдавать. Чему отдать предпочтение — об этом всё оставшееся руководство.

Точная, префиксная, вариантная — берите наименьший молоток

Точная очистка удаляет один конкретный URL. Это правильный вариант по умолчанию: вы заменили /images/hero.jpg — значит, пуржите /images/hero.jpg. Точно, мгновенно, всё остальное остаётся прогретым.

Префиксная очистка удаляет всё, что лежит под путём: /assets/ очищает каждый файл ниже. Используйте её после деплоя, переписавшего целый каталог. Инструмент мощный, поэтому целиться нужно аккуратно: очистка /images/ из-за одного изменившегося логотипа выбрасывает тысячи полезных закэшированных объектов.

Вариантная очистка удаляет каждую закэшированную версию одного ключа. Когда ваш источник отправляет заголовок Vary, edge может держать несколько копий одного URL, по одной на каждое значение этого заголовка — например, под разные устройства, — и если вы заменили исходный файл, вам нужно, чтобы исчезли все, а не только та, что совпала с вашим собственным браузером. Именно этот вариант упускают, когда пурдж «не сработал» для части посетителей, но сработал для вас самих.

Те же три варианта из командной строки

# one URL (the usual case)
cdnctl purge --account <uuid> --path /images/hero.jpg

# several at once
cdnctl purge --account <uuid> --paths "/css/app.css,/js/app.js"

# everything under a folder
cdnctl purge --account <uuid> --path /assets --type prefix

# every cached variant of one key
cdnctl purge --account <uuid> --path /index.html --type variants

# save this list to re-run after future deploys
cdnctl purge --account <uuid> --paths "/,/sitemap.xml" --save

Когда очищать всё (и чего это стоит)

Очистка кэша всего аккаунта уместна после изменения, затронувшего весь сайт: редизайн, правка шаблона, отражающаяся на каждой странице, миграция CMS. Это одна команда, и она честна в том, что делает: исчезает всё.

Сначала осознайте цену. Какое-то время после полной очистки edge не держит ничего, поэтому запросы, на которые раньше отвечали рядом с пользователем, идут к вашему источнику. Сайт, который спокойно отдаёт десять запросов в секунду за кэшем, вдруг может встретить их все сразу. На небольшом источнике это разница между «быстро» и «еле дышит». Именно потому, что инструмент намеренно грубый, CLI требует подтверждения.

Явное подтверждение обязательно — и это сделано специально

# clear the whole account cache
cdnctl purge all --account <uuid> --yes

# watch it complete
cdnctl purge all status --account <uuid>

Пурдж, который вам никогда не придётся делать

Лучшая стратегия инвалидации — не нуждаться в ней. Если имя файла меняется всякий раз, когда меняется его содержимое — app.a1b2c3.js, style.9f8e7d.css, — то деплой публикует новые URL. Старые всё ещё закэшированы, безвредны и ни на что не ссылаются; новые не кэшировались никогда, поэтому каждый посетитель мгновенно получает новую версию. Любой современный сборщик делает это за вас, и именно поэтому кэширование статики можно безопасно ставить на год.

Остаются файлы, чьи имена измениться не могут: ваши HTML-страницы, /sitemap.xml, robots.txt, JSON-фиды. Задайте им короткий max-age, чтобы они обновлялись сами, и пуржите их явно, когда изменение должно стать видимым немедленно. На практике в здоровой схеме после деплоя очищается несколько путей, а не тысячи.

Почему кажется, что пурдж не сработал

Почти каждое сообщение «очистка ничего не дала» — это одно из четырёх, и ни одно из них не о том, что edge ошибся.

Ваш собственный браузер тоже закэшировал файл. Cache-Control действует и на браузер: на edge уже свежая версия, а на вашем ноутбуке нет. Прежде чем эскалировать, проверьте в приватном окне или с добавленным к URL параметром.

Вы очистили не тот URL, который отдаётся. /page и /page/ могут быть разными ключами кэша, как и версии по http и https или URL с добавленными параметрами отслеживания. Пуржите тот URL, который на самом деле запрашивают пользователи.

Вы очистили один вариант. Когда ваш источник отправляет заголовок Vary, копии одного URL, которые он различает, — разные записи; если часть посетителей видит новую версию, а часть нет, пуржите с типом variants.

Или источник снова отдал старый файл. Пурдж лишь говорит edge забыть копию; следующий запрос заново забирает файл с вашего сервера. Если кэш вашего приложения или плагина всё ещё держит старую страницу, edge добросовестно закэширует устаревшую копию снова. Сначала очистите кэш приложения, затем пуржите edge.

Сделайте это частью деплоя, а не тем, что нужно помнить

Ручная очистка после каждого релиза — шаг, который кто-нибудь однажды забудет, обычно на самом важном релизе. Положите его в пайплайн: после успешного деплоя запускайте пурдж для тех немногих путей, чьи имена никогда не меняются. На cdn.com.tr это можно сделать из панели, через REST API или с помощью cdnctl в CI-задаче — команда одна и та же, запускается она из вашего терминала или из раннера. Сохранённые списки путей (--save) превращают это в однострочник, который вы храните, вместо списка, который приходится набирать заново.