Vercel добавил в Runtime‑логи причины кэширования
Теперь в Runtime‑логах Vercel показываются причины, почему запрос не попал в свежий кэш, что упрощает отладку и повышает hit‑rate.
Что изменилось?
Vercel объявил о новом обновлении платформы: Runtime logs теперь включают поле Cache Reason. Это небольшое, но очень полезное дополнение, которое объясняет, почему конкретный запрос не был обслужен из свежего кэша. Причины могут быть связаны с временной ревалидацией, тег‑базированной (tag‑based) ревалидацией, а также с другими директивами, задаваемыми в заголовках Cache‑Control.
Как это работает?
- Cache Reason появляется в логах для любого ответа, который может быть закеширован CDN Vercel. Это включает в себя ISR (Incremental Static Regeneration), Partial Prerendering и функции, использующие заголовки
stale-while-revalidate,max‑ageи пр. - Для полностью динамических ответов, которые генерируются при каждом запросе, поле Cache Reason не выводится – логика кэширования здесь не применяется.
- Пример записи:
Cache Status: REVALIDATED – Reason: time‑based (TTL expired).
Почему это важно?
- Улучшенная отладка: разработчики теперь могут быстро понять, почему конкретный запрос не попал в кэш, без необходимости вручную анализировать заголовки.
- Повышение hit‑rate: видя конкретные причины, команды могут оптимизировать стратегии ревалидации, менять TTL или использовать тег‑базированное управление кэшем.
- Поддержка всех кэшируемых сценариев: от ISR до пользовательских функций, что делает платформу более прозрачной.
Более подробно об обновлении можно прочитать в официальном блоге Vercel.
Для разработчиков, использующих Vercel в продакшене, новые «Cache Reasons» – это шанс быстрее находить узкие места кэширования и повышать эффективность доставки контента. Студенты курсов по сервер‑сайд рендерингу получат наглядный инструмент для практики оптимизации ISR. Главное – начать регулярно мониторить новые поля в логах и корректировать TTL/теги, иначе выгода может остаться незамеченной.
