Mi az a HTTP/2?

1999 óta tavaly először jelent meg új verziója a HTTP-nek. Ez a HTTP/2, mely mára készen áll az alkalmazásra, és sokkal gyorsabb netezést ígér mindenki számára. Mivel a HTTP/2 még sokak számára új, ezért érdemes egy mélyebb pillantást vetni az alkalmazására.

Egy éve, amikor megjelent a szabvány, egy hírben már foglalkoztunk vele, azonban mára egy kicsit előrébb léptünk. Azok számára, akik nem is igazán tudják, hova tegyék a HTTP-t, és mit is jelent ez számukra, a Smashing Magazine összefoglalója alapján a gyökereknél, azaz a HTTP mibenléténél kezdjük.

Mi az a HTTP, az SPDY és a HTTP/2? A Hypertext Transfer Protocol a szerverek és a böngészők közötti kapcsolatot irányítja. 1991-ben jött létre, míg első javított verziója HTTP/1.1 névre hallgatott, és 1999 óta él velünk, de sokáig nem nyúltak hozzá. Pedig akkoriban a weboldalak még nagyon máshogy néztek ki, mint amilyenekkel most futhatunk össze a weben. Elsősorban a weboldalak mérete növekedett meg azóta, így ma egy átlagos weboldal 1,9 MB és több mint 100 egyéni forrás szükséges ahhoz, hogy megjelenjen az oldal a böngészőablakban. Az egyéni forrás alatt olyan elemeket kell érteni, mint egy kép, egy font, egy JavaScript vagy egy CSS fájl. Manapság igen komoly küzdelem folyik a weboldalak sebességének javítása érdekében, és ebbe beletartozik az is, hogy csökkenteni kell a betöltendő elemeknek a számát, méretét, hogy még elfogadható sebességet érjünk el. A HTTP/1.1 nem igazán teljesít jól, amikor a mai követelményeknek kell megfelelnie.

Már 2009-ben két mérnök a Google-től bejelentette, hogy dolgoznak egy SPDY névre hallgató kutatási projekten, ami kiküszöböli a HTTP/1.1 néhány hiányosságát, és azóta már itt-ott használják is. Ennek az egyik legkomolyabb előnye az úgynevezett multiplexing, vagyis, hogy párhuzamosan több lekérés kiszolgálását is lehetővé teszi egyetlen TCP kapcsolaton keresztül. Emellett a böngészők priorizálhatják, hogy mi az, amit a legfontosabbnak tartanak egy weboldal megjelenítésénél. Csökkenti a HTTP header méretét és azok számát, valamint megjelenik a server push, vagyis, hogy a szerverek a legfontosabb elemeket már azelőtt elküldik a böngészőnek, hogy az lekérné őket. Ami még fontos, hogy mindehhez titkosított, azaz HTTPS kapcsolat szükséges a szerver és a böngésző között. Az SPDY egyébként nem váltotta le a HTTP-t, inkább egy csatornát jelentett a protokollban és megváltoztatta azt a módot, ahogy a lekérések és a válaszok küldésre kerülnek. Ehhez támogatást igényelt mind a szerver, mind pedig a böngészők részéről. Ez ma már nem gond, a NGINX fel van készítve rá, és az Apache esetében is elérhetők a megfelelő csomagok a Google-től, ahogy a böngészők minden modern verziója is támogatja. Kivételt a Microsoft Edge jelent, mely az IE 11-től eltérően nem támogatja az SPDY-t. Támogatja viszont a HTTP/2-t, vagyis a HTTP protokoll legújabb verzióját.

Az SPDY-támogatás egyébként a Chrome-ból is ki fog kerülni még az idei évben, és valószínűleg a többi böngésző is követi ezt a lépést. Ugyanakkor a HTTP/2-t már a Firefox, a Chrome és az Opera is támogatja, valamint a Safari a 9-es verziótól. Itt az ideje tehát, hogy ejtsünk pár szót a HTTP/2 lényegéről is. Ez a protokoll-verzió tulajdonképpen azt viszi tovább, amit az SPDY már tudott. Habár ennél nem követelmény a HTTPS kapcsolat megléte, a böngészők csak TLS (HTTPS) esetében támogatják a HTTP/2-t. Ez pedig azt jelenti, hogy csak akkor kezdhetsz gondolkodni a HTPP/2-re való váltáson, ha már HTTPS kapcsolattal elérhető a weboldalad. 2015 februárjában véglegesítették a HTTP/2 szabványt, így egy év elteltével a támogatás a legfrissebb verziójú böngészőkben már adott, ahogy a szervereknél is fokozatosan megtörténik a bevezetés. A W3Techs 2015 júliusában már közölt egy statisztikát a bevezetés gyorsaságáról, akkor azért még jócskán voltak elmaradások, de azóta sok idő eltelt.

Kötelező az átállás? Mivel a HTTP/2 visszafelé kompatibilis a HTTP/1.1-gyel, így semmi gondot nem okoz, ha valaki egyáltalán nem foglalkozik a dologgal, és nem eszközöl módosításokat a weboldala esetében. Minden ugyanúgy fog működni, ahogy eddig is. A felhasználók sem fogják észrevenni, hogy HTTP/1.1-en, SPDY-on vagy épp HTTP/2-n érnek el bizonyos oldalakat. Csak egyetlen dolog fog feltűnni, amikor egyre több weboldal vált HTTP/2-re, hogy a Te oldalad valahogy sokkal lassabb lesz, mint a többieké. Ahhoz, hogy Te is átállhass a HTTP/2-re, először is arra lesz szükség, hogy a szerver-szoftver támogassa már ezt a protokollt. Ezzel csak az a probléma, hogy ezt nem Te határozod meg, hanem a hosting-szolgáltatód. Mielőtt a weboldaladon változatásokat eszközölnél, annak a kérdésnek is érdemes egy pár percet szentelni, hogy a felhasználóid olyan böngészőket használnak-e már, mely támogatja az új protokollt. Azok számára, akiknek a felhasználói a legújabb böngészőkkel nézik a weboldalát, nyilván érdemes lenne minél hamarabb lépni az ügyben.

A weboldalak számára az egyik legnagyobb problémát az átállás kapcsán nem is az jelenti, hogy váltani kell HTTP/2-re, hanem sokkal inkább az, hogy ehhez alapvető követelmény a biztonságos kapcsolat, azaz a HTTPS. Új weboldalaknál érdemes már eleve ezzel indítani, illetve régi weboldalak esetén a redesign során meglépni a váltást. Ez egyébként azért is hasznos, mert a Google is előnyben részesíti már a találati oldal kialakításánál a HTTPS kapcsolatú oldalakat, vagyis ezeket választja, ha adott egy oldalból HTTP és HTTPS verzió is, ráadásul a böngészők jelezni fogják külön, ha egy weboldal kapcsolata nem biztonságos, valamint a jövőben jó pár fontos HTML5-funkció sem lesz elérhető, csak biztonságos kapcsolaton keresztül. A lényeg tehát az lenne, hogy ha a Te weboldalad is HTTP-t használ, akkor az első lehetséges alkalommal állj át HTTPS-re, majd utána valamikor érdemes váltanod HTTP/2-re!

Képek, CSS, JS és a HTTP-lekérések száma HTTP/2-nél A HTTP/1.1 esetben a böngészőnek egyszerűbb egy nagy képfájlt megjelenítenie, mint sok kicsit, a sok lekérés miatt. Ezért célszerű ezeket a kis fájlokat egy sprite fájlba rendezni. Ez ugyanis egyetlen HTTP-lekérést jelent, így megelőzi a sok lekérés okozta problémát. Ugyanakkor, ha egy felhasználónak valamely oldalon mindössze egyetlen kis képet kell megjeleníteni, ahhoz is az egész sprite fájlt le kell tölteni. A HTTP/2 esetében azonban ez már nem probléma a korábban is említett multiplex-képesség miatt. A legtöbb esetben a kis képek egyéni megjelenítése jobb eredményt hoz majd, a felhasználóknak pont azt a képet kell megjeleníteni, ami az általuk meglátogatott weboldal megtekintéséhez szükséges. Ugyanakkor a sprite-ok használata sem elvetendő egyes esetekben, hiszen bizonyos képek sprite-okba rendezésével jobb tömörítés érhető el, így a letöltési méret kisebb lesz. Elsősorban tehát akkor érdemes használni a sprite fájlokat, ha a képek mind a letöltendő oldalon szerepelnek. Ugyanakkor az kijelenthető, hogy a HTTP/2 esetében már nem minden esetben a sprite a lehető legjobb megoldás.

A CSS-ek és a JavaScript fájlok esetében ugyanez a helyzet, tehát ezek összefűzése csökkenti a HTTP-lekérések számát. Ugyanakkor ez a megoldás gyakran azzal jár, hogy a felhasználóknak akkor is le kell tölteni az összes CSS-t és JS-t, ha a legtöbbet soha nem fogják használni. Természetesen a dolgot lehet optimalizálni a fájlok megfelelő elrendezésével, ez azonban elég sok munkával jár. További probléma ezekkel az összefűzésekkel, hogy ilyenkor egyszerre ürülnek ki a fájlok a cache-ből. Nem tudod megtenni, hogy egyes fájlok esetében soha ne változzon a hosszú lejárati idő, miközben a kód gyakran változó részeinél rövidebb lejáratot határozol meg. Mindegyik le fog járni, még ha csak a CSS egyetlen sora, egyetlen oldalon is megváltozik. De mivel a HTTP-lekérések már nem jelentenek gondot a HTTP/2 esetében, sokkal egyszerűbbé válik a CSS és JavaScript elrendezése is. Elég lesz csak annyit betölteni a kódból, amennyire a felhasználónak szüksége van, nem fog számítani, hogy sok-sok kis stíluslapot kell letölteni. Az alapján érdemes majd szervezni ezeket a fájlokat csoportokba, hogy milyen gyakran változnak.

Emellett a HTTP/1.1 esetében korlátozott a nyitott kapcsolatok száma. Amennyiben nagy a források száma, akkor megoldás lehet, hogy többféle domain alól kérjük le őket. A domain sharding használatával jobb letöltési idők érhetők el, ami azonban önmagában is problémát okozhat, nem beszélve arról, hogy ez milyen munkával jár. A HTTP/2 esetében nincs szükség erre a megoldásra, mivel a lekérések számának nincs korlátja. Sőt, a sharding használata rontja a teljesítményt, mivel további TCP kapcsolatokat igényel és megakadályozza a HTTP/2-t abban, hogy priorizálja a forrásokat. Hogyan készülj elő a HTTP/2-re? Ha épp elindítasz egy projektet, mely terveid szerint hosszú távú lesz, akkor érdemes előkészületeket tenned a HTTP/2-re való átállásra, még ha azt jelen pillanatban egyelőre nem teszi lehetővé a szervertámogatás hiánya. Az egyik dolog, hogy ha sprite-okat használsz, akkor készítsd el az oldal-specifikus vagy sprite-ok nélküli megoldást, így könnyebb lesz a váltás a nagy sprite-okról. Ugyanez a helyzet a data URI-kkal is, melyeket ha használsz a CSS-edinél, akkor a képeket készítsd fel a váltásra, amikor már nem fogod ezeket használni. A CSS-ek és JavaScriptek összefűzésénél jobb teljesítményt érsz el HTTP/2 alatt a források megfelelő elrendezésével az egyetlen fájl helyett. Vagyis csak azok a fájlok töltődjenek be valamely oldal letöltésénél, amire az oldal megjelenítéséhez éppen szükség van. Ha már most ennek figyelembe vételével fejlesztesz, az később kifizetődő lesz számodra.

A HTTP/2-ről összességében elmondható, hogy teljesen más megoldásokat kell majd alkalmaznod, mint amit megszoktál HTTP/1.1 alatt. Az új protokoll visszaadja az irányítás nagy részét a kezedbe, ami azt is jelenti, hogy minden egyes projektnél szükség lesz új döntések meghozatalára. Sok dolog nem került most szóba, amivel szintén foglalkoznod kell majd, ilyen például a szerver push lehetősége, melynek révén eldöntheted majd, hogy mely források kapnak prioritást, és utasíthatod a szervert, hogy ezeket előbb töltse be, mint a kevésbé fontos dolgokat. Az ehhez kapcsolódó megoldások a későbbiekben alakulnak még, így érdemes figyelni az egyre szaporodó gyakorlati példákat és felhasználni a tapasztalatokat.

Mikor válts HTTP/2-re? Azon esetekben, amikor a szerverek felett nem Te gyakorlod a felügyeletet, a váltással várhatsz egészen addig, míg a szerverek készen nem állnak a HTTP/2-re. Persze már vannak olyan hosting-szolgáltatók, ahol felkészültek a HTTP/2-re, így ha előnye származik egy weboldalnak a váltásból, akkor meg kell tenni. Kérdés, hogy az adott weboldal felhasználóinak többsége készen áll-e rá, azaz alkalmas-e böngészőjük a HTTP/2 használatára. Mivel a HTTP/2 visszafelé kompatibilis, így a weboldalaknak nem muszáj bármit tenniük az átállás érdekében. Csak ahogy már korábban is említettük, optimalizálás hiányában lényegesen lassabb lesz a weboldal, mint a konkurenciáé. Érdemes tehát figyelni az analitikai adatokat, és ha azt látod, hogy a felhasználóid többség már HTTP/2-képes böngészőt használ, akkor itt az idő a váltásra. Ez a legtöbb esetben egyébként már most is így van, így ez nem akadály. Különösen fontos lenne lépni akkor, hogy nagy a mobilról érkező forgalmad. Ha pedig éppen most készítesz egy új weboldalt, akkor már mindenképpen érdemes a fejlesztés során HTTP/2-re optimalizálni, még akkor is, ha az indulásnál HTTP/1.1-et fogod használni a szerver-támogatás hiánya miatt, és emiatt kompromisszumokra kényszerülsz.

Röviden összefoglalva tehát úgy néz ki a folyamat: Válts biztonságos kapcsolatra már most! Készülj fel a HTTP/2-re a fejlesztés során! Figyeld az analitikát! Ellenőrizd a hosting-szolgáltatód készültségét! Végül váltsd le a korábbi megoldásokat a HTTP/2-nél megfelelőekre!