Перейти к содержимому 
Я использую хостинг для управления кэшем, чтобы контролировать, как браузеры, прокси-серверы и CDN кэшируют контент, чтобы страницы загружались быстрее и оставались актуальными. Для этого я использую целевые директивы такие как max-age, no-cache или no-store, и таким образом сбалансировать производительность, свежесть и нагрузку на сервер для HTML, активов и API.
Центральные пункты
В следующем обзоре представлены наиболее важные рычаги для Веб-оптимизация с контролем кэша.
- Конструкция TTLДлительный max-age для активов, короткое время или ревалидация для HTML.
- ВалидацияETag и Last-Modified сокращают трафик данных при использовании ответов 304.
- Управление краями: s-maxage, stale-while-revalidate и stale-if-error для CDN.
- Версионирование: Имена файлов с хэшем/версией позволяют использовать агрессивные кэши.
- МониторингПостоянно проверяйте частоту попадания в кэш, 304 квоты и TTFB.
Что делает контроль кэша таким эффективным в хостинге?
Я переношу работу с сервера Origin на Кэш, уменьшают задержку и экономят пропускную способность. Правильно настроенный заголовок управления кэшем определяет, как долго файлы остаются действительными и когда клиент запрашивает их у сервера. Я планирую длительные периоды действия для таких активов, как изображения, CSS и JS, в то время как HTML живет короткое время или всегда подтверждается. Это означает, что пользователи чаще сталкиваются с кэшированными ответами и при этом получают актуальный Содержание. Я избегаю типичных камней преткновения, таких как противоречивые заголовки или отсутствие версий, на ранних этапах, например, с помощью этого Руководство по исправлению кэша.
Основы: правильное комбинирование директив
С max-age Я задаю время жизни в секундах, например 31536000 на один год для статических ресурсов. no-cache заставляет клиента проверять перед использованием, но не запрещает хранение. no-store исключает любое хранение и защищает чувствительные ответы, такие как платежные данные. public позволяет кэшировать в общие хранилища, такие как CDN, private ограничивается кэшем браузера. immutable сигнализирует, что файл остается неизменным, что может быть изменено с помощью Версионирование (например, app.v1.2.js) являются отличным дополнением.
Четко определите заголовки Vary и ключи кэша
Я убеждаюсь, что кэшированные объекты соответствуют типу запроса. Сайт VaryПоэтому -заголовок должен присутствовать в каждой серьезной стратегии кэширования. Он влияет на ключ кэша и предотвращает неправильное повторное использование:
- Принять кодированиеОбязательно для gzip/br, чтобы сжатые и несжатые варианты кэшировались отдельно.
- Accept-Language: Используется только в том случае, если я действительно предоставляю содержимое, зависящее от языка - в противном случае есть риск фрагментации.
- Печенье: Я избегаю глобального Передача: Cookie, потому что это разрушает показатели попадания в кэш. Вместо этого я сегментирую их по релевантным кукам (например, A/B-вариант) или удаляю нерелевантные куки на границе.
- АвторизацияКонтент, зависящий от заголовков auth, не хранится в общих кэшах, или я намеренно делаю их ключевыми, если провайдер CDN поддерживает это.
# Apache: значимые заголовки Vary для HTML и активов
Слияние заголовков Vary "Accept-Encoding"
</FilesMatch
Слияние заголовков Vary "Accept-Encoding"
Я также определяю правила четкого кэш-ключа для CDN: Я не включаю в ключ параметры запроса, которые используются только для отслеживания (например, utm_*). Это предотвращает взрыв ключей без ущерба для свежести.
Практика: Конфигурация на Apache и Nginx
На Apache я устанавливаю правила в хтакесс или на виртуальном хосте. Я отделяю HTML от активов, даю статическим файлам долгий срок жизни и защищаю HTML с помощью ревалидации. Я избегаю конфликтов с заголовками Expires, современные браузеры в первую очередь уважают контроль кэша. На Nginx я слежу за правильным расположением add_header и убеждаюсь, что никакие последующие инструкции не перезаписывают их. Вот как я контролирую Кэширование браузера согласованно по всему стеку.
.
Набор заголовков Cache-Control "public, max-age=31536000, immutable"
</FilesMatch
Набор заголовков Cache-Control "no-cache, must-revalidate"
location ~* \.(css|js|png|jpg|svg|woff2)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
location ~* \.(html)$ {
add_header Cache-Control "no-cache, must-revalidate";
}
Кэширование HTML только в CDN
Если браузер должен всегда проверять, но Edge разрешено кэшировать, я устанавливаю разное время жизни для клиента и CDN:
# Apache: Браузер перепроверен, Edge кэширован 5 минут
.
Набор заголовков Cache-Control "public, max-age=0, s-maxage=300, must-revalidate, stale-while-revalidate=30, stale-if-error=86400"
Слияние заголовков Vary "Accept-Encoding"
</FilesMatch
# Nginx
location ~* \.(html)$ {
add_header Cache-Control "public, max-age=0, s-maxage=300, must-revalidate, stale-while-revalidate=30, stale-if-error=86400";
add_header Vary "Accept-Encoding";
}
Проверка: эффективное использование ETag и Last-Modified
Я сочетаю Управление кэшем с ETag и Last-Modified для контролируемой перепроверки. После истечения срока действия браузер отправляет If-None-Match или If-Modified-Since; сервер отвечает 304, если ресурс не изменился. Это экономит байты и значительно сокращает процессорное время в Origin. Важно: ETags должны быть последовательными, иначе будут происходить ненужные пропуски, несмотря на неизменное содержимое. На кластерах я деактивирую слабые ETag или создаю сильные хэши, чтобы ревалидация остается надежным.
Согласованность в многосерверных средах
Я слежу за тем, чтобы ETags не основывались на inode-функциях, которые различаются между узлами. Я либо предоставляю стабильный хэш (артефакт сборки), либо полагаюсь на last-modified, когда развертывание происходит атомарно. Для динамических ответов я использую ETags приложения, которые точно соответствуют хэшу полезной нагрузки. Если перепроверка обходится дороже, чем повторный рендеринг, я намеренно отвечаю 200 и коротким TTL - все решает измерение.
Стратегии по типам ресурсов
Я различаю их по типу содержимого, потому что HTML, активы, API и чувствительные ответы имеют разное содержание. Требования. Длинные TTL для версионных файлов обеспечивают наилучшие показатели, в то время как HTML должен оставаться жестко управляемым. Я планирую короткое время жизни API и закладываю в них отказоустойчивость. Я не допускаю хранения личных или конфиденциальных ответов. Тем, кто углубляется в интерфейсы, полезны компактные паттерны для Кэширование API в хостинге, который я адаптирую к характеристикам ответа.
| Тип ресурса | Рекомендуемая директива | Причина |
|---|---|---|
| Статические активы (изображения, CSS, JS) | public, max-age=31536000, immutable | Длительное хранение; предотвращение версионирования Стале-Содержание |
| Страницы HTML | no-cache, must-revalidate | Свежий контент благодаря ревалидация |
| API | публичный, max-age=300, stale-if-error=86400 | Короткий срок, можно использовать для Ошибки |
| Чувствительные данные | без магазина | Не хранить с Защита данных-Причины |
Коды состояния, перенаправления и страницы ошибок
- 301 можно и нужно кэшировать (длинный TTL), поскольку они постоянны. Я версифицирую целевые URL, чтобы облегчить последующие изменения.
- 302/307 временные - короткий TTL или повторная проверка, иначе есть риск появления неправильных путей в кэше.
- 404 Я кэширую на короткое время (например, 60-300 с), чтобы ошибочные хотлинки не нагружали Origin, не блокируя реальные воссоздания.
- 500+ Я не кэширую, но оставляю Edge stale-if-error чтобы предоставить пользователям самую свежую информацию.
Расширенные директивы для CDN и Edge
С s-maxage Я разделяю время жизни в пограничном кэше и в браузере. stale-while-revalidate продолжает доставлять просроченный контент, пока пограничный кэш обновляется в фоновом режиме. stale-if-error сохраняет доступность страниц во время сбоев в работе бэкенда и повышает конверсию и доверие. must-revalidate заставляет проверять содержимое после истечения срока действия и предотвращает нежелательные обновления. Этот контроль напрямую влияет на показатели попадания в кэш и Масштабирование Особенно в пиковые моменты движения.
Суррогатные и краевые заголовки
В установках с рендерингом краев я также использую суррогатные заголовки (например. Суррогатный контроль), чтобы установить более специфичные для CDN TTL и политики "замирания" без изменения поведения браузера. Таким образом, я строго разделяю конечного пользователя и пограничную стратегию и сохраняю контроль над обоими уровнями.
Инвалидизация и освобождение
Я планирую аннулирование сознательно: версионные активы редко нуждаются в чистке, в то время как HTML и API-маршруты требуют ее чаще. Я определяю четкие процедуры для:
- Очистка по URL/шаблону для исправлений и ошибок.
- Очистка на основе меток (если поддерживается) для аннулирования тематически связанного содержимого.
- Поэтапное развертываниеСначала разверните активы, а затем HTML с новыми ссылками - это предотвратит появление неработающих ссылок.
WordPress: внедряйте кэширование безопасно
В WordPress я активирую заголовки с помощью плагинов или собственного кода и наблюдаю за тем. Шаблон-структура. Статические файлы в wp-includes и uploads получают длинные TTL плюс immutable, страницы - no-cache с must-revalidate. Осторожно с залогиненными пользователями: приватные и дифференцированные куки предотвращают неправильную персонализацию в кэше. Я устраняю типичные камни преткновения с помощью четких правил и взгляда на эти Ошибка кэширования WordPress. При необходимости я добавляю кэширование страниц на стороне сервера и OPCache, чтобы сделать выполнение PHP более заметным. уменьшается.
<?php
функция add_cache_headers() {
if (!is_admin()) {
header('Cache-Control: public, max-age=31536000, immutable', true);
}
}
add_action('send_headers', 'add_cache_headers');
Откажитесь от персонализации и файлов cookie
Я убедился, что Set-Cookie не устанавливается на всех страницах. Лишние куки препятствуют общему кэшированию. Я доставляю их явно для вошедших в систему пользователей:
# Пример заголовка для сеансов входа в систему
Cache-Control: private, no-store, max-age=0
Vary: Accept-Encoding
Страницы списков и подробностей без персонализации, с другой стороны, получают всю мощь CDN. Там, где персонализация необходима, я работаю с краевыми фрагментами или небольшими полезными нагрузками API, а остальное агрессивно кэширую.
Распространенные ошибки и то, как я их исправляю
Слишком низкий TTL приводит к ненужной работе сервера и увеличению времени отклика. Отсутствующие или противоречивые заголовки заставляют браузеры применять эвристическое поведение и снижают производительность. Без версионности я рискую получить устаревшие активы, несмотря на длительное хранение в кэше. Различные стратегии ETag на нескольких серверах приводят к промахам; я обеспечиваю согласованность хэшей или отключаю ETag. Я также проверяю, есть ли у посредников, таких как шлюзы, свои собственные Заголовок и перезаписать.
Избегайте эвристического кэширования
Если ни Cache-Control, ни Expires не установлены, браузеры догадываются об этом. Поэтому я всегда отключаю явные директивы и устраняю унаследованные проблемы (например. Pragma: no-cache от старых прокси), чтобы добиться детерминированного поведения.
Строки запросов и очистка кэша
Я использую очистку кэша с помощью хэшей имен файлов (style.abc123.css), а не строк запросов. Многие кэши рассматривают различные запросы как отдельные объекты и тем самым увеличивают их количество; с другой стороны, при неизменных файлах новый хэш приводит к чистому аннулированию.
Мониторинг, тесты и метрики
Я измеряю эффекты и вношу целенаправленные коррективы, а не делаю радикальные изменения, потому что данные побеждают интуицию. очистить. Я использую curl для проверки заголовков, DevTools для симуляции первого и повторного просмотра и Lighthouse для оценки влияния на ключевые показатели. На стороне сервера и CDN я слежу за количеством попаданий в кэш, квотами 304, сохранением байтов и TTFB. Журналы показывают, действительно ли HTML перепроверяется и редко ли активы запрашиваются повторно. Это позволяет мне выявлять недостатки на ранних стадиях и улучшать их целевой.
Дополнительные диагностические сигналы
- Возраст-заголовок показывает, как долго объект находится в кэше - идеально подходит для проверки s-maxage.
- Состояние кэша (если доступно) показывает HIT/MISS/STALE и источник (BROWSER, CDN, ORIGIN).
- Время работы сервера Я использую его для собственных маркеров (например, cache;desc=“revalidated“), чтобы сделать пути видимыми в инструментах.
Я автоматизирую проверки в конвейере CI/CD: После каждого развертывания небольшой каталог тестов проверяет заголовки, коды состояния и размеры ответов для основных маршрутов. Регрессии замечаются сразу.
SEO и влияние на бизнес
Более быстрая доставка укрепляет Core Web Vitals, уменьшает количество отказов и повышает Видимость. Каждое предотвращенное путешествие туда и обратно снижает затраты на сервер и минимизирует риск пиковых нагрузок. При использовании сайтов с интенсивным трафиком я ежемесячно экономлю заметный объем данных; в зависимости от тарифа это может достигать трехзначных сумм в евро. Высокий коэффициент попадания в кэш также стабилизирует время отклика при проведении кампаний и продаж. Те, кто повышает производительность предсказуемым образом, обычно также увеличивают Конверсия.
Практический контрольный список в 7 шагов
(1) Проведите инвентаризацию файлов и отделите HTML, активы, API и чувствительные ответы; эти Сегментация облегчает соблюдение правил. (2) Внедрите версионность для CSS/JS/изображений; используйте хэши в именах файлов и устанавливайте неизменяемость. (3) Установите no-cache и must-revalidate для HTML; сохраняйте страницы свежими и контролируемыми. (4) Определите короткие TTL для API плюс stale-if-error для смягчения последствий сбоев. оставайтесь. (5) Активируйте ETag или Last-Modified последовательно; проверьте 304 квоты. (6) Синхронизируйте заголовки CDN и Origin; используйте s-maxage для Edge. (7) Измерьте количество попаданий, TTFB и экономию байтов; оптимизируйте итеративно и документируйте решения.
Дополнительные практические примеры и образцы
- API с условными запросамиЯ явно разрешаю GET/HEAD-ответы в общем кэше (публичном) с коротким TTL и ETag. Я кэширую POST-ответы, только если они точно определены и неизменны - по умолчанию они остаются некэшируемыми.
- Большие файлы и запросы на диапазон: Для СМИ Я доставляю Диапазон приема: байты и длинные TTL; Edge освобождает Origin от необходимости возобновлять загрузку.
- Отзывчивые изображенияЕсли я вывожу различные варианты изображения в зависимости от устройства, я задаю конкретные ключи (например, по DPR или Width) и избегаю неконтролируемой вариации на слишком большом количестве сигналов.
- Без преобразования: Если важно качество изображения или криптография, я использую Cache-Control: no-transform, чтобы прокси-серверы не изменяли ресурс.
Резюме на заметку
Я использую Cache-Control специально для того, чтобы Производительность, чтобы согласовать сроки и затраты. Длинные TTL плюс версионирование для активов, ревалидация для HTML и короткие сроки для API обеспечивают надежные результаты. ETag и Last-Modified снижают трафик данных, а политики s-maxage и stale используют краевое кэширование. Мониторинг делает эффект заметным и показывает, где мне следует подтянуться. Таким образом, хостинг становится быстрым, контролируемым и экономичным. привлекательный.
