Polyarix 5.0

Własna strona to najbardziej wymagający projekt: klient jest wybredny, deadline’ów nie ma, a wynik oglądają wszyscy. To szczera historia o tym, jak strona naszej firmy przeszła drogę od WordPressa przez Laravel do duetu „statyczny front na Astro + headless CMS na Laravelu” - i dlaczego nowa wersja ładuje się błyskawicznie, żyje w czterech językach i przebudowuje się sama po każdej zmianie w panelu administracyjnym.

Historia strony ciągnie się od 2013 roku i wszystkie pierwsze wersje żyły na WordPressie. To nie była „strona z szablonu”: unikalny motyw napisany pod nas, efekty na three.js, pola niestandardowe na ACF, wielojęzyczność. Przez te lata strona przeszła kilka redesignów - zmieniał się wygląd, ale platforma zostawała ta sama. Języki też dochodziły stopniowo: do 2020 roku strona żyła w dwóch, potem doszedł trzeci.

A WordPress uczciwie robił swoją robotę. Jeśli coś wymagało stałej uwagi, to bezpieczeństwo: WordPress to najpopularniejszy CMS na świecie, a więc i najczęściej atakowany, dlatego rdzeń i wtyczki trzeba łatać bez przerwy.

Z czasem doszła jeszcze jedna obserwacja: strona z ciężką grafiką 3D i kilkoma językami zderzała się z architekturą uniwersalnego CMS-a. Wszystko działało, ale nam nie chodziło o „działa” - szukaliśmy rozwiązania maksymalnie wygodnego i szybkiego. Dla firmy, która robi strony klientom, własna strona to też poligon: sprawdzamy na niej podejścia, zanim zaproponujemy je innym.

W 2022 roku przenieśliśmy stronę na Laravel - framework, na którym budujemy większość projektów klienckich. Klasyczny monolit: Laravel składa strony na serwerze, treść w bazie danych, własny panel administracyjny.

• Pełna kontrola nad kodem: każda funkcja to kwestia developmentu, a nie szukania odpowiedniej wtyczki.
• Porządek w danych: projekty, artykuły, opinie, oferty pracy i technologie stały się pełnoprawnymi bytami w bazie z własnymi polami i relacjami.
• Spokojniej o bezpieczeństwo: Laravel od razu zamyka całe klasy ataków, a powierzchnia ataku jest wyraźnie mniejsza niż w CMS-ie z dziesiątkami zewnętrznych wtyczek.

Ta wersja przepracowała cztery lata. Ale do 2026 roku znowu zachcieliśmy więcej.

Nową wersję zaczęliśmy nie od kodu, a od designu. Referencją nastroju były lekkie, „oddychające” strony z szeroką siatką: wybraliśmy kontener 1520 pikseli zamiast typowych 1140-1200, żeby prace i typografia miały przestrzeń. Stałe elementy marki zostały: logo, firmowy niebieski, font Gotham Pro. Dodaliśmy paletę akcentów - fiolet, pomarańcz, miętę, brzoskwinię.

Ważna decyzja architektoniczna: design system istnieje nie jako PDF z wytycznymi, ale jako żywa strona wewnątrz serwisu. To wewnętrzny UI kit, który renderuje prawdziwe tokeny i komponenty z kodu produkcyjnego: paletę, skalę typograficzną, odstępy, promienie, przyciski, karty, formularze, akordeony. Design i kod nie mogą się rozjechać: jeśli token zmienił się w CSS - zmienił się i w wytycznych. Ta strona nie trafia na produkcję.

Wszystkie tokeny żyją w jednym pliku CSS jako custom properties:

:root {
  --c-blue: #0204f5;
  --c-purple: #b535fc;
  --c-orange: #ff642c;
  --c-mint: #85f4c4;
  /* ...skala typograficzna, odstępy, promienie, cienie, funkcje easing */
}

Jeden plik - jedyne źródło prawdy dla całego wyglądu na każdej z setek stron.

• Astro - framework frontendowy. Składa strony do gotowego HTML-a z wyprzedzeniem i domyślnie wysyła odwiedzającemu zero kilobajtów JavaScriptu. Dla porównania: typowa strona na Reakcie niesie 100-300 KB skryptów tylko po to, żeby „wystartować”.
• Vite - bundler, na którym Astro działa pod maską: błyskawiczny serwer deweloperski i agresywna optymalizacja kodu produkcyjnego.
• TypeScript - każdy byt treści jest opisany typem i jeśli API zwróci coś innego, niż oczekuje szablon, błąd wyskoczy przy buildzie, a nie u odwiedzającego.
• three.js - grafika 3D do animacji na stronie głównej. Używamy „gołego”, bez nakładek: mniej kodu, wyższy FPS.
• sanitize-html - filtr dla HTML-a z panelu administracyjnego: treść z CMS-a fizycznie nie może przynieść na stronę podatności.
• sharp - obróbka obrazów na etapie builda.
• Laravel + Backpack CRUD - API treści i panel administracyjny: opisujesz byt - dostajesz gotowy interfejs z listami, filtrami i uprawnieniami.
• Cloudflare Pages - hosting statyki w sieci CDN: odwiedzający z Warszawy, Kijowa czy Nowego Jorku dostaje stronę z najbliższego punktu.
• GitHub Actions - CI/CD: każda zmiana przechodzi przez testy i wdraża się automatycznie.
• Sentry - monitoring błędów po obu stronach: dowiadujemy się o problemie, zanim odwiedzający napisze do supportu.

Kluczowa idea: strona-wizytówka powinna być statyczna. Przeglądarka dostaje gotowy HTML z najbliższego serwera CDN - nie ma czego renderować, nie ma na co czekać. Robot wyszukiwarki widzi w pełni gotową stronę, a nie pusty kontener, który „kiedyś dorysuje JavaScript”. Pliki statyczne nie mają bazy danych ani sesji - dosłownie nie ma czego atakować.

Cały build - 119 stron w czterech językach w około 2,5 sekundy. I to dopiero start: stron aktywnie przybywa - blog, landing pages usług, nowe case studies.

„Zero JS domyślnie” nie znaczy „nudno”. Animacje są, ale każda podpinana jest punktowo: „signal field” na stronie głównej ładuje się leniwie i zatrzymuje poza ekranem; portrety halftone w opiniach są rastrowane prosto w przeglądarce; pojawianie się bloków przy scrollu i liczniki - ręcznie na IntersectionObserver, bez ani jednej biblioteki.

Wymownym przykładem jest strona główna. Najpierw zintegrowaliśmy efektowną szklaną kulę 3D: React, silnik fizyczny, model 3D. Pięknie, ale ciężko - megabajty kodu i fizyka WebAssembly. Zastąpiliśmy ją „signal field”: czysty three.js bez Reacta i fizyki. Wizualnie prawie nie straciliśmy, a na wadze i płynności zyskaliśmy wielokrotnie. Czasem właściwa decyzja inżynierska to w porę zrezygnować z pięknego, ale drogiego.

Osobno o językach: strona żyje po angielsku, rosyjsku, ukraińsku i polsku - cztery języki po raz pierwszy w historii projektu. Każda strona istnieje w czterech wersjach z poprawnymi URL-ami i wszystkie składane są z jednego zestawu komponentów - zmieniają się tylko słowniki tłumaczeń i treść z CMS-a.

W klasycznym CMS-ie panel administracyjny i strona to jedna całość: system i przechowuje treść, i rysuje strony. W podejściu headless CMS jest „pozbawiony głowy”: tylko przechowuje treść i wydaje ją przez API - w formacie JSON. A strony rysuje ktoś inny - w naszym przypadku Astro.

Nie wyrzuciliśmy dorobku drugiej wersji: backend na Laravelu został, ale zmienił zawód - z „serwera renderującego stronę” stał się API treści i panelem administracyjnym na Backpacku. Żyje w nim dziesięć typów treści: strony, artykuły, autorzy, projekty, opinie, klienci, usługi, technologie, oferty pracy i ustawienia serwisu.

API zwraca pola tłumaczone jako mapę wszystkich lokalizacji z fallbackiem (jeśli polski tekst nie jest napisany - pokaże się angielski), ukrywa szkice, cache’uje się i odpowiada tylko zaufanym domenom frontendu.

Treść złożonych stron - case studies i usług - to nie „płachta” tekstu, a tablica typowanych bloków: fakty, tekst, kolumny, obraz, galeria, slider, kroki, FAQ, call to action. Redaktor składa stronę z bloków jak z klocków, a po stronie Astro jeden wspólny renderer zamienia każdy typ na własny komponent:

{blocks.map((block) => {
  switch (block.type) {
    case 'facts':   return <FactsGrid {...block} />;
    case 'gallery': return <Gallery images={block.images} />;
    case 'steps':   return <StepsTimeline {...block} />;
    case 'cta':     return <CtaBanner {...block} />;
    /* ...text, columns, image, slider, faq */
  }
})}

Content manager dostaje swobodę składu, ale nie może zepsuć designu: każdy blok renderuje się ściśle według design systemu. A cały HTML z panelu przechodzi przez sanitizer: usuwane są potencjalnie niebezpieczne tagi, a nawet wyrównywana jest hierarchia nagłówków - żeby redaktor fizycznie nie mógł popsuć struktury SEO strony. Swoją drogą, tę stronę czytasz właśnie z takich bloków.

Od zmiany w panelu do aktualizacji na produkcji mijają 3-4 minuty, bez udziału programisty. Na wypadek, gdy nie chce się czekać, w panelu jest przycisk „Przebuduj stronę”. To właśnie architektura JAMstack: szybkość i niewrażliwość statyki plus wygoda zwykłego CMS-a.

Szczegół dla niezawodności: snapshoty odpowiedzi API są zacommitowane w repozytorium frontendu. Stronę można zbudować i przetestować zupełnie bez backendu, a specjalna kontrola porównuje strukturę snapshotów z żywym API - o zmianie formatu dowiemy się z kontroli, a nie z zepsutej produkcji.

SEO było w tym projekcie wymaganiem numer jeden dla architektury - zakładaliśmy je od samego początku.

• Natychmiastowe wydawanie HTML-a: statyka z CDN daje najlepsze Core Web Vitals - nie ma serwera, który „myśli”, ani renderowania JS, które wyszukiwarka musiałaby wykonywać.
• Dokładnie jeden h1 na każdej stronie i bez przeskoków poziomów nagłówków - to zagwarantowane nawet dla treści z CMS-a.
• Canonical, title i description - po jednym na stronę, dla każdej ze 119.
• Wielojęzyczne SEO: każda strona deklaruje swoje wersje językowe przez hreflang, a mapa strony generuje się automatycznie ze wszystkimi powiązaniami.
• Dane strukturalne: graf Schema.org na każdej stronie - Organization, WebSite, WebPage, plus Article, JobPosting, FAQPage, Service, BreadcrumbList, Person. Z tego Google buduje rozszerzone wyniki.
• Uczciwe 404: bez specjalnego pliku Cloudflare Pages zwraca na nieistniejące URL-e stronę główną z kodem 200 (soft 404, za który wyszukiwarki karzą) - wyłapaliśmy to na audycie i naprawiliśmy.
• Żadnych linków strony do samej siebie: logo na stronie głównej, aktywna pozycja menu i bieżący język to nie linki. Higiena grafu linków, o którą prawie nikt nie dba.

I najważniejsze: wszystko powyższe jest sprawdzane automatycznie. Własny skrypt-audytor przechodzi po wszystkich zbudowanych stronach i żadna regresja SEO nie prześlizgnie się niezauważona - zero uwag albo build nie jedzie na produkcję.

Statyka statyką, ale zgłoszenia trzeba przyjmować. Formularze wysyłają się prosto do API Laravela: walidacja na serwerze, ochrona przed spamem, CV trafia do prywatnego magazynu, a każde zgłoszenie zapisuje stronę i język użytkownika.

Backend jest pokryty zestawem 72 testów automatycznych: kontrakt API (wszystkie lokalizacje na miejscu, szkice ukryte), CORS, formularze, przebudowa, import treści. Deploy jest fizycznie niemożliwy, dopóki choć jeden test jest czerwony. Front end ma własnych strażników: strukturalny audyt SEO wszystkich stron i kontrolę kontraktu z API. Błędy produkcji łapie Sentry po obu stronach.