aiact.waw.pl — case study strony w Astro

aiact.waw.pl to statyczna strona zbudowana w Astro 7 dla usługi doprowadzania firm do zgodności z AI Act. Pierwsze wejście na stronę główną kosztuje 108,5 KB transferu, powrót — 27,9 KB. Przeglądarka nie odpytuje ani jednej zewnętrznej domeny, a 82 podstrony powstają w jednym buildzie trwającym poniżej trzech sekund.

Wszystkie liczby w tym artykule pochodzą z produkcyjnego builda repozytorium (commit 2a15b36, pomiar z 2 września 2026) i są podane po kompresji gzip, czyli tak, jak zasób jedzie po sieci.

Czego wymagał projekt

Strona ma jedno zadanie sprzedażowe — doprowadzić właściciela małej lub średniej firmy od pytania „czy AI Act mnie dotyczy" do umówionego terminu — i kilka wymagań, które przy typowym stosie technologicznym stoją ze sobą w konflikcie:

• Formularz kwalifikujący i ankieta wyceny działające bez własnego backendu.
• Kalendarz rezerwacji spotkań z realną blokadą terminu, odporną na dwa równoczesne kliknięcia.
• Baza wiedzy: 66 artykułów w Markdown, każdy jako osobny adres do zaindeksowania.
• Zero analityki, pikseli i cookies — na stronie sprzedającej zgodność z prawem to nie jest detal.
• Wysoki wynik wydajności i dostępności jako wymóg briefu, nie miły dodatek.

Decyzje architektoniczne

Najważniejsza z tych decyzji jest druga. Dołożenie integracji React tylko po to, żeby użyć client:visible dla licznika i formularza, kosztowałoby dziesiątki kilobajtów przy interaktywności, którą obsługuje kilkaset linii własnego kodu. Mechanizm wysp opisujemy w artykule o architekturze wysp w Astro — tutaj wysp nie ma w ogóle, bo żadna nie była potrzebna.

Co strona faktycznie waży

Podstrony bazy wiedzy są jeszcze lżejsze: mediana z 82 wygenerowanych dokumentów to 21,6 KB po gzip, najlżejszy ma 6,5 KB. Cały build — 82 strony wraz z mapą witryny — zajmuje 2,84 sekundy, co ma znaczenie przy każdym wdrożeniu i przy każdym pull requeście w CI.

Jak to wygląda w pomiarze zewnętrznym

PageSpeed Insights (Lighthouse 13.4.1, pomiar z 2 września 2026) daje stronie 100 punktów we wszystkich czterech kategoriach — wydajność, ułatwienia dostępu, sprawdzone metody i SEO — jednocześnie w wariancie mobilnym i desktopowym. Największy element treści renderuje się w 1,0 s na emulowanym telefonie z łączem 4G i w 0,4 s na komputerze, przy zerowym czasie blokowania wątku głównego.

Progi „dobrego" wyniku dla metryk Core Web Vitals to 2,5 s dla LCP, 200 ms dla INP i 0,1 dla CLS (web.dev/articles/vitals). Pełny odczyt, warunki pomiaru i zastrzeżenia co do interpretacji rozkładamy w artykule o wynikach PageSpeed Insights.

Czego na tej stronie świadomie nie ma

• Frameworka UI w przeglądarce. Interaktywność to licznik, zakładki, dwuetapowy formularz i podgląd wzorów dokumentów — obsłużone własnym kodem na czystym DOM.
• Frameworka CSS. Zamiast klas narzędziowych jeden plik tokenów: kolory, skala typograficzna, odstępy. Audyt kontrastu czyta ten sam plik, więc kontrola jakości patrzy dokładnie na te wartości, które renderuje przeglądarka.
• Analityki, pikseli i banera cookies. Zero zewnętrznych domen oznacza brak skryptów trzecich stron rywalizujących o wątek główny i brak zgód do zbierania.
• Obrazów w treści. Wzory dokumentów są wektorami wstawionymi w HTML, więc skalują się bez utraty ostrości i nie rezerwują miejsca po pobraniu, tylko od razu.

Co przejmuje hosting, a czego strona nie musi robić sama

Netlify serwuje gotowe pliki z sieci brzegowej i unieważnia pamięć podręczną przy każdym wdrożeniu, więc nie trzeba ręcznie wersjonować zasobów ani czyścić cache po publikacji (dokumentacja Netlify o cache). Wdrożenie jest atomowe: albo publikuje się cała nowa wersja, albo żadna.

Formularze zgłoszeniowe obsługuje mechanizm hostingu, który skanuje zbudowany HTML przy wdrożeniu — nie ma dla nich osobnego backendu. Jedyny fragment działający po stronie serwera to rezerwacja terminu spotkania: funkcja zapisuje termin operacją „tylko jeśli wolny", więc dwa kliknięcia w tej samej sekundzie kończą się jedną rezerwacją i czytelnym błędem dla drugiej osoby, zamiast dwóch spotkań na tę samą godzinę.

Jak pilnujemy, żeby to się nie rozjechało

1. Każdy push i pull request uruchamia kontrolę typów oraz szablonów Astro.
2. Ten sam workflow uruchamia audyt kontrastu WCAG i struktury dostępności — jeden nagłówek h1, brak przeskoków w hierarchii, etykiety pól, brak duplikatów identyfikatorów.
3. Niezaliczona para kontrastu kończy build błędem, zamiast trafiać na produkcję.
4. Zmiany dotykające układu weryfikujemy zrzutem ekranu, nie samym przeczytaniem CSS.
5. Dolny próg testów mobilnych to 360 px szerokości — poniżej tego progu wychodzą błędy niewidoczne na desktopie.

Czego to podejście nie rozwiązuje

Statyczna strona nie zastąpi panelu redakcyjnego. Jeśli treść ma edytować kilka osób nietechnicznych codziennie, do tego samego Astro trzeba dołożyć headless CMS albo wybrać inne narzędzie — rozstrzygamy to w porównaniu Astro, WordPressa i Next.js.

Statyczne wyjście nie obsłuży też widoków zależnych od zalogowanego użytkownika. Tam, gdzie pojawia się konto, historia zamówień czy panel klienta, potrzebna jest warstwa serwerowa — albo w postaci pojedynczych funkcji, jak przy rezerwacji terminów, albo pełnej aplikacji.

Co z tego przenosimy do kolejnych projektów

• Zacznij od budżetu transferu i traktuj każdą bibliotekę jak wydatek z tego budżetu.
• Hostuj fonty u siebie i ładuj z wyprzedzeniem tylko te wagi, które widać na pierwszym ekranie.
• Trzymaj treść w jednym źródle, z którego budują się też dane strukturalne.
• Wpinaj audyt dostępności w CI, żeby regresja zatrzymywała się przed wdrożeniem.
• Każdy skrypt zewnętrzny wprowadzaj jako świadomą decyzję kosztową, nie jako domyślny element strony.