Всем привет! Недавно я решал задачу разработки сайта-лендинга для собственного проекта. У лендинга должна была быть админка, то есть данные для его содержимого должны были храниться и редактироваться на сервере. Поэтому я искал современный и мощный инструмент для генерации страниц на основе данных из API админ-панели.

Так я познакомился c подходом SSG (Static Site Generation — Генерация статических сайтов), попробовал его в деле, и хочу рассказать о том, что это такое, зачем может понадобиться SSG-фреймворк и почему Astro — лучший выбор для генерации статических сайтов прямо сейчас.

Что такое SSG?

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

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

Вот несколько преимуществ, которые может дать такой подход:

Производительность. Так как содержимое страниц формируется предварительно на сервере на этапе сборки, статические сайты обладают отличной производительностью. В отличие от подхода SSR (Server Side Rendering — Рендеринг на стороне сервера), когда содержимое генерируется по каждому запросу на сервер, статически сгенерированные сайты не нагружают сервер и грузятся быстрее.

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

Простота хостинга. Статические сайты намного легче развёртывать на различных хостинг-платформах, так как они не требуют настройки сложной инфраструктуры.

SEO-оптимизация. Статический контент легче проиндексировать поисковыми системами, а более быстрая загрузка страниц способствует более высокому доверию ресурсу со стороны поисковиков.

Зачем нужны SSG-фреймворки?

Генерация статических сайтов является комплексной задачей, и SSG-фреймворки признаны её упростить и автоматизировать. Вот основные возможности, которые дают SSG-фреймворки:

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

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

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

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

Использование современных языков программирования. Для создания динамической логики SSG-фреймворки позволяют использовать современные языки программирования, такие как TypeScript.

Поддержка многоязычности. Некоторые фреймворки предоставляют средства для создания многоязычных сайтов, поддерживая различные варианты контента для разных языков.

Почему Astro — лучший выбор на рынке?

Он очень быстрый. Astro намного быстрее конкурентов, таких как Next.js, Remix и Nuxt засчёт максимального уменьшения размера JS-кода.

Ему не важно, на чём вы пишете. Если такие фреймворки как Next.js, Remix, Qwik, Nuxt, VitePress и SvelteKit строго завязаны на работу только с конкретной UI-библиотекой (React, Vue.js, Svelte), то в Astro можно использовать любые перечисленные и не только технологии одновременно. Благодаря архитектуре «островов», возможно использовать компоненты, написанные с помощью любой библиотеки, и даже построить взаимодействие между ними и использовать общее состояние.

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

Он предоставляет мощный язык шаблонов. В Astro есть собственный язык шаблонов, который очень похож на обычный HTML. Он поддерживает такие возможности как: JSX-синтаксис, передача пропсов в Astro-компоненты, ограничение области видимости CSS, использование CSS-препроцессоров, подключение клиентских скриптов и настройка режима их гидратации.

Легко настраивается для работы с Headless CMS. Astro очень просто интегрировать с любой Headless CMS — системой управления контентом, которая не имеет собственного движка для генерации и рендеринга страниц, но предоставляет визуальный способ добавления и редактирования содержимого сайта (админку), а также позволяет настроить публичное API для общения с генератором статических сайтов. Подробнее про интеграции: https://docs.astro.build/en/guides/cms/.

Он использует роутинг, основанный на файлах. Astro автоматически генерирует маршруты на основе файлов в папке src/pages, а также поддерживает динамические маршруты, редиректы и автоматическую пагинацию для больших коллекций данных.

Он поддерживает многоязычность. Многоязычность в Astro основана на роутинге, а отдельные маршруты для каждого языка автоматически генерируются, используя структуру файлов в папке src/pages.

Astro может работать как SSR-движок. В Astro встроены возможности для интеграции с SSR-адаптерами, которые позволяют добавить генерацию HTML-разметки «по требованию» только для опредёленных страниц. Это позволяет использовать более сложную динамическую логику, в которой представление страниц изменяется в зависимости от действий пользователя на сервере, производимых через запросы к API.

Рекомендую попробовать Astro в деле, тем более его официальная документация переведена на множество языков, включая русский: https://docs.astro.build/ru/getting-started/.


Приглашаю вас подписаться на мой телеграм-канал: https://t.me/alexgriss, в котором я пишу о фронтенд-разработке, публикую полезные материалы, делюсь своим профессиональным мнением и рассматриваю темы, важные для карьеры разработчика.

Комментарии (9)


  1. Mogost
    08.12.2023 20:58

    Если сравнивать с jekyll то какие преимущества будут?

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


    1. AlexGriss Автор
      08.12.2023 20:58

      Добрый день!

      Во-первых, Jekyll требует Ruby, и все плагины для него написаны на Ruby. Astro написан на TypeScript — он воспринимается как обычная npm-зависимость, а не какая-то внешняя утилита. Во-вторых, Jekyll использует морально устаревший шаблонизатор Liquid, когда как в шаблонах Astro используется JSX-синтаксис со всей его гибкостью. В-третьих, в Jekyll будет целой эпопеей встроить виджет, написанный на любой UI-библиотеке, значит вы не сможете легко добавить какую-то мало-мальски сложную интерактивность на своих сайтах. В Astro можно использовать одновременно React, Vue, Svelte и т.д. и это будет работать очень быстро и легко настраиваться.

      Что касается второго вопроса, мне кажется, что генераторы статических сайтов подойдут для тех команд, которые могут выделить ресурс на разработку собственных решений, так как хотят иметь больший контроль над своими приложениями. Тот же Astro отлично интегрируется с различными решениями для админок, но команде разработки придётся самостоятельно заниматься настройкой всех этих инструментов. Это не тот вариант, где всё работает из коробки как в WordPress, так что генераторы стоит использовать, если только вам необходим полный контроль над инструментами и качеством сайтов, которые получаются на выходе. Кстати, тот же WordPress формирует разметку по запросу, а не на этапе сборки, это влияет на скорость работы и безопасность сайта.

      Ещё есть вариант, в котором маркетинг-команда работает с md-файлами, там очень простой синтаксис и тот же Astro умеет преобразовывать их в полноценные страницы, но, конечно, это не замена визуальному редактору, какие-то базовые навыки разработки при работе с этим синтаксисом необходимы.


  1. gmtd
    08.12.2023 20:58

    Интересно, почему производительность вы сравниваете с SSR фреймворками?

    Где другие SSG типа VitePress?

    Означает ли это, что Astro просто чуть легче, чем SSR?


    1. AlexGriss Автор
      08.12.2023 20:58

      Сравниваю не я, я предоставил ссылку на сравнение, которое проводила команда Astro. Там показана разность в скорости работы с SSR-фреймворками, когда они работают именно как генераторы статических сайтов и генерируют страницы при сборке. В этом случае, прирост скорости у Astro может быть довольно существенным.

      Что касается сравнения скорости и производительности с VitePress — такого я не нашёл, думаю, что здесь они оба покажут достаточно хорошие результаты. Я попробовал сформировать отчёты в PageSpeed Insights для главных страниц Astro и VitePress, замеры не претендуют на то, чтобы показать полноценное сравнение, но все равно приложу результаты:

      Astro: https://pagespeed.web.dev/analysis/https-astro-build/8s5msp9qs6?form_factor=mobile

      VitePress: https://pagespeed.web.dev/analysis/https-vitepress-dev/8q9i7x3xtf?form_factor=mobile

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

      Думаю, что в сравнении с VitePress основным фактором предпочтения Astro может стать его UI-agnostic философия и архитектура островов. Если VitePress завязан на использование Vue.js, то Astro не ограничивает в выборе UI-библиотеки.


      1. gmtd
        08.12.2023 20:58

        Спасибо за проведенные тесты. Да, все SSG должны давать примерно одно

        Кстати, свой язык шаблонов и поддержка JSX - это скорей минусы.

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

        Кому это сделать проще - VitePress с его Markdown-ом, или Astro со своим языком шаблонов?

        Понятно, что VitePress можно так закастомизировать, что тоже потребуется ощутимая работа, но всё же.


        1. AlexGriss Автор
          08.12.2023 20:58

          Astro тоже поддерживает markdown и даже mdx-синтаксис, в который можно встраивать JSX-выражения: https://docs.astro.build/en/guides/markdown-content/.

          Плюс язык шаблонов Astro очень простой, если вы писали на любой современной UI-либе типа React, Vue или Svelte, то вы можете практически сразу же писать шаблоны Astro. А если вам вообще не нужна динамика, то это будет просто обычный HTML-синтаксис, ничего специфического учить не нужно.


  1. Atorian
    08.12.2023 20:58

    Помимо Астро, есть еще и https://www.11ty.dev/. Делаю на нем пару небольших проектов. Они очень похожи.


  1. gun_dose
    08.12.2023 20:58

    Простота хостинга. Статические сайты намного легче развёртывать на различных хостинг-платформах, так как они не требуют настройки сложной инфраструктуры.

    Вот тут вы немного (вернее очень даже много) недоговариваете. Помимо хостинга статического сайта, ещё нужно где-то хранить его данные, иметь эндпоинты для отдачи этих данных сборщику, плюс ещё где-то запускать компиляцию этого всего. То есть получается нужен хостинг для Headless CMS, затем сервер с поддержкой Node.js, затем сервер для отдачи статики. То есть три сервера вместо одного. Понятное дело, что какие-то или даже все эти штуки можно физически разместить на одной машине, но это всё равно уже достаточно сложная инфраструктура получается.

    А ведь если приделать фронтенд напрямую к CMS, как было принято раньше, то вместо трёх сервисов останется всего один.

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

    PS: я сам люблю все эти модные реакты и делал несколько очень серьёзных проектов, где использовался next.js для SSR, но не SSG.


  1. monochromer
    08.12.2023 20:58

    Пока останавливает отсутствие гибкости в формировании ссылок при пагинации. Как понимаю, нельзя сделать, чтобы начальная страница была, скажем, `/articles/`, а следующая `/articles/feed/2`, используя один шаблон. В Eleventy с ссылками (permalink) можно делать почти что угодно.