Кэширование

Что такое кэширование сайта

Кэширование это повторное использование ранее полученного или подготовленного результата вместо выполнения всей работы заново при каждом запросе.

На сайте кэшироваться могут разные сущности. Браузер способен сохранять CSS, JavaScript, изображения и другие HTTP ответы. Сервер может хранить готовый HTML страницы. WordPress может сохранять результаты запросов к базе данных. CDN может отдавать сохранённую копию ресурса с промежуточного узла.

Поэтому выражение «на сайте включён кэш» само по себе почти ничего не объясняет. Для технической диагностики необходимо понимать, какой именно уровень используется, что хранится, сколько времени считается актуальным результат и как происходит обновление.

Текущая taxonomy Vagizov.com объединяет тему кэширования как часть технической оптимизации. При этом browser cache и object cache уже разобраны в отдельных практических материалах, поэтому справочная страница должна связывать уровни кэша между собой, а не дублировать эти инструкции.

Зачем сайту нужен кэш

Без кэширования один и тот же результат может вычисляться и передаваться снова при каждом обращении.

Браузер повторно скачивает неизменившийся файл.

PHP заново формирует одинаковую страницу.

WordPress повторяет запрос к базе данных.

Сервер выполняет работу, результат которой уже был получен несколько секунд назад.

Кэш позволяет убрать часть таких повторений.

Практический результат может выражаться в уменьшении количества запросов к серверу, сокращении объёма передаваемых данных, снижении нагрузки на PHP и базу данных и более быстрой обработке повторных обращений.

Но кэширование не является универсальным ускорителем. Если основная проблема находится в тяжёлом JavaScript, огромном изображении или медленном внешнем API, другой уровень кэша может почти не изменить пользовательский результат.

Какие уровни кэширования бывают

Для веб сайта полезно разделять несколько основных уровней.

Browser cache

Browser cache работает на стороне браузера пользователя.

Он позволяет повторно использовать уже полученные HTTP ответы, пока они остаются свежими согласно правилам кэширования.

Типичный сценарий это CSS, JavaScript, шрифты, изображения и другие статические ресурсы.

При повторном посещении страницы браузеру не обязательно заново скачивать каждый файл полностью. Если ресурс ещё свежий, может использоваться локальная копия. Если срок свежести закончился, браузер может выполнить проверку актуальности через условный запрос.

На Vagizov.com browser cache уже имеет отдельную подробную статью, поэтому текущая taxonomy рассматривает его как один уровень общей системы кэширования.

Page cache

Page cache сохраняет готовый результат формирования страницы.

Вместо запуска приложения, PHP и повторной сборки HTML сервер может отдать уже сохранённую версию документа.

Это особенно эффективно для страниц, которые одинаково выглядят для большого количества анонимных посетителей.

Page cache нужно отличать от object cache. Первый сохраняет готовый ответ страницы, второй сохраняет данные, которые приложение использует при её формировании.

Это различие подробно показано и в существующем материале Vagizov.com про object cache.

Object cache

Object cache сохраняет результаты получения данных, чтобы приложение не выполняло одну и ту же дорогую операцию повторно.

В WordPress встроенный объектный кэш по умолчанию действует в рамках текущего запроса. Persistent object cache позволяет использовать сохранённые значения между запросами через отдельное постоянное хранилище.

Такой уровень особенно полезен для динамических систем, где страницу нельзя полностью отдать из page cache.

Например, интернет магазин, личный кабинет или административная часть WordPress могут регулярно обращаться к базе данных даже при наличии других уровней кэширования.

Object cache уже разобран на Vagizov.com отдельным материалом, поэтому на taxonomy странице важно сохранять только его место в общей архитектуре.

Server cache

Серверное кэширование может работать перед приложением.

Например, Nginx поддерживает FastCGI cache, который способен сохранять ответы FastCGI приложения и повторно использовать их для последующих запросов.

В типичной связке Nginx и PHP FPM это позволяет в подходящих сценариях отдавать готовый ответ без полноценного повторного запуска обработки WordPress.

Но серверный page cache требует правильных исключений.

Корзина, личный кабинет, страницы с персональными данными и другие пользовательские состояния нельзя бездумно отдавать всем посетителям из одной общей копии.

CDN cache

CDN может выступать общим промежуточным кэшем между origin сервером и пользователем.

Такой кэш хранит копии подходящих ресурсов на инфраструктуре CDN и способен отдавать их без обращения к origin при каждом запросе.

Это особенно полезно для статических ресурсов и распределённой аудитории.

При этом CDN и browser cache не заменяют друг друга. Один работает в инфраструктуре доставки, другой непосредственно у пользователя.

Что такое HTTP cache

HTTP определяет стандартные механизмы управления сохранением и повторным использованием ответов.

Основным заголовком является Cache-Control.

Он содержит инструкции для браузеров и shared cache, включая CDN и прокси. Через него можно определить срок свежести, возможность хранения ответа и правила повторной проверки.

Правила HTTP cache важны независимо от используемой CMS.

WordPress, статический сайт и собственное веб приложение работают с браузером через один и тот же HTTP уровень.

Что делает Cache Control

Cache-Control управляет поведением HTTP кэша.

Например:

Cache-Control: max-age=86400

означает, что ответ может считаться свежим в течение заданного количества секунд.

Пока ответ свежий, браузер может повторно использовать сохранённую копию без запроса к серверу.

После завершения срока свежести ответ становится stale. Это не означает, что сохранённые данные обязательно немедленно удаляются. При наличии валидатора клиент может проверить, изменилась ли версия на сервере.

Что означает max age

max-age задаёт срок свежести ответа.

Чем стабильнее ресурс, тем дольше обычно можно хранить его без повторной проверки.

Но универсального срока для всех ресурсов нет.

HTML страницы, CSS файл с версией в URL и персонализированный ответ имеют разные требования.

Главный принцип состоит в согласовании срока жизни с реальным механизмом обновления ресурса.

Если файл получает новый URL при каждом изменении, старую версию можно хранить значительно дольше.

Если URL остаётся прежним и содержимое часто меняется, слишком большой срок способен оставить пользователю устаревшую версию.

Что такое cache busting

Cache busting позволяет изменить адрес ресурса при изменении его содержимого.

Например, вместо постоянного:

style.css

может использоваться версия:

style.v42.css

или другой адрес, зависящий от версии сборки.

В таком случае новая версия имеет новый URL, а старую можно безопаснее хранить длительное время.

MDN рекомендует подобную схему для ресурсов, URL которых можно менять при обновлении. Для версионированных ресурсов долгий срок хранения может сочетаться с immutable.

Для WordPress аналогичный принцип часто реализуется через изменение версии подключаемого CSS или JavaScript.

Что такое immutable

Директива immutable сообщает, что содержимое свежего ресурса не изменится в течение его срока жизни.

Она особенно логична для файлов, адрес которых изменяется при каждом обновлении содержимого.

В таком случае браузеру нет необходимости выполнять лишнюю проверку версии при обычной перезагрузке, пока ресурс остаётся свежим.

Использовать immutable для файла, который может измениться под тем же URL, опасно.

Пользователь способен продолжать получать старую копию до окончания срока хранения.

Что означает no cache

Название no-cache часто понимают неправильно.

Эта директива не означает «никогда не хранить».

Она требует проверить актуальность сохранённого ответа перед повторным использованием.

Если ресурс не изменился, сервер может подтвердить это и вернуть 304 Not Modified без повторной передачи полного тела ответа.

Такой подход подходит для содержимого, которое желательно сохранять локально, но перед использованием нужно удостовериться в актуальности версии.

Что означает no store

no-store запрещает сохранять ответ в HTTP cache.

Это более строгое поведение, чем no-cache.

MDN отдельно подчёркивает, что no-store не является механизмом удаления уже существующей старой копии ресурса из всех промежуточных кэшей.

Такая директива нужна там, где сам факт хранения ответа нежелателен.

Но ставить no-store на весь сайт ради «актуальности» обычно не следует, поскольку это полностью отключает преимущества HTTP cache для соответствующих ответов.

Public и private

private означает, что ответ предназначен для private cache, например браузера конкретного пользователя, и не должен повторно использоваться shared cache для других пользователей.

Это важно для персонализированных страниц.

MDN приводит private как подходящий механизм для ответов, содержимое которых персонализируется для конкретного пользователя.

public явно разрешает использование ответа общими кэшами там, где это соответствует правилам.

При проектировании CDN cache разница между общими и персональными ответами является критичной.

Что такое ETag

ETag это идентификатор конкретной версии ресурса.

После завершения срока свежести браузер может отправить сохранённое значение через If-None-Match.

Если версия на сервере совпадает, сервер возвращает 304 Not Modified.

Если ресурс изменился, сервер возвращает актуальную версию с обычным ответом 200 OK.

Таким образом, даже после завершения срока свежести не всегда требуется повторно передавать весь файл.

Что такое Last Modified

Last-Modified сообщает время последнего изменения ресурса по мнению origin сервера.

Клиент может передать это значение через If-Modified-Since.

Если ресурс после указанного времени не менялся, сервер способен ответить 304 Not Modified.

Last-Modified используется не только браузерами. MDN также отмечает его применение краулерами при регулировании повторного обхода.

При этом ETag обеспечивает более точное определение конкретной версии содержимого.

Что означает 304 Not Modified

304 Not Modified это ответ на условный запрос.

Он сообщает клиенту, что сохранённая версия ресурса остаётся актуальной.

Тело самого ресурса повторно не передаётся, поэтому уменьшается объём данных.

Ответ 304 нельзя оценивать как ошибку только потому, что это не 200.

В корректном сценарии повторной проверки кэша такой статус является ожидаемым поведением HTTP.

ETag или Last Modified

Оба механизма могут использоваться для проверки версии.

ETag сравнивает идентификатор представления.

Last-Modified использует дату изменения.

MDN указывает, что при наличии обоих условных заголовков проверка через If-None-Match имеет приоритет над If-Modified-Since. Также рекомендуется по возможности предоставлять оба валидатора.

Поэтому вопрос не обязательно заключается в выборе только одного механизма.

Важно, чтобы сервер возвращал корректные значения и действительно обновлял их при изменении ресурса.

Что такое Vary

Vary сообщает кэшу, какие заголовки запроса влияют на вариант ответа.

Это важно, когда один URL способен возвращать разные представления.

Неправильный Vary может либо привести к выдаче неподходящей версии, либо резко снизить эффективность кэширования из за слишком большого количества вариантов.

MDN отдельно предупреждает, что использование User-Agent в Vary создаёт большое число комбинаций и значительно уменьшает вероятность повторного использования кэша.

Поэтому количество вариаций ответа нужно минимизировать до реально необходимых.

Что кэшировать дольше

Лучшие кандидаты для длительного browser cache это статические ресурсы, содержимое которых меняется только вместе с изменением URL.

К ним могут относиться версионированные CSS, JavaScript, изображения и шрифты.

В такой архитектуре старый ресурс может сохраняться долго, потому что новая версия получит другой адрес.

HTML требует другой стратегии.

Главный документ страницы обычно нельзя безопасно cache bust через изменение URL при каждом обновлении. Поэтому для HTML часто используется более короткий срок либо обязательная revalidation. MDN приводит no-cache вместе с валидаторами как подходящую схему для HTML, который должен оставаться актуальным.

Почему нельзя задавать один TTL всему сайту

Разные ресурсы меняются с разной частотой.

Логотип может оставаться неизменным месяцами.

CSS меняется при релизах.

Новость может обновляться несколько раз после публикации.

Корзина изменяется после действий конкретного пользователя.

Поэтому единый срок хранения для всех ответов редко является оптимальным.

Политика кэширования должна определяться по типам ресурсов и способу их обновления.

Что такое очистка кэша

Очистка кэша удаляет сохранённые версии, чтобы при следующем запросе система сформировала или получила актуальный результат.

Но на современном сайте может существовать несколько независимых кэшей.

Браузер.

CDN.

Nginx.

Плагин page cache.

Object cache.

Кэш приложения.

Поэтому фраза «очистил кэш» без уточнения уровня не гарантирует, что пользователь увидит новую версию.

При диагностике важно определить, где именно остался устаревший результат.

Что такое purge

Purge обычно означает принудительное удаление сохранённого объекта из server или CDN cache.

Такой механизм полезен после обновления страницы, если ждать завершения обычного TTL слишком долго.

Для динамического сайта желательно иметь понятную стратегию invalidation.

После изменения записи очищается именно связанный кэш.

После глобального изменения шаблона может потребоваться более широкое обновление.

Постоянная полная очистка всего кэша после каждого небольшого изменения снижает пользу системы.

Почему invalidation считается сложной частью кэширования

Записать результат в кэш относительно просто.

Сложнее определить момент, когда он перестал быть действительным.

Если кэш очищается слишком рано, уменьшается эффективность.

Если слишком поздно, пользователь получает устаревшие данные.

Поэтому хорошая архитектура должна заранее отвечать на вопрос, какое событие делает объект неактуальным.

Для CSS это может быть новый deployment.

Для страницы WordPress изменение записи.

Для каталога изменение товара или цены.

Для object cache обновление данных, из которых был сформирован объект.

Кэширование WordPress

В WordPress одновременно могут использоваться несколько уровней.

Browser cache управляет повторным использованием HTTP ресурсов.

Page cache хранит готовый HTML.

Object cache уменьшает повторную работу с данными.

Перед WordPress дополнительно может стоять Nginx cache или CDN.

Официальная документация WordPress разделяет browser caching и object caching и описывает page caching через сохранение страниц как статических файлов.

Поэтому установка одного cache плагина ещё не означает, что вся система настроена оптимально.

Page cache в WordPress

Page cache особенно эффективен для публичных страниц, которые одинаковы для большинства посетителей.

Первый запрос формирует страницу обычным способом.

Полученный HTML сохраняется.

Следующий подходящий запрос получает готовую копию.

В результате PHP и база данных выполняют меньше повторной работы.

Но необходимо корректно исключать персональные и транзакционные сценарии.

Для WooCommerce это особенно важно для корзины, оформления заказа, личного кабинета и других страниц, содержимое которых зависит от пользователя.

Object cache в WordPress

WordPress использует WP_Object_Cache для сохранения данных, получение которых может требовать повторных обращений к базе.

По умолчанию такой кэш не является постоянным между запросами. Persistent реализация может быть подключена через соответствующий drop in.

Persistent object cache особенно полезен там, где приложение продолжает активно работать с PHP и базой даже после настройки page cache.

Подробная проверка Redis, Memcached и object-cache.php уже разобрана в отдельной статье Vagizov.com и не должна полностью повторяться на taxonomy странице.

Кэширование в Nginx

Nginx способен участвовать в кэшировании на серверном уровне.

Для связки с PHP FPM доступен fastcgi_cache, который хранит ответы FastCGI upstream и повторно использует их для подходящих запросов.

Такое решение способно значительно сократить количество обращений непосредственно к WordPress.

Но эффективность зависит от правил bypass, сроков хранения и корректного определения персонализированных запросов.

Без понимания архитектуры копировать готовый фрагмент конфигурации из чужой инструкции опасно.

Кэширование и CDN

CDN cache полезен как промежуточный общий уровень.

Он позволяет отдавать сохранённый ресурс без постоянного обращения к origin серверу.

Особенно логично использовать его для статических файлов.

Кэширование HTML через CDN тоже возможно, но требует более точных правил, поскольку HTML может зависеть от cookies, авторизации, региона и других факторов.

Главный принцип остаётся тем же: общий cache не должен выдавать одному пользователю приватное содержимое другого.

Можно ли кэшировать персонализированные страницы

Да, но архитектура значительно сложнее, чем у обычной публичной страницы.

Нельзя просто сохранить HTML личного кабинета одного пользователя и отдать его другому из shared cache.

Для персонализированных ответов используются соответствующие правила, включая private, исключения из shared cache или разбиение содержимого на независимо кэшируемые части.

Если нет уверенности в корректности разделения пользователей, безопаснее не включать общий page cache для такого ответа.

Cookie и кэш

Наличие cookie само по себе ещё не объясняет, нужно ли обходить кэш.

На сайте могут существовать технические или аналитические cookies, которые не изменяют HTML.

Другие cookies действительно определяют персональное содержимое, корзину или авторизацию.

Поэтому правило «если есть cookie, никогда не кэшировать» может резко снизить эффективность.

Но и правило «игнорировать все cookies» способно привести к утечке персонализированного ответа.

Кэширование должно учитывать только те признаки, которые реально изменяют представление.

Кэш и авторизация

Авторизованные пользователи часто получают другой ответ, чем анонимные посетители.

Поэтому page cache необходимо проектировать с учётом состояния входа.

Это особенно важно в WordPress, где администратор может одновременно редактировать сайт и просматривать frontend.

Если кэширование настроено ошибочно, пользователь способен увидеть старую версию или не тот вариант страницы.

Поэтому тестирование нужно проводить как минимум отдельно для анонимного и авторизованного состояния.

Кэш и WooCommerce

WooCommerce содержит большое количество динамических данных.

Корзина, оформление заказа и личный кабинет зависят от конкретного пользователя.

Каталог и обычные товарные страницы при определённой архитектуре могут кэшироваться значительно агрессивнее.

Object cache при этом способен уменьшать повторную работу с данными на динамических страницах, которые нельзя целиком отдавать из page cache.

Именно поэтому для ecommerce проекта особенно важно не смешивать page cache и object cache в одно понятие.

Влияет ли кэширование на SEO

Специального бонуса за наличие cache плагина, Redis или Nginx cache поисковая система не выдаёт.

Связь с SEO косвенная.

Если правильно настроенный cache сокращает серверное время и объём повторной загрузки ресурсов, это может улучшить фактическую производительность сайта.

Если инфраструктура становится стабильнее под нагрузкой, серверу проще обслуживать и пользователей, и поисковых роботов.

Но эффект необходимо измерять.

Существующая статья Vagizov.com про object cache прямо разделяет технологию и SEO результат: Redis сам по себе не повышает позиции, а ценность появляется только через устранение реального серверного ограничения.

Кэширование и TTFB

Page cache способен существенно сокращать серверную работу до начала передачи HTML.

Object cache тоже может помочь, если значимая часть времени тратится на повторные операции с базой.

Но уменьшение TTFB зависит от фактического узкого места.

Если задержка возникает в сетевом соединении, внешнем API или другой части инфраструктуры, включение очередного кэша может почти ничего не изменить.

Поэтому сначала измеряется текущая цепочка ответа, а затем выбирается уровень оптимизации.

Кэширование и Core Web Vitals

Кэширование не является отдельной метрикой Core Web Vitals.

Оно может косвенно влиять на пользовательскую загрузку.

Более быстрый старт HTML способен помочь цепочке загрузки основного контента.

Повторное использование CSS, JavaScript, шрифтов и изображений может уменьшить работу при последующих посещениях.

Однако LCP, INP и CLS зависят от множества других факторов.

На Vagizov.com скорость сайта вынесена в отдельную taxonomy и отдельные материалы, поэтому страница «Кэширование» должна рассматривать только роль кэша внутри общей производительности, не дублируя полноценный разбор Core Web Vitals.

Может ли кэширование навредить

Да, если правила не соответствуют данным.

Пользователь может получить старый CSS после обновления дизайна.

Старая версия JavaScript может конфликтовать с новым HTML.

Кэшированная цена может не совпадать с актуальной.

Общий cache может ошибочно сохранить персонализированный ответ.

После публикации новой версии страницы CDN может продолжать отдавать старую копию.

Поэтому задача состоит не в максимальном количестве кэша, а в правильной политике свежести и обновления.

Почему после изменения сайта видна старая версия

Наиболее частая причина состоит в том, что старая версия осталась на одном из уровней кэширования.

Это может быть browser cache.

Page cache WordPress.

Nginx.

CDN.

Object cache.

Отдельный кэш приложения.

Диагностику лучше проводить последовательно.

Сначала проверяется фактический HTTP ответ без предположения о причине.

Затем сравнивается результат для нового клиента, авторизованного пользователя и обычного посетителя.

После этого определяется конкретный слой, который отдаёт старую версию.

Нужно ли постоянно очищать кэш браузера

Обычный пользователь не должен регулярно вручную очищать browser cache, чтобы сайт работал корректно.

Если после каждого релиза разработчик пишет «нажмите Ctrl F5», проблема чаще находится в стратегии версионирования ресурсов.

CSS и JavaScript должны обновляться так, чтобы браузер мог отличить новую версию от старой.

Cache busting решает эту задачу значительно надёжнее постоянной ручной очистки.

Как проверить browser cache

Начать можно с HTTP заголовков реального ресурса.

Нужно посмотреть Cache-Control, ETag, Last-Modified, Age, Vary и другие применимые заголовки.

Затем проверить повторный запрос.

Важно понять, отправляется ли файл снова целиком, используется ли fresh cache или выполняется revalidation с ответом 304.

Подробный сценарий такой проверки уже опубликован на Vagizov.com в статье про browser cache.

Как проверить server cache

Одного наличия директивы в конфигурации недостаточно.

Нужно проверить боевой URL.

Для серверного или CDN cache часто используются служебные заголовки, позволяющие определить HIT, MISS, BYPASS или другое состояние, если такая диагностика настроена.

После этого сравнивается первый и повторный запрос.

Также важно проверить исключения.

Авторизованный пользователь, корзина или другая динамическая страница не должны попадать в общий cache только потому, что публичная главная корректно показывает HIT.

Как проверить object cache

Для WordPress нужно отличать наличие поддержки от фактической пользы.

WP CLI предоставляет команды для работы с Object Cache, а WordPress поддерживает persistent object cache через отдельную реализацию.

Дальше проверяется реальная производительность.

Если перед страницей уже находится page cache и PHP вообще не запускается, измерение публичной страницы ничего не говорит об эффективности Redis.

На Vagizov.com этот сценарий подробно разобран в отдельной статье про object cache.

Как проверить заголовки кэша

Для быстрой диагностики можно использовать инструменты разработчика браузера или HTTP клиент.

Проверять нужно именно конечный ответ production URL.

Конфигурация Nginx может выглядеть правильно, но CDN изменить заголовки.

Плагин WordPress может добавить свои правила.

Прокси может переписать Cache-Control.

Поэтому итоговый HTTP ответ важнее предположения о том, что должно происходить согласно одному конфигурационному файлу.

Почему Lighthouse не заменяет проверку HTTP

Инструмент производительности может указать на неоптимальную политику хранения статических ресурсов.

Но этого недостаточно для понимания полной архитектуры.

Он не отвечает автоматически на вопросы о том, корректно ли исключён личный кабинет, когда очищается page cache, работает ли object cache и не отдаёт ли CDN старый HTML.

Кэширование нужно проверять на соответствующем уровне.

Browser cache через HTTP.

Page cache через повторные ответы.

Object cache через работу приложения и базы.

CDN через фактическую цепочку доставки.

Нужно ли кэшировать HTML

Во многих проектах да.

Именно page cache готового HTML может дать заметное сокращение работы приложения.

Но политика зависит от содержимого.

Публичная статья обычно хорошо подходит для такого сценария.

Личный кабинет или корзина требуют совсем другого подхода.

Нельзя принимать решение только по типу файла text/html.

Необходимо понимать, одинаков ли ответ для разных пользователей.

Нужно ли кэшировать API

Зависит от API и конкретного endpoint.

Публичный справочный ответ может хорошо подходить для кэширования.

Персональные данные пользователя могут требовать private, запрета shared cache или полного запрета хранения.

API с быстро меняющимся состоянием требует короткого TTL либо revalidation.

Поэтому единое правило «API не кэшируется» так же некорректно, как «кэшируем все GET запросы».

Кэширование и обновление контента

Редакционный сайт должен обеспечивать своевременную публикацию изменений.

После обновления статьи page cache должен быть очищен или помечен как неактуальный.

Если используется CDN cache HTML, изменение должно доходить и до этого слоя.

Browser cache HTML не должен блокировать получение свежей версии слишком долго.

Именно поэтому стратегия обновления является такой же важной частью системы, как стратегия хранения.

Кэширование и поисковый робот

Поисковый робот получает обычный HTTP ответ сайта.

Для SEO важно, чтобы этот ответ соответствовал актуальному содержимому страницы и не зависел от ошибочной версии кэша.

Не должно возникать ситуации, когда обычный пользователь получает одну страницу, а поисковый робот из старого server cache другую.

Кэш также не должен сохранять ошибочные ответы дольше, чем это оправдано архитектурой.

Само наличие page cache или CDN для поискового робота не является проблемой. Важен корректный конечный ответ.

Кэш и HTTP коды

Кэшировать можно не только успешные ответы, поэтому правила для кодов состояния требуют отдельного внимания.

Если инфраструктура случайно надолго сохранит временную серверную ошибку, последствия могут оказаться хуже самой первоначальной проблемы.

Особенно внимательно нужно проектировать обработку 404, 410, 500, 502, 503 и других ответов, отличающихся от обычного документа 200 OK.

На Vagizov.com HTTP коды вынесены в отдельную taxonomy, поэтому текущая страница не должна дублировать полный разбор статусов.

Кэширование и Last Modified

Last-Modified полезен не только как технический заголовок для browser cache.

Он позволяет выполнять условную проверку ресурса через If-Modified-Since.

Если содержимое не менялось, сервер может вернуть 304 без повторной передачи тела.

Но дата должна отражать реальное состояние ресурса.

Если она обновляется при каждом запросе независимо от изменения содержимого, механизм теряет смысл.

Кэширование и Sitemap lastmod

HTTP Last-Modified и <lastmod> внутри XML Sitemap связаны общей идеей времени изменения, но это разные механизмы.

HTTP заголовок участвует в работе клиентских запросов и кэширования.

<lastmod> в Sitemap сообщает поисковой системе дату существенного изменения URL.

На Vagizov.com Sitemap lastmod разобран отдельной статьёй, поэтому смешивать эти два механизма на странице кэширования не следует.

Кэширование и сжатие

Кэширование и Brotli или gzip решают разные задачи.

Кэш отвечает на вопрос, нужно ли повторно получать или формировать результат.

Сжатие уменьшает размер передаваемого представления.

Они могут использоваться одновременно.

При этом инфраструктура должна корректно различать варианты ответа с разными content encoding. На Vagizov.com эта проблема отдельно рассматривается в материале про Brotli.

Поэтому тема сжатия не должна дублироваться внутри taxonomy «Кэширование».

Как выбирать стратегию кэширования

Сначала нужно определить тип ресурса.

Затем понять, одинаков ли ответ для всех пользователей.

После этого определить допустимый срок устаревания.

Далее выбрать способ обновления.

Для версионированного CSS это может быть долгий browser cache и новый URL при изменении.

Для HTML это может быть page cache с очисткой после редактирования.

Для динамических WordPress данных persistent object cache.

Для статических ресурсов глобальной аудитории CDN.

Так стратегия строится от поведения данных, а не от желания «включить максимум кэша».

Что проверить после настройки

После внедрения важно проверить не только скорость.

Нужно убедиться, что новая версия CSS появляется после deployment.

Изменение статьи видно посетителю.

Авторизованный пользователь не получает страницу другого пользователя.

Корзина работает корректно.

HTTP заголовки соответствуют предполагаемой политике.

Повторный запрос действительно использует нужный cache.

После purge ресурс обновляется.

Только после функциональной проверки имеет смысл сравнивать TTFB, нагрузку на сервер и пользовательскую производительность.

Типичные ошибки кэширования

Первая ошибка состоит в одинаковом TTL для всех ресурсов.

Вторая в слишком долгом хранении файлов, URL которых не меняется после обновления.

Третья в кэшировании персонализированного HTML как публичного.

Четвёртая в отсутствии понятной invalidation после изменения данных.

Пятая в бесконечной ручной очистке кэша вместо нормального версионирования ресурсов.

Шестая в установке Redis без понимания, является ли база данных реальным узким местом.

Седьмая в проверке только настроек плагина вместо фактического HTTP ответа.

Восьмая в попытке оценивать SEO результат по факту включения технологии, а не по изменившейся производительности.

Кэширование и SEO оптимизация

Кэширование относится к технической оптимизации, но его задача не заключается в прямом управлении ранжированием.

Правильный подход начинается с диагностики.

Если сервер медленно формирует публичные страницы, page cache может оказаться подходящим решением.

Если основная нагрузка создаётся повторными запросами WordPress к базе на динамических страницах, полезнее может быть persistent object cache.

Если повторный пользователь заново получает неизменившиеся ресурсы, необходимо проверить browser cache.

Если аудитория распределена географически, может иметь смысл CDN.

Главное правило заключается в устранении конкретного ограничения, а не в установке всех видов кэша одновременно.