Как настроить кэширование сайта для ускорения загрузки

Вы когда-нибудь замечали, что ваш сайт загружается быстро при первом посещении, но при повторных визитах — ещё быстрее? Это работает кэш браузера. А задумывались ли вы, почему после очистки кэша сайт снова становится медленным на несколько секунд? Значит, серверное кэширование настроено неправильно или отсутствует.

В этой инструкции — полная картина всех видов кэширования, от простого браузерного до продвинутых техник с дельта-компрессией для часто обновляемых приложений. Компания EDGESECTION занимается разработкой и оптимизацией сайтов, включая тонкую настройку всех уровней кэша под высокие нагрузки и требования Core Web Vitals 2026.

Что такое кэширование и зачем оно нужно

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

Для повторных посетителей правильно настроенный кэш сокращает время загрузки на 70–90%. И Google это знает: с 2026 года Core Web Vitals стали ещё более значимым фактором ранжирования. Если ваш сайт медленный — вы теряете позиции даже с отличным контентом.

Уровень 1. Браузерное кэширование (HTTP Cache)

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

Настройка заголовка Cache-Control

Управляется через HTTP-заголовок Cache-Control, который сервер добавляет к каждому ответу. Основные директивы:

>

Рекомендация Google: все статические ресурсы (шрифты, изображения, скрипты, стили) должны иметь срок жизни кэша не менее 30 дней (2 592 000 секунд).

Как настроить Cache-Control в разных окружениях

Apache (.htaccess)

 Header set Cache-Control "max-age=31536000, public" 

Header set Cache-Control "max-age=3600, public"

Nginx

location ~* .(jpg|jpeg|png|gif|ico|css|js|woff2|webp|avif)$ { expires 1y; add_header Cache-Control "public, immutable"; }
location ~* .(html|htm)$ {
expires 1h;
add_header Cache-Control "public";
}

Валидация кэша: ETag и Last-Modified

Даже если ресурс закэширован, браузер может проверить, не изменился ли он. Это делается через заголовки ETag (уникальный хеш файла) или Last-Modified (дата изменения). Если ресурс не изменился, сервер отвечает кодом 304 (Not Modified) — данные не передаются, но браузер знает, что кэш можно использовать.

Уровень 2. Серверное кэширование страниц (Page Cache)

Это кэш готового HTML на стороне сервера. Без него при каждом запросе сервер запускает PHP-движок (WordPress, Битрикс, Laravel), выполняет запросы к базе данных, собирает страницу из шаблонов — и только потом отдаёт её пользователю. Это занимает 200–2000 мс.

С серверным кэшем страниц готовый HTML сохраняется в память или на диск. При следующем запросе сервер отдаёт его мгновенно, даже не запуская PHP. Время ответа падает до 5–20 мс.

Настройка Nginx fastcgi_cache (рекомендуемый способ)

Это самый быстрый и надёжный метод кэширования для LEMP-стеков (Linux, Nginx, MySQL, PHP).

Шаг 1. Создайте зону кэша в nginx.conf

fastcgi_cache_path /var/cache/nginx/wp levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=2g;

Шаг 2. Настройте условия пропуска кэша

map $http_cookie $skip_cache { default 0; ~*wordpress_logged_in 1; # Пропустить для админов ~*comment_author 1; # Пропустить для оставивших комментарий ~*woocommerce_items_in_cart 1; # Пропустить для корзины WooCommerce }
map 
requesturi
request u riskip_cache_uri {
default 0;
~*^/wp-admin/ 1; # Пропустить админку
~*^/cart 1; # Пропустить корзину
~*^/checkout 1; # Пропустить оформление заказа
}

Шаг 3. Примените кэширование в location ~ .php$

location ~ .php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_cache WORDPRESS;
fastcgi_cache_skip 
skip cache;
fastcgi no cache;
skip_cache;
fastcgi_cache_valid 200 301 302 10m;
fastcgi_cache_use_stale error timeout updating;
add_header X-Cache-Status $upstream_cache_status;
}

После настройки вы будете видеть в заголовках ответа X-Cache-Status: HIT (попадание в кэш) или MISS (промах).

Для пользователей Apache и shared-хостинга

Если нет доступа к настройке Nginx, используйте плагин кэширования:

• WordPress: WP Rocket (платный), LiteSpeed Cache (бесплатный для LS-хостингов), W3 Total Cache
• 1С-Битрикс: встроенный механизм кэширования через CPageCache и CPHPCache

Уровень 3. Объектный кэш (Redis / Memcached)

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

Когда особенно эффективен:

• Сайты с большим количеством пользовательских опций
• WooCommerce (запросы к товарам, корзинам)
• Сайты на 1С-Битрикс с высокой нагрузкой
• Проекты с кастомными сложными запросами к БД

Настройка Redis для WordPress

1. Установите Redis на сервере: sudo apt install redis-server
2. Установите плагин Redis Object Cache
3. Подключитесь к Redis и включите кэш
4. Проверьте hit rate — должно быть >90%

Настройка для 1С-Битрикс

Битрикс поддерживает memcached и redis через настройки в файле dbconn.php:

define("BX_CACHE_TYPE", "memcache"); define("BX_CACHE_SID", $_SERVER["DOCUMENT_ROOT"]."#01"); define("BX_MEMCACHE_HOST", "127.0.0.1"); define("BX_MEMCACHE_PORT", "11211");

При использовании memcached кэш хранится в оперативной памяти и автоматически вытесняется по алгоритму LRU (Least Recently Used), переставая "расползаться" по диску.

Уровень 4. Кэш байткода PHP (OPcache)

Когда PHP-скрипт выполняется, он компилируется в байт-код. Без OPcache это происходит при каждом запросе. С OPcache скомпилированный байт-код сохраняется в памяти и переиспользуется для последующих запросов.

Разница колоссальная: сайт на WordPress без OPcache может тормозить даже на мощном сервере.

Настройка OPcache

Файл: /etc/php/8.x/fpm/conf.d/10-opcache.ini (для Debian/Ubuntu) или /etc/php-fpm.d/www.conf (для CentOS/RHEL)

opcache.enable=1 opcache.enable_cli=0 opcache.memory_consumption=256 opcache.interned_strings_buffer=16 opcache.max_accelerated_files=20000 opcache.validate_timestamps=1 opcache.revalidate_freq=60 opcache.fast_shutdown=1

Параметры для продакшена:

• memory_consumption=256 — выделите 256 МБ для кэша (для крупных проектов — 512 МБ)
• max_accelerated_files=20000 — сколько файлов кэшировать (для WordPress обычно 5000–10000)
• revalidate_freq=60 — как часто проверять, не изменился ли файл (в секундах)

Уровень 5. Кэширование в CMS и фреймворках

1С-Битрикс: встроенное кэширование компонентов

В Битрикс есть два класса для кэширования:

• CPageCache — для кэширования готового HTML всей страницы
• CPHPCache — для кэширования HTML + PHP-переменных (данных из БД)

Пример кэширования HTML страницы:

<?php
$obCache = new CPageCache();
$life_time = 30 * 60; // 30 минут
$cache_id = $ELEMENT_ID . $USER->GetUserGroupString();

if ($obCache->StartDataCache($life_time, $cache_id, "/")) {
    // Ресурсоёмкий код: запросы к БД, сложные вычисления
    $arResult = getIBlockElement($ELEMENT_ID);
    echo "

";
    print_r($arResult);
    echo "

";
    
    $obCache->EndDataCache();
}
?>

Очень важно формировать $cache_id с учётом всех переменных, которые влияют на результат: ID элемента, группы пользователя, параметры сортировки, номер страницы пагинации.

Очистка кэша в Битрикс: администрирование → Настройки продукта → Автокеширование → Очистка файлов кэша
Отключение кэша при разработке: добавить в URL &clear_cache=Y или &clear_cache_session=Y (для всей сессии)

WordPress: транзиты и объектный кэш

WordPress имеет встроенную систему транзитов для кэширования данных, но плагины объектного кэша эффективнее.

Плагины для ускорения WP в 2026:

• WP Rocket (оптимальный баланс функционала и простоты)
• LiteSpeed Cache (только для серверов LiteSpeed, очень мощный)
• Perfmatters (для отключения ненужных скриптов)

Уровень 6. CDN (Content Delivery Network)

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

Как правильно настроить CDN:

• Закэшируйте статику: CSS, JS, изображения, видео, шрифты — на длительный срок
• Для динамики (HTML) либо не используйте CDN, либо настройте короткий TTL (например, 5 минут)
• Настройте PULL-режим (CDN сам забирает файлы с вашего сервера) — удобнее и дешевле PUSH-режима
• Включите брокерование кэша (cache purging) — при обновлении файла на сервере CDN должна удалять старую версию

Популярные CDN в России 2026: Cloudflare (бесплатный тариф), VK Cloud CDN (PULL-режим), Qrator

Продвинутая техника 2026: Shared Dictionaries (дельта-компрессия)

Это новая технология, которая особенно актуальна для часто обновляемых приложений (SPA, PWA, чат-боты, дашборды). При частых деплоях браузер вынужден заново скачивать весь JS-бандл, даже если изменилась одна строчка кода.

Как работает Shared Dictionaries: браузер сохраняет предыдущую версию файла и использует её как "словарь" для распаковки нового. Сервер отправляет только разницу (diff) между версиями. Результаты впечатляют: файл 272 КБ после gzip (92 КБ) при использовании словарей сжимается до 2,6 КБ.

Поддержка в 2026: Chrome 130+, Edge 130+ уже поддерживают. Firefox в процессе реализации. Cloudflare запустил бета-версию поддержки 30 апреля 2026.

Оптимизация TTFB и Core Web Vitals через кэш

TTFB (Time To First Byte) — время ожидания ответа от сервера. Это первая метрика, которая влияет на восприятие скорости. Целевой показатель — менее 200 мс.

Как снизить TTFB через настройку кэша:

• Включите серверный page cache (HTML отдаётся без запуска PHP)
• Настройте PHP-FPM с адекватным количеством процессов (pm.max_children рассчитывается исходя из RAM: на 2 ГБ — 10–15 процессов, на 4 ГБ — 20–25)
• Используйте OPcache для ускорения выполнения PHP
• Для динамических страниц, которые нельзя кэшировать целиком, используйте фрагментное кэширование (кешируйте только тяжёлые блоки, но не всю страницу)

Как улучшить LCP (Largest Contentful Paint) через кэширование

LCP — это время, за которое появляется самый крупный элемент на экране (обычно главная картинка или заголовок). Цель — менее 2,5 секунд.

Что делать для улучшения LCP:

1. Добавьте preload для главного изображения:
2. Уберите lazy loading с LCP-элемента (он должен грузиться мгновенно)
3. Сжимайте изображения в WebP или AVIF с помощью серверного кэша (модули pagespeed или плагины)
4. Настройте кэширование шрифтов с font-display: swap; — текст появится быстро даже до загрузки красивого шрифта

Чек-лист: всё ли настроено правильно

Пройдите по пунктам. Отвечайте "да" только если уверены.

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

• [ ] Статические файлы (CSS, JS, изображения, шрифты) имеют Cache-Control: max-age=31536000
• [ ] HTML-страницы имеют max-age от 1 часа до 1 дня
• [ ] Авторизованные пользователи и владельцы корзины не получают закэшированные страницы (используются no-cache или пропуск кэша по cookie)

Серверный кэш

• [ ] Включён page cache (Nginx fastcgi_cache или плагин)
• [ ] Включён и настроен OPcache (memory_consumption >= 256MB)
• [ ] Для тяжёлых SQL-запросов используется объектный кэш (Redis/Memcached)

Техники оптимизации

• [ ] Изображения конвертированы в WebP/AVIF (или настроена автоматическая конвертация)
• [ ] Включена gzip или Brotli компрессия
• [ ] Настроен CDN (хотя бы для изображений и статических файлов)

Инструменты для проверки

• [ ] Google PageSpeed Insights — оценка не ниже 90 для десктопа и 70 для мобильных
• [ ] Chrome DevTools → Network — столбец Size показывает "(cache)" или "(memory cache)"
• [ ] Открыть сайт в новом инкогнито-окне — страница должна загружаться не дольше 2 секунд

Частые ошибки и как их избежать

Ошибка 1. Кэшируются страницы с персонализированным контентом

Проблема: в кэш попадают страницы с корзиной, личным кабинетом, приветствием "Здравствуйте, Иван!". В итоге пользователи видят чужие данные.

Решение: настройте пропуск кэша по cookie (в Nginx — map $http_cookie $skip_cache) или используйте директиву Cache-Control: private для таких страниц.

Ошибка 2. Слишком короткий TTL для статики

Проблема: max-age=3600 для CSS и изображений — каждый час браузер перезагружает их.

Решение: установите max-age=31536000 (1 год) и используйте cache busting при обновлении.

Ошибка 3. Бесконтрольный рост папки с кэшем

Проблема: на диске накапливаются гигабайты файлов кэша (особенно актуально для Битрикс по умолчанию).

Решение: настройте memcached или redis — они автоматически вытесняют старые данные и не растут бесконтрольно. Или настройте в Nginx inactive=60m max_size=2g.

Ошибка 4. Кэширование включено, но не работает из-за cookies

Проблема: любой cookie (даже несущественный) может заставлять сервер пропускать кэш.

Решение: явно укажите, какие cookie игнорировать, и настройте карту skip_cache только для критических: корзина, авторизация.

Заключение: кэширование как фундамент производительности

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

• Браузерный кэш — для повторных визитов
• Серверный page cache — для мгновенной отдачи HTML без запуска PHP
• Объектный кэш (Redis/Memcached) — для данных из БД
• OPcache — для байт-кода PHP
• CDN — для географического приближения статики

Начните с малого: проверьте заголовки Cache-Control и включите OPcache. Затем переходите к серверному page cache — это даст наибольший прирост. Если сайт на WordPress или Битрикс — настройте объектный кэш. И только потом, когда база готова, подключайте CDN.

Компания EDGESECTION оказывает услуги по разработке и технической оптимизации сайтов под высокие нагрузки. Мы настраиваем все уровни кэширования, решаем проблемы с TTFB, LCP и Core Web Vitals. Ваш сайт будет загружаться мгновенно даже при пиковых нагрузках — а вы будете в топе выдачи Google.