Кеш в DLE: что советуют на практике

В DLE кеш чаще всего становится заметен не тогда, когда ускоряет сайт, а когда посетители видят старую страницу после публикации новости или продолжают получать ошибку после правки шаблона. Для DLE 18.x рабочая стратегия проста: разделить кеш страниц, кеш шаблонов и кеш браузера, менять по одной настройке и проверять результат на незалогиненном пользователе. Обычно базовую диагностику можно провести за 15–30 минут, не удаляя файлы вручную и не трогая базу данных.

Что именно кеширует DLE

Под словом «кеш» владельцы сайта часто смешивают несколько разных механизмов. У них разные причины устаревших данных и разные способы очистки.

• Кеш страниц. DLE сохраняет готовый результат работы сайта, чтобы не собирать одну и ту же страницу заново при каждом запросе. Он особенно полезен для новостей, категорий и главной страницы с большим количеством посетителей.
• Кеш шаблонов. Система может хранить обработанные шаблоны. Поэтому после изменения HTML или CSS браузер иногда показывает не новую разметку, а старую собранную версию.
• Кеш браузера. Это копии CSS, JavaScript, изображений и других файлов на компьютере посетителя. Очистка кеша DLE не обязана удалить их у пользователя.
• Кеш на стороне хостинга или прокси. CDN, reverse proxy и панели хостинга могут отдавать собственную копию ответа. В этом случае кнопка очистки в админке DLE не решит проблему.

Сноска. Инвалидация кеша — удаление или пометка устаревшей сохранённой копии после изменения исходных данных. Если инвалидация не сработала, сайт продолжает отдавать старый результат, хотя запись в базе уже обновилась.

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

Базовая проверка перед изменением настроек

Откройте сайт в приватном окне и выйдите из учётной записи администратора. Администратор может видеть свежие данные, тогда как обычному посетителю отдается закешированная страница. Сравнивайте один и тот же URL: главную, страницу категории и конкретную новость.

Перед очисткой зафиксируйте четыре факта:

1. Что именно изменилось: текст новости, шаблон, CSS, настройки DLE или данные в базе.
2. Кто видит старую версию: все посетители, только вы или пользователи через определённого провайдера.
3. На каком URL воспроизводится проблема и есть ли она на другой странице того же типа.
4. Меняется ли результат после принудительного обновления браузера и полного выхода из админки.

Эта запись нужна не для отчётности. Она не даёт принять очистку всех кешей за доказательство того, что причина найдена.

Три рабочих подхода к кешу

1. Оставить кеш страниц включённым

Это нормальный режим для новостного сайта, каталога и проекта, где одна и та же публичная страница открывается сотни раз. Вы выигрываете в нагрузке на PHP и базу данных, но платите задержкой обновления. Чем дольше срок хранения страницы, тем выше вероятность, что посетитель увидит старый материал.

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

2. Уменьшить срок жизни динамичных страниц

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

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

3. Очищать кеш после конкретных изменений

Для редких правок это самый безопасный способ. После публикации новости, изменения шаблона или обновления расширения очистите кеш через штатный раздел админ-панели DLE, затем проверьте страницу в приватном окне.

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

Практический порядок действий

1. Проверьте проблему без админской сессии. Откройте страницу в приватном окне и обновите её. Если новая версия появилась только там, сравнивайте кеш браузера и кеш страницы, а не базу данных. Проверка успешна, если вы понимаете, кто именно получает старый ответ.
2. Очистите кеш штатными средствами DLE. Используйте пункт очистки кеша в административной панели вашей версии. Не удаляйте произвольные файлы из engine/cache, если не понимаете их назначение: это может привести к лишним ошибкам и усложнить диагностику. Проверка успешна, если изменённая новость или шаблон отображается в приватном окне.
3. Если изменяли шаблон, обновите статические файлы. Проверьте, что новый CSS или JavaScript действительно загружается браузером. В инструментах разработчика посмотрите URL файла и его дату или содержимое. Проверка успешна, если в разметке и стилях видна новая версия.
4. Проверьте внешний слой кеширования. Если у сайта есть CDN, прокси или кеш в панели хостинга, очистите его по правилам конкретного сервиса. Проверка успешна, если заголовки ответа и содержимое совпадают при запросе через обычную сеть и приватное окно.
5. Верните кеш после отладки. Отключённый кеш оставляйте только на тестовом стенде или на короткий период диагностики. Проверка успешна, если страница снова открывается с включённым кешем, а обновлённый контент появляется в ожидаемый срок.

Типичные ошибки и что они означают

Старая новость остаётся после очистки кеша

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

После правки шаблона появились старые блоки

Сначала очистите кеш шаблонов через админку DLE. Затем проверьте CSS и JavaScript: браузер мог оставить старые статические файлы. Добавление случайных параметров к URL помогает только как временная проверка и не заменяет настройку версионирования ресурсов.

После полного сброса сайт стал медленным

Это ожидаемо, если все страницы начали собираться заново. Не повторяйте очистку на каждом запросе и не отключайте кеш на боевом сайте без замеров. Посмотрите время ответа, загрузку CPU, количество PHP-процессов и медленные запросы базы данных.

Кеш ломает персональные данные

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

Где подход ломается

Кеш страницы не исправит медленный SQL-запрос, перегруженный сервер, ошибку расширения или неправильный HTML. Он лишь позволяет реже запускать проблемный код. Если время ответа растёт даже при попадании в кеш, смотрите логи веб-сервера и PHP, статус-коды HTTP, размер ответа и долю запросов, которые обходят кеш.

Отдельно проверяйте исключения для авторизованных пользователей. Администратор может видеть страницу без кеша, а обычный посетитель — старую копию. Поэтому тест «у меня всё обновилось» без приватного окна для DLE недостаточен.

Что делать дальше

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

Инвалидация данных внутри расширений DLE — отдельная тема. Здесь важнее сначала определить слой, который отдаёт старую страницу, и только затем нажимать кнопку очистки.