Michele Eccher
W tym poradniku
Wolny landing page może kosztować konwersje, gdy odwiedzający muszą czekać, żeby przeczytać ofertę, wypełnić formularz albo zobaczyć potwierdzenie po jego wysłaniu. Żeby zdecydować, co poprawić, znajdź etap, na którym strona zwalnia, i odtwórz problem na urządzeniach, z których korzysta Twoja grupa odbiorców.
Szybsza strona oraz więcej zapytań lub sprzedaży to dwa osobne wyniki i każdy trzeba sprawdzić oddzielnie. Darmowe narzędzia pomagają zmierzyć opóźnienie i dają programiście konkretne dowody. Żeby ocenić wpływ na biznes, porównaj dodatkowo dane o konwersjach i uwzględnij zmiany w kampaniach lub ofercie.
Kiedy wolna strona kosztuje konwersję
Kto klika reklamę, oczekuje oferty, która go do tego skłoniła. Jeśli pierwszy ekran pozostaje pusty, część osób wyjdzie, zanim cokolwiek przeczyta. Jeśli przycisk wygląda na aktywny, ale nie reaguje, odwiedzający potrafią stuknąć w niego kilka razy. Gdy potwierdzenie się spóźnia, zdarza się, że wysyłają ten sam formularz ponownie: dwa zarejestrowane zdarzenia mogą wtedy oznaczać tylko jedno zapytanie.
Z samego czasu ładowania nie da się przewidzieć sprzedaży. Na słabszych telefonach strona może działać wolniej, a ich użytkownicy mogą mieć inne zamiary niż osoby na komputerach. Jeśli ta grupa konwertuje rzadziej, sprawdź, z jakich kampanii przyszła i czego szuka, zanim przypiszesz ten wynik szybkości. Szybka strona nadal może mieć słabą ofertę. Treść i użyteczność omawia poradnik o optymalizacji konwersji landing page.
Które metryki czytać i co mówią
| Metryka | Co mierzy | Dobry wynik w danych z pola |
|---|---|---|
| LCP, Largest Contentful Paint | Czas od początku ładowania do pojawienia się w widocznym obszarze największego obrazu lub bloku tekstu. Ten element nie musi być ofertą. | ≤ 2,5 sekundy |
| INP, Interaction to Next Paint | Jak szybko strona widocznie reaguje na interakcje w trakcie wizyty. | ≤ 200 milisekund |
| CLS, Cumulative Layout Shift | Nieoczekiwane przesuwanie się elementów strony. To nie jest pomiar czasu. | ≤ 0,1 |
Google ocenia te progi Core Web Vitals na 75. percentylu, czyli p75, osobno dla urządzeń mobilnych i komputerów. Dla każdej metryki co najmniej 75% obserwacji musi mieścić się w progu. Mediana z trzech lokalnych testów opisuje te trzy wczytania strony w warunkach testowych. Nie rozstrzyga, czy realni użytkownicy osiągają progi.
W PageSpeed Insights sekcja z danymi realnych użytkowników opiera się na Chrome User Experience Report (CrUX) i obejmuje ostatnie 28 dni. Sprawdź, czy raport dotyczy adresu URL, czy całego źródła (origin), czyli stron o tym samym protokole, domenie i porcie. Dane dla https://qreativa.com obejmują na przykład wiele stron, nie tylko ten poradnik. Gdy danych jest za mało, wpisz „brak danych”. Wynik Lighthouse nie wypełni tej luki. Zasięg i sposób agregacji danych wyjaśnia dokumentacja PageSpeed Insights.
Sekcja laboratoryjna uruchamia Lighthouse w symulowanych warunkach. Total Blocking Time (TBT) pomaga wykryć zadania, które zajmują główny wątek przeglądarki i uniemożliwiają jej reakcję podczas ładowania. Nie mierzy INP: formularz może zwolnić po uruchomieniu widżetu czatu albo podczas walidacji danych. Google wyjaśnia różnice między danymi laboratoryjnymi a danymi z pola i pokazuje, dlaczego interakcje i przesunięcia układu trzeba sprawdzać też w trakcie całej wizyty.
Jak zebrać porównywalne dowody
Do wstępnej diagnozy wykonaj trzy kolejne testy w profilu mobilnym i trzy w profilu desktopowym, przed zmianą i po niej. Daje to sześć raportów wyjściowych i sześć kontrolnych, łącznie 12. Powtórzone testy pokazują, jak bardzo wyniki różnią się w tych samych warunkach. Nie mówią, u ilu odwiedzających strona zadziała tak samo. Jeśli test się nie powiedzie, zapisz błąd i usuń problem, zanim go powtórzysz.
Zapisz stronę i warunki testu
Zanotuj końcowy adres URL po wszystkich przekierowaniach, datę i godzinę, wersję strony, urządzenie lub symulowany profil, przeglądarkę i wersję narzędzia. Zapisz ustawienia sieci i procesora, informację, czy wyczyszczono pamięć podręczną i inne dane witryny, wybraną opcję zgody oraz to, czy użytkownik był zalogowany. Zachowaj parametry kampanii potrzebne do odtworzenia ścieżki, ale nie umieszczaj w dzienniku danych osobowych.
Utrzymaj te same warunki w każdym teście
Do wstępnej diagnozy możesz użyć PageSpeed Insights. Żeby wykonać testy lokalnie, otwórz stronę w Chrome, a potem narzędzia deweloperskie klawiszem F12. W panelu Lighthouse wybierz tryb Navigation i profil Mobile, po czym uruchom analizę trzy razy. Powtórz to dla profilu Desktop. Użyj profilu przeglądarki bez rozszerzeń i zamknij programy zużywające dużo zasobów. Zachowaj wszystkie ustawienia bez zmian, także opcję czyszczenia danych witryny przed każdym uruchomieniem. Zapisz każdy raport z menu eksportu pod nazwą w rodzaju
before-mobile-1. Porównuj wyniki z tego samego narzędzia: PageSpeed Insights i testy lokalne mogą działać w różnych warunkach.Przejdź ścieżkę na telefonie
Otwórz link z kampanii, przeczytaj ofertę, otwórz formularz i wypełnij pola. Zostaw puste pole wymagane, żeby sprawdzić komunikat o błędzie, następnie wyślij formularz z ustalonymi danymi testowymi i sprawdź potwierdzenie. Powtórz ścieżkę raz z odrzuconą, a raz z udzieloną zgodą; to dwa osobne warunki testu. Upewnij się, że dociera tylko jedno zapytanie, a śledzenie respektuje wybór zgody. Zapisz opóźnienia i przesunięcia układu, dołączając zrzuty ekranu lub nagranie z panelu Performance w narzędziach deweloperskich.
Zachowaj medianę, rozstęp i dowód problemu
Dla każdego profilu posortuj trzy wartości wybranej metryki i weź środkową jako medianę. Zachowaj też minimum i maksimum. Wskaż obraz lub blok tekstu wyznaczający LCP albo wolno działającą interakcję i dołącz raport, który to pokazuje. Po publikacji powtórz serię testów i kontrole działania na nowej wersji produkcyjnej.
Żeby mierzyć wydajność u realnych użytkowników właśnie tej strony, programista może zbierać Web Vitals w ramach monitorowania realnych użytkowników (RUM) i zapisywać przy tym wersję strony, urządzenie i okres. Jeśli chcesz analizować konwersje razem z wydajnością, powiąż wydajność z wynikiem tej samej wizyty i uszanuj wybory dotyczące zgód. Zagregowane raporty CrUX nie mówią nic o biznesowym wyniku pojedynczej wizyty.
Od objawu do poprawki: co sprawdzić najpierw
W narzędziach deweloperskich nagraj wczytanie strony w panelu Performance i zaznacz zdarzenie LCP. W raportach Lighthouse przejrzyj element LCP i, jeśli jest dostępny, podział czasu. W panelu Network prześledź dokument HTML i główny zasób. Jeśli do dalszych badań zmienisz narzędzie lub warunki, przechowuj ten zapis osobno od porównywalnej serii testów.
| Zaobserwowany objaw | Co sprawdzić | Poprawka do wypróbowania |
|---|---|---|
| HTML dociera późno | Przekierowania i Time to First Byte (TTFB) żądania dokumentu. | Usuń zbędne przekierowania. Sprawdź buforowanie i czas odpowiedzi aplikacji z osobą odpowiedzialną za serwer. |
| Obraz LCP jest pobierany późno | Sprawdź, czy adres URL obrazu jest w pierwotnym HTML, czy dodaje go JavaScript, i czy leniwe ładowanie opóźnia żądanie. | Umieść obraz w pierwotnym HTML i ładuj go od razu. fetchpriority=high może nadać mu pierwszeństwo przed innymi obrazami. |
| Zasób LCP pobiera się długo | Rzeczywiście przesłane bajty, format pliku i wymiary obrazu pobranego na telefonie. | Skompresuj obraz i użyj srcset oraz sizes, żeby przeglądarka pobierała wersję dopasowaną do ekranu, a obraz pozostał czytelny. |
| Zasób jest gotowy, ale element nadal niewidoczny | CSS blokujący renderowanie, czcionki i aktywność JavaScript w zapisie przed pojawieniem się elementu. | Usuń zależność, na którą element czeka, albo ogranicz pracę potrzebną do wyświetlenia treści. |
| Stuknięcia lub pola formularza reagują wolno | Nagraj wolną interakcję po załadowaniu strony, także walidację. | Ogranicz pracę, którą JavaScript wykonuje po stuknięciu lub wpisaniu danych. Sprawdź widżety i skrypty uruchamiane w tym momencie. |
| Formularz lub przycisk się przesuwa | Wskaż element, który zmienia położenie podczas ładowania lub korzystania ze strony. | Zarezerwuj miejsce na obrazy, osadzone elementy i komunikaty. Sprawdź banery i ładowanie czcionek. |
Jeśli formularz nie dostarcza zapytania albo wysyła je dwa razy, napraw najpierw ten błąd. Przy innych opóźnieniach oceń, ilu wizyt dotyczą i jak bardzo utrudniają zamierzone działanie. Oferta, która dla każdego użytkownika mobilnego pojawia się późno, zwykle ma pierwszeństwo przed wolnym widżetem, który otwiera niewiele osób. Do każdej poprawki zapisz, kto ją wykona, ile mniej więcej kosztuje i jakim testem sprawdzisz, czy rozwiązała problem.
Dla LCP przewodnik optymalizacji Google dzieli czas na oczekiwanie na HTML, opóźnienie ładowania zasobu, czas pobierania i opóźnienie renderowania. Przy interakcjach skorzystaj ze wskazówek dotyczących diagnozowania INP. Usuń zduplikowane lub nieużywane tagi, ale po każdej zmianie sprawdź zachowanie zgód i wymagane zdarzenia. Po usunięciu analityki mogą zniknąć same dane, a opóźnienie odczuwane przez klientów pozostanie.
Przykład: skrócenie LCP z 4,0 do 2,4 sekundy
Załóżmy, że mobilny landing page ładuje główny obraz przez JavaScript. Zapis pokazuje, że żądanie rusza późno, a plik jest większy, niż trzeba. Programista umieszcza obraz w pierwotnym HTML, usuwa leniwe ładowanie i wysyła mniejszy plik. Teksty, oferta i formularz pozostają bez zmian.
| Etap | Przed | Po |
|---|---|---|
| TTFB | 0,6 s | 0,6 s |
| Opóźnienie przed żądaniem | 1,4 s | 0,2 s |
| Czas pobierania | 0,7 s | 0,5 s |
| Oczekiwanie, aż obraz się pojawi | 1,3 s | 1,1 s |
| Suma w zapisie | 4,0 s | 2,4 s |
Przyjmijmy, że trzy testy mobilne dają przed zmianą wartości LCP 3,9 / 4,0 / 4,2 sekundy, a po niej 2,3 / 2,4 / 2,6 sekundy. Mediana spada z 4,0 do 2,4 sekundy, czyli o 1,6 sekundy, co stanowi 40% wartości wyjściowej (1,6 / 4,0 × 100). Mediana TBT pozostaje na poziomie 180 ms, a mediana CLS na poziomie 0,02. W testach laboratoryjnych element LCP pojawia się teraz wcześniej. Interakcje i Core Web Vitals realnych użytkowników nadal wymagają kontroli opisanych wyżej.
Jeśli strona produkcyjna potwierdzi te czasy, a formularz nadal działa, zmianę można zachować. W pokazanym wczytaniu między końcem pobierania a pojawieniem się obrazu mija jednak nadal 1,1 sekundy. W następnym kroku trzeba ustalić, co go wstrzymuje. Jeśli obraz czeka na JavaScript, jeszcze mniejszy plik może nie sprawić, że pojawi się szybciej.
Jak ocenić wpływ na konwersje
Zanim zaczniesz, ustal, co liczy się jako konwersja. Na stronie do generowania leadów możesz liczyć użytkowników, którzy wysłali co najmniej jedno zapytanie, które zostało poprawnie odebrane. Dwa zgłoszenia tej samej osoby to jedna konwersja. Podziel tych użytkowników przez wszystkich użytkowników uwzględnionych w porównaniu i pomnóż przez 100, żeby otrzymać współczynnik. Jeśli oceniasz tylko ruch mobilny, obie liczby muszą dotyczyć tej grupy i tego samego okresu. Samo kliknięcie przycisku nie potwierdza, że zapytanie dotarło.
Sprawdź też, ilu z tych użytkowników staje się wartościowymi leadami według kryteriów Twojego działu sprzedaży albo kończy zakup. Daj każdemu zapytaniu tyle samo czasu na ocenę. W przeciwnym razie nowsze zapytania mogą wyglądać na gorsze tylko dlatego, że nikt jeszcze ich nie zweryfikował.
Jeśli możesz w tym samym okresie pokazywać dwie równoważne wersje, przydzielaj użytkowników losowo do A lub B i przy powrocie zostawiaj ich na tej samej wersji. Zmień tylko ten zestaw poprawek technicznych, który chcesz ocenić. Upewnij się, że buforowanie, serwer ani kod eksperymentu nie dają obu grupom tej samej optymalizacji i nie wprowadzają innego opóźnienia. Przed startem określ wielkość próby, czas trwania, metrykę główną i regułę decyzyjną. Poradnik o optymalizacji konwersji tłumaczy, jak zaprojektować test A/B.
Jeśli ruch jest za mały na test A/B albo zmiana dotyczy serwera wspólnego dla obu wersji, możesz ją wdrożyć i obserwować, co się dzieje. Zapisuj zmiany w budżecie, grupie odbiorców, kreacji reklamowej, ofercie i śledzeniu, bo mogą wyjaśniać zmianę konwersji. Stopniowe wdrażanie bez losowego przydziału nie usuwa tego problemu. Przewodnik web.dev o powiązaniu szybkości strony z metrykami biznesowymi omawia łączenie metryk i stosowanie eksperymentów.
Przyjmijmy, że obserwujesz ten sam landing page przez 14 dni przed poprawką i 14 dni po niej. Każdy okres obejmuje 5000 użytkowników mobilnych. Licz każdego użytkownika raz i oceniaj zapytania w ciągu siedmiu dni od ich otrzymania.
| Miara, ten sam segment mobilny | Przed: 14 dni | Po: 14 dni |
|---|---|---|
| Uwzględnieni użytkownicy | 5000 | 5000 |
| Użytkownicy z co najmniej jednym prawidłowym zapytaniem | 200 | 230 |
| Współczynnik zapytań | 4,0% | 4,6% |
| Użytkownicy, których zapytanie dział sprzedaży przyjął w ciągu siedmiu dni | 120 | 140 |
| Użytkownicy z zapytaniem przyjętym przez sprzedaż / wszyscy uwzględnieni użytkownicy | 2,4% | 2,8% |
Współczynnik zapytań rośnie z 200 / 5000 × 100 = 4,0% do 230 / 5000 × 100 = 4,6%. To wzrost o 0,6 punktu procentowego, czyli o 15% względem wartości wyjściowej: (4,6 − 4,0) / 4,0 × 100. Rośnie też liczba użytkowników z przyjętym zapytaniem, ze 120 do 140. Przy 5000 użytkowników w każdym okresie ten współczynnik zwiększa się z 2,4% do 2,8%. Odczytaj wyniki siedem dni po zakończeniu każdego okresu, żeby nawet ostatnie zapytania miały pełne okno oceny.
Załóżmy teraz, że na początku drugiego okresu zmieniła się także kreacja reklamowa. Dodatkowych 30 użytkowników, którzy wysłali zapytanie, może być zasługą szybszej strony, nowej reklamy albo obu. Sprawdzoną poprawkę techniczną możesz zachować, ale nie ma podstaw, żeby na tym wzroście o 15% opierać prognozę sprzedaży. Test między grupami w tym samym okresie, o ile da się go przeprowadzić, nadal jest lepszym sposobem oszacowania wpływu szybkości. Więcej danych sprzed zmiany i po niej pomaga w monitorowaniu, ale samo nie oddzieli skutków innych zmian.
Jeśli ludzie wychodzą, zanim uruchomi się tag, pomiar może pomijać najwolniejsze wizyty. Podaj, skąd pochodzą Twoje liczby: z żądań strony odebranych przez serwer, z wizyt zarejestrowanych przez analitykę czy od użytkowników, którzy wyrazili zgodę. Nie dziel konwersji jednej grupy przez wizyty innej. Poradnik o mierzeniu skuteczności landing page szerzej opisuje zdarzenia i jakość danych.
Dziennik przed zmianą i po niej oraz decyzja o wdrożeniu
Skopiuj ten szablon dla każdej strony i każdej zmiany. Zachowaj oryginalne raporty i nagrania problemu. Na końcu zapisz, czy poprawka skróciła opóźnienie, i osobno, co pokazują dane o konwersjach.
Końcowy adres URL i wersje strony przed/po: Data i godzina, profil mobilny/desktopowy, przeglądarka i wersja narzędzia: Ustawienia sieci i procesora, czyszczenie danych witryny, zgoda i stan zalogowania: Zaobserwowany problem, element lub interakcja, dołączony raport lub nagranie: Podejrzewana przyczyna, planowana zmiana i osoba odpowiedzialna: Mobile przed: testy 1 / 2 / 3; mediana, minimum i maksimum dla każdej metryki Mobile po: testy 1 / 2 / 3; mediana, minimum i maksimum dla każdej metryki Desktop przed: testy 1 / 2 / 3; mediana, minimum i maksimum dla każdej metryki Desktop po: testy 1 / 2 / 3; mediana, minimum i maksimum dla każdej metryki Każdy test: LCP w sekundach, TBT w milisekundach i CLS; dołącz raport Dane z pola: źródło, URL lub origin, okres, urządzenie i 75. percentyl; jeśli ich brakuje, wpisz „brak danych” Test na telefonie: oferta, formularz, błędy, wysłanie, potwierdzenie i zgoda Konwersje: okres, uwzględniona grupa odbiorców, źródło danych i zasady liczenia; wszyscy użytkownicy i użytkownicy z co najmniej jednym prawidłowym zapytaniem Jakość leadów: użytkownicy z przyjętym zapytaniem lub zakupem i czas przeznaczony na ocenę Inne zmiany w kampanii lub na stronie, błędy i brakujące dane: Wynik techniczny: zachować, poprawić lub wycofać zmianę, z uzasadnieniem Wynik biznesowy: jakie wnioski można wyciągnąć i kiedy sprawdzić ponownie:
Jeśli po zmianie formularz przestaje działać, napraw go albo przywróć poprzednią wersję. Jeśli wszystko działa, a opóźnienie maleje w tych samych warunkach testu, możesz zachować poprawkę i dalej obserwować realne wizyty. Jeśli czasy mieszczą się w zakresie zapisanym przed zmianą, test nie wykazuje wyraźnego skrócenia. Zanim powtórzysz testy, obejrzyj nagranie problemu.
Najczęstsze pytania o szybkość landing page
Czy potrzebuję 100 punktów w PageSpeed Insights?
O tym, co poprawić, decyduj na podstawie poszczególnych pomiarów i wskazówek diagnostycznych. Wynik w kategorii Wydajność to ważone podsumowanie metryk laboratoryjnych i może się różnić między kolejnymi testami. 100 punktów nie mierzy konwersji i nie dowodzi, że strona działa dobrze u każdego odwiedzającego. Zachowaj wszystkie raporty, także te mniej korzystne.
Czy kreator stron zawsze spowalnia landing page?
Landing page zbudowany w kreatorze może działać szybko albo wolno, zależnie od szablonu, obrazów, widżetów i skryptów. Zanim zdecydujesz się na przebudowę, ustal przyczynę opóźnienia i sprawdź, czy da się ją usunąć na obecnej platformie. O migracji warto myśleć wtedy, gdy kreator uniemożliwia potrzebne prace, a spodziewana korzyść uzasadnia koszt i ryzyko.
Dlaczego liczba kliknięć w reklamę jest wyższa niż liczba zarejestrowanych wizyt?
Sprawdź docelowy adres URL, przekierowania, błędy sieci, ustawienia zgód i moment uruchomienia tagu. Kliknięcia i sesje są poza tym liczone według różnych zasad. Różnica może wskazywać problem wart zbadania, ale nie mówi, ilu odwiedzających zrezygnowało z powodu wolnej strony. Przejdź ścieżkę od reklamy na telefonie i sprawdź, kiedy zaczyna się żądanie strony, a kiedy wizyta zostaje zarejestrowana.
Czy Qreativa może poprawić istniejący landing page?
Tak. Qreativa może przeanalizować wydajność u realnych użytkowników i w testach laboratoryjnych, znaleźć wąskie gardła oraz usprawnić obrazy, kod i sposób ładowania narzędzi. Prace obejmują sprawdzenie formularzy, śledzenia i działania na różnych ekranach, a następnie zestawienie zmian z danymi o konwersjach. Można je zrealizować w elastycznym abonamencie miesięcznym Qreativa.
