Pregătirea pentru HTTP2: un ghid pentru designeri și dezvoltatori web

Protocolul de transfer hipertext (HTTP) este protocolul care guvernează conexiunea dintre serverul dvs. și browserele vizitatorilor site-ului dvs. Pentru prima dată din 1999, avem o nouă versiune a acestui protocol și promite site-uri web mult mai rapide pentru toată lumea.

În acest articol, ne vom uita la elementele de bază ale HTTP2, așa cum se aplică designerilor și dezvoltatorilor web. Voi explica câteva dintre caracteristicile cheie ale noului protocol , voi analiza compatibilitatea browser-ului și serverul și voi detalia lucrurile la care ar putea trebui să vă gândiți pe măsură ce vom vedea mai multă adoptare a HTTP2.

Citiți suplimentare despre Smashing:

• Preîncărcare: La ce este bun?
• Tot ce trebuie să știți despre AMP
• Îmbunătățirea performanței Smashing Magazine

Citind acest articol, veți obține o imagine de ansamblu asupra a ceea ce trebuie să luați în considerare modificarea fluxului dvs. de lucru pe termen scurt și lung. De asemenea, voi include o mulțime de resurse dacă doriți să explorați mai mult problemele ridicate. Scopul meu este să vă ofer suficient de fond pentru a putea lua decizii bune în timp ce vă planificați trecerea la HTTP2.

O scurtă istorie a HTTP

HTTP este un protocol vechi, definit inițial în 1991, cu ultima revizuire majoră — HTTP/1.1 — publicată în 1999. Site-urile web din 1999 erau foarte diferite de site-urile web pe care le dezvoltăm astăzi. În http2 explicat , Daniel Sternberg observă că cantitatea de date necesară acum pentru a încărca pagina de pornire a unui site web mediu este de 1,9 MB, cu peste 100 de resurse individuale necesare pentru a afișa o pagină - o „resursă” fiind orice dintr-o imagine sau un font într-un fișier JavaScript sau CSS.

HTTP/1.1 nu funcționează bine atunci când recuperează numărul mare de resurse necesare pentru afișarea unui site web modern. După cum vom vedea mai târziu în acest articol, multe dintre cele mai bune practici de performanță pe care le cunoaștem în calitate de dezvoltatori web provin din gestionarea limitărilor HTTP/1.1.

SPDY

În 2009, doi ingineri de la Google au postat despre un proiect de cercetare la care lucrau, numit SPDY. Acest proiect a abordat unele dintre problemele din HTTP/1.1. SPDY și-a propus:

• permite cereri concurente printr-o singură conexiune TCP, cunoscută sub numele de multiplexare ;
• permite browserelor să prioritizeze activele, astfel încât resursele vitale pentru afișarea unei pagini să poată fi trimise mai întâi de către server;
• comprimați și reduceți anteturile HTTP;
• implementați server push , prin care un server poate împinge resurse vitale către browser înainte de a fi solicitat pentru ele.

În plus, SPDY necesită o conexiune criptată (HTTPS) între browser și server.

SPDY nu înlocuiește HTTP; mai degrabă, este un tunel pentru protocol și modifică modul în care sunt trimise cererile și răspunsurile HTTP existente. Necesită suport atât de la server, cât și de la browser care se conectează la acel server. Cu suportul disponibil în NGINX și pachetele disponibile de la Google pentru a activa asistența în Apache, a existat o cantitate rezonabilă de adoptare a SPDY. Suportul pentru browser este, de asemenea, destul de bun, cu versiunile moderne ale tuturor browserelor majore care îl acceptă.

HTTP2

Am văzut că SPDY se bucură de un oarecare succes, câștigând adoptarea atât cu servere, cât și cu browsere. Cu toate acestea, este posibil să fi observat și că, în ciuda faptului că Internet Explorer 11 este acceptat, browserul Microsoft Edge l-a renunțat. Ce se intampla aici?

Suportul pentru SPDY a fost renunțat în Edge din cauza implementării de către Microsoft a suportului pentru HTTP2, cea mai recentă versiune a protocolului HTTP. În timp ce alte browsere actuale încă mențin suport pentru SPDY, Chrome va elimina suportul în 2016, iar alte browsere vor urma probabil. La momentul scrierii, Edge, Firefox, Chrome și Opera acceptă atât SPDY, cât și HTTP2. Safari, inclusiv pe iOS, se va alătura acestui grup mai târziu în acest an, odată cu lansarea Safari 9.

HTTP2 se bazează pe succesul SPDY, care a fost folosit ca punct de plecare pentru noul protocol. Ca atare, majoritatea obiectivelor SPDY sunt îndeplinite în HTTP/2. Cerința pentru o conexiune HTTPS a fost eliminată. Acestea fiind spuse, toți furnizorii de browsere au decis să implementeze numai HTTP2 pentru conexiunile TLS (https). Deci, deși ați putea utiliza HTTP/2 cu text clar în comunicațiile server-server, cazul nostru de utilizare a serviciului HTTP2 către browsere înseamnă că trebuie să aveți site-ul dvs. să ruleze pe https înainte de a vă putea gândi să treceți la HTTP2.

Specificația HTTP2 a fost finalizată în februarie 2015; un an mai târziu, suportul pentru browser în browserele moderne este excelent. Ca și în cazul SPDY, HTTP2 necesită suport atât la nivel de browser, cât și la nivel de server și există deja multe implementări de server web. Puteți urmări acestea pe wiki HTTP/2. W3Techs are și o postare din iulie 2015 care detaliază ratele de adoptare. Adoptarea acestui protocol are loc rapid, având în vedere cât de relativ nou este.

Va trebui să ne schimbăm site-urile web?

HTTP/2 este compatibil invers cu HTTP/1.1 , așa că ar fi posibil să îl ignorați complet și totul va continua să funcționeze ca înainte. Modificarea protocolului este complet transparentă pentru utilizatori. Mulți cititori ai acestui articol vor fi folosit de ani de zile un alt protocol decât HTTP/1.1. Dacă aveți un cont Gmail și utilizați Chrome pentru a-l accesa, veți fi folosit SPDY și apoi HTTP/2 fără să știți nimic despre el.

Cu toate acestea, multe dintre lucrurile pe care le considerați cele mai bune practici pot fi dăunătoare performanței sub HTTP/2. De-a lungul timpului, pe măsură ce mai multe servere se actualizează pentru a utiliza HTTP/2 și mai multe persoane au browsere care acceptă HTTP/2, site-ul dvs., la un moment dat bine optimizat conform celor mai bune practici, va începe să pară mai lent decât site-urile web optimizate pentru noul protocol.

Ce trebuie să schimbăm pentru a îmbrățișa HTTP/2?

În restul acestui articol, ne vom uita la unele dintre cele mai bune practici comune care vor deveni anti-modele odată cu adoptarea HTTP/2 . După cum am văzut, tranziția va fi una lentă pentru multe site-uri web. Pentru a trece la HTTP/2, software-ul serverului dvs. va trebui actualizat pentru a accepta protocolul - ceea ce poate fi ușor sau aproape imposibil, în funcție de modul în care sunteți găzduit.

Înainte de a face modificări site-ului dvs. în mod specific pentru HTTP/2, va trebui, de asemenea, să vă gândiți dacă vizitatorii dvs. tind să aibă browsere care îl acceptă. Proprietarii de site-uri web care atrag o mulțime de oameni care folosesc browsere foarte actualizate vor putea face această schimbare mai devreme decât proprietarii ale căror jurnale arată majoritatea utilizatorilor pe browsere mai vechi. Pentru a reflecta acest lucru, vă voi oferi și câteva sugestii despre cum să lucrați în această perioadă de tranziție.

Efectuați mutarea la TLS

Pentru multe site-uri, cel mai greu lucru despre trecerea la HTTP/2 poate să nu fie deloc HTTP/2, ci, în schimb, cerința de a rula site-ul printr-o conexiune sigură. Dacă dezvoltați un site nou sau actualizați unul vechi, prima dvs. mișcare ar trebui să fie să vă asigurați că vă lansați sau treceți la https cât mai curând posibil. Acest lucru este important nu doar pentru HTTP/2, Google folosește conexiuni securizate ca semnal de clasare, iar browserele încep să semnaleze site-urile non-https ca „nesecurizate”. În viitor, veți descoperi că unele funcții HTML5 puternice, cum ar fi localizarea geografică, nu sunt disponibile fără o conexiune sigură.

Dacă aveți un site care în prezent este doar http, atunci sugestia mea ar fi să prioritizați mai întâi o mutare la https și apoi să decideți asupra strategiei dvs. HTTP/2.

Transformarea mai multor fișiere imagine în sprites

În HTTP 1.1, preluarea unei imagini mari este mult mai eficientă pentru browser decât a face o mulțime de solicitări pentru cele mici. Acest lucru se datorează faptului că cererile multiple stau în coadă una în spatele celeilalte. Pentru a rezolva acest lucru, am fost sfătuiți să transformăm pictogramele noastre mici într-un fișier sprite.

Sprite-ul rezultat este returnat cu o singură solicitare HTTP, prevenind problema punerii în coadă a mai multor solicitări. Cu toate acestea, chiar dacă vizitatorul se află pe o pagină care arată doar una dintre acele pictograme, va trebui totuși să descarce un fișier mult mai mare decât este necesar pentru a vedea acea imagine.

Cu capacitatea de multiplexare a HTTP/2 , această așteptare a resurselor nu mai este o problemă. Servirea individuală a imaginilor mici va fi mai bună în multe cazuri; va trebui să difuzați doar ceea ce este necesar pentru pagina pe care se află vizitatorul. Crearea unui sprite va fi în continuare garantată în unele cazuri; Solicitările HTTP sunt doar un aspect al performanței. Combinarea unor imagini împreună într-un sprite ar putea obține o compresie mai bună și, prin urmare, o dimensiune de descărcare mai mică, în general, mai ales dacă toate acele imagini sunt utilizate pe pagina care este încărcată. Cu toate acestea, nu va mai fi cazul ca un sprite să fie întotdeauna cea mai bună alegere.

Alinierea imaginilor folosind URI-uri de date

O altă soluție pentru problema multiplelor solicitări HTTP în HTTP/1.1 este introducerea imaginilor în CSS folosind URI-uri de date. Încorporarea imaginilor în acest fel va face o foaie de stil mult mai mare. Dacă ați combinat acest lucru cu o altă tehnică de optimizare pentru concatenarea activelor, atunci un vizitator va descărca probabil tot acest cod, chiar dacă nu vizitează niciodată paginile în care sunt folosite imaginile.

Întrucât solicitările HTTP sunt foarte ieftine în HTTP/2, această „cea mai bună practică” va împiedica mai degrabă decât să ajute performanța.

Concatenarea CSS și JavaScript

Ca pas final în procesul nostru de construire, mulți dintre noi vom concatena toate fișierele mici CSS și JavaScript utilizate pe site-ul nostru. Adesea, dorim să le păstrăm separate în timp ce dezvoltăm pentru a facilita gestionarea acestor resurse - dar știm că livrarea unui fișier în browser este mai eficientă pentru performanță decât livrarea a cinci. Încă o dată, încercăm să limităm solicitările HTTP.

Dacă faceți acest lucru, atunci un vizitator care ajunge pe pagina dvs. de pornire ar putea descărca toate CSS și JavaScript necesare pentru site-ul dvs., chiar dacă nu le folosește niciodată. În calitate de dezvoltator, puteți ocoli această problemă selectând și incluzând cu atenție fișiere specifice pentru fiecare zonă a site-ului web în procesul dvs. de construire, dar asta poate fi destul de multă muncă.

O problemă suplimentară cu concatenarea este că totul va trebui să fie curățat dintr-o dată din cache. Nu puteți da unor fișiere care nu modifică niciodată o dată de expirare lungă, oferind în același timp părților care se schimbă adesea din baza de cod o dată mai scurtă. Totul trebuie să expire dacă chiar și o linie de CSS, folosită pe o singură pagină, este schimbată.

Îmi imaginez că vezi unde se duce asta! Solicitările HTTP sunt ieftine în lumea HTTP/2 . Organizarea activelor dvs. în timpul dezvoltării în funcție de paginile pe care vor fi utilizate va fi mult mai bună. Apoi puteți furniza doar codul de care are nevoie vizitatorul. Descărcarea multor foi de stil minuscule nu va conta. De asemenea, vă puteți organiza în funcție de cât de des se schimbă lucrurile; activele cu longevitate ar putea fi apoi îngrijite mai mult timp.

Împărțirea resurselor între gazde: Sharding

Cu HTTP/1.1, sunteți limitat la numărul de conexiuni deschise. Dacă încărcarea unui număr mare de resurse este inevitabil, o metodă de a ocoli această restricție este să le preluați de pe mai multe domenii. Acest lucru este cunoscut sub numele de fragmentare a domeniului. Acest lucru poate obține timpi de încărcare mai buni, dar poate cauza probleme în sine, ca să nu mai vorbim de cheltuielile de dezvoltare legate de pregătirea acestui site pentru site-ul dvs.

HTTP/2 elimină această necesitate pentru fragmentarea domeniului , deoarece puteți solicita atâtea resurse câte aveți nevoie. De fapt, această tehnică va afecta probabil performanța, deoarece creează conexiuni TCP suplimentare și împiedică HTTP/2 să prioritizeze resursele.

Cum să vă pregătiți pentru HTTP/2 acum

Dacă începeți un proiect despre care vă așteptați să aibă o oarecare longevitate, dar nu poate lansa HTTP/2, poate din cauza suportului de server, ar merita să vă gândiți cum vă puteți pregăti pentru HTTP/2. Ați putea adăuga câteva lucruri la procesul de construcție acum, care vor face schimbarea mai ușoară mai târziu.

Creați active individuale pe lângă Sprite-uri și URI-uri de date

Dacă creați sprite-uri, adăugați la procesul dvs. crearea și optimizarea acelor active individuale, sau sprite-uri mai mici specifice paginii, dacă credeți că performanța ar fi îmbunătățită cel mai bine de acestea. Acest lucru vă va face mai ușor să treceți de la sprite-uri mari la sprite-uri mici (sau fără) atunci când este atins punctul de vârf pentru site-ul dvs.

Același lucru este valabil și pentru URI-urile de date. Dacă le utilizați în prezent în CSS-ul dvs., aveți imaginile pregătite pentru atunci când renunțați la această tehnică.

Organizați-vă activele în funcție de secțiunea site

Cu concatenarea CSS și JavaScript, există o tentație de a optimiza pentru ușurința dezvoltării, deoarece fișierele vor fi zdrobite oricum. Când treceți la HTTP/2, veți obține cea mai bună performanță gestionând cu atenție resursele, astfel încât doar lucrurile necesare unei anumite pagini să fie livrate către pagina respectivă. Prin urmare, începerea acum să-ți organizezi dezvoltarea în acest fel va da roade. Deocamdată, s-ar putea să vă concatenați în continuare și, când este atins punctul de vârf, puteți opri acea parte a procesului de construcție și puteți servi resursele în mod individual.

Gestionați partajarea domeniului

Cea mai bună practică actuală pentru HTTP/1.1 este de a limita sharding-ul la două nume de gazdă. Există o modalitate de a obține HTTP/2 să unească conexiunile, dacă certificatul TLS este valabil pentru ambele gazde și gazdele se rezolvă la același IP. Deoarece implementatorii browserului necesită ca HTTP/2 să ruleze prin HTTPS, este necesar ca certificatul TLS să ruleze peste HTTP/2. Vezi mai multe pe slide-ul 26 al slidedeck-ului lui Ilya Grigorik de la Conferința Velocity.

Urmeaza

În cele din urmă, vom obține o mulțime de bune practici pentru HTTP/2. Pentru o performanță optimă, acest protocol vă va reda mult control, ceea ce înseamnă că va trebui să luați decizii pentru fiecare proiect. Nu am tratat în acest articol cum să profit de noile funcții ale HTTP/2, cum ar fi server push. Această tehnologie vă permite să decideți care resurse sunt prioritare și instruiește serverul să le distribuie înaintea lucrurilor mai puțin importante.

Când să comutați?

Pentru designerii și dezvoltatorii care nu au control total asupra serverelor pe care le implementează, decizia poate fi nevoită să aștepte până când serverele pe care le folosesc sunt actualizate. Există companii de găzduire care oferă deja HTTP/2 - chiar și pentru găzduire partajată - așa că implementarea pe un server de suport este ceva pe care l-ați putea recomanda unui client dacă știți că ar beneficia.

Odată ce site-ul dvs. este găzduit pe un server care acceptă HTTP/2, decizia de a continua optimizarea pentru HTTP/1.1 sau de a optimiza pentru HTTP/2 se va rezuma la protocolul acceptat de majoritatea utilizatorilor dvs. . Amintiți-vă că HTTP/2 este compatibil cu versiunea inversă - nu trebuie să faceți nimic specific. Decizia pe care trebuie să o iei este când să o optimizezi.

Va trebui să decideți în funcție de datele dvs. de analiză. Dacă mai mulți vizitatori folosesc browsere care acceptă HTTP/2 decât nu, atunci aș sugera că acesta este un punct de basculanță rezonabil pentru optimizare pentru acești utilizatori. Mulți dintre noi am ajuns deja la acel punct. Ar trebui să utilizați date de pe site-uri precum Can I Use împreună cu datele culese din propriile analize și cunoștințele despre publicul dvs. probabil. De exemplu, multe dintre beneficiile HTTP/2 vor fi resimțite cel mai mult de utilizatorii HTTP/2 care acceptă dispozitive mobile. Dacă aveți un procent mare de trafic mobil, aceasta ar putea fi un indiciu să treceți mai devreme la HTTP/2. Cu toate acestea, dacă aveți un procent mare de trafic mobil de la utilizatorii care navighează folosind Opera Mini, atunci acesta ar fi un motiv pentru a renunța la trecerea la HTTP/2, deoarece în prezent nu are suport, în timp ce are un număr mare de utilizatori în unele părți ale lumii.

Dacă construiți un site web nou-nouț astăzi, vă sugerez să țineți cont de optimizarea HTTP/2 pe tot parcursul construcției. Dacă la lansare, simțiți că trebuie să faceți concesii pentru HTTP/1.1 din cauza suportului pentru browser sau server, multe din acestea pot fi făcute în procesul de construire, permițându-vă să treceți la versiunea HTTP/2 de îndată ce simțiți timpul este potrivit.

Planul dvs. de acțiune HTTP/2

1. Lansați cu o conexiune sigură sau treceți la TLS acum Aceasta ar trebui să fie prioritatea dvs.
2. Pregătiți-vă pentru HTTP/2 în procesul de compilare. Orice site web pe care îl construiți acum ar beneficia probabil de a fi optimizat pentru HTTP/2 pe durata de viață. Utilizați sfaturile de mai sus pentru a crea un proces de compilare care poate fi optimizat pentru ambele protocoale.
3. Verificați-vă statisticile. Comparând utilizarea browserului pe site-ul dvs. cu tabelul de asistență din Can I Use, puteți vedea ce procent de vizitatori ar beneficia de optimizarea HTTP/2.
4. Verificați-vă găzduirea. Când ajungeți la punctul în care ați beneficia de schimbare, va trebui să vă asigurați că serverul dvs. acceptă HTTP/2. Discutați cu furnizorul dvs. de găzduire sau cu administratorul serverului pentru a afla planul lor de migrare.
5. Lansați optimizarea HTTP/2. Odată ce serverul dvs. acceptă HTTP/2, restul depinde de dvs. Nu mai utilizați cele mai bune practici vechi și treceți la cele noi. Acest lucru va însemna că utilizatorii cu browsere care nu acceptă HTTP/2 vor avea o experiență mai lentă, motiv pentru care driverul din spatele modificării dvs. ar trebui să fie punctul de basculanță în care majoritatea ar beneficia.

Când treceți la HTTP/2, ar fi interesant să evaluați creșterile de viteză și să vedeți care tehnici au făcut cele mai mari diferențe pe site-urile dvs. web. Aștept cu nerăbdare să văd informații din cazuri reale pe măsură ce oamenii migrează site-uri web. Aceste informații ne vor ajuta să dezvoltăm o nouă generație de bune practici.

Află mai multe

O cantitate din ce în ce mai mare de informații despre HTTP/2 este disponibilă online. Am enumerat câteva resurse aici pentru referință, multe dintre ele la care am făcut referire în timp ce scriam acest articol.

• „Hypertext Transfer Protocol Version 2 (HTTP/2)” (specificație), Internet Engineering Task Force Acesta este destinat persoanelor cărora le place să citească specificațiile sau care trebuie să înțeleagă punctele mai fine. Pentru toți ceilalți, întrebările frecvente HTTP/2 sunt un rezumat excelent al principalelor caracteristici.
• http2 explicat , Daniel Sternberg Această carte electronică gratuită merită citită dacă doriți să explorați detaliile protocolului în timp ce vă planificați strategia.
• Rețea de browser de înaltă performanță , Ilya Grigorik, O'Reilly Această carte acoperă atât cele mai bune practici HTTP/1.1, cât și HTTP/2. Ar fi util pentru oricine dorește atât să îmbunătățească performanța astăzi, cât și să se pregătească pentru viitor.
• „HTTP/2 este aici, să optimizăm” (slidedeck) Ilya Grigorik Acest set excelent de diapozitive conține mai multe informații despre unele dintre punctele abordate în acest articol.
• Indicator HTTP/2: Firefox și Chrome Acest plugin de browser vă spune dacă site-ul web pe care vă aflați este difuzat prin HTTP/2.
• Pentru mai multe lecturi, vedeți această listă uriașă de link-uri organizată de Rebecca Murphey.