Optymalizacje wydajności: Astro i Netlify

Szybkość statycznej strony nie bierze się z jednej sztuczki, tylko z kilkunastu decyzji o tym, co w ogóle trafia do przeglądarki. Poniżej rozpisujemy komplet zabiegów zastosowanych na aiact.waw.pl — z wagą, jaką każdy z nich realnie oszczędza, i z metryką Core Web Vitals, na którą wpływa.

Zasada wyjściowa: każdy kilobajt jest decyzją

Przy statycznym wyjściu z Astro nie ma kosztu, którego „nie da się uniknąć". Nie ma runtime frameworka, nie ma bibliotek, nie ma wtyczek dokładających własne skrypty. Wszystko, co pobiera przeglądarka, ktoś wpisał do repozytorium świadomie — więc każdy z tych wpisów można obronić albo usunąć.

CSS wbudowany w HTML zamiast osobnego pliku

Astro potrafi wstawić style bezpośrednio do dokumentu zamiast linkować osobny arkusz. Na aiact.waw.pl to ustawienie jest włączone dla wszystkich stron: 33,7 KB CSS przed kompresją jedzie razem z HTML-em i po gzip zajmuje 6,8 KB.

Zysk to jeden request mniej na ścieżce krytycznej — przeglądarka nie musi pobrać HTML-a, znaleźć w nim odwołania do arkusza, otworzyć drugiego połączenia i dopiero wtedy zacząć malować. Granica opłacalności tej techniki leży tam, gdzie CSS jest na tyle duży, że jego powtarzanie w każdym dokumencie kosztuje więcej niż jednorazowe pobranie do pamięci podręcznej. Przy kilku kilobajtach po kompresji ta granica jest odległa.

Fonty: własny hosting, subsety, ładowanie z wyprzedzeniem

Fonty są największą pojedynczą pozycją transferu na tej stronie: 65,7 KB przy pierwszym wejściu. Dlatego są traktowane jak osobny projekt optymalizacyjny.

Wyrównanie cyfr w cenach, datach i liczniku daje właściwość font-variant-numeric: tabular-nums, a nie osobny krój monospace. To jedna deklaracja CSS zamiast dwóch dodatkowych plików fontu.

Zero skryptów trzecich stron

Na aiact.waw.pl nie ma analityki, pikseli reklamowych, widżetu czatu ani testów A/B. Przeglądarka odpytuje wyłącznie domenę, na której stoi strona — 11 zasobów, wszystkie z tego samego serwera.

Skrypty zewnętrzne uderzają dokładnie w tę metrykę, którą najtrudniej naprawić później: wykonują się na wątku głównym, więc wydłużają czas odpowiedzi na pierwsze kliknięcie. Ich koszt jest też trudny do przewidzenia, bo zmienia się bez udziału zespołu — dostawca aktualizuje skrypt, a strona spowalnia w tygodniu, w którym nikt jej nie zmieniał.

Stabilność layoutu: skąd bierze się CLS równe zeru

• Brak obrazów rastrowych w treści. Wzory dokumentów są wektorami wstawionymi bezpośrednio w HTML, więc nie ma elementu, który dosuwa treść po pobraniu.
• Zarezerwowana szerokość licznika. Cyfry o stałej szerokości plus minimalna szerokość w jednostce ch sprawiają, że zmiana z 09 na 10 nie przesuwa sąsiednich elementów.
• Kroki formularza w jednej komórce siatki. Drugi krok leży dokładnie na pierwszym, więc przejście między nimi nie zmienia wysokości bloku.
• Fonty z wyprzedzeniem i swap. Podmiana kroju następuje wcześnie i na zbliżonych metrykach, zamiast przebudowywać stronę w połowie czytania.

JavaScript jako ulepszenie, nie warunek działania

Cały kod kliencki jest napisany tak, żeby strona działała bez niego. Nawigacja boczna bez JavaScriptu jest zwykłą listą linków — mechanizm zwijania włącza się dopiero, gdy skrypt oznaczy dokument klasą sygnalizującą swoją obecność. Sekcje pojawiające się przy przewijaniu nie są ukrywane, dopóki nie ma czym ich pokazać.

Globalna reguła respektująca ustawienie ograniczonego ruchu wyłącza wszystkie animacje i przejścia, a klasa uruchamiająca efekt wejścia nie jest wtedy w ogóle dodawana. To jednocześnie dostępność i wydajność: mniej pracy dla przeglądarki na słabszym sprzęcie.

Co przejmuje warstwa hostingu

Statyczne zasoby są serwowane z sieci brzegowej i unieważniane automatycznie przy każdym wdrożeniu, więc zespół nie musi wersjonować nazw plików ani czyścić pamięci podręcznej po publikacji (dokumentacja Netlify o cache). Wdrożenie jest atomowe, a wycofanie zmiany to powrót do poprzedniej wersji, nie ponowny build.

Kod po stronie serwera istnieje wyłącznie tam, gdzie jest nieunikniony: rezerwacja terminu spotkania zapisuje slot operacją „tylko jeśli wolny". Reszta strony pozostaje plikami, które nie wymagają uruchamiania niczego.

Podsumowanie technik i ich wpływu

Checklista optymalizacji dla strony w Astro

• Ustal budżet transferu dla pierwszego wejścia i zapisz go w repozytorium.
• Sprawdź listę domen odpytywanych przy wejściu — powinna zawierać wyłącznie Twoją.
• Policz wagę fontów i usuń każdą wagę oraz krój, których nie widać na stronie.
• Włącz wbudowywanie CSS, dopóki arkusz mieści się w kilku kilobajtach po kompresji.
• Zarezerwuj wymiary dla każdego elementu, który pojawia się lub zmienia po załadowaniu.
• Zweryfikuj, czy strona jest użyteczna z wyłączonym JavaScriptem.
• Zmierz build przed i po zmianie, zamiast opierać się na wrażeniu.

Najczęstsze błędy

• Optymalizacja obrazów przy zerowej liczbie obrazów. Zanim zaczniesz dobierać formaty, sprawdź, co faktycznie waży najwięcej — tutaj były to fonty, nie grafika.
• Dokładanie analityki „na chwilę". Skrypt zewnętrzny zostaje na lata i zmienia się bez Twojej wiedzy, a jego koszt wraca przy każdym pomiarze.
• Traktowanie wyniku pomiaru jako stanu trwałego. Wydajność jest właściwością konkretnego wdrożenia, nie technologii — dlatego pomiar wpinamy w proces, a nie robimy go raz, w dniu uruchomienia strony.

Jak te decyzje układają się w całość projektu, opisujemy w studium przypadku aiact.waw.pl, sam mechanizm zerowego JavaScriptu — w artykule o architekturze wysp, a efekt zmierzony narzędziem zewnętrznym — w odczycie PageSpeed Insights. Progi, do których odnoszą się te metryki, opisuje dokumentacja Google (web.dev/articles/vitals).