Budowanie z myślą o wydajności

Wydajność strony nie jest technicznym dodatkiem wykonywanym po publikacji. Wpływa na to, czy użytkownik zobaczy ofertę, czy interfejs nie przesunie się podczas kliknięcia i czy formularz szybko zareaguje.

Nie da się jej jednak rzetelnie opisać jednym wynikiem z testu. Potrzebne są wymagania, pomiar w kontrolowanych warunkach i obserwacja tego, czego doświadczają prawdziwi użytkownicy.

#Najpierw ustal ważną ścieżkę

Inaczej ocenia się prostą stronę usługową, inaczej sklep, a jeszcze inaczej aplikację po zalogowaniu. Przed rozmową o narzędziach wskaż najważniejsze zadanie użytkownika:

• odczytanie oferty i przejście do kontaktu;
• znalezienie produktu i rozpoczęcie zakupu;
• rezerwacja terminu;
• wykonanie operacji w panelu;
• przeczytanie artykułu i przejście do powiązanej usługi.

To na tej ścieżce wydajność ma znaczenie biznesowe. Strona może mieć dobry wynik ogólny, a jednocześnie opóźniać formularz, który generuje zapytania.

#Co mierzą Core Web Vitals?

Google wyróżnia trzy podstawowe wskaźniki doświadczenia:

• LCP (Largest Contentful Paint) — kiedy pojawia się największy istotny element widocznego obszaru;
• INP (Interaction to Next Paint) — jak szybko strona wizualnie odpowiada na interakcje;
• CLS (Cumulative Layout Shift) — jak bardzo układ niespodziewanie przesuwa się podczas używania.

Aktualne definicje i progi publikuje web.dev w dokumentacji Core Web Vitals. Warto odwoływać się do źródła zamiast wpisywać wartości raz do umowy i traktować je jako niezmienne.

Te wskaźniki nie opisują całego produktu. Nie powiedzą, czy treść jest zrozumiała, formularz działa ani czy użytkownik dociera do celu. Są częścią odbioru, nie jego zamiennikiem.

#Test laboratoryjny i dane użytkowników odpowiadają na inne pytania

Lighthouse lub PageSpeed Insights pomaga znaleźć problemy w powtarzalnym scenariuszu. Taki test jest dobry do porównania zmian przed i po wdrożeniu.

Dane terenowe pokazują natomiast doświadczenia prawdziwych osób: na różnych urządzeniach, połączeniach i trasach wejścia. Wynik może różnić się od testu uruchomionego na komputerze wykonawcy.

Dlatego sensowny proces wygląda tak:

1. przed zmianami zapisz warunki i wynik bazowy;
2. testuj te same adresy oraz scenariusze po wdrożeniu;
3. po publikacji obserwuj dane użytkowników;
4. oddziel regresję techniczną od zmiany treści, kampanii lub ruchu.

Jeśli strona dopiero startuje i nie ma odpowiedniej liczby wizyt, zacznij od testów laboratoryjnych. Nie przedstawiaj ich jednak jako danych od klientów.

#Najczęstsze źródła problemów

#Obraz nad pierwszym ekranem

Duży obraz wysłany w jednym rozmiarze może opóźnić LCP i niepotrzebnie obciążyć telefon. Wymagaj dopasowanych wariantów, współczesnego formatu, określonych wymiarów oraz właściwego priorytetu ładowania.

W Next.js komponent Image pomaga generować responsywne warianty i ograniczać przesunięcia układu, ale nie naprawi złego pliku źródłowego ani błędnie ustawionego parametru sizes.

#JavaScript, którego użytkownik nie potrzebuje od razu

Czat, mapa, rozbudowana animacja lub narzędzie analityczne mogą blokować główną ścieżkę. Część skryptów można załadować po interakcji, po wyrażeniu zgody albo dopiero na podstronie, która ich potrzebuje.

Pytanie odbiorowe brzmi nie tylko „ile waży paczka?”, ale „co musi zostać pobrane, zanim użytkownik wykona najważniejsze zadanie?”.

#Fonty i elementy zmieniające rozmiar

Brak zarezerwowanego miejsca na obraz, baner lub osadzony film powoduje przesunięcia. Font ładowany zbyt późno może zmienić długość wierszy i położenie przycisków. Każdy element o przewidywalnych proporcjach powinien otrzymać miejsce zanim pobierze się jego zawartość.

#Integracje zewnętrzne

Wolny skrypt spoza projektu trudniej kontrolować. Lista integracji powinna być jawna, a każda z nich mieć właściciela i uzasadnienie. To łączy wydajność z przeglądem compliance strony: część narzędzi wymaga również prawidłowej obsługi zgód.

#Ustal budżet wydajnościowy przed wdrożeniem

Budżet to granica, po której przekroczeniu zespół analizuje zmianę zamiast automatycznie ją publikować. Może dotyczyć:

• Core Web Vitals dla kluczowych szablonów;
• wagi obrazów nad pierwszym ekranem;
• ilości JavaScriptu uruchamianego na starcie;
• czasu odpowiedzi API dla głównej operacji;
• liczby zewnętrznych skryptów.

Nie kopiuj jednej liczby do każdego projektu. Ustal urządzenia, sieć, lokalizację testu, adresy i sposób powtarzania pomiaru. Bez tego nawet precyzyjny próg jest trudny do zweryfikowania.

#Checklista odbioru dla właściciela strony

Przy odbiorze poproś wykonawcę o pokazanie:

• wyników dla najważniejszych podstron, nie tylko strony głównej;
• porównania telefonu i komputera;
• zachowania obrazów, fontów i osadzonych materiałów;
• strony po odmowie opcjonalnych cookies oraz po ich akceptacji;
• reakcji formularza i komunikatów po wysłaniu;
• sposobu monitorowania regresji po publikacji.

Zapisz datę, narzędzie i warunki pomiaru. Dzięki temu kolejny audyt będzie porównaniem, a nie nową opinią.

#Wydajność wymaga utrzymania

Nowa kampania, film, piksel reklamowy lub zmiana CMS-a może pogorszyć stronę bez modyfikacji jej głównego kodu. Dlatego pomiar powinien wracać po ważnych zmianach i w ramach opieki nad stroną.

Jeśli obecna witryna działa wolno i nie wiadomo, czy wystarczy ją poprawić, zacznij od diagnozy opisanej w poradniku poprawić stronę czy zbudować nową. Decyzję warto oprzeć na ograniczeniach i kosztach, a nie na samym wyniku Lighthouse.