Czym jest szybkość strony WWW

Szybkość strony to czas, w którym użytkownik może realnie skorzystać z witryny. Nie tylko zobaczyć biały ekran. Nie tylko doczekać się pierwszego tekstu. Chodzi o moment, w którym strona jest czytelna, stabilna, reaguje na kliknięcia i pozwala zrobić to, po co człowiek na nią wszedł.

W dużym skrócie: szybkość strony to doświadczenie czekania. A nikt nie lubi czekać.

Spójrz na stronę jak na lokal, w którym podejmujesz klienta. Nie znam nikogo, kto lubi cisnąć się w ciasnej i dusznej przestrzeni, stojąc w długiej kolejce. Niezależnie od tego, czy prowadzisz gastronomię i klient czeka na posiłek, księgarnię, gabinet, sklep czy firmę usługową — bezproduktywne czekanie irytuje. Problem znany jest od dawna i nieprzypadkowo na kelnera Anglicy mówią „waiter”.

Świat idzie do przodu. Użytkownik nie porównuje Twojej strony z inną stroną sprzed dziesięciu lat. Porównuje ją z tym, co działa dziś: aplikacją banku, sklepem, mapą, komunikatorem, stroną konkurencji. Jeśli Twoja witryna ładuje się wolno, użytkownik nie będzie analizował powodów. Po prostu poczuje, że coś jest nie tak.

Dlaczego szybkość strony ma znaczenie dla SEO

Szybkość strony ma znaczenie, bo łączy techniczne SEO, UX i konwersję. Wolna strona utrudnia użytkownikowi wykonanie działania: przeczytanie oferty, wysłanie formularza, dodanie produktu do koszyka, kliknięcie telefonu albo przejście do kontaktu.

Google od lat zwraca uwagę na jakość doświadczenia użytkownika. Core Web Vitals mierzą między innymi ładowanie, interaktywność i stabilność wizualną strony. To nie znaczy, że sama szybkość zastąpi treść, linki, intencję i jakość serwisu. Nie zastąpi. Ale wolna, niestabilna i ciężka strona potrafi zmarnować dobrą pracę wykonaną w innych obszarach SEO.

Najmocniej widać to na urządzeniach mobilnych. Użytkownik telefonu często korzysta ze słabszego połączenia, jest w ruchu i ma mniej cierpliwości. Jeśli na ekranie długo nic się nie dzieje, formularz skacze, przycisk ucieka, a grafika ładuje się po kawałku, trudno mówić o dobrym doświadczeniu.

Szybkość ma też znaczenie dla crawlowania. Jeżeli serwer odpowiada wolno, strona jest ciężka, a CMS generuje dużo zbędnych zasobów, roboty wyszukiwarki mogą mniej efektywnie przeglądać witrynę. W małej stronie nie zawsze będzie to dramat. W dużym sklepie albo serwisie z tysiącami adresów zaczyna mieć znaczenie.

Najważniejsze metryki szybkości

Kiedyś szybkość strony oceniano głównie w sekundach. Potem pojawiły się narzędzia pokazujące wynik procentowy albo punktowy. Dziś warto patrzeć szerzej: nie tylko na jeden wynik, ale na kilka metryk, które opisują różne momenty ładowania i używania strony.

TTFB, czyli Time To First Byte, pokazuje czas reakcji serwera. Użytkownik wpisuje adres, przeglądarka wysyła zapytanie, a serwer odpowiada pierwszym bajtem danych. Jeśli TTFB jest wysoki, problem często zaczyna się zanim strona w ogóle zacznie się ładować po stronie użytkownika.

FCP, czyli First Contentful Paint, oznacza moment, w którym użytkownik widzi pierwszy element treści. Może to być tekst, obraz albo inny widoczny element. Jeśli FCP jest długi, użytkownik ma wrażenie, że strona stoi.

LCP, czyli Largest Contentful Paint, mierzy moment załadowania największego istotnego elementu widocznego w obszarze ekranu. Często jest to duży obraz, baner, hero albo blok treści. LCP dobrze pokazuje, kiedy użytkownik dostaje główną zawartość strony.

CLS, czyli Cumulative Layout Shift, mierzy stabilność układu. Jeśli ładuje się strona, potem dociągają się grafiki, reklamy, fonty albo formularze, a całość skacze po ekranie, CLS będzie problemem. Użytkownik chce kliknąć przycisk, a strona nagle przesuwa mu go spod palca. Piękna katastrofa.

INP, czyli Interaction to Next Paint, mierzy responsywność strony na interakcje użytkownika. Chodzi o to, jak szybko strona reaguje po kliknięciu, stuknięciu albo wpisaniu czegoś. To ważne szczególnie tam, gdzie użytkownik ma coś zrobić, a nie tylko przeczytać tekst.

Fully Load Time oznacza czas pełnego załadowania strony i wszystkich zasobów. Nie jest to jedyna metryka, ale nadal bywa praktyczna. Szczególnie przy porównaniach przed i po optymalizacji.

Od czego zacząć optymalizację szybkości

Optymalizacja szybkości strony to proces. Nie jednorazowy zabieg, nie magiczna wtyczka, nie sprint do wyniku 100/100. Strona żyje: pojawiają się nowe grafiki, skrypty, aktualizacje CMS, nowe moduły, formularze, piksele reklamowe, czaty, mapy, fonty i integracje. Każdy z tych elementów może coś zepsuć.

Najczęściej warto zacząć od podstaw:

• Grafiki. Za duże zdjęcia, brak WebP lub AVIF, brak kompresji i brak wymiarów potrafią zabić szybkość strony.
• Cache. Dobrze ustawiona pamięć podręczna może znacząco ograniczyć liczbę operacji wykonywanych przy każdym wejściu.
• CMS. Aktualny, czysty CMS zwykle działa lepiej niż strona obciążona latami przypadkowych dodatków.
• Wtyczki i moduły. Pięć wtyczek robiących to samo nie daje pięciu razy lepszego efektu. Częściej daje pięć razy większy bałagan.
• JavaScript i CSS. Nadmiar skryptów, nieużywany kod i blokujące zasoby mogą mocno opóźniać renderowanie strony.
• Serwer. Jeśli TTFB jest słaby, sama kompresja zdjęć nie rozwiąże wszystkiego.
• CDN. Przy większych serwisach albo ruchu z różnych lokalizacji CDN może skrócić czas dostarczania zasobów.
• Mobile. Strona musi działać dobrze na telefonie, nie tylko na szybkim komputerze właściciela.

Najpierw usuwa się oczywiste ciężary. Dopiero później ma sens dłubanie w detalach, krytycznym CSS, opóźnianiu skryptów i trudniejszych optymalizacjach.

Grafiki — najczęstszy winowajca

Tak na serio, bardzo często 80% efektu można uzyskać, optymalizując grafiki. Oczywiście nie zawsze. Są strony, które mają dramatyczny JavaScript, fatalny serwer albo źle skonfigurowany CMS. Ale w ogromnej liczbie przypadków pierwsze kilogramy leżą właśnie w obrazach.

Zdjęcie wrzucone prosto z aparatu albo telefonu potrafi ważyć kilka megabajtów. Jeśli takich zdjęć jest kilka, użytkownik nie ładuje strony. On pobiera album rodzinny w jakości do druku. Na telefonie to boli szczególnie.

Dobra optymalizacja grafik zaczyna się od kolejności:

1. kadrowanie,
2. zmiana rozmiaru do realnego miejsca na stronie,
3. kompresja,
4. konwersja do WebP albo AVIF, jeśli ma sens,
5. ustawienie width i height,
6. lazy loading dla obrazów poza pierwszym ekranem,
7. kontrola jakości po wdrożeniu.

Nie warto zaczynać od ślepego kompresowania. Jeśli obraz ma 5000 px szerokości, a wyświetla się w kolumnie 900 px, najpierw trzeba go zmniejszyć. Kompresja wielkiego zdjęcia to często tylko bardziej elegancki sposób marnowania transferu.

Cache, CMS i wtyczki

Duża część problemów z szybkością strony wynika z technicznej higieny CMS. Nieaktualne wtyczki, duplikujące się dodatki, ciężkie szablony, zbędne moduły i skrypty dokładane przez lata potrafią spowolnić nawet prostą stronę.

Cache pomaga, ale nie jest lekarstwem na wszystko. Dobrze skonfigurowana pamięć podręczna może przyspieszyć generowanie i dostarczanie strony, ale jeśli sam serwis jest technicznie ciężki, cache tylko maskuje część problemu.

Warto regularnie sprawdzać, które wtyczki są naprawdę potrzebne. Czy jedna nie dubluje drugiej. Czy moduł, który kiedyś obsługiwał promocję, nadal jest używany. Czy formularz, mapa, slider, pop-up, piksel, czat i zewnętrzny font są konieczne na każdej podstronie.

Strona, którą czytasz, przez długi czas działała na bardzo surowym CMS-ie, z minimalną liczbą dodatków. Jedna z nielicznych wtyczek służyła do backupu. Można? Można. Nie każda strona musi być technologiczną choinką.

JavaScript, CSS i elementy blokujące renderowanie

Po grafikach bardzo często problemem są skrypty. JavaScript odpowiada za formularze, menu, animacje, analitykę, reklamy, mapy, czaty, zgody cookies i dziesiątki innych rzeczy. Każdy z tych elementów może być potrzebny. Razem potrafią zrobić beton.

Największy problem pojawia się wtedy, gdy skrypty blokują wyświetlenie głównej treści albo obciążają stronę zanim użytkownik w ogóle zdąży cokolwiek zrobić. Czasem warto opóźnić ładowanie części zasobów, usunąć nieużywany kod, ograniczyć zewnętrzne skrypty albo przygotować krytyczny CSS dla pierwszego ekranu.

Nie chodzi jednak o ślepą walkę z każdym kilobajtem. Jeśli skrypt jest potrzebny do działania koszyka, formularza albo procesu sprzedaży, nie można go po prostu wyrzucić, bo narzędzie pokazało czerwony komunikat. Optymalizacja szybkości ma pomagać stronie, a nie niszczyć jej funkcje.

Serwer, TTFB i hosting

Serwer ma znaczenie. Szybki hosting nie naprawi złej strony, ale fatalny hosting potrafi zabić dobrą optymalizację. Jeśli strona jest lekka, grafiki są przygotowane, cache działa, a mimo to TTFB jest słaby, trzeba spojrzeć na serwer.

TTFB jest ważny, bo to początek całego procesu. Jeśli serwer długo odpowiada, użytkownik czeka jeszcze zanim przeglądarka zacznie pobierać właściwą treść. W takim przypadku dalsza optymalizacja frontendu może dawać coraz mniejsze efekty, bo korek stoi wcześniej.

Na naszym rynku hostingowym bywa różnie. Wielu klientów rotuje między kilkoma firmami, zmienia się logo na fakturze, ale jakość usługi nie zawsze idzie wyraźnie w górę. Dlatego przy ambitnych projektach warto testować TTFB, lokalizację serwera, wsparcie HTTP/2 lub HTTP/3, cache po stronie serwera, CDN, wersję PHP, limity zasobów i stabilność działania.

Prace serwerowe najlepiej robić ostrożnie. Najpierw backup, potem środowisko testowe, potem pomiary przed i po. Zmiana hostingu potrafi pomóc, ale nie powinna być ruchem wykonywanym w panice.

Case study — przeniesienie strony na lepszy serwer

Ten fragment jest efektem dłuższych testów i stopniowo wprowadzanych zmian na stronie positioning.site. W pewnym momencie uznałem, że zoptymalizowałem już większość rzeczy, które miały biznesowy sens. To nie znaczy, że nie dało się poprawić nic więcej. Dało się. Tylko nakład pracy zaczynał przestawać się spinać.

Postanowiłem więc przyjrzeć się parametrowi TTFB. W początkowej fazie zajmował on około połowy czasu ładowania strony. Szukałem hostingu z szybkim serwerem, dobrą infrastrukturą i sensowną konfiguracją pod stronę, która miała działać szybko nie tylko w teorii.

Po analizie różnych ofert zdecydowałem się przetestować Kinsta, czyli hosting oparty o infrastrukturę Google Cloud. Domyślnie oferta jest kierowana głównie do WordPressa, ale udało mi się uruchomić tam Joomlę. Test nie polegał na jednoczesnej przebudowie całej strony. Chodziło o porównanie wpływu zmiany serwera na szybkość.

Tak wyglądało to w osi czasu.

W listopadzie było zrobione już bardzo dużo. Strona ładowała się całkiem przyzwoicie, ale raport pokazywał, że nadal jest co poprawiać. Najbardziej interesował mnie wpływ serwera, bo część frontendowa była już mocno odchudzona.

Po przeniesieniu strony sprawa wyglądała wyraźnie lepiej. Najważniejszy wniosek nie brzmi jednak: „wszyscy na Kinsta”. To byłby tekst reklamowy, a nie analiza. Wniosek jest inny: gdy strona jest już dobrze zoptymalizowana, serwer może stać się realnym ograniczeniem.

Obserwowana zmiana była realizowana laboratoryjnie. Pokazane dane dotyczyły przede wszystkim zmiany serwera. Często polecam taki manewr wtedy, gdy hosting jest autentycznie fatalny albo cele digital marketingu są ambitne, a konkurencja trudna. Nie zaczynałbym jednak od migracji, jeśli strona ma nieprzygotowane grafiki, śmietnik w CMS i pięć warstw skryptów.

Realna szybkość na mistrzowskim poziomie: 614 ms

To samo narzędzie testujące, skonfigurowane na rynek europejski, przy testach z Londynu pokazało, że strona ładuje się w 614 ms, a LCP wynosi 384 ms. I to jest wynik, przy którym można spokojnie powiedzieć: bardzo dobrze.

Oczywiście trzeba pamiętać, że wyniki testów zależą od lokalizacji, urządzenia, połączenia, cache, konfiguracji narzędzia i chwilowego obciążenia. Dlatego jeden wynik nie jest wyrocznią. Liczy się powtarzalność i realne doświadczenie użytkowników.

Jak testować szybkość strony

Szybkość strony warto testować kilkoma narzędziami i kilka razy. Jedno badanie potrafi być mylące. Serwer mógł mieć chwilowe obciążenie, cache mógł być rozgrzany albo zimny, a narzędzie mogło testować stronę z lokalizacji, która nie ma nic wspólnego z Twoim rynkiem.

Do podstawowych narzędzi należą:

• PageSpeed Insights — pokazuje dane dla mobile i desktop, łączy dane laboratoryjne z danymi użytkowników, jeśli są dostępne.
• Lighthouse — dobre do diagnostyki technicznej i lokalnych testów.
• GTmetrix — przydatny do porównań i analizy zasobów.
• WebPageTest — bardzo dobre narzędzie do głębszych testów, lokalizacji i analizy ładowania krok po kroku.
• Google Search Console — pokazuje problemy Core Web Vitals na podstawie danych z realnych użytkowników, jeśli jest ich wystarczająco dużo.

Warto testować mobile i desktop osobno. Warto testować z rynku docelowego. Strona firmy z Poznania nie musi być perfekcyjna w teście z drugiego końca świata, jeśli jej realni klienci są w Polsce. Ale jeśli działa słabo również z Europy, to już nie jest ciekawostka.

Nie fetyszyzuj wyniku 100/100. To miłe, ale nie zawsze biznesowo potrzebne. Jeśli pogoń za setką psuje funkcje strony, usuwa ważne elementy albo zabiera absurdalnie dużo czasu, trzeba wrócić do pytania: co realnie poprawia doświadczenie użytkownika?

Czego nie robić przy optymalizacji szybkości

Optymalizacja szybkości potrafi pójść w złą stronę, jeśli zaczyna się od narzędzi, a nie od diagnozy.

• Nie instaluj pięciu wtyczek do cache naraz. Mogą sobie przeszkadzać, dublować funkcje i generować błędy trudne do wykrycia.
• Nie ścigaj 100/100 kosztem działania strony. Wynik w narzędziu nie może być ważniejszy niż formularz, koszyk albo czytelność.
• Nie wrzucaj zdjęć 5000 px. Jeśli grafika wyświetla się na 900 px, przygotuj ją pod realny rozmiar.
• Nie ignoruj mobile. Strona szybka na komputerze właściciela może być ciężka na telefonie klienta.
• Nie optymalizuj produkcji bez backupu. Zmiany w cache, CSS, JS i serwerze potrafią wywrócić stronę.
• Nie usuwaj skryptów bez zrozumienia. Czasem jeden plik odpowiada za krytyczną funkcję.
• Nie zaczynaj od serwera, jeśli strona jest ciężka. Dobry hosting pomaga, ale nie jest alibi dla bałaganu.

Najlepsza optymalizacja jest spokojna: pomiar, zmiana, test, kontrola. Nie „kliknij wszystko, może będzie szybciej”.

Wnioski

1. Szybkość strony to proces, nie jednorazowa poprawka. Nowe skrypty, grafiki, wtyczki i aktualizacje mogą zepsuć wynik po kilku miesiącach. Stronę trzeba regularnie kontrolować.

2. Najpierw usuwa się oczywiste ciężary. Grafiki, cache, nadmiar wtyczek i JavaScript zwykle dają największy efekt. Dopiero później ma sens dłubanie w detalach.

3. Serwer ma znaczenie, ale nie jest alibi. Dobry hosting pomaga, szczególnie przy TTFB, ale nie naprawi strony zbudowanej z ciężkich grafik, bałaganu w CMS i niepotrzebnych skryptów.