[Poradnik] Szybkość landera / strony WWW to kwestia pieniędzy i twoich zarobków, a nie techniki


Zanim przejdziemy do konfiguracji, jedno wyjaśnienie, bo bez niego cały poradnik będzie tylko listą czynności bez sensu.
Lander to strona, na którą trafia użytkownik po kliknięciu w Twoją reklamę, zanim zobaczy właściwą ofertę. Większość ruchu w afiliacji to telefony, często tańsze modele, na słabszym internecie. Taki
użytkownik nie czeka. Jeśli strona ładuje się długo, część osób wychodzi, zanim zobaczy cokolwiek.

A Ty i tak zapłaciłeś za ten klik. Wolny lander to realnie wyrzucanie części budżetu reklamowego w
błoto, zanim lejek sprzedażowy w ogóle zacznie działać.
Słowniczek na start, żebyś nie gubił się w terminach używanych dalej:

TTFB (time to first byte) — czas, w jakim Twój serwer w ogóle zaczyna odpowiadać. To pierwszy
etap ładowania strony.
LCP (largest contentful paint) — moment, w którym główna treść strony (np. duże zdjęcie czy
nagłówek) jest już w pełni widoczna.
waterfall — wykres w narzędziach do testowania, który pokazuje, co się ładuje, w jakiej kolejności i jak długo to trwa. To Twoje główne narzędzie diagnostyczne w tym poradniku.

Kampania, na której opieram ten poradnik: ruch typu push, kraj z niższą siłą nabywczą(niższy tier), głównie telefony z Androidem, oferta sweepstakes z pre-landerem. Pre-lander ładował się około 4,1 sekundy na symulowanym łączu 4G. Odsetek osób klikających dalej z pre-landera do oferty (CTR) wynosił 38%. Po wszystkich zmianach opisanych niżej ta sama strona ładowała się w około 1,4 sekundy, a CTR wzrósł do 51%. Ta sama treść, ta sama oferta. Zmieniła się tylko szybkość wyświetlenia się strony.
To oznacza jedną trzecią więcej opłaconych kliknięć docierających do oferty, bez wydawania złotówki więcej na reklamę.


Pierwszy krok: zmierz zanim cokolwiek zaczniesz usprawniać
Największy błąd to poprawianie na wyczucie. Bez pomiaru początkowego nie udowodnisz sobie ani nikomu, że coś się poprawiło, i nie będziesz wiedział, co faktycznie pomogło.
Dwa darmowe narzędzia, użyj obu:

PageSpeed Insights (pagespeed.web.dev) — pokazuje m.in. Core Web Vitals, czyli konkretne metryki czasu ładowania. Zignoruj ogólny wynik punktowy od 0 do 100, to tylko uproszczenie. Patrz na konkretne liczby wyszczególnione przez powyższe narzedzie.
GTmetrix, darmowy plan — pokazuje waterfall, czyli realny obraz tego, co spowalnia stronę.

Ustaw lokalizację testu jak najbliżej kraju, z którego masz ruch, i wybierz test na spowolnionym łączu mobilnym. Test na szybkim światłowodzie w biurze nic Ci nie powie o realnych użytkownikach.


Trzy liczby, na które patrzysz:


Zapisz swój punkt startowy. Mój wyglądał tak: TTFB 0,9s, LCP 3,4s, całość 4,1s.

Krok 1: Waterfall - pełna analiza bez znajomości kodu

Otwórz wykres waterfall w GTmetrix. Każdy wiersz to jeden plik, który ładuje Twoja strona zdjęcie, skrypt, czcionka. Długość paska pokazuje, ile czasu to zajęło. Szukasz trzech rzeczy, nic więcej na start nie musisz rozumieć:

1. Które paski są najdłuższe. W dziewięciu na dziesięć przypadków to jest zdjęcie, zwykle za duże i nieskompresowane.
2. Co ładuje się przed Twoją główną treścią. Wszystko, co na wykresie stoi przed obrazkiem czy nagłówkiem, opóźnia moment, w którym użytkownik cokolwiek zobaczy.
3. Ile jest w ogóle plików (requestów). Prosty lander powinien mieć ich niewiele. Jeśli widzisz 60 i więcej na jednej stronie, połowa to śmieci odziedziczone po szablonie, z którego korzystasz.

Moja diagnoza, od największego problemu:

• jedno zdjęcie w tle, 1,9MB, nieskompresowany PNG — zdecydowanie największy problem
• cała biblioteka jQuery (90KB) wczytywana tylko po to, żeby animować jeden przycisk
• trzy różne rodziny czcionek z Google Fonts, z czego strona realnie używała jednej
• skrypt trackera ładujący się w sposób blokujący renderowanie strony, wpisany w sekcji head
• brak kompresji i brak nagłówków cache po stronie serwera w ogóle
  
  

Brzmi znajomo? Tak wygląda właściwie każdy pobrany za darmo szablon landera. Teraz naprawiamy to po kolei, od największego problemu.

Krok 2: zdjęcia (to zwykle 60% całej poprawy)
Zdjęcia niemal zawsze ważą najwięcej na landerze i są najłatwiejsze do naprawienia.
Skompresuj i zmień format. Każde zdjęcie przepuść przez Squoosh (squoosh.app, darmowe, działa w przeglądarce, nic nie trzeba instalować). Zmień format na WebP, jakość w okolicach 75–
80. Moje zdjęcie w tle, 1,9MB jako PNG, po konwersji do WebP ważyło 142KB, bez widocznej różnicy na ekranie telefonu. Ta jedna zmiana zabrała ze strony 1,75MB.

Dopasuj rozmiar do rzeczywistej wielkości wyświetlania. Szablon miał zdjęcie w tle szerokie na 2400 pikseli. Na telefonie wyświetla się maksymalnie na 800 pikseli szerokości. Wysyłanie trzykrotnie większego obrazka niż potrzeba to czysta strata. Najpierw zmniejsz wymiary, dopiero potem kompresuj.
Podaj dokładne wymiary w kodzie. Zawsze dodawaj do znacznika obrazka atrybuty width i height. Bez nich strona “skacze” w trakcie ładowania zdjęć, co wygląda niechlujnie i psuje jedną z
metryk (CLS).

Ładuj z opóźnieniem wszystko poniżej pierwszego ekranu (lazy loading). Jeden dopisany atrybut, duży efekt:

Zdjęcie w tle, to pierwsze, które widać, NIE powinno mieć lazy loadingu gdyż ma się załadować jako pierwsze. Wszystko poniżej, co użytkownik widzi dopiero po przescrollowaniu.

Krok 3: usuń wszystko, co blokuje wyświetlanie
strony
Wszystko, co znajduje się w sekcji head strony i jest skryptem lub dużym arkuszem stylów ładowanym w sposób blokujący, zatrzymuje przeglądarkę, zanim cokolwiek pokaże użytkownikowi. Na landerze prawie nic nie zasługuje na taki priorytet.

Usuń jQuery całkowicie. Szablon używał 90KB biblioteki jQuery do jednej animacji przewijania i efektu na przycisku. Obie rzeczy da się zrobić w dziesięciu linijkach zwykłego JavaScriptu. Jeśli Twój lander wczytuje jQuery, to sygnał, że pochodzi z szablonu — usuń bibliotekę i przepisz te jedną czy dwie rzeczy, które robiła.

Wklej styl bezpośrednio do strony (inline CSS). Cały arkusz stylów landera zwykle jest niewielki. Zamiast zewnętrznego pliku CSS (czyli dodatkowego zapytania do serwera, które blokuje
wyświetlanie), wklej całą treść do znacznika <style> bezpośrednio w sekcji head. Jedno zapytanie mniej, strona może się wyświetlić od razu.

Czcionki: użyj systemowego zestawu. Trzy rodziny czcionek z Google Fonts to trzy dodatkowe zapytania plus efekt niewidocznego tekstu na chwilę, na wolniejszym łączu. Na landerze nikt nie podziwia typografii. Poniższy zapis nie kosztuje ani jednego dodatkowego zapytania i wygląda naturalnie na każdym urządzeniu:



Jeśli konkretna czcionka jest naprawdę częścią kreacji reklamowej i musi zostać, zostaw dokładnie jedną, wgraj ją na własny serwer w formacie woff2 i dodaj jej priorytetowe ładowanie (preload).
Odłóż ładowanie skryptu trackera na później (defer). Tracking musi działać, ale nie może blokować wyświetlania strony. Przenieś skrypt trackera tak, by ładował się z atrybutem defer lub
async (sprawdź dokumentację swojego trackera, większość to wspiera):


Wynik końcowy poprawy szybkości


Powodzenia!