Nie dawno miała miejsce premiera nowej wersji protokołu HTTP czyli HTTP/2. Poprzednia wersja (HTTP 1.1) weszła w życie w 1997 roku i jest używana do dzisiaj.
Głównymi różnicami są m.in:
- Ograniczenie ilości połączeń TCP potrzebnych do pobrania całej zawartości strony.
Źródło: cloudflare.com - Server Push czyli wysyłanie komponentów zanim przeglądarka o nie poprosi.
Źródło: cloudflare.com - Priorytety pobieranej treści. Jest to mechanizm przeglądarki pozwalający jej na ustalenie jakie zasoby będzie potrzebowała w jakiej kolejności. Oznacza to, że przykładowo najpierw zostanie pobrany HTML, następnie style a na koniec skrypty JS.
- Kompresowanie nagłówków. Każde zapytanie wiąże się z wysłaniem nagłówków HTTP. Protokół w wersji 1.1 nie pozwalał na ich kompresję co powodowało wysyłanie kilkuset bitów do kilobajta w każdym żądaniu. Algorytm HPACK pozwala na skompresowanie nagłówków o 80-85% powodując znaczny spadek czasu ładowania strony.
Ale przejdźmy do konkretów, czyli do tego jak szybko i łatwo skorzystać z dobrodziejstw HTTP/2 i przyspieszyć ładowanie strony.
Po pierwsze kilka słów o wymaganiach:
- W założeniu HTTP/2 nie wymaga by strona miała certyfikat. Niestety wszystkie obecne na rynku przeglądarki go wymagają. (http://caniuse.com/#search=http2).
- Jeśli nasza strona posiada certyfikat czyli jej adres zaczyna się od „https://” to musimy sprawdzić czy serwer naszego hostingodawcy jest już przystosowany do obsługi HTTP/2 (https://tools.keycdn.com/http2-test).
- Jeśli nie mamy certyfikatu lub nasz hosting nie wspiera HTTP/2 to polecam skorzystać z platformy cloudflare.com. Jest to CDN czyli serwis, który „kopiuje” naszą stronę na swoje chmury i serwuje je użytkownikom z tej, do której użytkownik ma najbliżej. Dodatkowo oferują oni darmowy certyfikat SSL, ochronę przed atakami czy kompresję plików. Opis jak skonfigurować Cloudflare z WordPressem znajdziecie tutaj -> https://www.marketingowy.net/konfiguracja-cloudflare-wordpress/
Ja korzystam z platformy Cloudflare, więc poniższe testy i ustawienia są wykonywanie właśnie na niej.
Na początek może przykład aby od razu zobrazować co można uzyskać z HTTP/2
Przed optymalizacją:
Po optymalizacji:
Jak widzicie czas ładowania spadł z 3,7s do 1,6s i ilość zapytań spadła o połowę. Co widać na poniższych wykresach. (te skoki są spowodowane odświeżaniem cache na serwerach cloudflare i kombinowaniem z ustawieniami)
Jak widzicie, gra jest warta świeczki bo niewielkim nakładem pracy otrzymaliśmy ponad dwukrotny spadek czasu ładowania. W uzyskaniu wyniku pomogło nam zastosowanie Server Push czyli wysłanie wybranych zasobów zanim poprosi o nie sama przeglądarka.
Cloudflare pozwala na korzystanie z Server Push ale musimy je o tym poinformować. Co najlepsze, możemy to zrobić nie ingerując kompletnie w kod strony. Wykorzystamy do tego plik .htaccess
Aby skorzystać z Server push musimy w naszym pliku .htaccess dopisać kilka reguł, które mówią serwerowi, jaki pliki ma wysłać. Korzystamy wtedy z zapisu:
Header add Link '</wp-content/themes/internet-maker-theme/style.css>; rel=preload; as=stylesheet'
Gdzie w sekcji
as=*
możemy skorzystać z następujących parametrów:
consumer | Preload directive |
---|---|
<audio>, <video> | <link rel=preload as=media href=...> |
<script> , Worker’simportScripts | <link rel=preload as=script href=...> |
<link rel=stylesheet> , CSS @import | <link rel=preload as=style href=...> |
CSS @font-face | <link rel=preload as=font href=...> |
<img> , <picture> , srcset, imageset | <link rel=preload as=image href=...> |
SVG’s <image> , CSS *-image | <link rel=preload as=image href=...> |
XHR, fetch | <link rel=preload href=...> |
Worker, SharedWorker | <link rel=preload as=worker href=...> |
<embed> | <link rel=preload as=embed href=...> |
<object> | <link rel=preload as=object href=...> |
<iframe> , <frame> | <link rel=preload as=document |
Czyli przykładowo gdy chcemy wysłać plik CSS, JS i obraz nasz zapis w .htaccess będzie następujący:
Header add Link '</wp-content/themes/internet-maker-theme/style.css>; rel=preload; as=stylesheet' Header add Link '</wp-includes/js/jquery/jquery.js>; rel=preload; as=script' Header add Link '</wp-content/uploads/2016/01/internet-maker-logo.png>; rel=preload; as=image'
Należy pamiętać o podawaniu ścieżek względnych czyli z pominięciem adresu naszej witryny. Dodatkowo wszystkie zasoby muszą znajdować się na naszym serwerze.
Teraz kwestia tego, jakie pliki wysyłać za pomocą server Push. Wysyłamy tylko pliki, które wczytują się na wszystkich podstronach a nie tylko na wybranej. Nie chcemy przecież pobierać za każdym razem wszystkich obrazów z galerii gdy użytkownik przegląda pozostałe strony ale na przykład możemy pobrać logo gdyż te jest zawsze w nagłówku każdej naszej podstrony.
Skąd mamy się dowiedzieć jakie pliki są wczytywane? Tutaj istnieje kilka rozwiązań. Można na przykład wyświetlić sobie źródło strony (ctrl + u w Chrome) i szukać plików z rozszerzeniem *.css, *.js czy obrazów. Można otworzyć sobie narzędzia developerskie (F12 w Chrome) i w sekcji Sources wybrać swoją domenę i zobaczyć co się z niej pobierało. Możemy także wejść na stronę do testowania prędkości naszej witryny jak na przykład https://gtmetrix.com i po przeprowadzeniu testu kliknąć w zakładkę Waterfall, w której znajdziemy rozpiskę pobieranych stylów, skryptów czy obrazów.
Poniżej jeszcze jeden przykład, myślę, że na wykresie dość wyraźnie widać miejsce w którym został skonfigurowany Server Push. Czas ładowania spadł z 17 do 3 sekund ale pamiętajcie, że optymalizacja strony to złożone zagadnienie i samo HTTP/2 nie czyni cudów.
Pochwalcie się swoimi wynikami w komentarzach!