Analiza witryn komórkowych w PageSpeed Insights

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

PageSpeed Insights analizuje stronę, sprawdzając, czy spełnia zalecenia odnośnie do sieci komórkowych i czy może zostać wyrenderowana w czasie krótszym niż jedna sekunda. Badania wykazały, że wszelkie opóźnienia dłuższe niż jedna sekunda powodują rozkojarzenie użytkownika, co ujemnie wpływa na atrakcyjność odwiedzanych stron. Naszym celem jest utrzymanie zainteresowania użytkownika i zadbanie o jego komfort niezależnie od typu urządzenia i sieci.

Nie jest łatwo osiągnąć tak krótki czas, jak jedna sekunda. Na szczęście nie musisz renderować całej strony w ramach tego budżetu. Zamiast tego musimy wyświetlić i wyrenderować część strony widoczną na ekranie w ciągu niecałej sekundy, co pozwoli użytkownikowi jak najszybciej rozpocząć korzystanie ze strony. Podczas gdy użytkownik zajmuje się pierwszą stroną treści, w tle trwa stopniowe dostarczanie reszty.

Dostosowywanie do sieci komórkowych o dużych opóźnieniach

Spełnienie kryterium renderowania części strony widocznej na ekranach urządzeń przenośnych w czasie krótszym od jednej sekundy wiąże się z wyzwaniami, które nie występują w przypadku innych sieci. Użytkownicy odwiedzają witryny za pośrednictwem różnych sieci: 2G, 3G i 4G. Czas oczekiwania w sieci jest znacznie wyższy niż połączenie przewodowe i zużywa znaczną część budżetu 1000 ms na wyrenderowanie treści ATF.

4G to dominujący typ sieci na całym świecie. Należy się spodziewać, że większość użytkowników będzie wchodzić na stronę w sieci 4G. Z tego powodu musimy przyjąć, że wszystkie żądania sieciowe trwają średnio 100 milisekund.

Mając to na uwadze, prześledźmy cały proces od końca. Patrząc na typową sekwencję komunikacji między przeglądarką a serwerem, 300 ms tego czasu zostało już wykorzystane przez obciążenie sieci: wyszukiwanie DNS w celu rozpoznania nazwy hosta (np. google.com) pod adresem IP, przebiegu w obrębie sieci na potrzeby uzgadniania połączenia TCP i opcjonalnego połączenia TLS. Zostało nam 700 ms.

Renderowanie w mniej niż jedną sekundę

Po odjęciu opóźnienia sieci pozostało nam tylko 700 milisekund, a nadal trwa wiele zadań: serwer musi renderować odpowiedź, kod aplikacji po stronie klienta i przeglądać oraz renderować treść. Mając to na uwadze, warto przyjąć następujące założenia, aby zmieścić się w czasie:

(1) Serwer musi wyrenderować odpowiedź (< 200 ms)
Czas odpowiedzi serwera to czas potrzebny na zwrócenie początkowego kodu HTML (z uwzględnieniem czasu przesyłania danych w sieci). Ponieważ nie mamy zbyt dużo czasu, musimy go ograniczyć do minimum – do 200 milisekund, a nawet jeszcze bardziej.
(2) Liczba przekierowań powinna być jak najmniejsza
Dodatkowe przekierowania HTTP mogą powodować dodawanie po jednym lub dwóch dodatkowych cyklach wymiany danych w sieci (dwóch w razie dodatkowego wyszukiwania DNS) i wymagających setek milisekund opóźnienia w sieciach 4G. Z tego względu stanowczo doradzamy minimalizowanie liczby przekierowań, a w miarę możliwości zupełne ich wyeliminowanie. Jest to istotne zwłaszcza w przypadku dokumentów HTML (warto unikać przekierowań do wersji komórkowej – „m.”).
(3) Liczba sesji wymiany danych przed pierwszym wyrenderowaniem powinna być jak najniższa

Ze wzgledu na sposób, w jaki protokół TCP szacuje wydajność połączenia (strategia powolnego startu w TCP), nowe połączenie TCP nie może od razu wykorzystać pełnej przepustowości łącza między klientem a serwerem. Serwer może przesłać maksymalnie 10 pakietów TCP w ramach nowego połączenia (ok. 14 KB) w ciągu pierwszej sesji wymiany danych, a następnie musi czekać na potwierdzenie klienta, aby zwiększyć transfer.

Pamiętaj też, że limit 10 pakietów (IW10) to najnowsza aktualizacja standardu TCP. Aby skorzystać z tej zmiany, musisz zaktualizować serwer do najnowszej wersji. W przeciwnym wypadku do dyspozycji będą najwyżej 3-4 pakiety.

Ze względu na tę właściwość protokołu TCP warto zoptymalizować zawartość strony, aby ograniczyć liczbę sesji wymiany danych niezbędnych do przesłania zasobów do pierwszego wyrenderowania strony. Najlepiej byłoby, gdyby treść ATF była niższa niż 98 KB – dzięki temu przeglądarka może pomalować stronę po maksymalnie 3 zaokrągleniach, co zapewni wystarczający czas oczekiwania na odpowiedź serwera i renderowanie klienta.

(4) Należy unikać zewnętrznych blokujących zasobów JavaScript i CSS w części strony widocznej na ekranie

Zanim przeglądarka wyrenderuje stronę, musi ją przeanalizować. Jeśli w trakcie analizy napotka na nieasynchroniczny lub blokujący skrypt zewnętrzny, musi się zatrzymać i pobrać te zasoby. Każda taka operacja to dodatkowy transfer danych w obie strony, który oznacza opóźnienie pierwszego wyrenderowania.

Kody JavaScript i CSS niezbędne do wyrenderowania widocznej części strony powinny więc być wbudowane, a JavaScript lub CSS umożliwiające uzyskanie dodatkowych efektów muszą ładować się już po wyrenderowaniu części strony widocznej na ekranie.

(5) Uwzględnij czas na wyświetlenie układu i wyrenderowanie strony przez przeglądarkę (200 ms)
Proces analizowania kodu HTML, CSS i JavaScriptu zajmuje czas i zasobów klienta. W zależności od szybkości urządzenia przenośnego oraz stopnia skomplikowania strony mogą to być nawet setki milisekund. Zalecamy zarezerwowanie 200 milisekund na ogólne działania przeglądarki.
(6) Zoptymalizuj wykonywanie JavaScriptu i czas renderowania
Uruchomienie skomplikowanych skryptów i niewydajnego kodu może trwać dziesiątki kilkuset milisekund – użycie wbudowanych narzędzi dla programistów w przeglądarce do profilowania i optymalizowania kodu. Na początek zapoznaj się z naszym interaktywnym kursem dotyczącym Narzędzi dla programistów Chrome.

Najczęstsze pytania

Co robić, jeżeli używam biblioteki JavaScript, takiej jak jQuery?
Wiele bibliotek JavaScript, takich jak JQuery, służy do wzbogacania strony o dodatkowe funkcje interaktywne, animacje i inne efekty. Wiele z tych działań można jednak bezpiecznie dodać już po wyrenderowaniu części strony widocznej na ekranie. Sprawdź, jaki będzie efekt przesunięcia wykonywania i wczytywania JavaScriptu na okres po wczytaniu strony.
Co robić, jeżeli moja strona jest zbudowana w oparciu o architekturę JavaScript?
Jeśli treść strony jest tworzona przez JavaScript po stronie klienta, zalecamy zbadanie wbudowanych modułów JavaScript, aby uniknąć dodatkowych połączeń sieciowych. Również skorzystanie z możliwości renderowania po stronie serwera może znacząco przyspieszyć pierwsze renderowanie strony: wyrenderuj szablony JS na serwerze, wbuduj uzyskany kod w HTML, a następnie użyj szablonów po stronie klienta po wczytaniu aplikacji.
Jak zidentyfikować krytyczne zasoby CSS na stronie?
W Narzędziach dla programistów Chrome otwórz panel kontroli i wygeneruj raport skuteczności strony internetowej, a następnie w wygenerowanym raporcie znajdź opcję Usuń nieużywane reguły CSS. Możesz tez użyć innego, zewnętrznego narzędzia lub skryptu, aby wskazać elementy wybierające pliki CSS na poszczególnych stronach.
Czy mogę zautomatyzować stosowanie tych sprawdzonych metod?
Jak najbardziej. Istnieje wiele komercyjnych i otwartych produktów do optymalizacji skuteczności stron internetowych (Web Performance Optimization – WPO), dzięki którym łatwiej osiągniesz zgodność z częścią powyższych kryteriów. Rozwiązania typu open source znajdziesz w narzędziach do optymalizacji PageSpeed.
Co mogę ulepszyć w serwerze, aby spełnić te kryteria?
Najpierw upewnij się, że na serwerze działa aktualna wersja systemu operacyjnego. Aby korzystać ze zwiększonego początkowego rozmiaru zatoru TCP (IW10), musisz mieć jądro Linuksa w wersji 2.6.39 lub nowszej. Inne systemy operacyjne znajdziesz w dokumentacji.
Aby zoptymalizować czas odpowiedzi serwera, dostosuj kod lub użyj narzędzia do monitorowania aplikacji, aby zidentyfikować wąskie gardła (np. środowisko wykonawcze skryptu, wywołania bazy danych, żądania RPC, renderowanie itd. Celem jest wyrenderowanie odpowiedzi HTML w ciągu 200 milisekund).
Co z zasadami bezpieczeństwa treści?
Jeśli korzystasz z CSP, może być konieczne zaktualizowanie domyślnych zasad.
Po pierwsze, wbudowane atrybuty CSS w elementach HTML(np. < p style=...>) należy unikać, ponieważ często powoduje niepotrzebne powielanie kodu i jest domyślnie zablokowany przez CSP (wyłączony przez „unsafe inline” w sekcji „style-src”). Jeśli ta opcja jest włączona, domyślnie blokuje wszystkie wbudowane tagi skryptu. Jeśli masz wbudowany kod JavaScript, musisz zaktualizować zasady CSP, aby korzystały z haszów skryptu lub liczb jednorazowych, lub „unsafe-inline”, aby włączyć wszystkie skrypty wbudowane. Jeśli używasz stylów wbudowanych, musisz zaktualizować zasady CSP, aby używały wartości hash lub jednorazowych, albo &"unsafe-inline", by umożliwić przetwarzanie wszystkich bloków stylów wbudowanych.

Masz pytania? Jeśli masz pytania, podziel się swoją opinią w grupie dyskusyjnej na stronie pagespeed-insights-dyskusja.

Prześlij opinię

Czy ta strona była pomocna?