Optymalizacja strony – jak poprawić widoczność i szybkość?

Proces, który nie ma daty zakończenia

Dwanaście znalezisk z jednego dnia

Ilustracja z własnego podwórka. W ciągu jednego dnia pracy nad tym słownikiem, 4 września 2026 roku, audyty przy okazji przepisywania haseł wygenerowały dwanaście nowych zadań technicznych: adresy zgłaszane w mapie witryny mimo przekierowań, zgadywanie adresu zamiast błędu 404, brak oznaczeń kampanii w kalendarzu publikacji, 175 odnośników stojących w łańcuszku, 101 odnośników do dokumentacji oznaczonych zastrzeżeniem, 40 haseł bez odnośnika przychodzącego, strona usługi nieosiągalna z nawigacji, 94 strony z błędnym typem danych strukturalnych, martwy adres w przypisie, hasło opisujące wycofane narzędzie, dwa zdania ocierające się o obietnicę pozycji i dwie nieważne pary znaczników językowych. Żadnego z tych punktów nie było na liście rano.2 Tak właśnie wygląda optymalizacja: lista rośnie szybciej, niż da się ją wykonać, więc rozstrzyga nie kompletność listy, tylko kolejność.

Kolejność ustala się dwiema liczbami

Przy każdym znalezisku warto zapisać dwie rzeczy: ile stron dotyczy i ile godzin zajmie naprawa. Iloraz tych liczb porządkuje listę lepiej niż jakakolwiek dyskusja. Z powyższych dwunastu punktów najwyżej trafiły błędne typy danych strukturalnych — 94 strony, jedna zmiana w module wtyczki — a najniżej dwa zdania na stronach miejskich, które dotyczą dwóch adresów i wymagają decyzji redakcyjnej. Osobną kategorię tworzą rzeczy tanie i szybkie, które robi się od ręki właśnie dlatego, że są tanie: martwy adres w przypisie poprawia się w minutę. Reguła praktyczna brzmi więc: najpierw to, co dotyka wielu stron przy jednej zmianie, potem to, co kosztuje minuty, na końcu to, co wymaga decyzji.

Dwie i pół sekundy jako granica

Przy warstwie technicznej łatwo utonąć w drobiazgach, więc dobrze mieć jeden próg, do którego wraca się przed każdą większą zmianą. Dokumentacja podaje go wprost: „sites should strive to have Largest Contentful Paint of 2.5 seconds or less”, a mierzyć należy „the 75th percentile of page loads, segmented across mobile and desktop devices”.1 Dwa wnioski są ważniejsze niż sama liczba. Liczy się doświadczenie wolniejszej ćwiartki odwiedzających, a nie średnia, którą podnosi kilka szybkich wczytań z biurowego łącza. I liczy się element widoczny jako pierwszy — zwykle duży obraz albo blok tekstu w nagłówku — a nie pliki na końcu dokumentu, od których zaczyna się większość „optymalizacji”.

Co odróżnia proces od jednorazowego zrywu

Trzy rzeczy, wszystkie organizacyjne. Pierwsza: jedna osoba odpowiedzialna za listę, bo zadanie bez właściciela wraca w kolejnym audycie w tym samym brzmieniu. Druga: stały rytm zamiast akcji po spadku — przegląd raz w miesiącu wychwytuje usterki, zanim ktokolwiek zauważy skutki. Trzecia: powrót do zamkniętych punktów po kilku tygodniach, bo część zmian cofa się sama przy aktualizacjach i przebudowach szablonu. Wszystko poza tym — szybkość strony, architektura informacji, poprawność danych strukturalnych — jest tylko zawartością listy, którą wypełnia kolejny audyt SEO.

Najczęstsze pytania

Od czego zacząć optymalizację?
Od audytu, a potem od punktów, które przy jednej zmianie dotykają największej liczby stron. Kolejność jest ważniejsza niż kompletność listy.

Kiedy optymalizacja się kończy?
Nie kończy się. U nas jeden dzień pracy nad treścią wygenerował dwanaście nowych zadań technicznych, których wcześniej na liście nie było.

Jaki próg szybkości przyjąć?
Największy wyrenderowany element poniżej 2,5 sekundy, mierzony na 75. percentylu wczytań, osobno dla telefonów i komputerów.

Źródła

1. web.dev, Largest Contentful Paint (LCP) — próg 2,5 sekundy oraz zalecenie pomiaru na 75. percentylu wczytań, osobno dla urządzeń mobilnych i komputerów. Zobacz dokumentację →

2. Dane własne essaseo.pl — dwanaście zadań technicznych zapisanych 4 września 2026 roku na podstawie audytów wykonanych przy przepisywaniu haseł słownika.