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

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

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

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

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

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

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

Вариантная очистка удаляет каждую закэшированную версию одного ключа. 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, который на самом деле запрашивают пользователи.

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

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

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

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