Webshark Blog

2015-ben 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. 

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.

A HTTP/2-ről egyszerűbben

Miután beszéltünk a szabványok fejlődéséről, most lássuk, hogy mit is tud a gyakorlatban a HTTP/2. Onnan induljunk ki, hogy amikor rákattintasz egy linkre egy weboldalon, akkor egy kérést kap a szerver. A szerver erre válaszol egy státuszüzenettel és az adott oldal fájllistájával. A böngésző ezután elkezdni lekérni a fájlokat.

A régi, azaz HTTP1.1-es protokoll esetében ez meglehetősen lassan zajlott, mivel egyesével mentek át a fájlok, és csak egyetlen vonalat használt az átvitelre úgy, hogy minden fájl esetén újra nyitotta és zárta azt. A HTTP/2 ezt a folyamatot felgyorsítja azzal, hogy folyamatosan nyitva tartja a vonalat és egyszerre jóval nagyobb adag áramlását biztosítja.

A Yoast által felhozott példa világítja meg talán a legjobban a működésbeli különbségeket: amikor van egy doboz Legód, akkor úgy állsz neki, hogy nézed az instrukciókat. Ez általában úgy épül fel, hogy tégláról-téglára, egyesével bemutatja, mit hova rakj. Vagyis egy időben egyetlen elemmel foglalkozol. Amikor azt elhelyezted, újra rátekintesz a leírásra, és megnézed, hogy a következő elemet hova kellene tenned. Ha mondjuk több ezer elem van a dobozodban, akkor ez a folyamat elég sokáig fog tartani. A HTTP1.1 valahogy így működik.

Ezzel szemben a HTTP/2-nél úgy történne, hogy egy nagyobb résznek tudod lekérni az összeállítási útmutatóját, és anélkül tudsz instrukciókat kapni az újabb elemek elhelyezéséhez, hogy rá kellene nézned az útmutatóra. Ha igazán gyors akarsz lenni, akkor akár az összes elemet lekérheted egyszerre, és egyből összeállíthatod a Legódat.

A lényeg tehát az, hogy a HTTP/2 egyszerre több dolgot tud kezelni: egy időben több lekérés történik egy – az átvitel során – folyamatosan nyitott kapcsolaton. Ez a legfontosabb a gyorsabb működés szempontjából. Ugyanakkor egy másik fontos dolog az úgynevezett szerver push: itt is egy lekéréssel indul a folyamat, azonban amikor a szerver észleli, hogy a HTML-nek további dolgokra van szüksége, akkor kérés nélkül küldi ezeket.

SEO szempontból elsősorban azért jó a HTTP/2, mert a weboldalsebesség rangsorolási tényező már évek óta. A mobil index indulásával pedig még fontosabbá vált. Miközben a weboldalak várhatóan csak egyre nagyobbak lesznek. A nagy weboldalak pedig sok elemből állnak: HTML, JavaScript, CSS, képek, stb. Ez pedig csak növeli a betöltési időt.

Egy másik fontos dolog a késleltetés, elsősorban a mobileszközöknél. Minél nagyobb a késleltetés, annál több idő, hogy egy kérést megkapjon a szerver, majd erre küldjön egy választ. Ez az oka annak, hogy érdemes CDN-t használni. Ezáltal csökkenthető az idő azok számára, akik egy közeli pontból neteznek.

Emellett persze vannak még további lehetőségek a szerverek finomhangolására a weboldalsebesség javítása érdekében, de a HTTP1.1 egy alapvető problémát jelentett. A HTTP/2 viszont sokkal könnyebbé teszi a folyamatok kezelését a szerverek és a böngészők számára, ezáltal pedig jelentős mértékben gyorsítja a weboldalt.

Az átállás sem túl bonyolult, és már az is lehet, hogy a szervered használja a HTTP/2-t.  Ezért ellenőrizd a szolgáltatódnál, hogy milyen lehetőségeid vannak. Emellett érdemes lehet a CDN-nel is megpróbálkoznod. A lényeg, hogy a HTTP/2 jelentős sebességnövekedést eredményez, ráadásul a biztonságot is fokozza, hiszen alapból HTTPS kapcsolatot használ.

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!

 

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:

1. Válts biztonságos kapcsolatra már most!
2. Készülj fel a HTTP/2-re a fejlesztés során!
3. Figyeld az analitikát!
4. Ellenőrizd a hosting-szolgáltatód készültségét!
5. Végül váltsd le a korábbi megoldásokat a HTTP/2-nél megfelelőekre!

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.