Содержание
С момента запуска Astro 1.0 разработчикам приходилось выбирать между статическим (SSG) и серверным (SSR) выводом. Статические веб-сайты обеспечивают невероятную производительность благодаря тому, что страницы создаются заранее. Серверы используют свои динамические возможности для генерации HTML по требованию, уникального для каждого запроса.
До сих пор это было решение ”все или ничего” - полностью ли это статический сайт или мне следует развернуть сервер?
Astro 2.0 открывает лучшие возможности обоих миров благодаря гибридному рендерингу. Выбирайте между производительностью статических страниц и полной гибкостью серверного рендеринга для каждой страницы вашего сайта.
В этом посте мы расскажем о том, как работает гибридный рендеринг, и рассмотрим лишь некоторые из новых функций и улучшений производительности, ставших возможными в Astro 2.0.
Как работает процесс сборки Astro?
Процесс сборки Astro происходит в несколько этапов, начиная с серверного пакета JavaScript, сгенерированного Vite. Чтобы немного упростить ситуацию, вывод этого пакета включает в себя:
JavaScript на стороне сервера, используемый для рендеринга HTML Клиентский манифест, который использует статический анализ для сбора всех компонентов, необходимых для интерактивности на стороне клиента CSS и другие активы для клиента
Далее Astro использует клиентский манифест для запуска второго процесса сборки, который собирает оптимизированный JavaScript на стороне клиента.
Если настроенный вывод статичен, Astro выполнит JavaScript на стороне сервера и запишет вывод в файлы .html. Затем серверный JavaScript отбрасывается.
Если настроенный вывод является серверным, Astro передает JavaScript на стороне сервера адаптеру для дальнейшей обработки.Адаптеры гарантируют, что ваш серверный JavaScript совместим со средой выполнения JavaScript конкретного хостинг-провайдера. Обратите внимание, что в этом случае конечным результатом является не набор файлов .html, а код JavaScript, необходимый для отображения HTML.
К сожалению, эта система была довольно жесткой и не позволяла смешивать статические и динамические маршруты в одном проекте. Нам действительно нужен был процесс, который позволял бы использовать оба шаблона параллельно.
Как работает гибридный рендеринг?
В Astro 2.0 мы переделали конвейер сборки astro для обработки гибридного рендеринга. Во время начального процесса сборки новый этап статического анализа определяет, какие страницы должны быть предварительно отрендерены. Это позволяет нам разделить ваши маршруты на отдельные фрагменты в зависимости от того, когда они должны быть отрендерены.
Как и в исходном статическом процессе, предварительно отрендеренный фрагмент выполняется, и результат записывается в файлы .html. Затем фрагмент отбрасывается.
Как и в исходном серверном процессе, серверный чанк передается адаптеру для дальнейшей обработки. В конечном итоге он будет развернут как бессерверная или Edge-функция, в зависимости от вашего адаптера.
Зачем нужен статический анализ?
Статический анализ - это техника, используемая для анализа исходного кода без его реального выполнения. Astro использует этот подход во многих местах, но он особенно важен в процессе сборки. По соображениям производительности Astro должен иметь возможность классифицировать ваши страницы без выполнения их исходного кода. Для небольших проектов выполнение кода может не вызывать беспокойства, но в масштабах проекта это быстро становится узким местом.
Гибридный рендеринг был специально разработан с учетом статического анализа, хотя мы рассматривали и альтернативные API. Процесс сборки Astro способен проверять наличие оператора export const prerender = true, чтобы определить, какие страницы должны быть предварительно отрендерены. Чтобы сделать это эффективно, мы полагаемся на замечательную библиотеку es-module-lexer, которая также используется внутри Node.
// This route should be generated at build time!
export const prerender = true
const text = await fetch('https://example.com/').then((res) => res.text())
<article set:html={text} />
Сферы применения гибридного рендеринга
Гибридный рендеринг открывает целый ряд новых вариантов использования, но мы хотели бы выделить несколько, которые нам особенно интересны.
Пример использования: повышение производительности рендеринга популярных страниц
Рассмотрим небольшой/средний сайт электронной коммерции, построенный с помощью Astro, с тысячами различных возможных продуктов и вариаций. Если бы вы использовали статическую генерацию сайта, вам пришлось бы перестраивать сайт каждый раз, когда один из этих продуктов менялся или исчезал из продажи.
Такой проект требует рендеринга на стороне сервера, что позволит генерировать страницы с товарами заново при каждом запросе. Но теперь у нас появилась новая проблема: ваша домашняя страница больше не является статичной. Производительность загрузки по-прежнему важна для стимулирования продаж, и на вашей домашней странице нет динамического контента, который бы требовал перегенерации при каждом запросе.
Гибридный рендеринг решает нашу проблему производительности путем предварительного рендеринга домашней страницы в статический HTML, в то время как остальная часть вашего сайта рендерится по требованию.
Пример использования: добавление API к существующему статическому сайту
По мере роста вашего статического сайта вы можете столкнуться с необходимостью размещения публичного API. Исторически добавление API на статический сайт требовало специфической настройки хоста, но в Astro 2.0 мы можем добавлять конечные точки сервера (маршруты API) без ущерба для производительности наших статических страниц.
Более того, конечные точки сервера могут быть добавлены автоматически с помощью хука injectRoute нашего Integrations API. Мы рады способствовать развитию мощной экосистемы сторонней интеграции с помощью этих новых примитивов!
Пример использования: повышение производительности сборки больших сайтов
Генерацию статических страниц сложно масштабировать до тысяч страниц, поскольку каждая страница должна быть отображена в процессе сборки. Рендеринг на стороне сервера откладывает рендеринг страниц до момента запроса, устраняя потенциальное узкое место в процессе сборки.
При наличии сотен маршрутов, генерируемых getStaticPaths, рендеринг на стороне сервера может привести к значительному увеличению производительности. В ходе внутреннего тестирования мы увидели, что время сборки увеличилось на 30% благодаря переключению динамических маршрутов на рендеринг на стороне сервера.
Начало работы с гибридным рендерингом
Гибридный рендеринг доступен уже сегодня в Astro 2.0! Вы можете обратиться к нашему руководству по рендерингу на стороне сервера, чтобы узнать больше о возможностях SSR в Astro. Официальные адаптеры Astro также были обновлены для поддержки гибридного рендеринга, поэтому не забудьте установить последнюю версию вашего адаптера.
Чтобы отпраздновать запуск, наши друзья из SST запустили astro-sst, свой официальный AWS-адаптер для Astro. Посмотрите их анонсирующее видео и руководство, чтобы узнать больше и начать работу с AWS + SST.
Мы приветствуем ваши отзывы! Мы собрали несколько замечательных предложений во время RFC Prerender API и приглашаем вас предлагать будущие идеи, используя нашу новую публичную дорожную карту или сообщество Discord.