Вы поменяли баннер на сайте в десять утра. Менеджер видит новый, дизайнер видит новый, а постоянный клиент в одиннадцать пишет: «У вас всё ещё старая акция». Через пять минут начинается традиционный корпоративный ритуал — кто-нибудь предлагает очистить кеш, перезагрузить компьютер и на всякий случай выключить чайник.
Именно для таких ситуаций стоит понимать browser cache. Это полезный механизм, который ускоряет повторную работу с сайтом, но при неудачной настройке способен сохранить у посетителя файл дольше, чем вы хотели.
Browser cache: что браузер сохраняет и зачем
Когда человек впервые открывает страницу, браузеру приходится получить HTML и связанные с ним файлы: стили CSS, JavaScript, изображения, шрифты. Часть этих ресурсов сервер разрешает сохранить локально. При следующем переходе браузер может взять уже знакомый файл с устройства, вместо того чтобы снова отправляться за ним через интернет.
Представьте обычный офис. Нет смысла каждый раз ехать на склад за степлером, если он уже лежит в ящике стола. Browser cache работает примерно так же. Проблема начинается, когда в ящике лежит инструкция трёхлетней давности, а сотрудники уверены, что это всё ещё актуальный регламент.
За правила хранения в основном отвечают HTTP-заголовки. Например, Cache-Control сообщает, можно ли сохранять ответ и как долго считать его свежим. ETag и Last-Modified помогают проверить, изменился ли ресурс, не скачивая его полностью без необходимости.
Важно не смешивать разные кеши. Browser cache находится у посетителя. Серверный page cache может хранить уже собранный HTML на сервере или CDN, а object cache в WordPress сохраняет результаты внутренних операций приложения. Все они называются кешем, но чинить один вместо другого — примерно как менять батарейку в пульте, когда телевизор вообще не подключён к розетке.
Как Browser cache связан с SEO на самом деле
У Browser cache нет волшебного свойства «прибавить три позиции». Он прежде всего сокращает ненужные сетевые запросы при повторных посещениях и переходах между страницами, где используются те же стили, скрипты, изображения и шрифты.
Это может быть полезно для пользовательского опыта и общей производительности сайта. Google учитывает Core Web Vitals среди сигналов, связанных с удобством страницы, но отдельно предупреждает: хорошие показатели не гарантируют высоких позиций. Поэтому нормальная логика здесь такая: кеширование нужно делать для пользователей и производительности, а не ради зелёной лампочки в отчёте.
Есть ещё одна важная деталь. Кеш обычного браузера пользователя и кеш системы рендеринга Google — не одно и то же. Google описывает, что его Web Rendering Service может самостоятельно сохранять CSS и JavaScript на срок до 30 дней, причём этот срок не определяется обычными HTTP-директивами кеширования сайта. Значит, настройка Cache-Control для браузеров не является способом приказать Googlebot чаще или реже загружать ресурс.
Browser cache также не заменяет другие задачи производительности. Если сервер долго формирует страницу, изображение весит четыре мегабайта, а JavaScript заставляет телефон задуматься о смысле жизни, большой max-age проблему первой загрузки не исправит. Здесь уже нужны более широкие работы по скоростным задачам технического SEO, оптимизации изображений, кода и сервера. По той же причине кеширование не заменяет сжатие gzip: это разные механизмы.
Как проверить Browser cache без глубокого погружения в сервер
Самая полезная проверка начинается не с плагина, а с воспроизведения проблемы. Если в обычном окне вы видите старую картинку, а после жёсткой перезагрузки или в чистом сеансе появляется новая, кеш становится первым подозреваемым. Это ещё не доказывает, что виноват именно Browser cache — между пользователем и сайтом может находиться CDN или другой уровень кеширования, — но область поиска уже резко сужается.
В Chrome откройте инструменты разработчика и вкладку Network. Опция Disable cache позволяет посмотреть страницу примерно глазами первого посетителя без использования браузерного кеша. Затем её можно отключить, повторить загрузку и сравнить поведение ресурсов. У конкретного CSS, JavaScript, изображения или шрифта полезно смотреть прежде всего Cache-Control, ETag, Last-Modified и то, был ли файл фактически получен по сети или использован локально.
Для быстрой серверной проверки необязательно ставить специальную программу. Заголовки конкретного ресурса можно запросить через терминал:
curl -I https://example.ru/wp-content/themes/site/assets/style.cssУсловно хороший ответ для версионированного статического файла может содержать:
HTTP/2 200
Cache-Control: public, max-age=31536000, immutable
ETag: "a84f..."max-age=31536000 разрешает считать этот конкретный ответ свежим до года. Но такое правило безопасно только тогда, когда при изменении файла меняется и его URL. ETag нужен для другой ситуации: браузер может спросить сервер, осталась ли сохранённая копия актуальной. Если ничего не изменилось, сервер способен вернуть HTTP-статус 304 Not Modified вместо повторной передачи всего файла.
Настройка без главной ошибки: не кешировать всё одинаково
Универсальное правило вида «поставим кеш на год на весь сайт» выглядит заманчиво примерно до первого обновления цены, корзины или личного кабинета. Политика должна зависеть от типа ресурса.
| Что отдаёт сайт | Разумная логика | Что проверить |
|---|---|---|
| Версионированные CSS, JS, шрифты, изображения | Длительный кеш | При изменении содержимого меняется URL файла |
| HTML обычной публичной страницы | Проверка актуальности или небольшой срок хранения | Новая редакция страницы появляется без ручной очистки кеша |
| Корзина, кабинет, персональные данные | Осторожная индивидуальная политика | Один пользователь не получает сохранённые данные другого |
| Сторонние файлы | Управление часто ограничено | Можно ли вообще изменить заголовки внешнего сервера |
Для файла, URL которого меняется вместе с содержимым, длительный срок хранения действительно удобен:
Cache-Control: public, max-age=31536000, immutableНапример, вместо вечного style.css после сборки могут появляться style.8f31c2.css, затем style.294bd1.css. Для браузера это два разных адреса. Старый файл можно спокойно хранить долго: новая версия всё равно будет запрошена по новому URL.
С HTML логика обычно осторожнее. Если страницу необходимо каждый раз проверять на актуальность, используется механизм повторной проверки, например:
Cache-Control: no-cache
ETag: "..."Название no-cache здесь слегка издевательское: оно не обязательно означает «ничего не хранить». Смысл в том, что сохранённый ответ нужно проверить перед повторным использованием. А no-store уже предназначен для случаев, когда ответ вообще не следует сохранять; применять его ко всему сайту «для надёжности» не стоит.
Почему «скажите клиенту очистить кеш» — плохая стратегия обновления
Допустим, сайт отдаёт style.css с кешем на год. В понедельник файл скачали тысяча постоянных посетителей. Во вторник разработчик изменил в нём оформление кнопки, но оставил тот же URL.
Новый посетитель скачает новую версию и увидит всё правильно. Часть старых посетителей продолжит использовать ещё свежую по правилам кеша старую копию. У разработчика всё работает, у владельца всё работает, а клиент почему-то оказывается крайним и получает инструкцию «нажмите Ctrl+Shift+R».
Правильнее изменить адрес ресурса вместе с содержимым. Тогда браузер видит новый URL и загружает новый файл, а старые неизменившиеся ресурсы продолжает брать из кеша. Пользователю не приходится знать, что такое Cache-Control, — и это хороший признак нормально построенного сайта.
Если на сайте одновременно возникают старые версии страниц, проблемы с CDN, нестабильная скорость, ошибки индексации и другие технические симптомы, исправлять один Cache-Control изолированно обычно бессмысленно. Такие вещи разумнее разбирать в рамках комплексного SEO-продвижения сайта с техническим аудитом: сначала определить настоящий узкий участок, а уже потом менять серверные настройки.
Что в итоге должен контролировать владелец сайта
Вам необязательно помнить синтаксис всех HTTP-заголовков. Важнее получить ответы на несколько практических вопросов: повторные переходы действительно используют уже загруженные статические ресурсы; новая версия сайта после релиза появляется без инструкции «очистите кеш»; HTML и персональные страницы не застревают в старом состоянии; разработчик умеет показать политику кеширования конкретного файла, а не просто сообщает, что «плагин включён».
И ещё один полезный критерий: проверяйте результат на самом сайте, а не только по баллам инструмента. PageSpeed Insights и браузерные диагностики хорошо показывают проблему, но цель бизнеса не в том, чтобы получить красивый отчёт. Цель — чтобы посетитель быстро получил правильную версию страницы и спокойно сделал то, ради чего пришёл.
FAQ
Когда кеш ускоряет сайт, а когда начинает мешать
Это место на устройстве пользователя, куда браузер временно складывает уже загруженные файлы сайта. При следующем открытии ему не приходится снова скачивать, например, тот же логотип, шрифт или CSS. За счёт этого повторные переходы могут происходить быстрее.
Само наличие Browser cache не является обещанием роста позиций. Корректное кеширование может улучшать реальную скорость повторных посещений и пользовательский опыт, а показатели производительности входят в общую оценку удобства страниц Google. Но хорошие показатели скорости сами по себе не гарантируют высоких позиций.
Откройте вкладку Network в инструментах разработчика браузера и сравните первую и повторную загрузку страницы. Для нужного CSS, JavaScript, изображения или шрифта проверьте Cache-Control, ETag, Last-Modified, а также источник загрузки. Заголовки конкретного файла дополнительно удобно проверить командой curl -I.
Для обычной работы сайта — нет. Очистка полезна как диагностический приём, если именно на вашем устройстве отображается старая или повреждённая версия страницы. Если после каждого обновления приходится просить клиентов очистить кеш, проблема находится в настройке сайта, а не в привычках клиентов.
Сначала определите, какой именно ресурс устарел: HTML, CSS, JavaScript, изображение или данные приложения. Затем проверьте его Cache-Control и версионирование URL, а также CDN и другие уровни кеширования. Для статических файлов обычно решением становится новый URL при изменении содержимого, а не принудительная очистка кеша у всех пользователей.
Рейтинг статьи
Материал был полезен?
Оценка помогает понимать, какие материалы стоит обновлять и расширять.
