Популярный документ открывался слишком долго
На сайте с большой базой юридических документов посетители регулярно обращались к объёмным материалам, в том числе к целым кодексам. В статистике было видно, что одна из таких страниц достаточно посещаема, но открывалась по 20–30 секунд. Это сделало её скорость важной задачей для проекта.
Документы менялись редко, однако при каждом посещении серверу приходилось снова выполнять тяжёлую работу по формированию страницы. При этом HTML одного из кодексов превышал 21 МБ. Нужно было ускорить повторную выдачу, сохранив существующий хостинг и тариф.
Кеш включён, но большой странице он не помогал
В Drupal уже использовалось кеширование с Memcached. Небольшие страницы успешно отдавались из кеша, поэтому сама по себе проверка «кеш включён» не объясняла проблему. Для крупных документов существующий механизм фактически не давал нужного результата: повторные обращения снова создавали высокую нагрузку на сервер.
Разница стала заметна при анализе конкретного тяжёлого документа и повторных запросов к нему. Задача заключалась не в отключении кеширования и не в замене всех механизмов Drupal, а в подходящем хранении готового ответа большого размера.
Сжатый файловый кеш для готовых страниц
Для объёмных страниц организовали отдельное хранение готового HTML в сжатом файловом кеше. После заполнения кеша повторный запрос может получить сохранённую страницу без повторной тяжёлой генерации документа.
Первое формирование
Drupal формирует страницу документа; подходящий готовый ответ сохраняется в сжатом файловом кеше.
Повторный запрос
При повторном анонимном обращении после заполнения кеша страница выдаётся из сохранённого представления.
Обновление материала
При изменении содержимого работают механизмы инвалидации Drupal, чтобы устаревшую версию не использовать как актуальную.
На этом этапе решение сохранило стандартные механизмы Drupal, включая проверки доступа и инвалидацию при изменении контента. Это важно: ускорение не должно превращать закрытые данные в общедоступные или оставлять на сайте устаревшие документы.
Меньше ожидания.
Тот же хостинг.
Первый замер после внедрения файлового кеша: повторный анонимный запрос после заполнения кеша.
TTFB — время до первого байта. Это время от запроса страницы до момента, когда браузер получает первый байт ответа сервера.
Первый байт TTFB
Полная загрузка HTML
Замер одного документа; время первого байта сократилось примерно в 47 раз.
Первый байт — за 0,43 секунды
На проверенном документе время ожидания первого байта сократилось с 20,1 до 0,43 секунды, примерно в 47 раз. Время полной загрузки HTML уменьшилось с 20,7 до 1,18 секунды.
Это результат замера повторного анонимного запроса после заполнения кеша для одного конкретного документа. Он не описывает первую загрузку после очистки кеша и не является гарантией такой же скорости для всех страниц или пользователей.
Важный результат для проекта: тяжёлые документы стали быстрее отдаваться при повторных посещениях на существующем хостинге, без перехода на более дорогой тариф и переноса сайта.
Быстрый кеш нужно было сделать управляемым
Первый результат показал, что файловый кеш ускоряет выдачу огромных документов. Но когда на диск перенесли все записи, в условиях shared-хостинга начала накапливаться другая нагрузка: более 701 тысячи файлов общим объёмом 7,7 ГБ. Мы выявили причину и переработали схему, чтобы контролировать не только скорость, но и два ресурса хранения — число файлов и объём данных.
Небольшие записи — в Memcached
Мелкие записи остаются в Memcached и не создают отдельный файл на диске.
Крупные объекты — в файловый кеш
Объекты от 256 КБ сохраняются в сжатом виде. Так готовые большие документы можно быстро отдавать повторно.
Для каждого из трёх файловых кешей установлены ограничения: 256 записей и 128 МиБ. При достижении лимита старые записи вытесняются; повторная запись не накапливает устаревшие версии. При этом сохранены механизмы Drupal: проверки прав доступа, разделение вариантов страницы и инвалидация по тегам.
После доработки: быстрый ответ и ограниченный кеш
После удаления старых накоплений каталог кеша сократился с 7,7 ГБ до 27 МБ. Проверенный кодекс при повторном запросе отдавался с отметкой HIT: первый байт пришёл за 0,41 секунды, полная загрузка HTML заняла 0,94 секунды.
В локальном тесте 5 000 мелких записей не создали ни одного файла, а после записи 300 больших объектов сохранился предел в 256 записей. Эти проверки показывают поведение решения в описанных условиях, но долгосрочную стабильность ещё предстоит оценить по наблюдению за работой сайта.
Работы выполнили на существующем хостинге, без повышения тарифа и переноса сайта. Снижение нагрузки на CPU и влияние на SEO количественно не измерялись.
Когда стоит проверить кеш больших страниц
Если сайт на Drupal медленно открывает длинные статьи, документацию, юридические базы или другие объёмные материалы, полезно отдельно измерить первую и повторную выдачу. Даже при включённом кешировании разные типы страниц могут вести себя по-разному.
Для диагностики важно сравнить время первого байта и полную загрузку HTML, проверить размер ответа, поведение при повторном запросе, обновление контента и права доступа. Подход к кешированию выбирается под конкретный сайт и его ограничения, а не только по факту наличия Memcached.
Обсудить ускорение сайта на Drupal можно с разбора проблемной страницы и условий её работы.
О кешировании и скорости Drupal
Почему Drupal медленно открывает большую страницу, хотя кеширование включено?
Причина зависит от проекта. В этом случае небольшие страницы кешировались успешно, а для очень большого HTML действовавший механизм не давал нужного результата. Поэтому проверили поведение конкретного документа при повторных запросах.
Что даёт файловый кеш больших страниц?
В этом проекте крупные объекты от 256 КБ сохраняются на диске в сжатом виде, а мелкие остаются в Memcached. Для файловых кешей ограничены число записей и объём, чтобы повторная выдача больших страниц не приводила к бесконтрольному накоплению файлов.
Обновится ли страница после изменения документа?
В решении сохранены механизмы инвалидации Drupal при изменении контента. Для другого проекта правила и связанные зависимости нужно проверять отдельно.
Нужно ли менять хостинг, чтобы ускорить сайт на Drupal?
Не всегда. В этом случае повторную выдачу тяжёлого документа ускорили на существующем хостинге без повышения тарифа. Для другого сайта решение зависит от причины задержек и доступных ресурсов.
Технологии решения
Существующая платформа и отдельное хранение больших готовых страниц.
Контент, проверки доступа и инвалидация
Существующее кеширование сайта
Сжатое хранение больших страниц
