Если после повторного визита сайт WordPress всё равно грузит одни и те же изображения, стили и скрипты заново, проблема часто не в самом кешировании страниц, а в заголовках браузерного кеша. Именно они подсказывают браузеру, можно ли взять файл из локального кеша или нужно снова обращаться к серверу. Для статических файлов это один из самых практичных способов ускорить повторные посещения и улучшить поведение в PageSpeed Insights.
Но здесь легко ошибиться: слишком короткий срок кеширования заставит браузер постоянно перезапрашивать файлы, а слишком длинный — может помешать быстро увидеть обновления после правок. Поэтому важно понимать, чем отличаются Cache-Control и Expires, где их лучше задавать и как не сломать обновление CSS и JS.
Что именно дают Cache-Control и Expires
Оба заголовка относятся к браузерному кешу, а не к кешу страниц, object cache или CDN. Это разные уровни оптимизации. Кеш страницы ускоряет отдачу HTML, object cache помогает базе данных и PHP, CDN раздаёт контент ближе к пользователю, а Cache-Control и Expires управляют тем, как браузер хранит отдельные файлы на стороне посетителя.
Expires — более старый механизм. Он задаёт конкретную дату и время, до которых файл считается свежим. Cache-Control — современный и более гибкий заголовок. Он позволяет указать срок жизни в секундах через директиву max-age, а также дополнительные правила поведения.
На практике сейчас обычно используют Cache-Control как основной заголовок, а Expires добавляют для совместимости со старыми клиентами и некоторыми конфигурациями серверов. Если задать оба заголовка, они должны быть согласованы, иначе браузер может ориентироваться на более строгие правила.
Какие файлы WordPress имеет смысл кешировать надолго
Долго кешировать стоит только то, что меняется редко и не зависит от пользователя:
- изображения:
.jpg,.jpeg,.png,.webp,.avif,.gif; - стили:
.css; - скрипты:
.js; - шрифты:
.woff,.woff2; - иконки и другие статические ассеты.
Не стоит бездумно применять длинный срок кеширования к HTML-страницам, страницам входа, личному кабинету, корзине, оформлению заказа и любым URL, где содержимое зависит от авторизации или сессии. Для таких страниц нужен другой подход, а иногда кеширование вообще нужно отключать.
Какие значения обычно ставят для статических файлов
Для обычного информационного сайта разумно использовать длительный срок кеширования для версионированных статических файлов. Часто применяют срок от нескольких недель до года. Если файлы подключаются с версией в URL, например style.css?ver=1.2.3, длинный кеш безопаснее: при обновлении версии браузер увидит новый адрес файла и загрузит его заново.
Если версия в URL не меняется, слишком длинный срок кеширования может привести к тому, что посетитель увидит старый CSS или JS до истечения срока или до принудительной очистки кеша. Поэтому на практике лучше не полагаться только на заголовки, а ещё и версионировать файлы при обновлениях темы, плагинов или кастомного кода.
Для файлов, которые часто меняются без смены имени, длинный кеш использовать рискованно. Это типичная причина, когда после правки стили на сайте «не обновляются», хотя на сервере уже лежит новая версия файла.
Как настроить заголовки на сервере
Способ настройки зависит от веб-сервера и доступа к конфигурации хостинга. В WordPress сам по себе плагин кеширования не всегда управляет заголовками для статических файлов: часто это делает сервер или CDN. Поэтому сначала проверьте, где именно у вас обслуживаются файлы.
Apache: через .htaccess
Если сайт работает на Apache и хостинг разрешает .htaccess, можно задать заголовки через модуль mod_expires и mod_headers. Перед изменением файла сделайте резервную копию: ошибка в .htaccess может привести к 500-й ошибке и недоступности сайта.
Пример для статических файлов:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(jpg|jpeg|png|gif|webp|avif|css|js|woff|woff2)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
</IfModule>Здесь max-age=31536000 — примерно один год в секундах. Директива immutable полезна для версионированных файлов: она сообщает браузеру, что в течение срока жизни файла не нужно лишний раз перепроверять его на сервере.
Но immutable стоит использовать только тогда, когда вы действительно меняете URL файла при обновлении. Если файл остаётся по тому же адресу, это может затянуть показ старой версии.
Nginx: через конфигурацию сервера
На Nginx такие заголовки обычно задают в конфигурации сайта или на уровне сервера. На shared-хостинге доступ к этому может быть закрыт, и тогда нужно обращаться в поддержку хостинга. Пример конфигурации:
location ~* \\.(jpg|jpeg|png|gif|webp|avif|css|js|woff|woff2)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000";
}Если вы используете CDN, часть заголовков может переопределяться на его стороне. Тогда проверять нужно не только origin-сервер, но и ответ CDN.
Когда Expires достаточно, а когда лучше опираться на Cache-Control
Если говорить практично, Cache-Control — более гибкий и предпочтительный вариант. Он лучше подходит для современных браузеров и даёт больше контроля. Expires полезен как дополнительный заголовок, но сам по себе он менее удобен, потому что завязан на конкретную дату.
Для WordPress-сайта обычно достаточно такой логики:
Cache-Control— основной заголовок для срока жизни и поведения кеша;Expires— дополнительный заголовок для совместимости;- долгий срок кеширования — для изображений, CSS, JS и шрифтов;
- версионирование файлов — обязательная часть схемы, если вы хотите безопасно кешировать надолго.
Если у вас уже настроен CDN, он может сам выставлять свои правила кеширования. В этом случае не стоит дублировать конфликтующие настройки на сервере без понимания приоритета заголовков.
Как это связано с PageSpeed и повторными визитами
PageSpeed Insights часто показывает предупреждения о слишком коротком сроке кеширования статических ресурсов. Это не означает, что сайт обязательно медленный в целом, но указывает на лишние повторные загрузки при повторных визитах. Для пользователя это выражается в том, что браузер снова тратит время и трафик на уже знакомые файлы.
При этом одними заголовками нельзя решить все проблемы производительности. Если сайт тяжёлый из-за больших изображений, лишнего JavaScript, медленного хостинга, большого количества внешних запросов или неоптимального CSS, правильный кеш браузера лишь частично улучшит картину. Он помогает именно с повторной загрузкой статических файлов, а не заменяет оптимизацию кода и медиаконтента.
Что проверить после настройки
После изменения заголовков важно убедиться, что они реально применились. Самый простой способ — открыть страницу в браузере, перейти в инструменты разработчика и посмотреть ответ файла во вкладке Network. У нужного ресурса должны быть видны Cache-Control и, если вы их задали, Expires.
Ещё полезно проверить заголовки через команду curl, если у вас есть доступ к терминалу:
curl -I https://example.com/wp-content/themes/your-theme/style.cssВ ответе ищите строки вроде Cache-Control: public, max-age=... и Expires: .... Если заголовков нет, значит настройка не сработала на том уровне, где вы её вносили, или их перезаписывает другой слой — плагин, CDN либо конфигурация хостинга.
Типичные ошибки, которые потом мешают обновлять сайт
Самая частая ошибка — поставить длинный кеш на файл без версионирования и потом удивляться, что изменения не видны. Вторая по частоте — пытаться кешировать всё подряд, включая страницы, которые должны быть динамическими. Третья — настраивать заголовки в нескольких местах сразу: в плагине, в .htaccess, на CDN и в панели хостинга. В таком случае итоговое поведение зависит от того, кто последний переписал ответ.
Если вы используете плагин оптимизации вроде Clearfy Pro, его удобно применять для сопутствующей технической чистки сайта и уменьшения лишнего служебного кода, но не стоит ожидать, что он сам по себе правильно настроит серверные заголовки для всех статических файлов. Для этого всё равно важны настройки веб-сервера и, при необходимости, CDN. Подробности и инструменты можно посмотреть на wpshop.ru.
Если сайт часто меняется, а обновления должны появляться сразу после публикации, продумайте процесс очистки кеша: после смены темы, обновления плагинов, замены изображений или правок CSS/JS нужно сбрасывать не только кеш страницы, но и учитывать браузерный кеш, если файл не получил новый URL. Для магазинов, личных кабинетов и сайтов с авторизацией это особенно важно: там неправильная настройка может привести к показу устаревших данных или некорректному поведению интерфейса.
В итоге рабочая схема выглядит так: долго кешируем только статические файлы, используем Cache-Control как основной заголовок, добавляем Expires при необходимости, версионируем ресурсы и проверяем результат на реальных ответах сервера. Именно это даёт пользу для повторных визитов и помогает убрать лишние замечания в PageSpeed без риска сломать обновления сайта.