Analiza witryn komórkowych w PageSpeed Insights

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 cała strona musi się w tym czasie wyświetlić. W ciągu jednej sekundy musimy przesłać i wyrenderować część widoczną na ekranie (ang. Above The Fold – ATF), aby użytkownik mógł jak najszybciej zacząć korzystać 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. Opóźnienia sieciowe są znacznie większe niż w przypadku połączeń kablowych i pochłaniają sporą część z 1000 ms przeznaczonych na wyrenderowanie części strony widocznej na ekranie:

  • 200-300 ms zabiera transfer w obie strony w sieciach 3G
  • 50-100 ms zabiera transfer w obie strony w sieciach 4G

3G to najczęściej spotykany typ sieci na świecie, natomiast sieć 4G jest dopiero wdrażana, zatem należy się spodziewać, że użytkownicy Twojej strony będą ją odwiedzać głównie za pośrednictwem sieci 3G. Z tego względu możemy przyjąć, że średni czas przypadający na żądanie sieciowe wynosi około 200 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, widzimy, że 600 ms już zostało wykorzystane na wyszukiwanie DNS i identyfikację nazwy hosta (np. google.com) powiązanej z adresem IP, wymianę danych w związku z uzgodnieniami TCP i w końcu na przesłanie żądania HTTP. Zostaje już tylko 400 ms.

Renderowanie w mniej niż jedną sekundę

Po odjęciu opóźnień sieciowych zostaje nam jedynie 400 milisekund do wykorzystania i wciąż całe mnóstwo pracy: serwer musi wyrenderować odpowiedź, aplikacja kliencka musi wykonać kod, a przeglądarka zadbać o układ i wyrenderowanie treści. 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 HTML-a, bez uwzględniania przesyłu 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 oznaczają kolejną sesję wymiany danych (dwie, jeśli konieczne będzie ponowne wyszukiwanie DNS), co wiąże się z setkami milisekund dalszych opóźnień w sieciach 3G. 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 względu 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.

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. Optymalny rozmiar zawartości części strony widocznej na ekranie nie powinien przekraczać 14 KB. To pozwoli przeglądarce odrysować stronę w ramach jednej sesji wymiany danych. Pamiętaj też, że w standardzie TCP rozszerzono ostatnio ograniczenie liczby pakietów do 10 (IW10). Aby skorzystać z tej zmiany, musisz zadbać o zaktualizowanie serwera do najnowszej wersji. W przeciwnym wypadku do dyspozycji będą najwyżej 3-4 pakiety.

(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 analizy kodu HTML i CSS oraz wykonywania JavaScriptu zajmuje czas i angażuje zasoby po stronie 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
Wykonanie skomplikowanych skryptów i nieefektywnego kodu może wymagać setek milisekund. Warto posłużyć się narzędziami programistycznymi w przeglądarce, aby sprofilować i zoptymalizować kod. Na początek polecamy nasz interaktywny kurs Chrome Developer Tools.

Najczęstsze pytania

Jak sieci 4G mają się do powyższych kryteriów?
Mniejsze opóźnienia wymiany danych to najważniejsze usprawnienia wprowadzone w sieciach 4G. To duże ułatwienie, ponieważ pozwala znacznie skrócić łączny czas poświęcany na ogólne operacje sieciowe, na które w sieciach 3G schodzi obecnie ponad 50% założonej przez nas jednej sekundy. 3G to jednak najpowszechniejszy typ sieci na świecie i z pewnością nie zmieni się to przez kolejne lata. Musisz więc zadbać o optymalizację stron pod kątem użytkowników sieci 3G.
Co robić, jeżeli używam biblioteki JavaScript, takiej jak jQuery?
Biblioteki JavaScript, takie jak JQuery, umożliwiają wzbogacenie strony o dodatkowe funkcje, 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żeli zawartość strony jest oparta na kodzie JavaScript po stronie klienta, powinieneś rozważyć wbudowanie odpowiednich modułów JavaScript, by móc uniknąć dodatkowych transferów danych w obie strony. 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.
Czy SPDY i HTTP 2.0 w czymś pomogą?
Zarówno SPDY, jak i HTTP 2.0 umożliwiają zmniejszenie opóźnień we wczytywaniu strony poprzez efektywniejsze wykorzystanie połączenia TCP (zwielokrotnianie, kompresję nagłówków, priorytetyzację). Ponadto zastosowanie mechanizmu Server Push może pomóc jeszcze bardziej zwiększyć wydajność poprzez wyeliminowanie kolejnych opóźnień sieciowych. Zachęcamy do przetestowania, co zmieni wdrożenie na serwerach obsługi protokołu SPDY i przejścia na standard HTTP 2.0, gdy tylko będzie gotowy.
Jak zidentyfikować krytyczne zasoby CSS na stronie?
W Chrome Developer Tools otwórz panel audytów i uruchom narzędzie raportowania skuteczności stron internetowych. W raporcie poszukaj części poświęconej regułom usuwania nieużywanych zasobów 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?
Oczywiście. 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 na stronie narzędzi optymalizacyjnych PageSpeed.
Co mogę ulepszyć w serwerze, aby spełnić te kryteria?
Po pierwsze, upewnij się, że masz na serwerze aktualną wersję systemu operacyjnego. Aby skorzystać z większej przepustowości pierwszej sesji TCP (IW10), będziesz potrzebować jądra Linuksa w wersji co najmniej 2.6.39. W przypadku innych systemów operacyjnych musisz zapoznać się z dokumentacją.
Jeżeli chcesz zoptymalizować czas odpowiedzi serwera, wprowadź do kodu odpowiednie mechanizmy sprawdzające lub zastosuj narzędzia do monitorowania aplikacji i znajdź wąskie gardła: czas wykonywania skryptów, wywołania bazy danych, żądania RPC, renderowanie itp. Celem jest umożliwienie wyrenderowania odpowiedzi HTML w ciągu 200 milisekund.
Co z zasadami bezpieczeństwa treści?
Jeśli używasz zasad bezpieczeństwa treści (Content Security Policy – CSP), być może trzeba będzie zaktualizować domyślne zasady.
Przede wszystkim w miarę możliwości unikaj stosowania atrybutów CSS wbudowanych w elementy HTML (np. &lt p style=...&gt), ponieważ często powoduje to niepotrzebną duplikację kodu i jest domyślnie blokowane przez zasady CSP (wyłączane zgodnie z zarządzeniem „unsafe inline” w ramach atrybutu „style-src”). Jeśli zasady CSP są włączone, domyślnie zablokują wszystkie wbudowane tagi skryptu. W przypadku wbudowanego JavaScriptu musisz zaktualizować zasady CSP i używać sum kontrolnych skryptu lub kodów jednorazowych albo za pomocą zarządzenia „unsafe-inline” włączyć wykonywanie wszystkich wbudowanych skryptów. Jeśli masz wbudowane style, zasady CSP muszą opierać się na sumach kontrolnych stylów lub kodach jednorazowych albo zarządzenie „unsafe-inline” musi włączać przetwarzanie wszystkich wbudowanych bloków stylów.

Masz więcej pytań? Zapraszamy do zadawania pytań i zamieszczania komentarzy na grupach dyskusyjnych w witrynie pagespeed-insights-discuss.