Коротко. Пример кэширования, который проще всего увидеть своими глазами: открыть карточку товара в интернет-магазине первый раз (загрузка займёт условно 800-1500 мс) и второй раз через минуту (загрузка займёт 100-200 мс) — разница и есть работа серверного кэша. Второй наглядный пример — заголовок Cache-Control: max-age=31536000 у картинки в инструментах разработчика браузера: это значит, что браузер не скачает файл повторно целый год. Оба примера проверяются за две минуты без доступа к коду сайта.
Пример 1: карточка товара в интернет-магазине до и после кэша
Самый наглядный пример работы кэша — открыть одну и ту же страницу дважды. Первая загрузка карточки товара на сайте без кэша обычно означает: сервер запрашивает у базы данных название, цену, остатки, характеристики, отзывы, похожие товары — это может быть 15-40 отдельных запросов, каждый занимает время. Итоговое время ответа сервера (TTFB) на обычном хостинге в этом случае — 600-1500 мс. При включённом page cache сервер после первой сборки сохраняет готовый HTML, и повторный запрос той же страницы получает готовую копию без единого запроса к базе — TTFB падает до 50-150 мс. Проверить это можно самостоятельно: открыть вкладку Network в инструментах разработчика браузера (клавиша F12), обновить страницу дважды подряд и сравнить время у самого первого запроса в списке — того, что относится к HTML-документу, а не к картинкам.
Пример 2: заголовок Cache-Control у статики
Второй пример — не про скорость сборки страницы, а про повторное скачивание файлов. У правильно настроенного изображения на сайте в ответе сервера будет заголовок вида Cache-Control: public, max-age=31536000, immutable. Число 31536000 — это количество секунд в году: браузер не будет заново запрашивать файл целый год, если только адрес файла не изменится. Посмотреть это можно в той же вкладке Network: кликнуть на любую картинку в списке загруженных файлов, открыть вкладку Headers и найти строку Cache-Control в Response Headers. Если такой строки нет вовсе или значение — что-то вроде max-age=0 — браузерный кэш для статики не настроен, и посетитель будет скачивать одни и те же файлы логотипа или иконок при каждом визите.
Пример 3: код ответа 304 вместо повторной загрузки
Третий пример показывает работу кэша с проверкой актуальности. Для файлов, которые могут обновляться (например, CSS без версии в имени), вместо долгого max-age часто используют схему с проверкой: браузер спрашивает сервер «файл не изменился с прошлого раза?», и если нет — сервер отвечает кодом 304 Not Modified без передачи самого файла. В той же вкладке Network это видно по столбцу Status: вместо 200 (полная загрузка) — 304, и размер переданных данных для этого файла — около нуля. Это тоже кэширование, только с постоянной, но лёгкой проверкой вместо полного доверия сроку хранения.
Пример 4: чем лендинг под рекламу отличается от интернет-магазина
Кэш на практике даёт разный эффект в зависимости от сценария посещения. На лендинге, куда приводит разовая рекламная кампания, почти каждый посетитель — новый, повторных визитов почти нет, поэтому браузерный кэш здесь почти бесполезен: посетитель не вернётся, чтобы воспользоваться сохранённой копией. Здесь решает именно серверный кэш — скорость первого и единственного захода. На интернет-магазине или сервисе с личным кабинетом ситуация другая: один и тот же посетитель заходит по нескольку раз перед покупкой, поэтому браузерный кэш статики (логотип, иконки, общий CSS сайта) реально экономит время при каждом повторном визите. Разбор, какая стратегия кэширования приоритетна для какого типа сайта, — тема отдельного материала.
Пример 5: когда кэш настроен неправильно
Наглядный отрицательный пример — сайт, где после публикации новой статьи или изменения цены товара посетители неделю видят старую версию. Причина обычно в том, что срок хранения серверного кэша HTML выставлен избыточно долгим (например, сутки или больше) без механизма принудительной очистки при публикации. Более серьёзный пример ошибки — когда под кэш страниц случайно попадает страница личного кабинета или корзины без исключения: один посетитель может на короткое время увидеть содержимое, относящееся к другому пользователю сайта. Такие случаи редки при использовании готовых плагинов кэширования с настройками по умолчанию, но становятся вероятны при ручной настройке без понимания, какие страницы кэшировать нельзя — такие тонкости обычно закрывает подрядчик ещё на этапе разработки или доработки сайта.
Как посмотреть работу кэша на своём сайте за пять минут
Порядок действий: открыть сайт в браузере, нажать F12 (или через меню — «Инструменты разработчика»), перейти на вкладку Network, поставить галочку Disable cache в положение выключено (чтобы не мешать проверке), обновить страницу. Дальше — три проверки. Первая: найти в списке запрос самой страницы (обычно первая строка, тип document) и посмотреть время (Time) — если оно больше 500-700 мс на обычном хостинге, вероятно серверный кэш не настроен или не работает для этой страницы. Вторая: кликнуть на любую картинку и посмотреть заголовок Cache-Control в Response Headers. Третья: обновить страницу второй раз и сравнить время загрузки статики — файлы с работающим кэшем либо не появляются в списке заново (браузер их не запрашивал), либо показывают код 304. Такая проверка — только диагностика: она показывает симптом, а не причину и не решение, для которых нужен уже технический разбор конфигурации сервера.
Что эти примеры не показывают
Важно понимать границы такой самостоятельной проверки. Она показывает, работает кэш или нет, но не показывает, правильно ли расставлены исключения для персонализированных страниц, — это проверяется отдельно и требует понимания структуры сайта. Она также не показывает, какая часть медленной загрузки связана с кэшем, а какая — с тяжёлыми изображениями, сторонними виджетами (чаты, счётчики) или медленным сервером хостинга в принципе: кэш ускоряет повторную сборку HTML, но не может ускорить то, что вообще не проходит через генерацию страницы. Такая диагностика и настройка обычно входит в техническую поддержку сайта, а более полная картина с разбивкой по конкретным причинам задержки — в объём SEO-аудита.
Как быстро проверить, работает ли кэш на моём сайте?
Открыть сайт, нажать F12, вкладка Network, обновить страницу дважды. Сравнить время загрузки HTML-документа в первый и второй раз и посмотреть заголовок Cache-Control у картинок. Разница в разы между первой и второй загрузкой — признак работающего серверного кэша.
Почему при обновлении страницы время загрузки иногда не меняется?
Значит, серверный кэш для этой конкретной страницы не работает или не настроен — либо страница исключена из кэша намеренно (например, страница с формой заказа), либо кэш вообще не подключён на уровне сервера или CMS.
Можно ли увидеть кэш браузера отдельно от серверного?
Да, это разные вещи в одной и той же вкладке Network: серверный кэш виден по времени загрузки самой HTML-страницы (тип document), браузерный — по заголовкам Cache-Control у картинок, шрифтов и скриптов и по коду 304 при повторном запросе.
Одинаково ли кэшируются все страницы одного сайта?
Нет, и это нормально: страницы с уникальным или персональным содержимым (корзина, личный кабинет, результаты поиска) обычно исключены из серверного кэша намеренно, поэтому будут показывать более долгую загрузку даже на сайте с настроенным кэшированием.
Что делать, если проверка показала, что кэш не работает?
Зафиксировать конкретные цифры (время загрузки, заголовки) и обратиться к разработчику или в техподдержку хостинга — самостоятельная настройка без опыта рискованна там, где есть страницы с персональными данными, которые нельзя случайно закэшировать целиком.
Проверить кэширование на практике, а не по чек-листу
Замерим реальное время ответа сервера, заголовки статики и найдём, где именно теряется скорость на вашем сайте.