Разделить ресурсы по содержимому
Разработчик условного сайта начинает с файлов, одинаковых для всех посетителей. Проверяет, меняется ли ответ в зависимости от авторизации, корзины, параметров запроса или языка. Название каталога само по себе не доказывает публичность его содержимого.
Персональные страницы и динамические операции остаются вне выбранной области. Задача сценария — уменьшить повторные обращения за подходящими файлами, сохранив корректность приложения.
Проверить указания исходного сервера
Для выбранных файлов проверяются правила хранения и варианты ответа. Настроенный предел свежести не должен превращаться в разрешение игнорировать приватность или срок, заданный origin.
Отдельно проверяются cookies, авторизация и Set-Cookie. Защита различает служебные cookies Guard и пользовательскую сессию приложения. Файл, подходящий по пути, всё равно может не подлежать кешированию по другим условиям.
- Содержимое публичного ресурса действительно одинаково для сравниваемых запросов.
- Заголовки хранения соответствуют ожидаемому сроку обновления.
- Параметры запроса, влияющие на содержимое, не теряются.
- Ответ с персональными данными не становится общим из-за выбора каталога.
Включить область и проверить реальные ответы
В кабинете выбирается точный ресурс или каталог публичных файлов. При необходимости включается доступное сжатие. После публикации проверяют подтверждение настроек узлами и содержимое ответов.
- Откройте выбранный файл при первом и повторном запросе, сравните содержимое и наблюдаемое обращение к origin.
- Проверьте варианты с параметрами запроса и согласование сжатия браузером.
- Войдите в разные тестовые аккаунты и убедитесь, что персональные страницы не смешиваются.
- Измените тестовый публичный ресурс и проверьте выбранный способ обновления.
- Проверьте обычные динамические операции отдельно от кешируемых файлов.
Предусмотреть обновление до первого выпуска файлов
Для статических сборок удобно использовать новые адреса изменённых файлов. Если ресурс остаётся по прежнему URL, его свежесть зависит от заголовков и выбранной очистки.
Очистка отдельного URL имеет границу: заполнение, начатое раньше, может завершиться позже. Очистка сайта меняет поколение и отсекает такие заполнения на узлах. Копия в браузере посетителя при этом не стирается; её обновление определяется адресом и HTTP-условиями.
Что измерить для вывода об ускорении
Сравнивают загрузку одинаковой страницы, объём передачи и обращения к origin при сопоставимых условиях. Первую загрузку и повторные обращения анализируют отдельно. Разница на одном быстром файле не описывает весь пользовательский путь.
Динамические страницы, формы и API тоже проверяют на ошибки и задержку. Улучшение отдачи статики не должно скрывать проблему в остальных запросах.
Границы примера
В этой модели нет реального клиентского сайта, измеренной доли попаданий или процентов ускорения. Их можно получить только после проверки конкретной конфигурации.
Кеш и сжатие не преобразуют изображения в новые форматы, не исправляют медленный запрос к базе приложения и не означают наличие глобальной CDN. Для каждой такой задачи требуется отдельное решение.
Вопросы и ответы
Можно ли добавить каталог и больше ничего не проверять?
Нет. Выбор пути задаёт область, но не подтверждает публичность всех ответов. Нужно проверить данные, заголовки, cookies и варианты содержимого.
Очистка URL гарантирует мгновенное обновление у всех?
Нет. Есть уже начатые заполнения кеша и независимые копии в браузерах. Способ обновления нужно выбирать с учётом этих границ.
Какое ускорение показал этот пример?
Никакое численное ускорение здесь не заявлено: это вымышленный сценарий проверки. Эффект измеряется на реальном сайте.