Zobacz, jak Twoja witryna ładuje się oczami odwiedzających
Dowiedz się, czego faktycznie doświadczają użytkownicy odwiedzający Twoją witrynę.
Zauważasz, że coś ładuje się powoli lub nie jest na swoim miejscu? Pomoże Ci to zidentyfikować ważne opóźnienia i problemy z konwersją, których doświadczają Twoi użytkownicy.
Zrzut ekranu przedstawiający wynik testu wydajności sieci DebugBear, październik 2022 r. Pasek filmowy osi czasu pokazuje postęp renderowania witryny w czasie.
Na przykład ta strona zaczyna się renderować po 0,7 sekundy, a główny obraz renderuje się po 1,3 sekundy.
Strona jest w pełni renderowana, znana również jako Wizualnie zakończona, gdy widżet czatu wyświetla się po 3,7 sekundy.
Zrzut ekranu DebugBear pokazujący postęp renderowania witryny w czasie, październik 2022 r. W ramach narzędzia możesz również obejrzeć nagranie wideo z procesu renderowania.
To świetny sposób na zademonstrowanie wpływu problemów z wydajnością klientom lub innym członkom zespołu.
Zrzut ekranu przedstawiający nagranie wideo częściowo renderowanej strony internetowej w DebugBear, październik 2022 r. Przetestuj zmiany szybkości witryny, widząc prawdziwe statystyki ładowania
Załóżmy, że optymalizujesz swoją witrynę i chcesz dowiedzieć się, czy te zmiany będą miały wpływ.
To narzędzie przeprowadza „test laboratoryjny” w optymalnym środowisku, aby sprawdzić, czy prawidłowo optymalizujesz witrynę.
Gdy przetestujesz swoją witrynę, otrzymasz oficjalny „Wynik laboratoryjny”, który jest podsumowaniem sześciu wskaźników wydajności, które pochodzą z Wyniku wydajności z narzędzia Google Lighthouse:
- First Contentful Paint (10% ogólnego wyniku).
- Indeks prędkości (10%).
- Największa zawartość farby (25%).
- Czas na interaktywne (10%).
- Całkowity czas blokowania (30%).
- Łączna zmiana układu (15%).
Korzystając z tych danych, dowiesz się, jak pomocna była ostatnia runda optymalizacji i co możesz zmienić.
Do tej pory prawdopodobnie zastanawiasz się, co musisz zmienić. Dowiedzmy się, jak zoptymalizować witrynę, korzystając z każdego kluczowego wskaźnika w Przeglądzie danych.
Jak zoptymalizować szybkość witryny?
Przeprowadzenie testu prędkości to pierwsza część Twojej optymalizacji witryny.
Gdy już będziesz mieć swoje dane, musisz wiedzieć, jak je interpretować i co zrobić, aby je naprawić.
W obszarze Przegląd danych raportu szybkości witryny zobaczysz kluczowe dane, na których się skupimy, aby przyspieszyć działanie witryny:
- First Contentful Paint : Można to przyspieszyć, poprawiając szybkość komunikacji z serwerem.
- Największe malowanie treści : można to przyspieszyć, optymalizując media i zasoby.
Ponadto możesz użyć kaskady żądań, aby zobaczyć, jak długo trwają żądania i jaki ma to wpływ na te dane.
Jak przyspieszyć pierwsze malowanie treści (FCP)
Zacznijmy od tego, aby Twoja witryna pojawiła się wcześniej dla odwiedzających; najpierw zajmiemy się First Contentful Paint.
Co to jest pierwsza zawartość treściowa?
First Contentful Paint mierzy, jak szybko zawartość strony zaczyna się pojawiać po przejściu użytkownika na tę stronę.
Ważne jest, aby kluczowe treści pojawiały się szybko, aby uniemożliwić odwiedzającym opuszczenie witryny. Im szybciej użytkownik opuszcza Twoją witrynę, tym szybciej Google dowiaduje się, że strona może być zła.
Ale skąd dokładnie wiesz, co powoduje powolne ładowanie witryny?
Jak odkryć, które problemy z serwerem spowalniają Twoją witrynę? Dowiedzmy Się.
Dlaczego moje pierwsze malowanie treści trwa tak długo?
Na Twój FCP może mieć wpływ szybkość połączenia z serwerem, żądania serwera, zasoby blokujące renderowanie i inne.
Wydaje się, że to dużo, ale istnieje prosty sposób, aby zobaczyć, co dokładnie spowalnia Twój FCP – wodospad żądań.
To przydatne narzędzie pokazuje, jakie żądania są wysyłane przez Twoją witrynę oraz kiedy każde żądanie zaczyna się i kończy.
Na przykład na tym zrzucie ekranu najpierw widzimy żądanie dokumentu HTML, a następnie dwa żądania załadowania arkuszy stylów, do których odwołuje się dokument.
Zrzut ekranu przedstawiający dane debugowania dla metryki First Contentful Paint w DebugBear, październik 2022 r. Dlaczego pierwsze wyrenderowanie treści następuje po 0,6 sekundy? Aby to zrozumieć, możemy podzielić się tym, co dzieje się na stronie.
Zrozumienie, co się dzieje przed pierwszą treścią malowania
Zanim pierwsze fragmenty treści załadują się na Twojej stronie internetowej, przeglądarka użytkownika musi najpierw połączyć się z Twoim serwerem i pobrać treść.
Jeśli ten proces zajmuje dużo czasu, wyświetlenie Twojej witryny przez użytkownika zajmuje dużo czasu.
Twoim celem jest dowiedzieć się, co się dzieje, zanim Twoja witryna zacznie się ładować, aby móc zidentyfikować problemy i przyspieszyć działanie.
Wczytywanie strony, część 1: przeglądarka tworzy połączenie z serwerem
Przed pierwszym żądaniem witryny internetowej z serwera przeglądarka użytkownika musi nawiązać połączenie sieciowe z tym serwerem.
Zwykle zajmuje to trzy kroki:
- Sprawdzanie rekordów DNS w celu wyszukania adresu IP serwera na podstawie nazwy domeny.
- Ustanowienie niezawodnego połączenia z serwerem (znanego jako połączenie TCP).
- Ustanowienie bezpiecznego połączenia z serwerem (znanego jako połączenie SSL).
Te trzy kroki są wykonywane przez przeglądarkę, jeden po drugim. Każdy krok wymaga przejścia w obie strony z przeglądarki odwiedzającego na serwer Twojej witryny.
W takim przypadku nawiązanie połączenia z serwerem zajmuje około 251 milisekund.
Zrzut ekranu DebugBear przedstawiający objazdy sieci używane do nawiązania połączenia z serwerem, październik 2022 r. Wczytywanie strony, część 2: przeglądarka żąda dokumentu HTML (tutaj nadchodzi czas na pierwszy bajt)
Po nawiązaniu połączenia z serwerem przeglądarka odwiedzającego może zażądać kodu HTML zawierającego zawartość Twojej witryny. Nazywa się to żądaniem HTTP.
W takim przypadku żądanie HTTP zajmuje 102 milisekundy. Ten czas trwania obejmuje zarówno czas spędzony w sieci w obie strony, jak i czas oczekiwania na wygenerowanie odpowiedzi przez serwer.
Po 251 milisekundach na utworzenie połączenia i 102 milisekundach na wysłanie żądania HTTP, przeglądarka odwiedzającego może wreszcie rozpocząć pobieranie odpowiedzi HTML.
Ten kamień milowy nazywa się Time to First Byte (TTFB). W tym przypadku dzieje się to po łącznie 353 milisekundach.
Gdy odpowiedź serwera jest już gotowa, przeglądarka użytkownika spędza dodatkowy czas na pobraniu kodu HTML. W tym przypadku odpowiedź jest dość mała, a pobieranie zajmuje tylko dodatkowe 10 milisekund.
Zrzut ekranu DebugBear przedstawiający różne składniki żądania HTTP, październik 2022 r. Wczytywanie strony, część 3: Twoja witryna ładuje dodatkowe zasoby blokujące renderowanie
Przeglądarki nie renderują ani nie wyświetlają stron natychmiast po załadowaniu dokumentu. Zamiast tego zwykle dostępne są dodatkowe zasoby blokujące renderowanie.
Większość stron wyglądałaby źle bez stylizacji wizualnej, więc arkusze stylów CSS są ładowane przed rozpoczęciem renderowania strony.
Ładowanie 2 dodatkowych arkuszy stylów w tym przykładzie testu szybkości witryny zajmuje 137 milisekund.
Pamiętaj, że te żądania nie wymagają nowego połączenia z serwerem. Pliki CSS są ładowane z tej samej domeny co poprzednio i mogą ponownie wykorzystać istniejące połączenie.
Zrzut ekranu DebugBear przedstawiający dodatkowe zasoby blokujące renderowanie ładowane po załadowaniu dokumentu HTML, październik 2022 r. Wczytywanie strony, część 4: Przeglądarka renderuje stronę
Wreszcie, po załadowaniu wszystkich niezbędnych zasobów, przeglądarka odwiedzającego może rozpocząć renderowanie strony. Jednak wykonanie tej pracy zajmuje również pewien czas przetwarzania – w tym przypadku 66 milisekund. Wskazuje na to pomarańczowy znacznik zadania CPU w widoku wodospadu.
Zrzut ekranu DebugBear przedstawiający kroki prowadzące od załadowania dokumentu HTML do renderowania strony internetowej, październik 2022 r. Teraz rozumiemy, dlaczego FCP następuje po 632 milisekundach:
- 364 milisekundy na żądanie dokumentu HTML.
- 137 milisekund na załadowanie arkuszy stylów.
- 66 milisekund na renderowanie strony.
- 65 milisekund dla innych prac związanych z przetwarzaniem.
Inne prace związane z przetwarzaniem obejmują drobne zadania, takie jak uruchamianie skryptów wbudowanych lub analizowanie kodu HTML i CSS po jego pobraniu. Możesz zobaczyć tę aktywność jako małe szare linie tuż pod taśmą renderującą.
Jak zoptymalizować pierwszy Contentful Paint (FCP)
Teraz, gdy rozumiesz, co prowadzi do renderowania Twojej witryny, możesz pomyśleć o tym, jak ją zoptymalizować.
- Czy serwer może szybciej odpowiedzieć na żądanie HTML?
- Czy zasoby można ładować przez to samo połączenie zamiast tworzyć nowe?
- Czy istnieją żądania, które można usunąć lub zmienić, aby nie blokowały już renderowania?
Teraz, gdy początkowe elementy Twojej witryny ładują się wcześniej, nadszedł czas, aby skupić się na szybszym wczytywaniu całej witryny.
Jak przyspieszyć największe malowanie treści (LCP) dzięki rekomendacjom DebugBear?
Istnieje wiele sposobów na przyspieszenie LCP.
Aby to ułatwić, DebugBear daje nam świetne kolejne kroki w sekcji Rekomendacje.
Rzućmy okiem na kilka przykładów zaleceń i dowiedzmy się, jak przyspieszyć LCP tej witryny.
Zalecenie 1: Zainicjuj żądania obrazu LCP z dokumentu HTML
Jeśli największym elementem treści na Twojej stronie jest obraz, najlepszą praktyką jest upewnienie się, że adres URL jest bezpośrednio zawarty w początkowym dokumencie HTML. Pomoże to jak najszybciej rozpocząć ładowanie.
Jednak ta najlepsza praktyka nie zawsze jest stosowana i czasami przeglądarka odkrywa, że musi pobrać główny obraz, zajmuje dużo czasu.
W poniższym przykładzie największa treść, czyli obraz, jest dodawana do strony za pomocą JavaScript. W rezultacie przeglądarka musi pobrać i uruchomić 200-kilobajtowy skrypt, zanim wykryje obraz i zacznie go pobierać.
Zrzut ekranu DebugBear przedstawiający sekwencyjny łańcuch żądań prowadzący do żądania obrazu, październik 2022 r. Jak naprawić: W zależności od witryny istnieją dwa możliwe rozwiązania.
Rozwiązanie 1: Jeśli używasz JavaScript do leniwego ładowania dużego obrazu, zoptymalizuj rozmiar obrazu i usuń skrypt leniwego ładowania lub zastąp go atrybutem modern loading=”lazy”, który nie wymaga JavaScript.
Rozwiązanie 2: W innych przypadkach renderowanie po stronie serwera uniemożliwiłoby pobranie aplikacji JavaScript przed renderowaniem strony. Jednak czasami może to być trudne do wdrożenia.
Zalecenie 2: Upewnij się, że obrazy LCP są ładowane z wysokim priorytetem
Po załadowaniu kodu HTML strony przeglądarki odwiedzających mogą odkryć, że oprócz głównego obrazu może być konieczne załadowanie dużej liczby dodatkowych zasobów, takich jak arkusze stylów.
Celem jest upewnienie się, że większe, główne zdjęcie zostanie załadowane, aby spełnić wymagania Google dotyczące największej zawartości treści.
Inne zasoby, takie jak skrypty analityczne innych firm, nie są tak ważne jak główny obraz.
Ponadto większość obrazów, do których odwołuje się kod HTML Twojej witryny, będzie znajdować się w części strony widocznej na ekranie po wyrenderowaniu strony. Niektóre mogą być całkowicie ukryte w zagnieżdżonej nawigacji nagłówka.
Z tego powodu przeglądarki początkowo ustawiają priorytet wszystkich żądań obrazów na Niski. Po wyrenderowaniu strony przeglądarka dowiaduje się, które obrazy są ważne i zmienia priorytet. Przykład tego można zobaczyć na poniższym zrzucie ekranu, na co wskazuje gwiazdka w kolumnie priorytetu.
Zrzut ekranu DebugBear przedstawiający ładowanie obrazu LCP z niskim priorytetem początkowym, październik 2022 r. Wodospad pokazuje, że chociaż przeglądarka wcześnie wiedziała o obrazie, nie zaczęła go pobierać, co wskazuje szary pasek.
Jak naprawić: Aby rozwiązać ten problem, możesz użyć nowej funkcji przeglądarki o nazwie wskazówki dotyczące priorytetów. Jeśli dodasz atrybut fetchpriority=”high” do elementu img, przeglądarka zacznie ładować obraz od samego początku.
Zalecenie 3: Nie ukrywaj treści strony za pomocą CSS
Czasami możesz spojrzeć na wodospad żądań i wszystkie zasoby blokujące renderowanie zostały załadowane, ale nadal nie wyświetla się żadna zawartość strony. Co się dzieje?
Narzędzia do testowania A/B często ukrywają treść strony do czasu zastosowania odmian testowych do elementów treści na stronie. W takich przypadkach przeglądarka wyrenderowała stronę, ale cała zawartość jest przezroczysta.
Co możesz zrobić, jeśli nie możesz usunąć narzędzia do testowania A/B?
Jak naprawić: Sprawdź, czy możesz skonfigurować narzędzie tak, aby ukrywało tylko zawartość, na którą mają wpływ testy A/B. Możesz też sprawdzić, czy istnieje sposób na szybsze ładowanie narzędzia do testowania A/B.
Zrzut ekranu DebugBear przedstawiający renderowany przezroczy, w którym zawartość jest ukryta przez narzędzie do testowania A/B, październik 2022 r. Monitoruj prędkość swojej witryny za pomocą DebugBear
Chcesz stale testować swoją witrynę? Wypróbuj nasze płatne narzędzie do monitorowania z bezpłatnym 14-dniowym okresem próbnym.
W ten sposób możesz sprawdzić, czy optymalizacje wydajności działają i otrzymywać powiadomienia o wszelkich regresjach wydajności w Twojej witrynie.
Zrzut ekranu przedstawiający trendy szybkości witryny dla witryny w DebugBear, październik 2022 r. 
Zrzut ekranu przedstawiający dane Core Web Vitals w DebugBear, październik 2022 r.