Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 25
Сейчас эту проблему решили инкрементальной сборкой. Пересобирается только изменившаяся страница.
Eleventy— через плагины.
А такие точно есть? Сейчас в документации Eleventy такая функциональность помечена как to-do.
Да, у Eleventy сейчас есть флаг --incremental, но он не делает полноценную инкрементальную сборку страниц в CI/продакшене. Он ускоряет работу в режиме serve при разработке, пересобирая локально только изменённые файлы. Это действительно не то, о чем говорится в статье. Да, есть плагины которые улучают инкрементальное поведение в процессе разработки, но это всё тоже для прода не подходит. Действительно в этом моменте информация, которая может запутать. Спасибо, уберу это из статьи.
поправил опечатку = запустил полную пересборку. 10 тысяч страниц, 5–10 минут ожидания
Это как это? В какой странице опечатка - ту поправил и залил. Остальные зачем трогать?
Если 10_000 страниц по отдельным товарам собираются на основании одного шаблона и вот в этом шаблоне нашли ошибку, то да, в случае статического сайта придется исправить ошибку в 10_000 файлах с описаниями товаров. В случае динамической генерации страниц с товарами было бы достаточно исправить ошибку в шаблоне страницы и после этого инвалидировать кэш.
А если через старый добрый SSI (Server Side Includes) странички собирать? Или это уже не совсем статика получается?
Минусы SSI по сравнению с чистой статикой:
SSI не позволит использовать предварительное сжатие контента в Nginx. Предварительное сжатие статики здорово разгружает процессор по сравнению со сжатием на лету. Отсутсвие сжатия здорово увеличивает трафик на текстовом контенте.
SSI не позволит использовать sendfile() для отдачи статики. Использование sendfile() позволяет уменьшить количество системных вызовов, которые надо будет сделать для выпихивания контента в сеть. Системные вызовы обходятся дорого.
SSI будет тратить время на сканирование текста страницы в поисках директивы.
Плюсы SSI по сравнени с чистой статикой:
Удобнее вносить изменения такие, которые затрагивают шаблонную часть множества однотипных страниц.
Однотипные страницы занимают меньше места на диске просто за счет того, что шаблонная часть вынесена в отдельный файл а не дублируется во множетсве страниц.
В принципе всё. Вы можете выбирать.
Или кешировать вывод отдельных компонентов как это обычно делается на php. А сборка страницы из кешированной статики 10-15 компонентов происходит очень быстро и не сильно затратно.
а если просто поставить перед вордпрессом (к примеру) кеш с внешней инвалидацией (например по хуку из админки посре редактирования поста), это будет не то же самое?
А ещё статические сайты легко копировать для просмотра оффлайн (через wget например). Крайне полезное свойство при нынешней моде на блокировки.
Какого года статья? Все можно делать на статике, кроме страниц, которые должны быть проиндексированы поисковиками (и то). Я вообще не понимаю кто и зачем сегодня делает сайты, которые на каждый запрос отдают страницу полностью. Новости, статьи, короче тупотекст - понимаю. Но
Статика не подойдёт, если:
Контент меняется каждую минуту (биржи, котировки, соцсети).
У каждого пользователя свой персональный кабинет.
Контент массово создают сами пользователи.
Требуется сложная бизнес-логика на бэкенде с длинными транзакциями
имхо статика + API fetch
Спасибо за дополнение! Действительно, для личных кабинетов и случаев со сложной бизнес-логикой это не совсем уместно. Поправил статью.
кроме страниц, которые должны быть проиндексированы поисковиками
Поясните, пожалуйста. Как раз статику индексируют без проблем. Особенно по сравнению с динамикой, в которой параметры передаются в GET и есть множество способов получить одно и то же меняя эти параметры или их порядок.
Раньше выбор был бинарным: либо полностью динамический сайт, либо полностью статический.
Ого, интересно как, хорошо что эти искусственные ограничения только в голове, видимо)
В статье в плане преимуществ SSG практически сплошное враньё.
Усталость от переусложнения. Типовой WordPress-сайт на десять статей в год тянет PHP, MySQL, Apache, кеширование, плагины безопасности и еженедельные обновления. Это рабочее решение, но задаёшься вопросом: не слишком ли тяжёлая артиллерия для такой задачи?
А пунктом выше:
Бэкенд не исчезает — он выносится в микросервисы и API.
Автор, если тебе LAMP-стек с вордпрессом тяжело, то куда тебе в микросервисы?
WordPress тянет за собой шлейф обязательств:
Обновлять ядро
А некст не надо обновлять? У них каждые полгода критическая уязвимость.
Статика — это папка с HTML-файлами на CDN или хостинге.
А бэкенд с микросервисами уже куда делся? Понятно, что можно тот же некст поставить на локальную машину, билдить оттуда и пушить. Но что это значит для бизнеса? Плюс один комп со строго настроенным окружением. Специалист, который умеет обращаться с консолью, умеет чинить сборку, когда она падает. А если он уволится? Или платить за каждый билд вебстудии? Так и вебстудии не вечные. А тот же вордпресс залил и пользуйся себе админкой. Захотел поменять того, кто обслуживает сайт - пожалуйста, всё лежит в одном месте.
А вообще, что такое SSG? Сначала появились реактивные фреймворки, потом людям захотелось SEO, поэтому придумали SSR. Но на деле это получился дико тормознутый монстр, который годами пытались ускорить, и в итоге сдались, добавив SSG. Но решили умолчать, что статика - это всего лишь фронтенд. А за этим ещё кроется огромный айсберг в виде инфраструктуры для сборки и хранения данных.
если тебе LAMP-стек с вордпрессом тяжело, то куда тебе в микросервисы?
Микросервисы — это возможность, а не обязательство. Речь не о замене WordPress собственной распределённой системой. Идея в том, что при SSG динамика может выноситься в готовые сервисы или API и использоваться по необходимости, а не жить внутри одной CMS и обслуживать каждый запрос. Это не про упрощение любой ценой. Мысль в ином распределении ответственности.
А некст не надо обновлять? У них каждые полгода критическая уязвимость.
Да, как и любые другие инструменты. Но WordPress работает в продакшене (PHP + БД), а Next.js при статической сборке — только на этапе билда. Уязвимость в рантайме и уязвимость в build-time — это разный класс риска.
А бэкенд с микросервисами уже куда делся? Понятно, что можно тот же некст поставить на локальную машину, билдить оттуда и пушить. Но что это значит для бизнеса? Плюс один комп со строго настроенным окружением.
Он никуда не делся. Но при SSG он не обязан постоянно работать вместе с сайтом. Если динамика нужна — её можно подключить отдельно, а не держать вместе с сайтом полноценный LAMP 24/7. Если не нужна — сайт остаётся статическим набором файлов, который можно разместить на любом хостинге или CDN
Специалист, который умеет обращаться с консолью, умеет чинить сборку, когда она падает. А если он уволится? Или платить за каждый билд вебстудии? Так и вебстудии не вечные. А тот же вордпресс залил и пользуйся себе админкой. Захотел поменять того, кто обслуживает сайт - пожалуйста, всё лежит в одном месте.
Современная сборка — это чаще CI, а не комп разработчика. Репозиторий и пайплайн остаются.
WordPress тоже не магия: плагины, бэкапы, обновления, взломы — всё это требует компетенции. Это проблема другого типа.
А вообще, что такое SSG? Сначала появились реактивные фреймворки, потом людям захотелось SEO, поэтому придумали SSR. Но на деле это получился дико тормознутый монстр, который годами пытались ускорить, и в итоге сдались, добавив SSG.
SSR и SSG — это разные инструменты для разных задач. И SSG существовал задолго до React (Jekyll, Hugo). Если страница одинакова для всех, её логично собрать заранее.
Но решили умолчать, что статика - это всего лишь фронтенд. А за этим ещё кроется огромный айсберг в виде инфраструктуры для сборки и хранения данных.
Да, инфраструктура есть. Вопрос в том, где она живёт:
— в вашем сервере с PHP и БД,
— или сборка + CDN/хостинг + внешних API.
Статья не говорит, что SSG лучше всегда. Сложность никуда не исчезает. Она меняет характер: вместо постоянно работающего бэкенда — этап сборки и внешние сервисы по потребности.
И ключевая мысль статьи именно в этом: если сайт — это в первую очередь контент, а не приложение с персонализацией и сложной логикой, то держать полноценную CMS бывает избыточно.
Я не утверждаю, что WordPress плох, SSG — серебряная пуля, всем срочно в Next.js. Мы слишком часто используем CMS как универсальный молоток.
Это не «враньё», а разный взгляд на допустимую сложность под конкретную задачу.
В целом у меня нет цели научить вас делать сайты или рассказать вам про «правильный» или «неправильный», я лишь делаю субъективный обзор на то, «Почему статические сайты возвращаются и чему они научились» 🙂
Спасибо за комментарий — действительно полезные замечания!
Это не «враньё»
Нет, это именно враньё. Вопрос не только в технической стороне, но и в маркетинге. Менеджеры очень любят втюхивать всякий некст, рассказывая про небывалые скорости и дешевизну хостинга. А как результат, имеем кратное удорожание процесса разработки, плюс необходимость содержания инфраструктуры для билда.
Репозиторий и пайплайн остаются.
И любое внесение изменений в контент идёт через репозиторий. Ага, очень удобно. И опять же, что там по деньгам, если у нас кодер вместо контентщика? Мне вообще интересно, как такое в принципе умудряются продать?
При этом не стоит забывать, что LAMP-стек можно захостить даже на самом дешёвом shared-хостинге и при этом иметь вменяемую производительность. По итогу окажется, что в цене хостинга для статики и для LAMP-стека вообще нет никакой разницы. При этом если LAMP окажется медленным, то не важно, что там Wordpress, Drupal, Symfony, Laravel - под всё есть плагины/модули/библиотеки для кэша разных типов. Более того, под всё это есть модули, которые могут перегенерировать весь сайт в статику. К примеру друпальный Boost появился ещё в 2006 году (раньше, чем Jekill!).
Нельзя все случаи сразу сравнивать. У кого-то сложная система и генерация потребует частого вмешательства разработчика. У кого-то обновление прайса раз в месяц, инструкция по запуску + как развернуть генерацию с нуля на новом компьютере (условно, в 10 кликов). Альтернатива - не обновляемая CMS (лень, не понятные технологии, требует сложного вмешательства при переходе на новую мажорную версию), которую сломают в автоматическом режиме. Если сайт как услуга с подпиской - вопросов нет, все держать на сервере будет проще для поддержки.
Если у вас сайт на 100 статичных страничек, то зачем вам устанавливать LAMP на железо, вам достаточно любого копеечного хостинга.
В 2025 году статические сайты вернулись. Не в качестве альтернативы для бедных, а как зрелая архитектура, которая решает 90% задач быстрее, дешевле и безопаснее, чем тяжёлый бэкенд.
Давайте по пунктам:
1) 90%. Откуда эта цифра? От какого маркетолога? На мой дилетантский взгляд программиста с 30+ лет стажа, технология отлично подойдет для википедии, документации и... все? Про лендинги на статике вместо той же тильды можно поспорить, но мне кажется решение на статике дороже в разработке и более нишевое (или нет?).
2) Дешевле. Если рассматривать мелкие проекты, то разница вообще ничтожна и не стоит рассмотрения, а на крупных проектах уже есть нюансы. Если мы говорим об использовании готовых внешних сервисов, то возможно и скорее всего гибкость их будет весьма ограничена и подходит далеко не всем (при стоимости сопоставимой с селфхостинг монолитом на каком-нибудь готовом движке), а при необходимости поднимать собственную инфраструктуру, настроить связку Next.js + Headless CMS + CI/CD инфраструктуру стоит в 3–5 раз дороже, чем развернуть классический монолит, сложность системы сильно выше, серверные ресурсы плюс-минус те же, а спецы на постоянку сильно дороже чем те же пыхеры под ларавел. Короче, в большинстве случаев нифига не дешевле.
3) Быстрее. Да, согласен, это хорошая альтернатива кэшируемым ресурсам, но разве не проще использовать готовые сервисы типа клоудфлейра вместо перехода на пререндер, где мы еще и не теряем большую часть интерактивности, например при использовании в каких-нибудь блогах с комментариями и личным кабинетом?
3) безопаснее. Вынос бэкенда в чей-то облачный сервис снимает с вас ответственность за безопасность бэкенда, в ущерб суверенитету данных, которые теперь не совсем ваши. Зависимость от внешних структур в айти (как практически в любой сфере) - палка о двух концах, в любой момент вы можете потерять доступ/возможность работы с ним. Очень большой пласт айти решений попросту не готов отдавать инфраструктуру в аутсорс.
Алсо, мы меняем личные риски на риск утечки у крупного сервиса, что совсем не редкость.
По итогу, выглядит как восторженный маркетинг булшит...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему статические сайты возвращаются и чему они научились