← Все статьи

Astro 7: Rust-движок, кэширование маршрутов и инструменты для ИИ

В Astro 7 компилятор и обработку Markdown перевели на Rust, ускорили сборки и добавили гибкое кэширование маршрутов.

Astro 7: Rust-движок, кэширование маршрутов и инструменты для ИИ
Содержание

Коротко

22 июня вышел Astro 7 — крупное обновление фреймворка для преимущественно статических сайтов. Самые тяжёлые части сборки получили реализацию на Rust, а переход на Vite 8 и Rolldown дополняет это ускорение.

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

Что произошло

Компилятор компонентов .astro переписали с Go на Rust. Он больше не исправляет сомнительную HTML-разметку молча: незакрытые теги и неполные атрибуты становятся ошибками, которые можно устранить до публикации сайта.

Также Astro 7 использует Sätteri — обработчик Markdown и MDX на Rust. Для документационных сайтов с тысячами страниц это особенно заметно: прежде файлы проходили длинную цепочку JavaScript-плагинов, теперь многие распространённые возможности разметки реализованы в самом обработчике.

Фреймворк перешёл на Vite 8, где появился Rolldown. В большинстве проектов изменения конфигурации не нужны: слой совместимости сохраняет привычные настройки и плагины, а единый инструментарий сборки уменьшает время ожидания локальных и непрерывных проверок.

Почему это важно

По данным команды Astro, полная сборка в их тестах стала быстрее на 15–61%. Это не универсальная гарантия для каждого репозитория: выигрыш зависит от количества страниц, файлов Markdown, клиентского кода и подключённых расширений.

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

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

На практике

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

Отдельно протестируйте серверные сценарии: кэш не должен скрывать обновления редакции или персональные ответы. У экспериментальных провайдеров кэша для CDN также важно сверить условия доступа у своего хостинга.

  1. Запустите рекомендованное обновление через npx @astrojs/upgrade, затем соберите проект и проверьте страницы с компонентами .astro.
  2. Если сайт богат документацией, измерьте время сборки до и после перехода: именно обработка Markdown и MDX чаще всего даёт заметный эффект.
  3. Для рендеринга по запросу настройте cache и routeRules, начиная с безопасных коротких сроков жизни и понятных тегов очистки.
  4. Если нужен нестандартный порядок обработки запросов, оцените src/fetch.ts: он подходит для проксирования API, аутентификации и измерения времени рендеринга.
  5. При работе с ИИ-агентами используйте astro dev --background, astro dev status и astro dev logs, чтобы не создавать дублирующие серверы.

Для проектов, зависящих от специфичных расширений remark или rehype, прежний обработчик остаётся доступным. Обновление не требует отказываться от него сразу, если совместимость важнее скорости.

Итог

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

Наиболее практичный путь — обновиться на отдельной ветке, сравнить реальные сборки и только затем включать кэширование или новый обработчик запросов. Так преимущества Rust-частей релиза не будут заслонены неожиданностями в собственных шаблонах и расширениях.

Новый режим фонового сервера особенно полезен в автоматизированных проверках: он явно сообщает состояние процесса и позволяет завершить его штатной командой.

Цифры ускорения стоит воспринимать как повод для собственного замера, а не как замену измерениям на конкретном проекте.