Кэширование сайтов: виды и подходы

Кэширование — самый быстрый способ ускорить сайт и снизить нагрузку на сервер, независимо от платформы. Смысл один и тот же на любом стеке: не делать одну и ту же дорогую работу дважды, если можно один раз сохранить результат и отдавать его повторно.

Разные платформы решают эту задачу разными механизмами — от статической генерации при сборке (Astro) до многоуровневых плагинных схем (WordPress) и композитного кэша с тегами (Bitrix). Ниже — общие уровни кэширования и то, как они реализованы на четырёх популярных платформах.

Уровни кэширования

Кэш сайта — это не одна система, а несколько независимых уровней, которые работают вместе.

Браузерный кэш

Снижает количество запросов к серверу за счёт хранения статических файлов (изображения, CSS, JS) на компьютере посетителя.

Механизм работы:

• Сервер отправляет заголовки Cache-Control (особенно max-age) и Expires
• Браузер проверяет Entity Tags (ETag) вместо повторной загрузки
• Сервер отвечает 304 Not Modified вместо 200 OK с телом файла

Cache-Control: public, max-age=31536000, immutable

Результат — меньше трафика и быстрее загрузка при повторных визитах. Работает одинаково независимо от платформы; разница только в том, как каждый стек выставляет заголовки (см. примеры ниже).

CDN

Content Delivery Network кэширует статику (и иногда целые HTML-страницы) на edge-серверах, географически близких к посетителю. Уменьшает задержку и снимает нагрузку с origin-сервера. Практически обязателен для медиа- и изображение-тяжёлых сайтов; современные платформы (Vercel, Netlify, Cloudflare) встраивают CDN как часть деплоя.

Серверный / edge-кэш (full-page cache)

Кэширование готового HTML-ответа целиком, до того как запрос доходит до кода приложения. Реализуется реверс-прокси (Varnish, Nginx FastCGI Cache), edge-функциями (Vercel Edge, Cloudflare Workers) или встроенными механизмами платформы (page cache плагины в WordPress, композитный кэш в Bitrix, статическая генерация в Astro/Next.js). Даёт наибольший прирост скорости, но требует аккуратной инвалидации для персонализированного и динамического контента (корзина, личный кабинет).

Объектный кэш (данные / вычисления)

Перенос данных из медленного и дорогого хранилища (БД, внешний API) в быстрое и дешёвое (память). В отличие от кэша страниц, обычно персистентный: данные, закэшированные при одном запросе, доступны при следующем.

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

Движки объектного кэша:

Движок	Тип	Особенности
Redis	In-memory	Самый популярный, богатая структура данных
Memcached	In-memory	Простой, проверенный временем
APC/u	In-memory	Локальный для одного сервера
Файловая система	Disk-based	Не требует доп. сервисов

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

Opcode-кэш

Специфичен для PHP-платформ (WordPress, Bitrix): сохраняет скомпилированный байт-код в памяти, избавляя от повторного парсинга и компиляции PHP-файлов на каждый запрос. OPcache встроен в PHP 5.5+ и должен быть включён всегда. У JS-платформ (Astro, Next.js на Node.js) прямого аналога нет — V8 компилирует и JIT-оптимизирует код в рамках процесса рантайма.

Примеры на платформах

1С-Битрикс

Битрикс сочетает кэш компонентов, тегированную инвалидацию и композитный режим:

• Кэш компонентов — каждый компонент можно кэшировать индивидуально (CACHE_TYPE: авто / управляемый / отключён), результат хранится через \Bitrix\Main\Data\Cache.
• Управляемый кэш (тегированный) — через \Bitrix\Main\Data\TaggedCache кэш привязывается к тегам (например, к ID инфоблока); при изменении данных сбрасываются только связанные теги, а не весь кэш.
• Композитный сайт (Composite Cache) — гибрид статического и динамического: страница отдаётся как статический HTML, а персонализированные зоны (корзина, авторизация, счётчики) подгружаются отдельными AJAX-запросами поверх, похоже на ESI. Позволяет держать полный full-page cache даже для сайтов с личным кабинетом.
• Бэкенд хранения — файлы по умолчанию, либо Memcached/APCu/Redis через секцию cache в .settings.php.

WordPress

WordPress собирает кэш из плагинов и ядра — три встроенных механизма плюс инфраструктурный уровень:

• Страничный кэш через плагины (Surge, WP Rocket, W3 Total Cache, Batcache) — сохраняет HTML целиком.
• Объектный кэш через WP_Object_Cache, персистентный с Redis/Memcached-плагинами.
• Transients API — кэш с TTL для внешних данных и тяжёлых запросов.
• Инфраструктура — OPcache, Varnish/Nginx FastCGI перед PHP.

Подробный разбор каждого механизма и примеров кода — в разделе Кэширование в WordPress и на странице Кэширование WordPress: инфраструктурный уровень.

Astro

Astro по умолчанию — статический генератор (SSG): страницы рендерятся в HTML на этапе сборки, а не на каждый запрос.

• Статический вывод (output: 'static') — готовые HTML-файлы и хешированные статические ассеты (/_astro/*.abc123.js) с Cache-Control: public, max-age=31536000, immutable — их можно кэшировать бессрочно, потому что при изменении содержимого меняется имя файла.
• On-demand rendering — для отдельных маршрутов (export const prerender = false) или всего сайта (output: 'server') страницы рендерятся по запросу через серверный адаптер (Vercel, Netlify, Cloudflare, Node.js); заголовки кэша выставляются вручную в коде страницы через Astro.response.headers.set('Cache-Control', ...).
• Дальше кэш такого ответа обеспечивает edge/CDN-слой хостинг-платформы — сам Astro не хранит кэш ответов. Встроенного персистентного кэша данных (аналога Next.js Data Cache) у Astro нет — Content Collections компилируются один раз при сборке.

Next.js

Next.js 16 перешёл на модель Cache Components (директива "use cache" + cacheComponents: true в конфиге) — она заменяет прежнюю связку Request Memoization / Data Cache / Full Route Cache / Router Cache для проектов, которые её включили:

• "use cache" — кэширует результат асинхронной функции или целого компонента; управляется cacheLife() (время жизни) и cacheTag() (теги для точечной инвалидации).
• Partial Prerendering (PPR) — страница собирается частично на этапе сборки (статический “shell”), а динамические куски (персонализация, cookies) стримятся при запросе внутри <Suspense>.
• Инвалидация — по тегам (updateTag/revalidateTag) или по времени через cacheLife.

Для проектов без cacheComponents действует прежняя модель: Request Memoization (дедуп fetch() в рамках рендера), Data Cache (персистентный кэш fetch()), Full Route Cache (предрендер статических маршрутов), Router Cache (клиентский кэш навигации), инвалидация через revalidate/revalidatePath/revalidateTag. При деплое на Vercel поверх добавляется edge/CDN-кэш. Про связку с WordPress как headless-бэкендом — Headless WordPress с Next.js.

Сравнение подходов

Платформа	Full-page cache	Объектный/данные кэш	Инвалидация	Типичный edge/CDN слой
1С-Битрикс	Композитный кэш (статика + AJAX-зоны)	Кэш компонентов, Memcached/Redis	По тегам (TaggedCache)	Внешний (CDN, Nginx)
WordPress	Плагины (Surge, WP Rocket, Batcache)	WP_Object_Cache + Redis/Memcached	По событиям публикации/сохранения	Varnish, Nginx FastCGI, внешний CDN
Astro	Статические файлы при сборке	Нет встроенного (компиляция при сборке)	Пересборка / заголовки на edge	Встроен в хостинг-платформу
Next.js	Full Route Cache / PPR-shell	"use cache" (Cache Components) или Data Cache (fetch)	По тегам (cacheTag/updateTag, revalidateTag) или по времени (cacheLife, revalidate)	Встроен в Vercel/edge

Выбор стратегии

Для большинства сайтов достаточно одного-двух уровней: браузерный кэш есть всегда «бесплатно», а full-page/статический кэш даёт наибольший прирост при наименьших усилиях. Объектный кэш и opcode-кэш подключаются, когда растёт нагрузка на БД и PHP; CDN и edge-кэш — когда важна география аудитории.

Материалы и источники

• WordPress Developer Handbook — Cache — официальная документация
• Astro — On-demand rendering — режимы рендеринга и настройка заголовков кэша
• Next.js — Caching — официальная документация по Cache Components (use cache, cacheLife, cacheTag)
• 1С-Битрикс — Кеширование компонентов — курс разработчика Bitrix Framework
• Кэширование в WordPress: обзор — детальный разбор механизмов ядра
• Кэширование WordPress: инфраструктурный уровень — OPcache, Varnish, Nginx FastCGI