Как исключить отдельные файлы из кэша в WordPress

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

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

Когда проблема действительно в кэше, а не в коде

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

Признаки, что нужно исключение из кэша

• после деплоя меняется CSS, но на сайте видна старая верстка;
• новый JS-файл есть на сервере, но в браузере загружается старая версия;
• проблема исчезает после очистки кэша, но возвращается при следующем обновлении;
• ошибка проявляется только при включённом плагине кэширования или CDN.

Что проверить до правок

• откройте файл напрямую по URL и убедитесь, что на сервере лежит нужная версия;
• посмотрите заголовки ответа в DevTools: cache-control, etag, last-modified;
• сравните URL файла в исходнике страницы и фактический URL в запросе;
• если используется версия в query string, проверьте, меняется ли параметр ?ver= после обновления.

Какой способ исключения выбрать

В WordPress это обычно делается не кодом, а настройкой плагина кэширования. Код нужен реже — например, когда вы хотите стабильно менять версию ассетов через wp_enqueue_style() и wp_enqueue_script(), чтобы браузер перестал держать старый файл.

Подход	Когда подходит	Минус
Исключение файла в плагине кэша	Нужно быстро убрать конкретный CSS/JS из кэширования	Настройка зависит от плагина
Версионирование ассета через filemtime()	Файлы меняются при деплое и нужен автоматический сброс браузерного кэша	Нужно править тему или плагин
Отключение минификации/объединения для файла	Проблема появляется после оптимизации JS/CSS	Может снизить выигрыш по скорости

Пошагово: как исключить CSS или JS из кэша

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

Шаг 1. Найдите проблемный файл

Откройте страницу в браузере, нажмите F12, перейдите во вкладку Network и обновите страницу. Отфильтруйте запросы по css или js и найдите файл, который не обновляется. Скопируйте его полный путь.

Пример: если в запросах виден /wp-content/themes/root/assets/js/header.js?ver=1.4.2, исключать нужно не только header.js, а весь путь, который использует ваш плагин кэша.

Шаг 2. Добавьте файл в исключения плагина

В большинстве плагинов есть поле для исключения отдельных файлов, путей или шаблонов URL. Названия разделов отличаются, но смысл один: указать файл так, чтобы плагин не пытался его оптимизировать, объединять или отдавать из устаревшего кэша.

Если плагин позволяет исключать по маске, используйте её только там, где это действительно нужно. Слишком широкое правило вроде /wp-content/themes/ может выключить кэширование для половины фронтенда.

Шаг 3. Сбросьте только нужный слой кэша

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

Пример: как правильно версионировать CSS и JS в теме

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

<?php
function mytheme_assets() {
    $css_path = get_stylesheet_directory() . '/assets/css/main.css';
    $js_path  = get_stylesheet_directory() . '/assets/js/main.js';

    wp_enqueue_style(
        'mytheme-main',
        get_stylesheet_directory_uri() . '/assets/css/main.css',
        array(),
        file_exists( $css_path ) ? filemtime( $css_path ) : null
    );

    wp_enqueue_script(
        'mytheme-main',
        get_stylesheet_directory_uri() . '/assets/js/main.js',
        array(),
        file_exists( $js_path ) ? filemtime( $js_path ) : null,
        true
    );
}
add_action( 'wp_enqueue_scripts', 'mytheme_assets' );

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

Если проблема в минификации или объединении файлов

Иногда сам файл кэшируется нормально, но ломается после объединения, сжатия или переноса в footer. Тогда исключать нужно не весь кэш, а конкретный файл из оптимизации. Это особенно заметно у скриптов, которые зависят от порядка загрузки.

Типичный сценарий: библиотека загружается после кода, который её использует, и на странице появляется ошибка jQuery is not defined или аналогичная проблема с зависимостями. В этом случае файл лучше исключить из объединения и проверить, исчезла ли ошибка.

Что делать в первую очередь

• отключите для проблемного файла объединение и минификацию;
• проверьте, не меняет ли плагин путь к файлу на версию из своей папки;
• если есть defer/delay JS, временно уберите файл из отложенной загрузки;
• посмотрите консоль браузера после очистки кэша.

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

Проверять нужно не только визуально. Идеальный сценарий — убедиться, что браузер действительно запрашивает новый файл, а не старую копию из памяти или service worker.

Чек-лист проверки

• в DevTools в Network у файла изменился URL или параметр ver;
• ответ приходит с актуальным содержимым, а не со старой версией;
• в консоли нет ошибок, связанных с этим файлом;
• после очистки кэша страницы и перезагрузки проблема не возвращается;
• если есть CDN, файл обновился и на его стороне.

Для быстрой проверки можно открыть файл в режиме инкогнито и сравнить содержимое с тем, что лежит на сервере. Если у вас подключён CDN, полезно проверить заголовки ответа через curl -I или любой HTTP inspector.

curl -I https://example.com/wp-content/themes/root/assets/js/main.js

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

Частые ошибки и как их исправить

Указывают не тот путь к файлу

Плагин может ожидать относительный путь, а вы вставляете полный URL, или наоборот. Из-за этого правило не совпадает с реальным запросом. Сверяйте формат с документацией конкретного плагина и тестируйте на одном файле.

Исключают только имя файла без учёта версии

Если файл подключается с параметром ?ver=, а плагин кэша сравнивает полный URL, одного имени недостаточно. В таком случае нужно исключать путь целиком или настроить версионирование через filemtime().

Забывают про CDN

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

Слишком широко отключают кэширование

Иногда в исключения добавляют целую папку /assets/ или даже весь /wp-content/. Это убирает проблему, но создаёт лишнюю нагрузку и ухудшает скорость загрузки. Лучше сузить правило до конкретного файла или подпапки.

Практические советы по безопасности и производительности

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

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

Если у вас несколько сред — staging и production — проверяйте исключения сначала на тестовой копии. Это особенно важно, когда файл участвует в критичном сценарии: меню, форма, фильтр, модальное окно или аналитика.

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