O introducere în HTTP/2 și viteza paginii

Publicat: 2020-01-03

Introducere

În 1991, a fost introdusă prima versiune documentată a protocolului HTTP cerere-răspuns (HTTP 0.9). De atunci, web-ul s-a extins drastic și, 24 de ani mai târziu, cea mai recentă versiune a HyperText Transfer Protocol (HTTP/2) a fost lansată în 2015, introducând o multitudine de beneficii posibile performanței site-ului atunci când este implementată corect.

Acest articol se adresează SEO care doresc să implementeze HTTP/2 ca parte a inițiativelor lor de optimizare a vitezei paginii.

HTTP/2 este un subiect extrem de bogat care ar putea fi discutat în detaliu. Există o mulțime de informații online care discută despre HTTP/2 și sunt beneficii mai largi pentru utilizatorii finali și dezvoltatori, dar înainte de a vă afla cufundat în multitudinea de informații despre HTTP/2, asigurați-vă că obțineți informațiile de care aveți nevoie. Aceasta începe cu a pune întrebările potrivite:

  1. Cum va afecta acest lucru optimizarea motorului de căutare și/sau viteza paginii?
  2. Se poate face o recomandare din perspectivă?
  3. Recomandarea poate fi realizată în mod realist?

Aceste întrebări vă ajută să vă întrebați „Este ceea ce fac eficient și valoros?” și în cele din urmă vă pune într-o poziție mai bună pentru a evalua modul în care HTTP/2 poate ajuta la îmbunătățirea unui site web.

Datorită naturii largi a subiectului, există o cantitate mare de cunoștințe despre HTTP/2 care nu este necesară atunci când încercați să înțelegeți importanța pentru SEO. Beneficiul principal al HTTP/2 pentru SEO este viteza paginii.

Pentru a vă ajuta să navigați prin multitudinea de informații online, iată o introducere în HTTP/2, care descrie evoluția de la HTTP 1.1 la Spdy compatibil HTTP de la Google și, eventual, la HTTP/2.

Înțelegerea modului în care a evoluat web-ul va ajuta la evidențierea îmbunătățirilor care i-au fost aduse ca urmare a adăugării protocolului HTTP/2.

Cum evaluează Google viteza paginii?

Pentru a vedea cum evaluează Google Viteza paginii, nu căutați mai departe decât Rapoartele despre experiența utilizatorului Chrome . Aceste rapoarte oferă valori ale experienței utilizatorilor pentru modul în care utilizatorii se confruntă cu destinațiile populare de pe web. Acest lucru este alimentat folosind valori cheie de implicare a utilizatorilor (First Paint, First Contentful Paint, First Meaningful Paint, Time to Interactive) și este susținut în continuare prin instrumente comune, cum ar fi Page Speed ​​Insights, Public Google Big Query Project, Lighthouse și Web Page Test. Utilizarea acestor valori și instrumente poate ajuta la posibile îmbunătățiri în ceea ce privește Viteza paginii.

Introducere în HTTP/2

HTTP 1.1

Până în 2015, HTTP 1.1 devenise depășit. Au dispărut vremurile în care paginile web/site-urile erau construite/se bazau pe HTML, CSS și JavaScript de bază și pe numeroase resurse și cadre diferite. Epoca de dinainte de 2015 s-a bazat pe ideea că erai limitat la o singură solicitare per conexiune TCP. Acest lucru a dus la situații în care clienții web aveau mai multe resurse în coadă pentru descărcare, provocând congestionarea rețelei și timpii de încărcare a paginii lenți.

HTTP/2 a fost conceput pentru a viza trei domenii principale de îmbunătățire pentru a atenua problemele discutate mai sus:

  • Simplitate
  • Performanta ridicata
  • Robusteţe

Beneficii SEO pentru HTTP/2

Viteza paginii este probabil motivul principal pentru care SEO ar lua în considerare implementarea HTTP/2 fie pe site-urile lor proprii, fie pe site-urile clientului lor. Viteza/Performanța paginii este un set de valori care au fost un factor de clasare din 2010 pentru interogările Desktop. Datorită creșterii utilizării dispozitivelor mobile, în iulie 2018 Google a anunțat oficial că Viteza paginii va deveni un factor de clasare pentru mobil.

HTTP/2 oferă 3 funcționalități principale care pot fi utilizate la optimizarea site-urilor pentru viteza paginii:

  1. Multiplexarea
  2. Server Push
  3. Prioritizarea fluxului

Multiplexarea

Multiplexarea permite unui client web să includă mai multe cereri într-o singură conexiune TCP, rezultând o încărcare mai mică a serverului și reducerea congestionării rețelei.

Clienții web moderni (Chrome, Firefox, Safari și Opera) care utilizează protocoalele mai vechi HTTP 1/1.1 au o limită implicită a numărului de conexiuni TCP simultane pe nume de gazdă. Prin urmare, un client web care utilizează HTTP 1/1.1 poate avea cu ușurință dificultăți cu congestia TCP. Cu clienții web moderni, această problemă este rezolvată folosind multiplexarea, care poate oferi unele dintre cele mai semnificative îmbunătățiri ale vitezei paginii.

Mai jos este demonstrat beneficiul multiplexării utilizând o comparație între HTTP/1.1 și HTTP/2, arătând un comportament tipic atunci când multiplexarea HTTP/2 este și nu este activată.

( WebpageTest, HTTP/1.1, Fără multiplexare demonstrată )

( WebpageTest, HTTP/2, multiplexare demonstrată )

În imaginile de mai sus, o cascadă bazată pe performanță este folosită pentru a demonstra încărcarea resurselor între un utilizator (care solicită resursele) și serverul (care răspunde la care resurse) unei pagini web. De obicei, resursele paginii includ HTML, JavaScript, CSS și imagini. Cascada bazată pe performanță demonstrează momentul exact când o anumită resursă este apelată, descărcată și redată în cadrul clientului, ceea ce este critic în descoperirea, evaluarea și analiza problemelor legate de viteza paginii de pe un site. După cum demonstrează imaginea de mai sus „HTTP/2”, toate resursele încep să se descarce simultan, fără ca resursele să înceapă să se încarce într-un alt punct. Deoarece HTTP/2 utilizează multiplexarea și nu se mai bazează pe trimiterea unei singure solicitări printr-o singură conexiune TCP, mai multe resurse pot fi descărcate în același timp, văzute mai sus. În schimb, așa cum se demonstrează în imaginea „HTTP/1.1”, resursele nu se descarcă simultan, deoarece nu pot utiliza funcționalitatea de multiplexare. Browserul modern obișnuit sub HTTP/1.1 este capabil să aibă simultan 6 conexiuni, dar avantajul implementării HTTP/2 este că o strângere de mână TCP nu este necesară pentru fiecare solicitare, în timp ce indiferent câte conexiuni pot rula simultan cu HTTP/1.1, o inițială procesul de conectare trebuie finalizat de fiecare dată. Prin urmare, acestea încep să se descarce în puncte diferite, provocând astfel o încărcare mai lungă a paginii pentru utilizator.

( Diagrama de upwork HTTP/1.1 vs HTTP/2 )

Crawlerele de căutare precum Google și Bing nu beneficiază direct de implementarea HTTP/2. După cum este descris mai sus, beneficiul major al acestor optimizări ar putea fi pentru Viteza paginii. Prin urmare, deși implementarea HTTP/2 poate să nu afecteze în mod direct crawler-ul de căutare, aceasta poate afecta Viteza paginii, care este un factor direct de clasare pentru interogările Google pentru desktop din 2010 și interogările Mobile din iulie 2018. Prin urmare, este esențial ca site-urile web să nu livreze. o experiență lentă pentru utilizatori, deoarece Google poate suprima performanța influențând clasamentele sau, mai recent, semnalând utilizatorilor că site-ul dvs. poate fi lent.

Server Push

Server Push permite serverului specific sau rețelei de margine să trimită resurse către clienții web atunci când acestea nu au fost solicitate de client. Pentru a înțelege modul în care funcționează server push, este mai întâi important să înțelegeți modelul cerere-răspuns pe care îl urmează un site web. Un utilizator solicită o pagină de pe un site web, iar serverul răspunde cu conținutul/resursa solicitată.

În mod ipotetic, gândiți-vă la un site care are toate stilurile definite într-o foaie de stil externă numită styles.css. Când utilizatorul solicită scheletul HTML pentru pagină (să spunem în acest caz index.html), serverul push poate „împinge” CSS-ul către utilizator imediat după ce începe să trimită răspuns la index.html.

( S mashing Magazine, Server Push )

Înainte de a înțelege modul în care Server Push poate ajuta la îmbunătățirea vitezei paginii, este important să înțelegeți cum funcționează un browser cu diferite resurse, cum ar fi imagini, CSS și JavaScript, care apar în browserul dvs. Vedeți, browserul trimite instrucțiuni despre cum să descărcați imagini, CSS și resurse JavaScript. Când vizitați prima dată un site web, faceți de obicei o solicitare GET, care este fișierul .html. Odată ce acest fișier .html este primit, browserul îl scanează pentru a-l înțelege și apoi poate face solicitări GET suplimentare, în funcție de ceea ce este conținut în fișierul HTML.

Cum ajută Server Push la îmbunătățirea vitezei paginii?

Prin utilizarea Server Push, numărul de solicitări GET necesare din browser (călătorii dus-întors) este redus și sunt evitate întârzierile în randare care determină creșterea timpului de încărcare a paginii. Acest lucru poate ajuta în mod dramatic la îmbunătățirea timpului de redare pentru clientul web, ceea ce ajută pagina web să apară mai rapid pentru utilizatori, oferindu-le astfel o experiență mult mai bună.

Deși Server Push nu influențează direct modul în care Googlebot vă accesează cu crawlere site-ul sau, într-adevăr, alte crawler-uri, beneficiul SEO este câștigat prin îmbunătățiri ale factorilor centrați pe utilizator, cum ar fi First Paint și First Meaningful Content.

Utilizând Testarea paginii web, Lighthouse, Page Speed ​​Insights și Raportul privind experiența utilizatorului Chrome, puteți determina performanța unui site/pagină în comparație cu concurenții din aceleași industrii. Mai jos sunt două imagini care demonstrează implementarea fără (Imaginea 1) și cu Server Push (Imaginea 2).

(WebpageTest, fără server Push)

(WebpageTest, HTTP/1.1, cu server Push)

Cu server push, serverul poate fi configurat astfel încât să trimită întotdeauna orice componente suplimentare ale paginii (cum ar fi fișiere CSS, JavaScript și imagini) dacă i se cere să trimită peste fișierul .html care le conține.

În cascadele de mai sus putem vedea că push.php folosește patru fișiere CSS.

Fără server push, browserul trebuie să primească fișierul push.php, să analizeze HTML și apoi să facă cereri specifice pentru fiecare fișier CSS suplimentar. Doar odată ce a primit toate fișierele CSS poate începe să le folosească în procesul de randare.

Când serverul push este activat, cererea pentru push.php declanșează automat serverul să trimită cele patru fișiere CSS. Browserul le primește și poate începe să le folosească în procesul de randare mult mai devreme. Aceasta înseamnă că browserul poate începe să redeze conținutul paginii mult mai devreme, ceea ce are ca rezultat valori mai bune privind viteza paginii.

Prioritizare HTTP/2

Prioritizarea HTTP/2 le revine proprietarilor site-ului controlul ordinii în care sunt încărcate resursele. Făcută corect, prioritizarea beneficiază de experiența utilizatorului și de viteza paginii/site-ului prin livrarea resurselor paginii într-o ordine optimizată, creând astfel o experiență de utilizator „rapidă”.

Dacă ne uităm la predecesorul HTTP/2 HTTP/1.1, clientul web controla ordinea când vor fi încărcate resursele. După cum sa discutat mai sus, acest lucru sa datorat faptului că fiecare conexiune TCP a fost capabilă să suporte doar o resursă la un moment dat. Depinde de browser să programeze cereri, hotărând ce resurse să aleagă și câte conexiuni să deschidă în paralel.

Înainte de a înțelege cum se face, este important să înțelegem de ce am dori să folosim prioritizarea pentru resursele noastre.

Dacă avem o imagine în partea de sus a unei pagini și o imagine în partea de jos a paginii, logic am dori să ne asigurăm că imaginea din partea de sus se încarcă înaintea imaginii din partea de jos. Acest concept ajută la demonstrarea importanței și impactului pe care le poate aduce prioritizarea HTTP/2. Prioritizarea HTTP/2 ne permite să specificăm ce resurse trebuie livrate mai întâi și să se încarce înaintea altora (fie că sunt JavaScript, CSS sau imagini), asigurând astfel cel mai rapid timp de încărcare a paginii.

În timp ce browserul poate solicita acum mai multe resurse simultan printr-o singură conexiune TCP folosind multiplexarea, acum poate specifica și informații prioritare cu fiecare solicitare pentru a ajuta la determinarea când/cum ar trebui livrată resursa. Dacă atât serverul, cât și browserul acceptă prioritizarea HTTP/2, browserul ar trebui să definească regulile de prioritizare utilizând lățimea de bandă completă fără a avea resurse în competiție între ele. Pentru a înțelege mai bine cum funcționează procesul de prioritizare, este important să discutăm trei parametri care sunt importanți pentru prioritizarea HTTP/2:

Flux: Acesta este un flux bidirecțional de octeți în cadrul unei conexiuni stabilite care poate transporta unul sau mesaje.

Fluxul părinte: Acesta este un flux de care depind resursele

Fluxul secundar: acesta este un flux dependent de fluxul părinte. Ei au același părinte și, prin urmare, sunt cunoscuți ca flux de copii

Greutate: Acesta este un număr alocat între 1 și 256, care identifică câtă lățime de bandă să alocați fluxului dacă mai multe fluxuri partajează o conexiune. Lățimea de bandă este alocată în raport cu ponderile tuturor celorlalte fluxuri active.

Bit exclusiv: acesta este un semnalizare care indică faptul că fluxul trebuie descărcat fără a partaja lățimea de bandă cu alte fluxuri.

Cadru antet: Aceasta este identificarea fluxului căreia îi aparține

Strat de încadrare binară: Acesta este modul în care mesajele HTTP sunt încapsulate și transferate între client și server

Un exemplu de mai jos demonstrează un exemplu de mai sus:

( Google Developers HTTP/2 Stream Prioritization )

Pentru a efectua prioritizarea HTTP/2, va trebui să adăugați informații de prioritizare în cadrul Antetelor aflat în noul strat de cadru binar HTTP/2. Fluxul părinte și dependența/nondependența de alte fluxuri secundare vor determina prioritatea/ponderea și, prin urmare, livrarea către clientul web a resursei.

Deși prioritizarea HTTP/2 este acum acceptată pe numeroase platforme, multe CDN-uri și furnizori de găzduire nu acceptă prioritizarea HTTP/2. Prin urmare, este important să vă asigurați că utilizați un CDN/furnizor de găzduire care acceptă prioritizarea HTTP/2 dacă doriți să utilizați această tehnică de optimizare. Mai jos este un tabel care descrie ce CDN/găzduire/servere sunt capabile și nu pot accepta prioritizarea HTTP/2.

Prioritizare HTTP/2 - Compatibilitate comună server/gazdă/CDN

Această comparație a fost corectă la 02.01.2020 , dar merită să verificați dacă potențialii furnizori de servicii și-au îmbunătățit compatibilitatea înainte de a vă decide pe care să alegeți.

De asemenea, este important să privim în mod critic anumite browsere, deoarece, din păcate, nu toate browserele acceptă prioritizarea HTTP/2 și prioritizează diferit, deoarece sunt clienți web diferiți. Mai jos este un tabel care descrie ce clienți web sunt capabili să accepte prioritizarea HTTP/2.

Prioritizare HTTP/2 Compatibilitate client web

Prioritizarea HTTP/2 poate îmbunătăți în mod semnificativ percepția utilizatorului asupra vitezei paginii/site-ului și va avea un impact pozitiv asupra datelor acumulate în Raportul privind experiența utilizatorului Chrome. Deși această optimizare nu are niciun impact asupra crawlerelor de căutare, cum ar fi Googlebot, instrumente precum Lighthouse și Page Speed ​​Insights vă vor ajuta să evaluați impactul prioritizării HTTP/2 asupra performanței vitezei paginii din perspectiva unui utilizator.

Configurarea corectă a greutății fluxului atât cu serverul, cât și cu clientul utilizând un CDN/gazdă compatibil HTTP/2, veți putea îmbunătăți drastic valorile de viteză a paginii pentru clientul dvs.

Care sunt premisele pentru HTTP/2

Înainte de a putea profita de avantajele de viteză ale HTTP/2, asigurați-vă că îl puteți utiliza. Există câteva condiții prealabile care trebuie luate în considerare:

  1. Este important să vă asigurați că HTTPS este activat.
  2. Utilizați un certificat TLS de la o autoritate autentificată și activați și instalați certificatul.
  3. Asigurați-vă că software-ul Web Server, cum ar fi Nginx, Apache și IIS, acceptă HTTP/2. O listă completă autentificată pentru asistență poate fi găsită la http://ayi.ma/browsershttp2 , care va afișa compatibilitatea browserului pentru HTTP/2. Dacă sunteți în căutarea suportului HTTP/2 pentru CDN-uri/Găzduire, vă rugăm să consultați http://ayi.ma/serverhosting .

Capcane comune / Lucruri care trebuie să se schimbe odată cu introducerea HTTP/2

Datorită limitărilor protocoalelor anterioare HTTP 1.0 și HTTP 1.1, dezvoltatorii și SEO s-au străduit să găsească modalități de a evita multitudinea de probleme pe care aceste limitări le prezentau pentru performanța și securitatea vitezei paginii.

În cele din urmă, au reușit să găsească „hack-uri” pentru a ocoli unele dintre aceste limitări, dar multe dintre aceste metode au făcut dezvoltatorilor și mai multă muncă. Care sunt unele dintre aceste hack-uri pe care le puteți întreba? Iată câteva dintre cele mai comune hack-uri pe care le veți vedea pe site-uri care pot fi rezolvate prin implementarea corectă a HTTP/2.

Evitați partajarea domeniului

În mod surprinzător, o multitudine de site-uri încă folosesc acest hack, deși au implementat corect HTTP/2. Când HTTP/2 este activat, va fi important să evitați utilizarea fragmentării domeniului. Domain Sharding este tehnica de împărțire a resurselor pe diferite nume de gazdă, permițând astfel deservirea simultană a mai multor resurse.

Datorită protocolului HTTP/2 actualizat, Domain Sharding nu mai este necesară și, de fapt, provoacă mai multe probleme decât rezolvă. Dacă HTTP/2 este configurat și activat corect pentru site-ul dvs. și utilizați, de asemenea, Domain Sharding, contracarați de fapt unele dintre beneficiile HTTP/2, deoarece browserul nu va putea beneficia de multiplexare și descărcări pe mai multe nume de gazdă.

În plus, prin intermediul Domain Sharding, de fapt încalci Stream Prioritization și resursele tale nu vor putea fi încărcate pentru a profita la maximum de Page Speed.

Utilizați corect Server Push

Server Push are câteva dezavantaje de care ar trebui să fii conștient. Server Push poate fi de fapt suprautilizat și ar trebui să fii selectiv când alegi când să-l folosești. Nu doriți neapărat să împingeți prea multe resurse, deoarece acest lucru ar putea determina clientul web să descarce nu numai HTML, ci tot ceea ce este „împins” cu acesta. Aceasta înseamnă că pagina ar putea dura mai mult pentru încărcare și redare (creșterea valorilor centrate pe utilizator, pe care Google se concentrează, cum ar fi Time to Interactive).

O a doua capcană comună pentru împingerea serverului este să descoperi cum să nu împingi resursele pe care clientul web le are deja. Acest lucru poate fi controlat prin numeroase metode. O metodă este să alegeți să nu împingeți resursele către utilizatorii care revin și, prin urmare, să le permiteți utilizatorilor reveniți să-și folosească activele din cache. Aceasta este de departe cea mai ușoară implementare. Acest lucru se poate face pur și simplu verificând antetele cache pentru resurse, asigurându-vă că anteturile nu se suprapun cu implementarea serverului push.

Teste din viața reală sub HTTP/2

Cunoștințele teoretice sunt întotdeauna importante pentru a pune bazele înțelegerii HTTP/2 și a beneficiilor sale. Odată ce conceptele sunt înțelese și înțelese, este important să testați aceste teorii pentru a măsura impactul pe care HTTP/2 îl poate avea asupra Vitezei paginii.

Partea 2 a acestei serii Viteza paginii HTTP/2 în viața reală - folosind teste și analize site-uri web va discuta despre adevăratul beneficiu al HTTP/2 în ceea ce privește viteza paginii și valoarea pentru SEO, așa că nu ratați!

Dar HTTP/3?

Deși HTTP/3 demonstrează un potențial clar ca succesor al protocolului HTTP/2, nu semnalează și nu ar trebui să semnaleze sfârșitul HTTP/2 pentru SEO pe web. Ca și în cazul oricărei noi dezvoltări majore pentru web-ul mondial, acesta va trece printr-o fază normală de lansare și, probabil, va dura timp pentru ca un site să adopte noul protocol și înainte ca acesta să devină un standard de facto în industria SEO. Implementarea HTTP/2 reprezintă încă un câștig benefic și simplu care, atunci când este implementat corect, poate ajuta la îmbunătățirea performanței site-ului dvs.