Почему системы управления содержанием могут превосходить генераторы статических сайтов

Один или два раза в месяц я получаю следующий вопрос: «Почему бы вам не использовать генератор статического сайта (Static Site Generator (SSG)) для своего блога?»

Я не буду врать, то, что я основатель и лидер проекта Drupal играет определяющую роль в том, почему я использую Drupal для своего сайта. Если бы я не использовал Drupal, это было бы похоже на то, как директор Coca-Cola пьёт Pepsi, пекарь покупает хлеб в супермаркете или мебельщик обставляет свой дом из IKEA. Люди бы не поняли.

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

Главная причина, по которой я не пользуюсь SSG в том, что не не нравится их рабочий процесс публикации содержания. В Drupal, я могу внести правку, сохранить изменения и сразу увидеть результат. С SSG это сложнее. Мне нужно зафиксировать изменения в Git, перестроить сайт, отправить обновления в веб-сервер. Я просто предпочитаю пользоваться более удобным процессом в Drupal.

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

Сторонники статических сайтов сразу укажут на то, что статические сайты «гораздо быстрее». Лично я считаю это заблуждением. Мой сайт на Drupal — dri.es — быстрее большинства статических сайтов, в том числе домашних сайтов ведущих SSG.

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

Мой сайт самый быстрый, потому что его код HTML/CSS/JavaScript маленький и быстрый для рендеринга. Ещё я не использую внешние шрифты, отслеживание посетителей или объёмный JavaScript. Кроме того, Drupal ещё оптимизирует быстродействие путём отложенной загрузки изображений, сборки стилей и скриптов, а также других техник.

Другими словами, быстродействие сайта больше зависит от кода HTML, CSS, JavaScript, изображений, видео, шрифтов и так далее, чем от используемой базовой технологии. Также влияет на быстродействие и способ кэширвоания данных. Использование реверс-прокси, таких как Varnish, эффективнее кэширования через файловую систему. А использование CDN ещё больше улучшает скорость. CMS, которая использует CDN для кэширования, может обеспечить лучшее быстродействие в сравнении с SSG, который хранит медиаданные только в файловой системе.

В целом, я не против SSG. Я могу понять случаи их использования, и есть много ситуаций, когда они являются отличным выбором. Любые данные, которые могут быть статическими, должны быть статическими. Но я также считаю, что любые динамически сгенерированные данные, которые эффективно кэшированы, становятся статическими. Страница, динамически созданная CMS и эффективно закэшированная, это статический ресурс. Генерировать статические данные могут и CMS, и SSG.

Короче говоря, я просто предпочитаю процесс работы в CMS и поддерживаю скорость работы своего сайта, сохраняя сгенерированный код HTML лёгким и хорошо кэшированным. И что мне сильно помогает, так это наличие обработчика запросов на стороне сервера. Я знаю, что это может звучать странно, но поверьте мне: обработчик запросов на стороне сервера приносит удовольствие. Годами это приносило мне удовольствие и позволяло делать на сайте интересные вещи. И я не остановлюсь в ближайшее время!