Astro 7.4: профилирование времени сборки с флагом --timings и раздельные сервисы изображений

Ты наверняка сталкивался с неприятным явлением: проект на Astro растет, количество контентных страниц переваливает за сотню, и в какой-то момент запуск команды сборки начинает длиться мучительно долго. Вместо привычных пятнадцати секунд терминал замирает на несколько минут. Что именно пошло не так? Зависла обработка тяжелых изображений? Какой-то плагин Vite выполняет лишнюю работу на каждом шаге? Или во время пререндеринга страницы происходит скрытый каскад сетевых запросов к внешней CMS?

Раньше разработчикам приходилось действовать практически вслепую, расставляя по конфигам замеры console.time(). Если ты следил за развитием экосистемы, то помнишь, как Astro 7.3: параллельные dev-серверы, рантайм-логгер и Cloudflare-хелперы заложил основу для углубленного мониторинга рантайма. В свежем релизе Astro 7.4 команда во главе с Мэттью Филлипсом (Matthew Phillips) довела эту идею до логического совершенства, добавив встроенный профилировщик процесса сборки.

Рентген сборки с флагом --timings

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

# Запуск профилирования сборки проекта
npx astro build --timings

После завершения генерации Astro выводит в консоль красивое иерархическое дерево, где разложены по полочкам абсолютно все этапы:

• чтение и валидация конфигурации (resolve config, setup);
• синхронизация контентных коллекций (content sync);
• сборка клиентских бандлов и серверных манифестов (client bundle, manifest injection);
• время, потраченное каждым отдельным плагином Vite;
• обработка Markdown/MDX и парсинг метаданных.

Но самая ценная секция отчета — блок Slowest pages. Профилировщик автоматически ранжирует сгенерированные маршруты по времени рендеринга, вычисляя медиану и 95-й перцентиль (p95). В демонстрационном примере команды Astro одна из страниц блога собиралась за 2.10 секунды из-за последовательных асинхронных вызовов к базе данных внутри компонента. Как только разработчики сгруппировали сетевые запросы через Promise.all(), время генерации маршрута рухнуло до 1.13 секунды. С флагом --timings такие скрытые грабли становятся видны мгновенно.

Разделение оптимизации картинок: Sharp для сборки, CDN для SSR

Вторая важнейшая новинка релиза решает давний инфраструктурный компромисс при гибридном деплое.

Раньше свойство image.service в конфигурации было глобальным. Если ты хотел собирать статические страницы с максимальной скоростью, ты использовал локальный C-модуль Sharp. Но если в проекте одновременно присутствовали динамические SSR-маршруты, развертываемые на Cloudflare Workers или Vercel Edge, возникал тупик: бинарные зависимости Sharp просто не работают в легковесных изолятах V8. Приходилось переключать весь проект на медленные JS-энкодеры или полностью отдавать обработку внешнему Image CDN.

В Astro 7.4 объект image.service научился принимать раздельные настройки для фазы сборки (build) и фазы исполнения (runtime):

import { defineConfig } from 'astro/config';

export default defineConfig({
  image: {
    service: {
      // Быстрый локальный Sharp на сервере сборки CI/CD
      build: { entrypoint: 'astro/assets/services/sharp' },
      // Внешний облачный обработчик для динамических SSR-запросов
      runtime: { entrypoint: 'my-custom-image-cdn' },
    },
  },
});

Вдобавок релиз принес нативную функцию notFound() для кастомных точек входа, улучшил интеграцию пререндеринга картинок в адаптере @astrojs/cloudflare и представил экспериментальный параллельный пререндеринг в отдельных Worker-потоках. Обновиться на новую версию можно стандартной командой npx @astrojs/upgrade или через пакетный менеджер.