Як зберегти швидкість сайту на Astro

Чистий звіт PageSpeed тішить, але зелена сотня — не продукт. Продукт — сторінка, що швидко з’являється на звичайному телефоні, не стрибає під час завантаження й одразу реагує на дотик. Оцінка корисна, бо показує регресії. Вона не є довічним сертифікатом швидкості.

Astro дає контентному сайту хороший старт. Останні рішення все одно конкретні: який шрифт preload’ити, чи затримує анімація справжній контент і які файли сервер може безпечно кешувати рік.

Спочатку дайте браузеру менше роботи

Компоненти Astro перетворюються на HTML під час збірки й за замовчуванням не додають клієнтський runtime. Це задокументована модель Astro «нуль JavaScript за замовчуванням», а не обіцянка, що кожен Astro-сайт надсилає нуль JavaScript.

Уявімо вигадане портфоліо з перемикачем теми, невеликим canvas-графіком і появою секцій. Цим функціям потрібен браузерний код. Корисне обмеження інше: кожен скрипт має видиму роботу, а текст статті не треба гідратувати як застосунок, коли його вже описує HTML.

Для кожної взаємодії поставте два питання: чи може це зробити звичайний HTML і чи мусить код запускатися раніше, ніж людина почне читати? Вкладка може залишатися справжнім посиланням, навіть якщо JavaScript робить перехід плавним. Після збою скрипта навігація має працювати.

Шрифт — частина Largest Contentful Paint

Якщо головний заголовок використовує вебшрифт, перше змістовне відображення може чекати на файл. Зберігайте потрібний WOFF2-набір локально й робіть справді критичний шрифт видимим у початковому HTML:

<link rel="preload" as="font" type="font/woff2"
      href="/fonts/mono-latin.woff2" crossorigin>

Google наводить preload вебшрифту як спосіб скоротити затримку ресурсу для текстового LCP. Продакшн-збірка може хешувати ім’я файлу; принцип залишається тим самим — раннє виявлення.

Preload усього підряд не є оптимізацією. Ресурси конкурують за канал. Cyrillic-набір можна обмежити сторінками, що його використовують, а зображення нижче першого екрана залишити lazy.

Декоративна анімація має поступатися контенту

Появу елементів легко недооцінити. Текст з opacity: 0 не може бути кандидатом LCP за правилами браузера, тому прихований до запуску JavaScript заголовок робить швидкий сервер повільним на вигляд.

Уявімо анімацію, яка чекає на шрифти й показує секції одну за одною. На ноутбуці це виглядає охайно, а на повільному телефоні найбільший текст може бути невидимим цілу секунду. Безпечніший варіант має коротку затримку, одразу показує все при reduced motion і примусово відкриває контент, якщо модуль не завантажився.

Навіть це не робить анімацію безкоштовною. Якщо польові дані погіршилися, декор прибирається першим. Розміри й позиції, що змінюють layout, теж краще не анімувати. Opacity і transform легше втримати подалі від CLS, ніж height, margin або top/left.

Кешуйте файли відповідно до зміни URL

Ресурси з хешем у назві можна кешувати надовго: новий вміст створює новий URL.

location ^~ /_astro/ {
    add_header Cache-Control "public, max-age=31536000, immutable" always;
    try_files $uri =404;
}

З HTML інакше: його URL після деплою той самий, тому потрібна ревалідація. Зображення можуть мати коротший спільний кеш, а JSON, що змінюється протягом дня, — ще коротший. Варто прочитати документацію nginx про add_header: успадкування у вкладених location може здивувати навіть із валідним конфігом.

Правило просте: кешуйте за стабільністю URL, а не за звичкою до розширення файлу.

Розумійте, що вимірюють Core Web Vitals

Поточні «хороші» межі: LCP не більше 2,5 секунди, INP не більше 200 мілісекунд і CLS не більше 0,1 на 75-му перцентилі відвідувань. Google пояснює числа та їхню логіку в гайді про межі Core Web Vitals.

Це польові метрики. Lighthouse — лабораторний тест у змодельованих умовах, і без взаємодії він не вимірює INP. Лабораторний тест ловить регресію до релізу, реальні дані показують досвід після. Не варто змішувати їх в одну обіцянку.

Використовуйте PageSpeed як діагностику

Тестуйте канонічний live-URL і localhost. Запускайте mobile та desktop кілька разів, а потім дивіться на окремі метрики й waterfall раніше за загальну оцінку. Документація Lighthouse пояснює коливання через пристрій, маршрут мережі, розширення та інші умови.

Коротка перевірка виглядає так:

1. Переконатися, що LCP-елемент — очікуваний контент.
2. Перевірити його ресурс у початковому HTML і відсутність lazy loading.
3. Знайти зсуви від шрифтів, зображень без розмірів і layout-анімації.
4. Побачити скрипти, що займають main thread раніше за потребу.
5. Окремо перевірити кеш HTML, хешованих ресурсів, зображень і даних.
6. Повторити після суттєвої зміни, а не вважати одну сотню постійною.

Результат, який має значення

Статичний сайт може отримати ідеальний лабораторний бал і втратити його за п’ять хвилин в інших умовах. Останній пункт вартий зусиль лише тоді, коли виправлення покращує сторінку для людини.

Стійка мета простіша: HTML приходить швидко, основний контент не чекає запуску застосунку, сторінка не стрибає, а невелика кількість JavaScript виправдовує своє місце. Цей стандарт переживе наступну зміну формули Lighthouse.