1. HTTP/2 – co nowego
Mija już ponad rok od ukończenia prac nad nową wersją protokołu HTTP/1.x o nazwie HTTP/2. Nowa wersja bardzo mocno bazuje na googlowskim protokole SPDY ale w przeciwieństwie do niego nie wymaga TSL (SSL) ale jest to właściwość teoretyczna o czym wspomnę w dalszej części artykułu. Nowa wersja jest zgodna wstecznie co oznacza, że do poprawnego funkcjonowania nie są konieczne żadne zmiany w kodzie Twojej witryny.
W sieci jest sporo dyskusji , w których trwa spór o to czy HTTP/2 spełnia oczekiwania czy nie. Jedni dowodzą, że tak, inni odwrotne. Na pewno jest to krok do przodu. Inną kwestią czy jest to krok siedmiomilowy czy dużo mniejszy. W poniższym artykule nie będę jednak zagłębiał się w technikalia i optował za którąś ze stron.
Przyjrzyjmy się co wnosi (na bardzo ogólnym poziomie) HTTP/2:
- Protokół jest binarny w przeciwieństwie do swojego poprzednika, który był tekstowy. Dzięki temu jest bardziej ?strawny? dla oprogramowania serwerowego i klienckiego. Łatwiej i szybciej się go parsuje (odpada translacja tekst <-> kod binarny) a przede wszystkim jest mniejsze ryzyko powstania błędu. Binarność ma też swoją wadę – praktycznie uniemożliwia obsługę tego protokołu przez ?interfejs białkowy? za pomocą np. sesji telnetowej (ale są / powstaną odpowiednie nakładki / wtyczki).
- Wprowadza kompresję nagłówków http. Teoretycznie powinno to wpłynąć w jakiś sposób na poprawę szybkości ładowania strony ale w praktyce bywa różnie. Zależy to od ilości danych przepływającej w nagłówkach pomiędzy serwerem a klientem (przeglądarką). W komunikacji np. z serwisem Facebook może to być w jakimiś stopniu odczuwalne (duży udział procentowy informacji w nagłówkach http w stosunku do danych). Kosztem kompresji / dekompresji jest obciążenie procesorów serwera i przeglądarki.
- Jedno połączenie TCP wiele żądań http (multiplexing) i priorytet zasobu. W starej wersji można było wysłać tylko jedno żądanie o zasób w ramach sesji TCP. Przeglądarka wysyłała żądanie o zasób, otrzymywała dane i dopiero mogła wysłać następne. Obejściem tego problemu po stronie przeglądarki było otwieranie wielu sesji TCP (ilość ich zawsze jest limitowana). Do protokołu po stronie serwera wprowadzono możliwość otrzymywania wielu żądań bez otrzymywania odpowiedzi na poprzednie ale tu nie przeskoczono problemu po stronie serwera – konieczność przetwarzania żądań wg. kolejności ich otrzymywania (np. pierwszy duży plik blokował kolejne małe ale istotniejsze do renderowania strony). Dla zainteresowanych – dochodzi jeszcze problematyczna właściwość połączenia TCP tzw. slow start.
W HTTP/2 wprowadzono możliwość wysyłania wielu żądań http w ramach jednej sesji połączenia TCP. Oczywiście połączenie TCP jest per host. Jeżeli ktoś korzysta z zasobów z własnego hostingu oraz np. z zasobów jakiegoś CDNa to zostaną utworzone 2 połączenia. Każde żądanie jest strumieniem (w połączeniu TCP), współdzielonym przez klienta i serwer, które mogą być zamykane lub odrzucane. Przeglądarka wysyła kilka żądań i ustawia ich priorytet, który informuje serwer o kolejności zwracania zasobów (np. najpierw zasób html, css, js, obrazek). Serwer stara się (jeżeli się da) obsługiwać w pierwszej kolejności żądania z wyższą wagą.
Dzięki powyższym mechanizmom uzyskujemy redukcję ilości połączeń a tym samym zmniejszenie zasobów serwera i klienta koniecznych do utrzymywania wielu sesji TCP, redukcję ilości przesyłanych pakietów, zredukowanie szansy na stratę pakietów, szybsze renderowanie strony przez przeglądarkę.
- Push z serwera. Dla programistów temat ?rzeka?. Jednym zdaniem: umożliwia serwerowi wysyłanie danych do klienta bez wcześniejszego żądania. W niniejszym artykule skupię się właśnie na wykorzystaniu tej technologi w celu poprawy szybkości wczytywania strony. Resztę profitów wynikających z użycia głównych zmian w HTTP2 dostajemy niejako ?za darmo?. Proszę się jednak nie przerażać, nie będę proponował grzebania w kodzie Waszych witryn, nie będzie wymagana praktycznie żadna tajemna wiedza programistyczna. Po prostu pokażę jak poustawiać kilka ?wajch? w pliku htaccess :).
2. Wdrożenie HTTP2
Aktualnie praktycznie wszystkie liczące się na rynku przeglądarki mają zaimplementowaną obsługę nowego protokołu. Wg danych podawanych przez serwis caniuse.com aktualnie 76% internautów (w Polsce 83%), korzysta z takich przeglądarek. Generalnie strona kliencka jest przygotowana do serwowania jej treści za pomocą http2. Jest tylko małe ?ale? – praktycznie wszystkie przeglądarki wymagają aby strona miała certyfikat ssl. Niby http2 nie wymaga posługiwania się SSL?em ale w rzeczywistości bez niego nie ma sensu optymalizacji witryny pod nowy protokół. Jest to kolejny powód do zastanowienia się nad zakupem certyfikatu dla naszych stron.
Aby nasza strona korzystała z dobrodziejstw nowego standardu oprócz obsługi po stronie klienta wymagana jest jeszcze jego obsługa po stronie serwera na którym jest hostowana. I tu niestety sprawa wygląda dużo gorzej. Ofert hostingu z obsługą HTTP2 jest jak na lekarstwo, w Polsce znalazłem chyba tylko dwie (na nowych wersjach serwera Litespeed). Z pozoru problem nie do przeskoczenia ale można go bardzo prosto rozwiązać za pomocą usługi cloudflare.com. Czym jest ta usługa i jakie korzyści (oprócz obsługi HTTP2 po stronie serwera) daje nie będę opisywał – temat na kilka artykułów. Wdrożenie usługi jest banalnie proste i sprowadza się do rekonfiguracji rekordów DNS naszej domeny – po dokładny opis jak to zrobić odsyłam do dokumentacji pomocy CloudFlare. Najważniejsza sprawa – dla naszych zastosowań w zupełności wystarczy darmowa wersja usługi 🙂
3. Dopalamy naszą witrynę.
Wszyscy klienci CloudFlare korzystający z HTTP2 maja domyślnie włączoną technologię Server Push ale tak jak wcześniej wspomniałem, to nie wystarczy. Należy jeszcze coś grzebnąć w naszym pliku htaccess aby cieszyć się z profitów tej technologi. Grzebanie polega na dodaniu dyrektywy nakazującej dodanie dodatkowego nagłówka http:
Header add Link '</sciezka/do/styl.css>; rel=preload; as=stylesheet'
Gdzie:
preload – informacja (dla serwera i klienta) że dany zasób będzie wysłany za pomocą push?a
as – typ zasobu, możliwe wartości przedstawiono w poniższej tabeli
Ścieżki do zasobów muszą być relatywne i ?lokalne? nie mogą to być wskazania na obiekty spoza naszej domeny.
Nic nie zmieniamy w kodzie naszej witryny, nie usuwamy referencji do obiektów, które zadeklarowaliśmy jako link w htaccess! I to już właściwie wszystko :). O czym należy pamiętać? W dodawanych nagłówkach typu link należy wskazywać ?uniwersalne? zasoby, które są ładowane na wszystkich stronach naszej witryny a więc globalne style, skrypty, obrazki logo, ikonki menu, fonty itp. Nie ma sensu wskazywać obrazka, który występuje tylko na jednej konkretnej stronie naszej witryny.
Jeżeli chcemy zoptymalizować szybkość konkretnej strony to proponuję użyć poniższej składni
<Files /sciezka/do/konkretna-strona.php>
Header add Link '</sciezka/do/obrazek1.jpg>; rel=preload; as=image'
Header add Link '</sciezka/do/obrazek2.jpg>; rel=preload; as=image'
?..
</Files>
Jeżeli optymalizowana ma być grupa stron, którą da się zidentyfikować za pomocą wyrażenia regularnego to proponuję zastosować FilesMatch.
4. Testy HTTP2
Warunki testu referencyjnego:
- strona hostowana na środowisku z zainstalowaną usługą cloudFlare – w ten sposób zniwelowano wpływ jaki daje sama usługa
- na stronie nie ma referencji do obiektów zewnętrznych (nie hostowanych poza domeną), wyjątkiem są skrypty GTM i GA
Warunki testu optymalizacji:
- warunki dla strony takie same jak w teście referencyjnym
- zidentyfikowano zasoby wspólne (12) dla całej witryny i dla nich stopniowo wprowadzono odpowiednie zapisy w pliku htaccess.
Wynik testu:
Jak widać z powyższych wykresów czas ładowania strony spadł z ponad 3 [s] do 1.4 [s].
Jak należało się spodziewać ilość żądań zmalała. Na wykresie widać spadek wagi strony ale wynika to z tego że GTmetrix nie sumuje danych otrzymanych za pomocą pusha. Tak naprawdę waga strony się nie zmieniła. Generalnie można się spodziewać skrócenia czasu ładowania strony średnio o 30% – 40%. Myślę, że gra warta świeczki 🙂
Podczas testów zdarzało się, że wyniki były niestabilne, tak jakby GTMetrix nie zawsze dawał sobie radę z pushem lub mogło to być wynikiem jakiś jego wewnętrzych keszów, brakiem odświeżenia CDNa CloudFlara (zapewne korzysta z lokalizacji CDNa w Kanadzie) itp. Poszczególne wyniki optymalizacji bardzo ładnie widać w narzędziach deweloperskich jakie są dostępne w Chormie i Firefoxie (wykresy czasowe).
Po optymalizacji okazało się, że stosunkowo dużym obciążeniem czasowym jaki pozostał są skrypty googla (GTM i GA). Teoretycznie nie da się ich optymalizować ale widzę furtkę aby coś tam pokombinować. Inną możliwością jest poczekanie na zakończenie prac przez W3C i obsługę przez przeglądarki atrybutu HTML: preload.
W czasie testów wyszła jedna sprawa. Do tej pory zalecane było umieszczanie skryptów js na końcu dokumentu HTML. Przy wykorzystaniu server push korzystniejszym jest umieszczanie takich zasobów w sekcji head. Zauważyłem, że jak skrypt był umieszczony za końcem sekcji body bardzo często zdarzało się, że występowało żądanie tego zasobu (pomimo wcześniejszego dostarczenia go za pomocą push). Niestety takie umieszczenie skryptów może spowodować obniżenie oceny za szybkość działania strony (komunikat o kodzie blokującym renderowanie) w narzędziu googla do testowania szybkości strony. Prawdopodobnie GoogleSpeed Insights nie jest dostosowane do HTTP2 i zgłasza coś co nie występuje.
5. Co na to Google – co oni mówią o HTTP2 ?
Pod koniec roku 2015 John Mueller zapowiedział, że najpóźniej do początku roku 2016 googlebot będzie obsługiwał HTTP2
[embedplusvideo height=”300″ width=”480″ editlink=”http://bit.ly/29C62jk” standard=”http://www.youtube.com/v/tcU1elqTkJQ?fs=1″ vars=”ytid=tcU1elqTkJQ&width=480&height=300&start=&stop=&rs=w&hd=0&autoplay=0&react=1&chapters=¬es=” id=”ep2578″ /]
Czy tak się stało – nie wiem. W GSC w opcji pobierz jako Googlebot nie ma problemów dla stron z HTTP2 jednak pobieranie odbywa się po starej wersji protokołu. W opcji statystyki indeksowania, linia czasu spędzonego na pobieraniu strony jakby się ?wygładziła? – mniejsze piki (średni czas pobierania spada).
Obrazek tytułowy pochodzi z serwisu: media.licdn.com
Dodaj komentarz