Что вообще такое кеширование и зачем оно нужно
Попробуем без заумных терминов.
Кеширование — это когда мы один раз делаем тяжёлую работу (генерируем страницу, считаем данные, загружаем картинку), а результат временно складываем «под рукой» — в быстрый кеш. И в следующий раз уже не пересчитываем всё с нуля, а отдаём готовый сохранённый результат.
По сути, кеш — это:
- «черновик» уже сгенерированной страницы;
- копия файла/запроса, сохранённая в более быстром месте;
- способ не напрягать сервер каждый раз по полной программе.
Если без кеша:
1 запрос пользователя → сервер запускает PHP/Node/Python → лезет в базу → собирает HTML → отправляет ответ. Так для каждого посетителя.
С кешем:
1 запрос пользователя → сервер смотрит, есть ли готовая копия страницы → если есть, просто отдаёт её, минуя всё тяжёлое.
Результат в цифрах:
- среднее время ответа без кеша: 500–1500 мс;
- с грамотно настроенным кешем: 80–200 мс;
- снижение нагрузки на процессор сервера: зачастую в 3–10 раз.
Какие бывают виды кеширования на сайте
Чтобы разобраться, как работает настройка кэширования сайта, надо понимать, какие вообще варианты есть. Разделю по уровням — от браузера до сервера и дальше.
1. Кеширование в браузере (client-side)
Это то, что происходит у посетителя.
Браузер может запоминать файлы:
- CSS, JS
- изображения
- шрифты
- иногда даже HTML
Когда пользователь заходит на сайт второй раз, браузер не тянет всё заново с сервера, а берёт часть ресурсов из кеша.
Ключевые заголовки, которыми это управляется:
- `Cache-Control`
- `Expires`
- `ETag`
- `Last-Modified`
Пример:
Если вы прописали `Cache-Control: max-age=2592000`, браузер будет использовать кешированную версию файла до 30 дней (2 592 000 секунд), пока не решит, что пора проверить обновления.
2. Кеширование на уровне сервера (server-side)
Здесь уже включаются:
- веб-сервер (Nginx, Apache)
- приложения (PHP-FPM, Node.js)
- системные кеши (OPcache, Memcached, Redis)
Самое частое — кеширование готовых HTML-страниц. Пример: пользователь заходит на страницу статьи в блоге, движок WordPress один раз её собирает, сохраняет в файловый кеш, и дальше всем гостям эта страница отдаётся уже как статический HTML.
3. Кеширование в базе данных
Если сайт активно лезет в БД, запросы можно:
- кэшировать в память (Redis/Memcached),
- или хотя бы оптимизировать и реже выполнять.
Например, если один и тот же запрос выполняется 5000 раз в час — есть смысл положить его результат в Redis на 60 секунд и резко разгрузить базу.
4. Кеширование на уровне CDN
CDN (Cloudflare, Fastly, Bunny, и т.д.) могут сохранять:
- статику (картинки, CSS, JS),
- HTML-страницы (если правильно настроить заголовки и правила).
Смысл простой: ваш сайт физически может находиться в Европе, а пользователь — в Новосибирске. CDN отдаёт кешированную копию с ближайшего сервера, экономя 100–200 мс только на географии.
Оптимизация скорости сайта с помощью кэширования: реальный пример
Реальный кейс: небольшая информационная витрина на WordPress, ~150 страниц, трафик 10–15 тыс. визитов в сутки.
До кеширования:
- TTFB (время до первого байта): 700–900 мс
- Полная загрузка страницы: 4–6 сек
- Пиковая нагрузка: 80–90% CPU на дешёвом VPS
После внедрения кеширования:
- включили кеширование страниц (page cache),
- настроили кеш браузера,
- вынесли статику на CDN.
Результат:
- TTFB: 120–180 мс
- Полная загрузка: 1.8–2.5 сек
- Нагрузка CPU упала до 20–30%
Что самое приятное — настроили всё примерно за 2–3 часа, без серьёзного ковыряния в коде, только плагины и базовые правки конфигов.
Как настроить кеширование в WordPress пошагово
WordPress — идеальная площадка, чтобы объяснить всё по шагам. Сейчас покажу базовый сценарий для обычного сайта/блога без кучи кастомной логики.
Шаг 1. Выбор плагина кеширования
Самый простой путь — использовать проверенный плагин. Они бывают:
- бесплатные (WP Super Cache, W3 Total Cache, LiteSpeed Cache)
- платные (WP Rocket, Swift Performance Pro и др.)
Если вы никогда этим не занимались и хотите «включил и поехало»:
- WP Rocket — один из самых удобных, но он платный;
- LiteSpeed Cache — бесплатный, но нужен сервер с LiteSpeed/OLS;
- W3 Total Cache мощный, но требует аккуратной настройки.
Отдельный момент — иногда владельцы сайтов думают, что если плагины кэширования для сайта купить подороже, всё «само взлетит». На деле даже дорогой плагин можно неправильно настроить и получить белый экран или сломанный дизайн.
Шаг 2. Включаем кеш страниц (Page Cache)
Основная функция плагина — хранить сгенерированные HTML-страницы.
Типовой алгоритм:
1. Заходим в настройки плагина.
2. Находим раздел Cache / Page Cache.
3. Включаем режим кеширования для гостей (не авторизованных).
Важно:
- нет смысла кешировать страницы личного кабинета, корзину, страницу оформления заказа — их обычно исключают;
- страницы, которые меняются каждую секунду (онлайн-чаты, биржевые котировки), требуют более аккуратной настройки.
Технический блок: пример настроек кеша страниц
Для Nginx часто добавляют что-то похожее:
```nginx
location / {
try_files /cache/$uri/index.html $uri $uri/ /index.php?$args;
}
```
А в самом PHP-приложении логика примерно такая:
- пришёл запрос
- проверили, есть ли в `/cache` уже сгенерированная версия
- если да — отдали её, не загружая весь WordPress.
Шаг 3. Кеш браузера
Здесь работает связка: сервер + HTTP-заголовки. Нам нужно сказать браузеру: «Храни статику у себя какое-то время, не качай всё заново».
Пример для Apache (`.htaccess`):
```apache
ExpiresActive On
ExpiresByType text/css "access plus 30 days"
ExpiresByType application/javascript "access plus 30 days"
ExpiresByType image/jpeg "access plus 30 days"
ExpiresByType image/png "access plus 30 days"
ExpiresByType image/svg+xml "access plus 30 days"
```
Что это даёт:
- повторы заходов на сайт становятся ощутимо быстрее;
- снижается трафик с сервера (особенно актуально, если он ограничен).
Шаг 4. Интеграция с CDN
Если у вас мультирегиональный трафик или тяжёлые картинки, CDN — почти must-have.
Типичные шаги:
- зарегистрироваться в CDN (Cloudflare, Bunny, KeyCDN и т.п.);
- подключить домен (либо через NS, либо через CNAME);
- в настройках CDN включить кеш статики (а при желании и HTML);
- проверить, чтобы заголовки `Cache-Control` не запрещали кеширование.
Многие плагины WordPress умеют автоматически переписывать URL статических файлов на CDN-домен (`cdn.site.ru`).
Настройка кэширования сайта не на WordPress: общая логика
Если у вас:
- самописный сайт,
- Laravel / Symfony / Django / Express / Nest,
- или любая другая платформа,
логика примерно такая же:
1. HTML-кеш (страниц)
- свой middleware, который сохраняет готовый HTML в файловую систему или Redis;
- исключение динамических страниц (личный кабинет, корзина, админка).
2. Кеш запросов к базе
- оборачиваем тяжёлые SELECT-запросы в слой кеша;
- задаём TTL (Time To Live) — например, 60–300 секунд.
3. Кеш статики
- правильно выдаём заголовки;
- по возможности выносим статику на отдельный домен/поддомен+CDN.
Технический блок: пример кеша в PHP с Redis
```php
$key = 'article_' . (int)$articleId;
$data = $redis->get($key);
if (!$data) {
$data = $db->query("SELECT * FROM articles WHERE id = {$articleId}")->fetch();
$redis->setex($key, 300, json_encode($data)); // храним 5 минут
} else {
$data = json_decode($data, true);
}
```
Частые ошибки новичков при настройке кеша
Вот здесь обычно и начинаются приключения. Разберём самые типичные промахи.
Ошибка 1. «Включил всё, что было в плагине»
Новый сайт, новый плагин — и рука сама тянется включить все галочки:
- HTML minify
- JS combine
- defer JS
- lazyload всего подряд
- object cache
- database cache
и ещё десяток опций.
Чем это заканчивается:
- ломается верстка;
- не работает корзина/формы;
- скрипты чата или аналитики отваливаются.
Как делать правильно:
- включать опции по одной;
- после каждого изменения проходить по ключевым страницам: главная, карточка товара, корзина, оформление заказа (если есть), контакты;
- иметь возможность быстро откатить настройки.
Ошибка 2. Кешируют то, что вообще не надо кешировать
Типичные жертвы:
- корзина интернет-магазина;
- личный кабинет;
- страница оплаты;
- страницы с пользовательским контентом «на лету».
Что происходит:
- один пользователь видит чужую корзину;
- данные профиля «залипают»;
- не подтягиваются актуальные статусы заказов.
Решение:
- чётко прописывать правила исключений в плагине или конфиге сервера;
- ориентироваться на URL (например, не кешировать `/cart`, `/my-account`, `/checkout` и т.п.);
- не кешировать страницы, завязанные на cookie/сессии.
Ошибка 3. Неправильный TTL: либо слишком маленький, либо запредельно большой
TTL — это время жизни кеша.
- Слишком маленький (5–30 секунд):
- кеш почти не помогает;
- сервер всё равно постоянно перерасчитывает страницы.
- Слишком большой (недели/месяцы) для HTML:
- изменения на сайте не видны;
- после правки текстов или дизайна людям ещё долго показывается старая версия.
Оптимальный подход:
- для HTML-страниц: от 5 минут до пары часов, плюс система очистки кеша при обновлении контента;
- для статики: вполне нормально ставить 30 дней и больше, если вы используете версионирование файлов (добавляете `?v=123` или меняете имя файла при обновлении).
Ошибка 4. Забыли про очистку кеша
Очень частая ситуация:
- вы обновили страницу,
- в админке всё красиво,
- а посетители по-прежнему видят старый вариант.
Причины:
- кеш не очищается автоматически после обновления контента;
- CDN продолжает отдавать старую копию;
- браузер пользователя держит старые файлы.
Что делать:
- настраивать автоматическую очистку кеша при публикации/обновлении записи (это умеют почти все популярные плагины);
- при сильных изменениях (редизайн, смена темы) принудительно сбрасывать кеш CDN;
- при работе с фронтендом использовать версионирование файлов.
Ошибка 5. Кеш вместо оптимизации кода
Кеш — не серебряная пуля. Если сайт:
- делает по 200–300 запросов к базе на одну страницу,
- тянет 8–10 МБ скриптов и картинок,
- генерирует страницу по 2–3 секунды из-за кривых плагинов,
кеширование поможет, но лишь частично. Вы всё равно будете бороться с:
- долгой первой генерацией страницы;
- высоким временем рендеринга на слабых устройствах.
Здравый подход:
- сначала убрать явный мусор (лишние плагины, тяжёлые запросы);
- потом уже включать кеш, чтобы ускорить и стабилизировать.
Когда лучше передать кеширование специалистам
Если у вас:
- интернет-магазин с оплатами и сложной корзиной;
- CRM/личный кабинет с кучей ролей и прав;
- высоконагруженный проект (десятки тысяч визитов в сутки),
ошибка с кешированием может обойтись гораздо дороже, чем сами услуги по настройке кэширования сайта. Особенно если затронуты:
- оплата и приём денег;
- авторизация и доступ к личным данным;
- отчёты и статистика.
В таких случаях имеет смысл:
- минимум проконсультироваться со специалистом по производительности;
- а часто — отдать настройку под ключ, с тестированием всех сценариев.
Итого: как подойти к кешированию без боли
Кратко, по шагам:
- Определитесь, что нужно кешировать:
- HTML-страницы,
- статические файлы,
- тяжёлые запросы к БД.
- Начинайте с простого:
- включите кеш страниц,
- настройте кеш браузера,
- при необходимости добавьте CDN.
- Избегайте классических ошибок:
- не кешируйте чувствительные к пользователю страницы,
- не включайте все функции плагина разом,
- следите за очисткой кеша и TTL.
- Для WordPress:
- выбирайте один основной плагин,
- не ставьте несколько кеш-плагинов одновременно,
- пошагово проверяйте сайт после каждого изменения.
- Помните:
- корректная настройка кэширования сайта даёт очень заметный прирост скорости;
- «нажал кнопку и забыл» — так бывает только на совсем простых проектах;
- если страшно сломать что-то важное, лучше один раз заплатить за грамотную настройку, чем потом чинить потери из-за ошибок.
Кеширование — это не магия, а аккуратная работа с тем, что и когда можно временно сохранить. Разобравшись один раз, вы будете смотреть на скорость сайтов совсем другими глазами.
