WP Fastest Cache для WordPress: правильные настройки и история одного сломанного сайта

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

Именно это произошло на сайте стоматологической клиники, который я вёл. Разберу по порядку: что случилось, почему виноват оказался плагин WP Super Cache, и как настроить WP Fastest Cache так, чтобы история не повторилась.

Зачем вообще кеш страниц

Без кеша каждый заход посетителя запускает полный цикл: поднимается ядро WordPress, грузятся все плагины и тема, выполняются запросы к базе, собирается HTML. На среднем сайте это 0,5–1,5 секунды до первого байта.

Кеш страниц сохраняет готовый HTML в файл и отдаёт его напрямую, минуя PHP и базу. Время ответа падает до 50–150 мс. Разница видна и в Core Web Vitals, и в поведении поисковых роботов, и в нагрузке на хостинг при наплыве трафика.

На сайте клиники, о котором идёт речь, генерация страницы занимала 2,83 секунды. После включения кеша — под 0,3 секунды. Это тот случай, когда одна настройка даёт больше, чем неделя оптимизации картинок.

Почему WP Fastest Cache

Бесплатная версия закрывает всё, что нужно типовому сайту: кеш страниц, gzip, заголовки браузерного кеша, предварительная загрузка, минификация, гибкие исключения. Настройки собраны на одной странице, интерфейс переведён на русский, документация по совместимости с конструкторами есть на сайте разработчика.

Плагин работает на Apache через .htaccess и на nginx. На серверах LiteSpeed разумнее ставить LiteSpeed Cache — там кеш живёт на уровне сервера, а не PHP, и это принципиально быстрее. Проверить свой сервер можно в разделе «Инструменты → Здоровье сайта → Информация → Сервер», строка «ПО веб-сервера».

Базовая настройка WP Fastest Cache: что включить

Не ставьте все галки разом. Сначала база, потом проверка, потом добавки — иначе при поломке невозможно понять, что именно виновато.

Вкладка «Настройки», включаем:

Опция	Зачем
Система кеширования	Главный переключатель, без него остальное не работает
Предварительная загрузка	Плагин сам обходит сайт и создаёт кеш заранее. Отметьте главную, записи, страницы, рубрики. Интервал 4–6 страниц в минуту
Зарегистрированные пользователи	Не показывать кеш авторизованным. Вы и клиент всегда видите актуальную версию
Новая запись	Сброс кеша при публикации
Обновить запись	Сброс при редактировании. Для сайтов с блогом обязательно
Gzip	Сжатие ответов. Экономит до 80% веса страницы
Кэш браузера	Заголовки Expires для картинок, шрифтов, скриптов
Отключить Emojis	Минус один скрипт на каждой странице, побочных эффектов нет

Язык интерфейса переключается там же, внизу списка.

Что включать не нужно

Этот раздел важнее предыдущего. Большинство проблем с кеш-плагинами приходит именно отсюда.

Минификация CSS и Объединить CSS. Объединение файлов стилей ломает порядок каскада — самая частая причина «поехавшей» вёрстки. Выигрыш при этом копеечный, особенно если стили конструктора встроены в страницу.

Минификация JS, Объединить JS, Объединить JS Plus. Главный источник белых экранов на сайтах с конструкторами. Скрипты Elementor, слайдеров, форм и аналитики объединяются в неправильном порядке, и часть функциональности просто перестаёт работать. Проверяется это не на главной, а на всех типах страниц, что мало кто делает.

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

Мобильный и Мобильная тема. Нужны только при отдельной мобильной теме. Для адаптивной вёрстки это удвоение объёма кеша без всякого смысла.

Минификация HTML — единственное из спорного, что можно включить. Но отдельно, после того как база заработает, и с обязательной проверкой нескольких типов страниц.

Вкладка «Исключить»

Два правила плагин создаёт сам — для wp-login.php и wp-admin. Их не трогаем. Добавляем своё через кнопку «Добавить новое правило»: выбираем условие, вписываем значение без домена, сохраняем.

Разделы «Исключить CSS» и «Исключить JS» нужны только при включённой минификации. Если вы её не включали, оставьте пустыми.

Дополнительные настройки для сайта на Elementor

Без них любой кеш-плагин рано или поздно покажет посетителям сайт без стилей.

Инструкция: Как получить лицензию ELementor за 84$ — бесплатно!

Шаг 1. Перевести CSS в тело страницы

Elementor → Настройки → Производительность → Метод генерации CSS → Встраивание в код.

Вместо ссылки на внешний файл стили попадают прямо в <head> страницы. HTML и оформление становятся одним объектом — рассинхрон физически невозможен. Файл нельзя потерять, если файла нет.

Цена вопроса: страница тяжелеет на 40–100 КБ без сжатия, то есть на 8–18 КБ реально переданных. Взамен исчезают два-четыре блокирующих рендеринг запроса, что на мобильном соединении стоит 100–250 мс от времени до отрисовки. На сайтах, куда люди приходят из поиска и рекламы на конкретную страницу, баланс уверенно в пользу встраивания.

Шаг 2. Отключить кеш элементов

Elementor → Настройки → Производительность → Кэш элемента → Отключить.

Именно с временем жизни этого кеша связан суточный цикл очистки папки со стилями. Отключение рекомендует и сам WP Fastest Cache в своей документации по совместимости.

Не путайте эту опцию с кешем страниц: она хранит отрисованные копии отдельных виджетов и на скорость влияет в пределах процентов. Терять тут нечего.

Шаг 3. Проверить экспериментальные функции

Elementor → Настройки → Возможности. Экспериментальные пункты вроде «Улучшенная загрузка CSS» и «Инлайн иконок шрифтов» меняют способ доставки ресурсов и в паре со сторонним кешем дают похожие артефакты. Если они вам не нужны — Inactive.

Шаг 4. Исключить редактор из кеша

Добавьте в «Исключить страницы» три правила с условием «Содержит»:

elementor-preview
elementor_library
action=elementor

Формально WP Fastest Cache не кеширует адреса с параметрами запроса, а редактор работает как раз через них. Но правила ставятся за минуту и страхуют от изменений в будущих версиях.

Шаг 5. Проверить локальные шрифты

Функция «Загружать Google шрифты локально» создаёт файлы с именами вида local-1002-frontend-desktop.css в той же папке /uploads/elementor/. На них встраивание CSS не распространяется — они остаются внешними и падают под ту же чистку.

Если после всех настроек вы всё-таки ловите поломку, и в консоли 404 именно на local-*.css, есть два пути: отключить функцию и подключить шрифты через @font-face в теме, либо оставить как есть и мириться с редкими сбросами. Для клиентских сайтов я выбираю первое — свои файлы .woff2 в теме дают полный контроль и не зависят от генератора.

Шаг 6. Связать кеши хуком

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

php

/**
 * Синхронизация кеша Elementor и кеш-плагина.
 *
 * Проблема: Elementor периодически удаляет сгенерированные CSS-файлы
 * из /wp-content/uploads/elementor/css — при обновлениях, сохранении
 * шаблонов и по крону. Кеш-плагин продолжает отдавать сохранённый HTML
 * со ссылками на удалённые файлы, и сайт открывается без стилей.
 *
 * Решение: перехватываем момент очистки и сразу сбрасываем кеш страниц,
 * чтобы разметка и стили всегда были одного поколения.
 *
 * Куда положить: mu-plugin или плагин для пользовательского кода.
 * В functions.php темы тоже работает, но при обновлении темы потеряется.
 */

// Хук срабатывает при любой очистке сгенерированных файлов Elementor
add_action( 'elementor/core/files/clear_cache', 'wpfc_flush_after_elementor', 20 );

// Дополнительно ловим сохранение любого документа Elementor:
// при правке шаблона хедера или футера меняются стили сразу многих страниц
add_action( 'elementor/document/after_save', 'wpfc_flush_after_elementor', 20 );

function wpfc_flush_after_elementor() {

    // WP Fastest Cache: класс существует только при активном плагине,
    // проверка страхует от фатальной ошибки при его отключении
    if ( class_exists( 'WpFastestCache' ) ) {
        do_action( 'wpfc_clear_all_cache', true ); // true — чистить и минифицированные файлы
    }

    // WP Super Cache: функция объявляется только при активном плагине
    if ( function_exists( 'wp_cache_clear_cache' ) ) {
        wp_cache_clear_cache( get_current_blog_id() ); // аргумент нужен для мультисайта
    }

    // WP Rocket: у него есть своя интеграция, но лишний сброс не повредит
    if ( function_exists( 'rocket_clean_domain' ) ) {
        rocket_clean_domain();
    }
}

При встроенном CSS этот код не нужен. Но если ведёте чужие сайты на поддержке, держите его под рукой.

Проверка результата

Галки поставлены — теперь убедитесь, что они работают, а не просто стоят.

Через браузер

Откройте сайт в режиме инкогнито, нажмите Ctrl+U и прокрутите в самый низ исходного кода. WP Fastest Cache оставляет комментарий с временем создания кеша. Есть комментарий — кеш отдаётся.

Там же поиском по uploads/elementor/css проверьте, что ссылок на внешние стили Elementor не осталось. Если вместо них находится блок <style id="elementor-frontend-inline-css"> — встраивание работает.

Ориентиры: время до первого байта 0,05–0,2 с, переданный объём 25–40 КБ для типовой страницы. Если время не упало — кеш не отдаётся, проверяйте .htaccess и права на папку wp-content/cache.

Контроль стилей на следующий день

Главная проверка — пережить суточную чистку Elementor. Откройте сайт через сутки в инкогнито с открытой вкладкой «Сеть» и фильтром -status-code:200. Пусто — значит, всё настроено правильно.

Для клиентских сайтов эту проверку удобно поставить на автомат:

Если переходите с другого кеш-плагина

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

1. В старом плагине сначала отключите кеширование и сбросьте кеш, и только потом деактивируйте и удалите сам плагин.
2. Проверьте, что удалились wp-content/advanced-cache.php и папка wp-content/cache/. У WP Super Cache есть ещё wp-content/wp-cache-config.php.
3. В wp-config.php уберите строку define('WP_CACHE', true); — новый плагин пропишет свою.
4. В .htaccess вычистите блок между # BEGIN WPSuperCache и # END WPSuperCache.
5. Только после этого ставьте новый плагин.

Два кеш-плагина одновременно — гарантированные необъяснимые баги. Держите активным ровно один.

Частые ошибки

Включить всё разом. Потом непонятно, что сломало сайт. Идите по шагам с проверкой.

Проверять только главную. Ломается обычно то, что на главной не встречается: формы, слайдеры, фильтры каталога, страницы врачей или товаров. Проверяйте пять-шесть типов страниц.

Забыть про совпадающие функции других плагинов. Оптимизаторы вроде Clearfy, сборки от разработчиков тем, плагины лениво загружаемых картинок — у всех есть свои минификация и отложенная загрузка. Две системы, работающие с одними и теми же скриптами, дают странности, которые потом ищут часами.

Не проверить сжатие. После смены плагина правила из .htaccess могут не восстановиться. Страница весом 180 КБ вместо 30 КБ — это вся экономия от кеша, выброшенная в трубу. Проверяется одной командой выше.

Чистить базу без бэкапа. Вкладка DB предлагает удалить ревизии, черновики и транзиенты. Полезно, но сначала копия базы.

История: как WP Super Cache оставил сайт без стилей

Сайт работает на Elementor. Раз в несколько дней он открывался без дизайна: текст, ссылки, структура на месте, оформления нет. Заход в админку, кнопка «Удалить кеш» — и всё возвращалось. До следующего раза.

Вот что выяснилось в DevTools на вкладке «Сеть» с фильтром по неуспешным ответам:

global-1002-frontend-desktop.css?ver=8334ad422b00   404
local-1002-frontend-desktop.css?ver=571e39bfea5b    404
global-1002-frontend-tablet.css?ver=8334ad422b00    404
global-1002-frontend-mobile.css?ver=8334ad422b00    404

Шесть запросов к стилям Elementor, все с кодом 404, каждый по полторы секунды. Механика оказалась такой:

1. Elementor по умолчанию складывает сгенерированные стили в отдельные файлы в папке /wp-content/uploads/elementor/css/.
2. Эти файлы он периодически удаляет — при обновлениях, при сохранении шаблонов и по крону примерно раз в сутки.
3. Кеш-плагин продолжает отдавать сохранённый HTML со ссылками на уже удалённые файлы.
4. PHP при этом не выполняется — статика отдаётся напрямую. Значит, Elementor не получает шанса сгенерировать файл заново.
5. Посетитель видит сайт без стилей.

Ручной сброс кеша разрывал цепочку: следующий запрос шёл через PHP, Elementor пересобирал CSS, дизайн возвращался.

Почему WP Super Cache всё-таки не стоит выбирать сегодня

Причины объективные, и они не про «ломает сайт»:

Нет интеграции с современными конструкторами. WP Rocket и LiteSpeed Cache подписаны на хуки очистки Elementor и сбрасывают свой кеш автоматически. WP Super Cache про Elementor не знает ничего — отсюда и цикл «раз в сутки ломается, пока не почистишь руками».

Развитие фактически остановилось. Плагин от Automattic, установок по-прежнему больше миллиона, но новых функций нет годами, а динамика загрузок падающая. Это не мёртвый проект, но и не тот, за которым стоит идти в 2026 году.

Настройки устарели по духу. Режим mod_rewrite, отдельная страница для сжатия, ручные исключения — всё это работает, но требует понимания, которого у большинства владельцев сайтов нет. Ошибка в настройке preload — и битая страница живёт в кеше неделями.

Вывод простой: если вы только выбираете кеш-плагин, берите что-то живое. Если у вас уже стоит WP Super Cache и всё работает — менять срочно не нужно, но и развития от него не ждите.

Итог

Правильная настройка кеша — это не «включить всё, что есть», а включить базу и не трогать опасное. Для сайта на Elementor к этому добавляются два обязательных шага на стороне самого конструктора: встраивание CSS в код и отключение кеша элементов. Вместе они закрывают тот самый сценарий с пропадающими стилями, из-за которого многие в итоге отказываются от кеширования вообще — и теряют на скорости гораздо больше, чем приобретают.

Если после настройки сайт работает быстрее, а через сутки всё ещё цел — вы всё сделали правильно.