Wprowadzenie do HTTP/2 i szybkości strony

Opublikowany: 2020-01-03

Wstęp

W 1991 roku wprowadzono pierwszą udokumentowaną wersję protokołu HTTP żądanie-odpowiedź (HTTP 0.9). Od tego czasu sieć drastycznie się rozwinęła, a 24 lata później najnowsza wersja protokołu HyperText Transfer Protocol (HTTP/2) została wydana w 2015 roku, wprowadzając wiele możliwych korzyści dla wydajności witryny, jeśli jest prawidłowo zaimplementowana.

Ten artykuł jest skierowany do SEO, którzy chcą wdrożyć HTTP/2 w ramach swoich inicjatyw optymalizacji szybkości strony.

HTTP/2 to niezwykle bogaty temat, który można by szczegółowo omówić. Istnieje wiele informacji online omawiających protokół HTTP/2 i zapewnia on szersze korzyści użytkownikom końcowym i programistom, ale zanim zanurzysz się w bogactwo informacji związanych z HTTP/2, upewnij się, że otrzymujesz potrzebne informacje. Zaczyna się od zadania właściwych pytań:

  1. W jaki sposób wpłynie to bezpośrednio na optymalizację wyszukiwarek i/lub szybkość strony?
  2. Czy na podstawie wglądu można wystawić rekomendację?
  3. Czy rekomendacja może być realistycznie wykonana?

Te pytania pomagają zadać pytanie „czy to, co robię, jest skuteczne i wartościowe?” i ostatecznie zapewni Ci lepszą pozycję do oceny, w jaki sposób HTTP/2 może pomóc ulepszyć witrynę.

Ze względu na szeroki charakter tematu istnieje duża wiedza na temat HTTP/2, która nie jest potrzebna, aby zrozumieć znaczenie SEO. Podstawową korzyścią HTTP/2 dla SEO jest Page Speed.

Aby pomóc Ci poruszać się po bogactwie informacji online, oto wprowadzenie do HTTP/2, opisujące ewolucję od HTTP 1.1 do Spdy zgodnego z HTTP Google i ostatecznie do HTTP/2.

Zrozumienie, jak ewoluowała sieć, pomoże podkreślić ulepszenia, które zostały w niej wprowadzone w wyniku dodania protokołu HTTP/2.

Jak Google ocenia szybkość strony?

Aby zobaczyć, jak Google ocenia Page Speed, wystarczy spojrzeć na raporty Chrome User Experience Reports . Raporty te dostarczają metryki doświadczenia użytkownika dotyczące tego, jak użytkownicy korzystają z popularnych miejsc docelowych w sieci. Jest to oparte na kluczowych wskaźnikach zaangażowania użytkowników (pierwsze malowanie, pierwsze treściwe malowanie, pierwsze znaczące malowanie, czas na interakcję) i jest dodatkowo wspierane przez popularne narzędzia, takie jak Page Speed ​​Insights, Publiczny projekt Google Big Query, Lighthouse i Web Page Test. Korzystanie z tych danych i narzędzi może pomóc w ulepszeniu funkcji Page Speed.

Wprowadzenie do HTTP/2

HTTP 1.1

Do 2015 roku HTTP 1.1 stał się przestarzały. Dawno minęły czasy, w których strony internetowe / witryny były budowane / opierały się na podstawowym języku HTML, CSS i JavaScript, a także na licznych zasobach i różnych strukturach. Era sprzed 2015 roku opierała się na założeniu, że ograniczano się do jednego żądania na połączenie TCP. Doprowadziło to do sytuacji, w których klienci sieci Web mieli wiele zasobów oczekujących w kolejce do pobrania, powodując przeciążenie sieci i powolne ładowanie stron.

Protokół HTTP/2 został zaprojektowany w celu ukierunkowania na trzy główne obszary poprawy w celu złagodzenia problemów omówionych powyżej:

  • Prostota
  • Wysoka wydajność
  • Krzepkość

Korzyści SEO dla HTTP/2

Page Speed ​​jest prawdopodobnie głównym powodem, dla którego SEO rozważy wdrożenie protokołu HTTP/2 w witrynach własnych lub swoich klientów. Page Speed/ Performance to zestaw wskaźników, które od 2010 roku stanowią czynnik rankingowy dla zapytań na komputery. Ze względu na wzrost wykorzystania urządzeń mobilnych, w lipcu 2018 r. Google oficjalnie ogłosiło , że Page Speed ​​stanie się czynnikiem rankingowym dla urządzeń mobilnych.

HTTP/2 zapewnia 3 główne funkcje, które można wykorzystać podczas optymalizacji witryn pod kątem Page Speed:

  1. Multipleksowanie
  2. Serwer Push
  3. Priorytety transmisji

Multipleksowanie

Multipleksowanie pozwala klientowi WWW na uwzględnienie wielu żądań w jednym połączeniu TCP, co skutkuje mniejszym obciążeniem serwera i zmniejszeniem przeciążenia sieci.

Współcześni klienci WWW (Chrome, Firefox, Safari i Opera) korzystający ze starszych protokołów HTTP 1/1.1 mają domyślny limit liczby jednoczesnych połączeń TCP na nazwę hosta. Dlatego klient sieciowy korzystający z protokołu HTTP 1/1.1 może łatwo mieć problemy z przeciążeniem TCP. W przypadku nowoczesnych klientów internetowych ten problem jest rozwiązywany za pomocą multipleksowania, co może zapewnić jedne z najbardziej znaczących ulepszeń szybkości strony.

Poniżej przedstawiono korzyści z multipleksowania przy użyciu porównania HTTP/1.1 i HTTP/2, pokazujących typowe zachowanie, gdy multipleksowanie HTTP/2 jest i nie jest włączone.

( Test strony internetowej, HTTP/1.1, brak demonstracji multipleksowania )

( Test strony internetowej, HTTP/2, zademonstrowano multipleksowanie )

Na powyższych obrazach wodospad oparty na wydajności służy do zademonstrowania ładowania zasobów między użytkownikiem (który żąda zasobów) a serwerem (który odpowiada, które zasoby) strony internetowej. Zazwyczaj zasoby strony obejmują HTML, JavaScript, CSS i obrazy. Kaskada oparta na wydajności pokazuje dokładny moment, w którym określony zasób jest wywoływany, pobierany i renderowany w kliencie, co ma kluczowe znaczenie dla wykrywania, oceny i analizowania problemów z szybkością strony w witrynie. Jak pokazano na powyższym obrazku „HTTP/2”, wszystkie zasoby zaczynają się pobierać jednocześnie, a żadne zasoby nie zaczynają się ładować w innym punkcie. Ponieważ protokół HTTP/2 wykorzystuje multipleksowanie i nie polega już na wysyłaniu tylko 1 żądania przez pojedyncze połączenie TCP, wiele zasobów można pobrać w tym samym czasie, jak pokazano powyżej. W przeciwieństwie do tego, jak pokazuje obraz „HTTP/1.1”, zasoby nie są pobierane jednocześnie, ponieważ nie są w stanie wykorzystać funkcji multipleksowania. Przeciętna nowoczesna przeglądarka pod HTTP/1.1 jest w stanie jednocześnie mieć 6 połączeń, ale korzyścią z implementacji HTTP/2 jest to, że uzgadnianie TCP nie jest potrzebne dla każdego żądania, podczas gdy bez względu na to, ile połączeń może być jednocześnie uruchomionych z HTTP/1.1, początkowy proces łączenia musi być każdorazowo zakończony. Dlatego zaczynają się one pobierać w różnych punktach, co powoduje dłuższe ładowanie strony dla użytkownika.

( Uaktualnij schemat HTTP/1.1 i HTTP/2 )

Roboty indeksujące, takie jak Google i Bing, nie odnoszą bezpośrednich korzyści z wdrożenia protokołu HTTP/2. Jak opisano powyżej, główną korzyścią z tych optymalizacji może być potencjalnie Page Speed. Dlatego chociaż implementacja HTTP/2 może nie wpływać bezpośrednio na robota wyszukiwania, może mieć wpływ na Page Speed, który jest bezpośrednim czynnikiem rankingowym dla zapytań Google for Desktop od 2010 r. i zapytań mobilnych od lipca 2018 r. W rezultacie bardzo ważne jest, aby witryny nie dostarczały powolne działanie dla użytkowników, ponieważ Google może obniżać wydajność, wpływając na rankingi, a ostatnio sygnalizując użytkownikom, że Twoja witryna może działać wolno.

Serwer Push

Server Push umożliwia określonemu serwerowi lub sieci brzegowej wysyłanie zasobów do klientów sieci Web, gdy klient nie zażądał ich. Aby zrozumieć, jak działa serwer push, najpierw ważne jest zrozumienie wzorca żądanie-odpowiedź, który podąża strona internetowa. Użytkownik żąda strony ze strony internetowej, a serwer odpowiada żądaną treścią/zasobem.

Hipotetycznie pomyśl o witrynie, która ma wszystkie swoje style zdefiniowane w zewnętrznym arkuszu stylów o nazwie styles.css. Gdy użytkownik zażąda szkieletu HTML dla strony (powiedzmy w tym przypadku index.html), serwer push może „wypchnąć” CSS do użytkownika zaraz po rozpoczęciu wysyłania odpowiedzi do index.html.

( S mashing Magazine, Server Push )

Zanim zrozumiesz, w jaki sposób Server Push może pomóc poprawić Page Speed, ważne jest, aby zrozumieć, jak przeglądarka działa z różnymi zasobami, takimi jak obrazy, CSS i JavaScript, które pojawiają się w przeglądarce. Widzisz, przeglądarka wysyła instrukcje dotyczące pobierania obrazów, zasobów CSS i JavaScript. Przy pierwszej wizycie na stronie internetowej zwykle wysyłasz żądanie GET, którym jest plik .html. Po odebraniu tego pliku .html przeglądarka skanuje go, aby go zrozumieć, a następnie może wykonać dodatkowe żądania GET w zależności od zawartości pliku HTML.

W jaki sposób Server Push pomaga poprawić Page Speed?

Dzięki zastosowaniu funkcji Server Push liczba żądań GET wymaganych z przeglądarki (podróże w obie strony) zostaje zmniejszona i unika się opóźnień w renderowaniu, które powodują wydłużenie czasu ładowania strony. Może to znacząco pomóc w skróceniu czasu renderowania dla klienta internetowego, co pomaga użytkownikom szybciej wyświetlać stronę internetową, zapewniając im tym samym znacznie lepsze wrażenia.

Chociaż Server Push nie ma bezpośredniego wpływu na sposób, w jaki Googlebot indeksuje Twoją witrynę, ani w rzeczywistości inne roboty, korzyści SEO uzyskuje się dzięki ulepszeniu czynników zorientowanych na użytkownika, takich jak pierwsze malowanie i pierwsza znacząca treść.

Korzystając z Web Page Test, Lighthouse, Page Speed ​​Insights i raportu Chrome User Experience Report, możesz określić, jak dana witryna/strona wypada na tle konkurentów z tych samych branż. Poniżej znajdują się dwa obrazy przedstawiające implementację bez (zdjęcie 1) iz serwerem Push (zdjęcie 2).

(Test strony internetowej, bez serwera Push)

(Test strony internetowej, HTTP/1.1, z serwerem Push)

Dzięki serwerowi push serwer można skonfigurować tak, aby zawsze wysyłał dodatkowe komponenty strony (takie jak pliki CSS, JavaScript i obrazy), jeśli zostanie poproszony o przesłanie zawierającego je pliku .html.

W powyższych wodospadach widzimy, że push.php używa czterech plików CSS.

Bez serwera push przeglądarka musi otrzymać plik push.php, przeanalizować kod HTML, a następnie wykonać określone żądania dla każdego dodatkowego pliku CSS. Dopiero po otrzymaniu wszystkich plików CSS może zacząć używać ich w procesie renderowania.

Gdy serwer push jest włączony, żądanie push.php automatycznie powoduje wysłanie przez serwer czterech plików CSS. Przeglądarka otrzymuje je i może znacznie wcześniej zacząć z nich korzystać w procesie renderowania. Oznacza to, że przeglądarka może zacząć renderować zawartość strony znacznie wcześniej, co skutkuje lepszymi wskaźnikami szybkości strony.

Priorytetyzacja HTTP/2

Priorytetyzacja HTTP/2 przekazuje kontrolę nad kolejnością ładowania zasobów z powrotem do właścicieli witryn. Wykonana prawidłowo, priorytetyzacja poprawia wrażenia użytkownika i szybkość strony/witryny, dostarczając zasoby strony w zoptymalizowanej kolejności, tworząc w ten sposób „szybkie” wrażenia użytkownika.

Jeśli spojrzymy na poprzednika HTTP/2, HTTP/1.1, klient sieciowy kontroluje kolejność ładowania zasobów. Jak omówiono powyżej, wynikało to z faktu, że każde połączenie TCP mogło obsługiwać tylko jeden zasób na raz. Od przeglądarki zależy planowanie żądań, decydując, jakie zasoby wybrać i ile połączeń ma być otwieranych równolegle.

Zanim przejdziemy do tego, jak to się robi, ważne jest, aby zrozumieć, dlaczego chcemy używać priorytetów dla naszych zasobów.

Jeśli mamy obraz na górze strony i obraz na dole strony, logicznie rzecz biorąc, chcielibyśmy upewnić się, że obraz na górze ładuje się przed obrazem na dole. Ta koncepcja pomaga zademonstrować znaczenie i wpływ, jaki może przynieść Priorytet HTTP/2. Priorytetyzacja HTTP/2 pozwala nam określić, które zasoby powinny być dostarczone jako pierwsze i wczytane przed innymi (czy są to JavaScript, CSS, czy obrazy), zapewniając w ten sposób najszybszy czas ładowania strony.

Podczas gdy przeglądarka może teraz żądać wielu zasobów jednocześnie za pośrednictwem jednego połączenia TCP za pomocą multipleksowania, może teraz również określać informacje o priorytecie w każdym żądaniu, aby pomóc określić, kiedy/jak zasób powinien zostać dostarczony. Jeśli zarówno serwer, jak i przeglądarka obsługują nadawanie priorytetów HTTP/2, przeglądarka powinna zdefiniować zasady nadawania priorytetów z wykorzystaniem pełnej przepustowości bez konieczności konkurowania ze sobą zasobów. Aby lepiej zrozumieć, jak działa proces priorytetyzacji, ważne jest omówienie trzech parametrów, które są ważne dla priorytetyzacji HTTP/2:

Stream: Jest to dwukierunkowy przepływ bajtów w ramach ustanowionego połączenia, które może przenosić jeden lub komunikaty.

Strumień nadrzędny: Jest to strumień, od którego zależne są zasoby

Strumień podrzędny: jest to strumień zależny strumienia nadrzędnego. Dzielą tego samego rodzica i dlatego są znane jako strumień podrzędny

Waga: jest to liczba przydzielona między 1 a 256, która określa, ile przepustowości należy przydzielić do strumienia, jeśli wiele strumieni współdzieli połączenie. Przepustowość jest przydzielana względem wag wszystkich innych aktywnych strumieni.

Bit na wyłączność: Jest to flaga wskazująca, że ​​strumień powinien zostać pobrany bez współdzielenia przepustowości z innymi strumieniami.

Ramka nagłówków: To jest identyfikator strumienia, do którego należy ramka

Binarna warstwa ramek: W ten sposób wiadomości HTTP są enkapsulowane i przesyłane między klientem a serwerem

Poniższy przykład pokazuje przykład powyższego:

( Priorytet strumieni HTTP/2 Google Developers )

Aby przeprowadzić priorytetyzację HTTP/2, musisz dodać informacje o priorytecie w ramce nagłówków znajdującej się w nowej warstwie ramek binarnych HTTP/2. Strumień nadrzędny i zależność/niezależność od innych strumieni podrzędnych określają priorytet/ważenie, a tym samym dostarczanie zasobu do klienta WWW.

Chociaż priorytetyzacja HTTP/2 jest teraz obsługiwana na wielu platformach, wiele sieci CDN i dostawców hostingu nie obsługuje priorytetyzacji HTTP/2. Dlatego ważne jest, aby upewnić się, że korzystasz z dostawcy CDN/hostingu, który obsługuje priorytety HTTP/2, jeśli chcesz korzystać z tej techniki optymalizacji. Poniżej znajduje się tabela opisująca, które CDN/hosting/serwery są w stanie, a które nie mogą obsługiwać priorytetyzacji HTTP/2.

Priorytetyzacja HTTP/2 — wspólna kompatybilność serwerów/hostingu/CDN

To porównanie było poprawne w dniu 02.01.2020 , ale warto sprawdzić, czy potencjalni usługodawcy poprawili swoją kompatybilność przed podjęciem decyzji o wyborze.

Ważne jest również krytyczne spojrzenie na określone przeglądarki, ponieważ niestety nie wszystkie przeglądarki obsługują nadawanie priorytetów HTTP/2 i ustalanie priorytetów w inny sposób, ponieważ są różnymi klientami sieciowymi. Poniżej znajduje się tabela opisująca, którzy klienci sieci Web mogą obsługiwać priorytetyzację HTTP/2.

Zgodność z klientem sieciowym z priorytetami HTTP/2

Nadawanie priorytetów HTTP/2 może znacznie poprawić postrzeganie szybkości strony/witryny przez użytkowników i pozytywnie wpłynąć na dane gromadzone w raporcie dotyczącym wrażeń użytkowników Chrome. Chociaż ta optymalizacja nie ma wpływu na roboty wyszukiwania, takie jak Googlebot, narzędzia takie jak Lighthouse i Page Speed ​​Insights pomogą ocenić wpływ priorytetyzacji HTTP/2 na szybkość strony z perspektywy użytkownika.

Prawidłowo konfigurując wagę strumienia z serwerem i klientem korzystającym z CDN/hosta obsługiwanego przez HTTP/2, będziesz w stanie radykalnie poprawić wskaźniki szybkości strony dla swojego klienta.

Jakie są wymagania wstępne dla HTTP/2?

Zanim będziesz mógł skorzystać z zalet szybkości HTTP/2, upewnij się, że możesz z niego korzystać. Należy wziąć pod uwagę kilka warunków wstępnych:

  1. Ważne jest, aby upewnić się, że protokół HTTPS jest włączony.
  2. Wykorzystaj certyfikat TLS z uwierzytelnionego urzędu i aktywuj oraz zainstaluj certyfikat.
  3. Upewnij się, że oprogramowanie serwera sieci Web, takie jak Nginx, Apache i IIS, obsługuje protokół HTTP/2. Pełną listę uwierzytelnionych wsparcia można znaleźć pod adresem http://ayi.ma/browsershttp2 , która pokaże obsługę przeglądarki HTTP/2. Jeśli szukasz obsługi HTTP/2 dla CDN/hostingu, odwiedź http://ayi.ma/serverhosting .

Typowe pułapki / rzeczy, które muszą się zmienić wraz z wprowadzeniem HTTP/2

Ze względu na ograniczenia wcześniejszych protokołów HTTP 1.0 i HTTP 1.1, programiści i SEO starali się znaleźć sposoby na obejście wielu problemów, które te ograniczenia przedstawiały dla wydajności i bezpieczeństwa strony.

W końcu udało im się znaleźć „hacki”, aby ominąć niektóre z tych ograniczeń, ale wiele z tych metod wymagało od programistów jeszcze więcej pracy. Jakie są niektóre z tych hacków, o które możesz zapytać? Oto niektóre z najczęstszych ataków hakerskich na stronach, które można rozwiązać poprzez prawidłową implementację protokołu HTTP/2.

Unikaj dzielenia domeny

Co zaskakujące, wiele witryn nadal korzysta z tego hacka, chociaż mają poprawnie zaimplementowany protokół HTTP/2. Gdy protokół HTTP/2 jest włączony, ważne będzie unikanie korzystania z dzielenia domeny. Dzielenie domeny na fragmenty to technika dzielenia zasobów między różne nazwy hostów, co pozwala na jednoczesne udostępnianie większej liczby zasobów.

Dzięki zaktualizowanemu protokołowi HTTP/2 podział domeny nie jest już potrzebny i w rzeczywistości powoduje więcej problemów niż rozwiązuje. Jeśli protokół HTTP/2 jest poprawnie skonfigurowany i włączony dla Twojej witryny, a także korzystasz z podziału domeny, faktycznie przeciwdziałasz niektórym korzyściom wynikającym z protokołu HTTP/2, ponieważ przeglądarka nie będzie mogła korzystać z multipleksowania i pobierania między wieloma nazwami hostów.

Co więcej, dzięki podziałowi domeny faktycznie łamiesz priorytety transmisji, a twoje zasoby nie będą mogły zostać załadowane, aby jak najlepiej wykorzystać szybkość strony.

Prawidłowo wykorzystuj serwer Push

Server Push ma pewne wady, o których powinieneś wiedzieć. Serwer Push może w rzeczywistości być nadużywany i powinieneś być ostrożny przy wyborze, kiedy go użyć. Niekoniecznie chcesz wypychać zbyt wiele zasobów, ponieważ może to spowodować, że klient sieciowy pobierze nie tylko HTML, ale wszystko, z czym jest „wypychany”. Oznacza to, że wczytywanie i renderowanie strony może w rzeczywistości trwać dłużej (zwiększając dane skoncentrowane na użytkowniku, na których koncentruje się Google, takie jak Time to Interactive).

Drugą powszechną pułapką związaną z wypychaniem serwerów jest ustalenie, jak nie wypychać zasobów, które klient sieciowy już posiada. Można to kontrolować za pomocą wielu metod. Jedną z metod jest wybranie niewypychania zasobów do powracających użytkowników, a tym samym umożliwienie powracającym użytkownikom korzystania z ich zasobów z pamięci podręcznej. To zdecydowanie najłatwiejsza implementacja. Można to po prostu zrobić, sprawdzając nagłówki pamięci podręcznej dla zasobów, upewniając się, że nagłówki nie pokrywają się z implementacją wypychania serwera.

Testy w praktyce pod HTTP/2

Wiedza teoretyczna jest zawsze ważna dla stworzenia podstaw do zrozumienia HTTP/2 i jego zalet. Po zrozumieniu i zrozumieniu pojęć ważne jest, aby przetestować te teorie, aby zmierzyć wpływ, jaki HTTP/2 może wywrzeć na Page Speed.

Część 2 tej serii Page Speed ​​HTTP/2 w prawdziwym życiu — za pomocą testów i analiz witryn omówimy prawdziwe korzyści protokołu HTTP/2 w odniesieniu do szybkości strony i wartości dla SEO, więc nie przegap!

A co z HTTP/3?

Chociaż HTTP/3 wykazuje wyraźny potencjał jako następca protokołu HTTP/2, nie oznacza i nie powinien sygnalizować końca HTTP/2 dla SEO w całej sieci. Podobnie jak w przypadku każdego nowego dużego rozwoju sieci na całym świecie, przejdzie on przez normalną fazę wdrażania i prawdopodobnie zajmie trochę czasu, zanim witryna przyjmie nowy protokół i zanim stanie się de facto standardem w branży SEO. Implementacja HTTP/2 nadal stanowi korzystną i prostą korzyść, która po prawidłowym wdrożeniu może pomóc w poprawie wydajności witryny.