{"id":1546,"date":"2018-04-20T04:23:37","date_gmt":"2018-04-20T02:23:37","guid":{"rendered":"http:\/\/blog.webshark.hu\/?p=1546"},"modified":"2018-04-20T07:44:35","modified_gmt":"2018-04-20T05:44:35","slug":"mi-az-a-http2","status":"publish","type":"post","link":"http:\/\/blog.webshark.hu\/2018\/04\/20\/mi-az-a-http2\/","title":{"rendered":"Mi az a HTTP\/2? \u00c9s Te k\u00e9szen \u00e1llsz m\u00e1r r\u00e1?"},"content":{"rendered":"

2015-ben jelent meg \u00faj verzi\u00f3ja a HTTP-nek. Ez a HTTP\/2, mely m\u00e1ra k\u00e9szen \u00e1ll az alkalmaz\u00e1sra, \u00e9s sokkal gyorsabb netez\u00e9st \u00edg\u00e9r mindenki sz\u00e1m\u00e1ra.\u00a0Mivel a\u00a0HTTP\/2\u00a0m\u00e9g sokak sz\u00e1m\u00e1ra \u00faj, ez\u00e9rt \u00e9rdemes egy m\u00e9lyebb pillant\u00e1st vetni az alkalmaz\u00e1s\u00e1ra.\u00a0<\/strong><\/p>\n

Azok sz\u00e1m\u00e1ra, akik nem is igaz\u00e1n tudj\u00e1k, hova tegy\u00e9k a HTTP-t, \u00e9s mit is jelent ez sz\u00e1mukra, a Smashing Magazine<\/a> \u00f6sszefoglal\u00f3ja alapj\u00e1n a gy\u00f6kerekn\u00e9l, azaz a HTTP mibenl\u00e9t\u00e9n\u00e9l kezdj\u00fck.<\/p>\n

Mi az a HTTP, az SPDY \u00e9s a HTTP\/2?<\/h2>\n
A Hypertext Transfer Protocol a szerverek \u00e9s a b\u00f6ng\u00e9sz\u0151k k\u00f6z\u00f6tti kapcsolatot ir\u00e1ny\u00edtja. 1991-ben j\u00f6tt l\u00e9tre, m\u00edg els\u0151 jav\u00edtott verzi\u00f3ja HTTP\/1.1 n\u00e9vre hallgatott, \u00e9s 1999 \u00f3ta \u00e9l vel\u00fcnk, de sok\u00e1ig nem ny\u00faltak hozz\u00e1. Pedig akkoriban a weboldalak m\u00e9g nagyon m\u00e1shogy n\u00e9ztek ki, mint amilyenekkel most futhatunk \u00f6ssze a weben. Els\u0151sorban a weboldalak m\u00e9rete n\u00f6vekedett meg az\u00f3ta, \u00edgy ma egy \u00e1tlagos weboldal 1,9 MB \u00e9s t\u00f6bb mint 100 egy\u00e9ni forr\u00e1s sz\u00fcks\u00e9ges ahhoz, hogy megjelenjen az oldal a b\u00f6ng\u00e9sz\u0151ablakban. Az egy\u00e9ni forr\u00e1s alatt olyan elemeket kell \u00e9rteni, mint egy k\u00e9p, egy font, egy JavaScript vagy egy CSS f\u00e1jl.<\/p>\n
Manaps\u00e1g igen komoly k\u00fczdelem folyik a weboldalak sebess\u00e9g\u00e9nek jav\u00edt\u00e1sa \u00e9rdek\u00e9ben, \u00e9s ebbe beletartozik az is, hogy cs\u00f6kkenteni kell a bet\u00f6ltend\u0151 elemeknek a sz\u00e1m\u00e1t, m\u00e9ret\u00e9t, hogy m\u00e9g elfogadhat\u00f3 sebess\u00e9get \u00e9rj\u00fcnk el. A HTTP\/1.1 nem igaz\u00e1n teljes\u00edt j\u00f3l, amikor a mai k\u00f6vetelm\u00e9nyeknek kell megfelelnie.<\/p>\n
M\u00e1r 2009-ben k\u00e9t m\u00e9rn\u00f6k a Google-t\u0151l bejelentette, hogy dolgoznak egy SPDY n\u00e9vre hallgat\u00f3 kutat\u00e1si projekten, ami kik\u00fcsz\u00f6b\u00f6li a HTTP\/1.1 n\u00e9h\u00e1ny hi\u00e1nyoss\u00e1g\u00e1t, \u00e9s az\u00f3ta m\u00e1r itt-ott haszn\u00e1lj\u00e1k is. Ennek az egyik legkomolyabb el\u0151nye az \u00fagynevezett multiplexing, vagyis, hogy p\u00e1rhuzamosan t\u00f6bb lek\u00e9r\u00e9s kiszolg\u00e1l\u00e1s\u00e1t is lehet\u0151v\u00e9 teszi egyetlen TCP kapcsolaton kereszt\u00fcl. Emellett a b\u00f6ng\u00e9sz\u0151k prioriz\u00e1lhatj\u00e1k, hogy mi az, amit a legfontosabbnak tartanak egy weboldal megjelen\u00edt\u00e9s\u00e9n\u00e9l. Cs\u00f6kkenti a HTTP header m\u00e9ret\u00e9t \u00e9s azok sz\u00e1m\u00e1t, valamint megjelenik a server push, vagyis, hogy a szerverek a legfontosabb elemeket m\u00e1r azel\u0151tt elk\u00fcldik a b\u00f6ng\u00e9sz\u0151nek, hogy az lek\u00e9rn\u00e9 \u0151ket. Ami m\u00e9g fontos, hogy mindehhez titkos\u00edtott, azaz HTTPS kapcsolat sz\u00fcks\u00e9ges a szerver \u00e9s a b\u00f6ng\u00e9sz\u0151 k\u00f6z\u00f6tt.<\/p>\n
Az SPDY egy\u00e9bk\u00e9nt nem v\u00e1ltotta le a HTTP-t, ink\u00e1bb egy csatorn\u00e1t jelentett a protokollban \u00e9s megv\u00e1ltoztatta azt a m\u00f3dot, ahogy a lek\u00e9r\u00e9sek \u00e9s a v\u00e1laszok k\u00fcld\u00e9sre ker\u00fclnek. Ehhez t\u00e1mogat\u00e1st ig\u00e9nyelt mind a szerver, mind pedig a b\u00f6ng\u00e9sz\u0151k r\u00e9sz\u00e9r\u0151l. Ez ma m\u00e1r nem gond, a NGINX fel van k\u00e9sz\u00edtve r\u00e1, \u00e9s az Apache eset\u00e9ben is el\u00e9rhet\u0151k a megfelel\u0151 csomagok a Google-t\u0151l, ahogy a b\u00f6ng\u00e9sz\u0151k minden modern verzi\u00f3ja is t\u00e1mogatja. Kiv\u00e9telt a Microsoft Edge jelent, mely az IE 11-t\u0151l elt\u00e9r\u0151en nem t\u00e1mogatja az SPDY-t. T\u00e1mogatja\u00a0viszont\u00a0a HTTP\/2-t, vagyis a HTTP protokoll leg\u00fajabb verzi\u00f3j\u00e1t.<\/p>\n
Az SPDY-t\u00e1mogat\u00e1s egy\u00e9bk\u00e9nt a Chrome-b\u00f3l is ki fog ker\u00fclni m\u00e9g az idei \u00e9vben, \u00e9s val\u00f3sz\u00edn\u0171leg a t\u00f6bbi b\u00f6ng\u00e9sz\u0151 is k\u00f6veti ezt a l\u00e9p\u00e9st. Ugyanakkor a HTTP\/2-t m\u00e1r a Firefox, a Chrome \u00e9s az Opera is t\u00e1mogatja, valamint a Safari a 9-es verzi\u00f3t\u00f3l.<\/p>\n
Itt az ideje teh\u00e1t, hogy ejts\u00fcnk p\u00e1r sz\u00f3t a HTTP\/2 l\u00e9nyeg\u00e9r\u0151l is. Ez a protokoll-verzi\u00f3 tulajdonk\u00e9ppen azt viszi tov\u00e1bb, amit az SPDY m\u00e1r tudott. Hab\u00e1r enn\u00e9l nem k\u00f6vetelm\u00e9ny a HTTPS kapcsolat megl\u00e9te, a b\u00f6ng\u00e9sz\u0151k csak TLS (HTTPS) eset\u00e9ben t\u00e1mogatj\u00e1k a HTTP\/2-t. Ez pedig azt jelenti, hogy csak akkor kezdhetsz gondolkodni a HTPP\/2-re val\u00f3 v\u00e1lt\u00e1son, ha m\u00e1r HTTPS kapcsolattal el\u00e9rhet\u0151 a weboldalad<\/strong>.<\/p>\n
2015 febru\u00e1rj\u00e1ban v\u00e9gleges\u00edtett\u00e9k a HTTP\/2 szabv\u00e1nyt, \u00edgy egy \u00e9v eltelt\u00e9vel a t\u00e1mogat\u00e1s a legfrissebb verzi\u00f3j\u00fa b\u00f6ng\u00e9sz\u0151kben m\u00e1r adott, ahogy a szerverekn\u00e9l is fokozatosan megt\u00f6rt\u00e9nik a bevezet\u00e9s. A W3Techs 2015 j\u00falius\u00e1ban m\u00e1r k\u00f6z\u00f6lt egy statisztik\u00e1t<\/a> a bevezet\u00e9s gyorsas\u00e1g\u00e1r\u00f3l, akkor az\u00e9rt m\u00e9g j\u00f3csk\u00e1n voltak elmarad\u00e1sok, de az\u00f3ta sok id\u0151 eltelt.<\/p>\n
A HTTP\/2-r\u0151l egyszer\u0171bben<\/h2>\n
Miut\u00e1n besz\u00e9lt\u00fcnk a szabv\u00e1nyok fejl\u0151d\u00e9s\u00e9r\u0151l, most l\u00e1ssuk, hogy mit is tud a gyakorlatban a HTTP\/2. Onnan induljunk ki, hogy amikor r\u00e1kattintasz egy linkre egy weboldalon, akkor egy k\u00e9r\u00e9st kap a szerver. A szerver erre v\u00e1laszol egy st\u00e1tusz\u00fczenettel \u00e9s az adott oldal f\u00e1jllist\u00e1j\u00e1val. A b\u00f6ng\u00e9sz\u0151 ezut\u00e1n elkezdni lek\u00e9rni a f\u00e1jlokat.<\/p>\n
A r\u00e9gi, azaz HTTP1.1-es protokoll eset\u00e9ben ez meglehet\u0151sen lassan zajlott, mivel egyes\u00e9vel mentek \u00e1t a f\u00e1jlok, \u00e9s csak egyetlen vonalat haszn\u00e1lt az \u00e1tvitelre \u00fagy, hogy minden f\u00e1jl eset\u00e9n \u00fajra nyitotta \u00e9s z\u00e1rta azt. A HTTP\/2 ezt a folyamatot felgyors\u00edtja azzal, hogy folyamatosan nyitva tartja a vonalat \u00e9s egyszerre j\u00f3val nagyobb adag \u00e1raml\u00e1s\u00e1t biztos\u00edtja.<\/p>\n
A Yoast<\/a> \u00e1ltal felhozott p\u00e9lda vil\u00e1g\u00edtja meg tal\u00e1n a legjobban a m\u0171k\u00f6d\u00e9sbeli k\u00fcl\u00f6nbs\u00e9geket: amikor van egy doboz Leg\u00f3d, akkor \u00fagy \u00e1llsz neki, hogy n\u00e9zed az instrukci\u00f3kat. Ez \u00e1ltal\u00e1ban \u00fagy \u00e9p\u00fcl fel, hogy t\u00e9gl\u00e1r\u00f3l-t\u00e9gl\u00e1ra, egyes\u00e9vel bemutatja, mit hova rakj. Vagyis egy id\u0151ben egyetlen elemmel foglalkozol. Amikor azt elhelyezted, \u00fajra r\u00e1tekintesz a le\u00edr\u00e1sra, \u00e9s megn\u00e9zed, hogy a k\u00f6vetkez\u0151 elemet hova kellene tenned. Ha mondjuk t\u00f6bb ezer elem van a dobozodban, akkor ez a folyamat el\u00e9g sok\u00e1ig fog tartani. A HTTP1.1 valahogy \u00edgy m\u0171k\u00f6dik.<\/p>\n
Ezzel szemben a HTTP\/2-n\u00e9l \u00fagy t\u00f6rt\u00e9nne, hogy egy nagyobb r\u00e9sznek tudod lek\u00e9rni az \u00f6ssze\u00e1ll\u00edt\u00e1si \u00fatmutat\u00f3j\u00e1t, \u00e9s an\u00e9lk\u00fcl tudsz instrukci\u00f3kat kapni az \u00fajabb elemek elhelyez\u00e9s\u00e9hez, hogy r\u00e1 kellene n\u00e9zned az \u00fatmutat\u00f3ra. Ha igaz\u00e1n gyors akarsz lenni, akkor ak\u00e1r az \u00f6sszes elemet lek\u00e9rheted egyszerre, \u00e9s egyb\u0151l \u00f6ssze\u00e1ll\u00edthatod a Leg\u00f3dat.<\/p>\n
$\"A$ <\/p>\n
A l\u00e9nyeg teh\u00e1t az, hogy a HTTP\/2 egyszerre t\u00f6bb dolgot tud kezelni: egy id\u0151ben t\u00f6bb lek\u00e9r\u00e9s t\u00f6rt\u00e9nik egy – az \u00e1tvitel sor\u00e1n – folyamatosan nyitott kapcsolaton. Ez a legfontosabb a gyorsabb m\u0171k\u00f6d\u00e9s szempontj\u00e1b\u00f3l. Ugyanakkor egy m\u00e1sik fontos dolog az \u00fagynevezett szerver push: itt is egy lek\u00e9r\u00e9ssel indul a folyamat, azonban amikor a szerver \u00e9szleli, hogy a HTML-nek tov\u00e1bbi dolgokra van sz\u00fcks\u00e9ge, akkor k\u00e9r\u00e9s n\u00e9lk\u00fcl k\u00fcldi ezeket.<\/p>\n
SEO szempontb\u00f3l els\u0151sorban az\u00e9rt j\u00f3 a HTTP\/2, mert a weboldalsebess\u00e9g rangsorol\u00e1si t\u00e9nyez\u0151 m\u00e1r \u00e9vek \u00f3ta<\/a>. A mobil index indul\u00e1s\u00e1val pedig m\u00e9g fontosabb\u00e1 v\u00e1lt. Mik\u00f6zben a weboldalak v\u00e1rhat\u00f3an csak egyre nagyobbak lesznek. A nagy weboldalak pedig sok elemb\u0151l \u00e1llnak: HTML, JavaScript, CSS, k\u00e9pek, stb. Ez pedig csak n\u00f6veli a bet\u00f6lt\u00e9si id\u0151t.<\/p>\n
Egy m\u00e1sik fontos dolog a k\u00e9sleltet\u00e9s, els\u0151sorban a mobileszk\u00f6z\u00f6kn\u00e9l. Min\u00e9l nagyobb a k\u00e9sleltet\u00e9s, ann\u00e1l t\u00f6bb id\u0151, hogy egy k\u00e9r\u00e9st megkapjon a szerver, majd erre k\u00fcldj\u00f6n egy v\u00e1laszt. Ez az oka annak, hogy \u00e9rdemes CDN-t haszn\u00e1lni. Ez\u00e1ltal cs\u00f6kkenthet\u0151 az id\u0151 azok sz\u00e1m\u00e1ra, akik egy k\u00f6zeli pontb\u00f3l neteznek.<\/p>\n
Emellett persze vannak m\u00e9g tov\u00e1bbi lehet\u0151s\u00e9gek a szerverek finomhangol\u00e1s\u00e1ra a weboldalsebess\u00e9g jav\u00edt\u00e1sa<\/a> \u00e9rdek\u00e9ben, de a HTTP1.1 egy alapvet\u0151 probl\u00e9m\u00e1t jelentett. A HTTP\/2 viszont sokkal k\u00f6nnyebb\u00e9 teszi a folyamatok kezel\u00e9s\u00e9t a szerverek \u00e9s a b\u00f6ng\u00e9sz\u0151k sz\u00e1m\u00e1ra, ez\u00e1ltal pedig jelent\u0151s m\u00e9rt\u00e9kben gyors\u00edtja a weboldalt.<\/p>\n
Az \u00e1t\u00e1ll\u00e1s sem t\u00fal bonyolult, \u00e9s m\u00e1r az is lehet, hogy a szervered haszn\u00e1lja a HTTP\/2-t.\u00a0 Ez\u00e9rt ellen\u0151rizd a szolg\u00e1ltat\u00f3dn\u00e1l, hogy milyen lehet\u0151s\u00e9geid vannak. Emellett \u00e9rdemes lehet a CDN-nel is megpr\u00f3b\u00e1lkoznod. A l\u00e9nyeg, hogy a HTTP\/2 jelent\u0151s sebess\u00e9gn\u00f6veked\u00e9st eredm\u00e9nyez, r\u00e1ad\u00e1sul a biztons\u00e1got is fokozza, hiszen alapb\u00f3l HTTPS kapcsolatot haszn\u00e1l.<\/p>\n
K\u00f6telez\u0151 az \u00e1t\u00e1ll\u00e1s?<\/h2>\n
Mivel a HTTP\/2 visszafel\u00e9 kompatibilis a HTTP\/1.1-gyel, \u00edgy semmi gondot nem okoz, ha valaki egy\u00e1ltal\u00e1n nem foglalkozik a dologgal, \u00e9s nem eszk\u00f6z\u00f6l m\u00f3dos\u00edt\u00e1sokat a weboldala eset\u00e9ben. Minden ugyan\u00fagy fog m\u0171k\u00f6dni, ahogy eddig is. A felhaszn\u00e1l\u00f3k sem fogj\u00e1k \u00e9szrevenni, hogy HTTP\/1.1-en, SPDY-on vagy \u00e9pp HTTP\/2-n \u00e9rnek el bizonyos oldalakat. Csak egyetlen dolog fog felt\u0171nni, amikor egyre t\u00f6bb weboldal v\u00e1lt HTTP\/2-re, hogy a Te oldalad valahogy sokkal lassabb lesz, mint a t\u00f6bbiek\u00e9.<\/p>\n
Ahhoz, hogy Te is \u00e1t\u00e1llhass a HTTP\/2-re, el\u0151sz\u00f6r is arra lesz sz\u00fcks\u00e9g, hogy a szerver-szoftver t\u00e1mogassa m\u00e1r ezt a protokollt. Ezzel csak az a probl\u00e9ma, hogy ezt nem Te hat\u00e1rozod meg, hanem a hosting-szolg\u00e1ltat\u00f3d. Miel\u0151tt a weboldaladon v\u00e1ltozat\u00e1sokat eszk\u00f6z\u00f6ln\u00e9l, annak a k\u00e9rd\u00e9snek is \u00e9rdemes egy p\u00e1r percet szentelni, hogy a felhaszn\u00e1l\u00f3id olyan b\u00f6ng\u00e9sz\u0151ket haszn\u00e1lnak-e m\u00e1r, mely t\u00e1mogatja az \u00faj protokollt. Azok sz\u00e1m\u00e1ra, akiknek a felhaszn\u00e1l\u00f3i a leg\u00fajabb b\u00f6ng\u00e9sz\u0151kkel n\u00e9zik a weboldal\u00e1t, nyilv\u00e1n \u00e9rdemes lenne min\u00e9l hamarabb l\u00e9pni az \u00fcgyben.<\/p>\n
$\"felhasznalo\"$ <\/p>\n
A weboldalak sz\u00e1m\u00e1ra az egyik legnagyobb probl\u00e9m\u00e1t az \u00e1t\u00e1ll\u00e1s kapcs\u00e1n nem is az jelenti, hogy v\u00e1ltani kell HTTP\/2-re, hanem sokkal ink\u00e1bb az, hogy ehhez alapvet\u0151 k\u00f6vetelm\u00e9ny a biztons\u00e1gos kapcsolat, azaz a HTTPS. \u00daj weboldalakn\u00e1l \u00e9rdemes m\u00e1r eleve ezzel ind\u00edtani, illetve r\u00e9gi weboldalak eset\u00e9n a redesign sor\u00e1n megl\u00e9pni a v\u00e1lt\u00e1st.<\/p>\n
Ez egy\u00e9bk\u00e9nt az\u00e9rt is hasznos, mert a Google is el\u0151nyben r\u00e9szes\u00edti m\u00e1r a tal\u00e1lati oldal kialak\u00edt\u00e1s\u00e1n\u00e1l a HTTPS kapcsolat\u00fa oldalakat, vagyis ezeket v\u00e1lasztja, ha adott egy oldalb\u00f3l HTTP \u00e9s HTTPS verzi\u00f3 is, r\u00e1ad\u00e1sul a b\u00f6ng\u00e9sz\u0151k jelezni fogj\u00e1k k\u00fcl\u00f6n, ha egy weboldal kapcsolata nem biztons\u00e1gos, valamint\u00a0a j\u00f6v\u0151ben j\u00f3 p\u00e1r fontos HTML5-funkci\u00f3 sem lesz el\u00e9rhet\u0151, csak biztons\u00e1gos kapcsolaton kereszt\u00fcl.<\/p>\n
A l\u00e9nyeg teh\u00e1t az lenne, hogy ha a Te weboldalad is HTTP-t haszn\u00e1l, akkor az els\u0151 lehets\u00e9ges alkalommal \u00e1llj \u00e1t HTTPS-re<\/a>, majd ut\u00e1na valamikor \u00e9rdemes v\u00e1ltanod HTTP\/2-re!<\/strong><\/p>\n
<\/p>\n
Hogyan k\u00e9sz\u00fclj el\u0151 a HTTP\/2-re?<\/h2>\n
Ha \u00e9pp elind\u00edtasz egy projektet, mely terveid szerint hossz\u00fa t\u00e1v\u00fa lesz, akkor \u00e9rdemes el\u0151k\u00e9sz\u00fcleteket tenned a HTTP\/2-re val\u00f3 \u00e1t\u00e1ll\u00e1sra, m\u00e9g ha azt jelen pillanatban egyel\u0151re nem teszi lehet\u0151v\u00e9 a szervert\u00e1mogat\u00e1s hi\u00e1nya. Az egyik dolog, hogy ha sprite-okat haszn\u00e1lsz, akkor k\u00e9sz\u00edtsd el az oldal-specifikus vagy sprite-ok n\u00e9lk\u00fcli megold\u00e1st, \u00edgy k\u00f6nnyebb lesz a v\u00e1lt\u00e1s a nagy sprite-okr\u00f3l. Ugyanez a helyzet a data URI-kkal is, melyeket ha haszn\u00e1lsz a CSS-edin\u00e9l, akkor a k\u00e9peket k\u00e9sz\u00edtsd fel a v\u00e1lt\u00e1sra, amikor m\u00e1r nem fogod ezeket haszn\u00e1lni.<\/p>\n
A CSS-ek \u00e9s JavaScriptek \u00f6sszef\u0171z\u00e9s\u00e9n\u00e9l jobb teljes\u00edtm\u00e9nyt \u00e9rsz el HTTP\/2 alatt a forr\u00e1sok megfelel\u0151 elrendez\u00e9s\u00e9vel az egyetlen f\u00e1jl helyett. Vagyis csak azok a f\u00e1jlok t\u00f6lt\u0151djenek be valamely oldal let\u00f6lt\u00e9s\u00e9n\u00e9l, amire az oldal megjelen\u00edt\u00e9s\u00e9hez \u00e9ppen sz\u00fcks\u00e9g van. Ha m\u00e1r most ennek figyelembe v\u00e9tel\u00e9vel fejlesztesz, az k\u00e9s\u0151bb kifizet\u0151d\u0151 lesz sz\u00e1modra.<\/p>\n
A HTTP\/2-r\u0151l \u00f6sszess\u00e9g\u00e9ben elmondhat\u00f3, hogy teljesen m\u00e1s megold\u00e1sokat kell majd alkalmaznod, mint amit megszokt\u00e1l HTTP\/1.1 alatt. Az \u00faj protokoll visszaadja az ir\u00e1ny\u00edt\u00e1s nagy r\u00e9sz\u00e9t a kezedbe, ami azt is jelenti, hogy minden egyes projektn\u00e9l sz\u00fcks\u00e9g lesz \u00faj d\u00f6nt\u00e9sek meghozatal\u00e1ra.<\/p>\n
Sok dolog nem ker\u00fclt most sz\u00f3ba, amivel szint\u00e9n foglalkoznod kell majd, ilyen p\u00e9ld\u00e1ul a szerver push lehet\u0151s\u00e9ge, melynek r\u00e9v\u00e9n eld\u00f6ntheted majd, hogy mely forr\u00e1sok kapnak priorit\u00e1st, \u00e9s utas\u00edthatod a szervert, hogy ezeket el\u0151bb t\u00f6ltse be, mint a kev\u00e9sb\u00e9 fontos dolgokat. Az ehhez kapcsol\u00f3d\u00f3 megold\u00e1sok a k\u00e9s\u0151bbiekben alakulnak m\u00e9g, \u00edgy \u00e9rdemes figyelni az egyre szaporod\u00f3 gyakorlati p\u00e9ld\u00e1kat \u00e9s felhaszn\u00e1lni a tapasztalatokat.<\/p>\n
Mikor v\u00e1lts HTTP\/2-re?<\/h2>\n
Azon esetekben, amikor a szerverek felett nem Te gyakorlod a fel\u00fcgyeletet, a v\u00e1lt\u00e1ssal v\u00e1rhatsz eg\u00e9szen addig, m\u00edg a szerverek k\u00e9szen nem \u00e1llnak a HTTP\/2-re. Persze m\u00e1r vannak olyan hosting-szolg\u00e1ltat\u00f3k, ahol felk\u00e9sz\u00fcltek a HTTP\/2-re, \u00edgy ha el\u0151nye sz\u00e1rmazik egy weboldalnak a v\u00e1lt\u00e1sb\u00f3l, akkor meg kell tenni. K\u00e9rd\u00e9s, hogy az adott weboldal felhaszn\u00e1l\u00f3inak t\u00f6bbs\u00e9ge k\u00e9szen \u00e1ll-e r\u00e1, azaz alkalmas-e b\u00f6ng\u00e9sz\u0151j\u00fck a HTTP\/2 haszn\u00e1lat\u00e1ra. Mivel a HTTP\/2 visszafel\u00e9 kompatibilis, \u00edgy a weboldalaknak nem musz\u00e1j b\u00e1rmit tenni\u00fck az \u00e1t\u00e1ll\u00e1s \u00e9rdek\u00e9ben. Csak ahogy m\u00e1r kor\u00e1bban is eml\u00edtett\u00fck, optimaliz\u00e1l\u00e1s hi\u00e1ny\u00e1ban l\u00e9nyegesen lassabb lesz a weboldal, mint a konkurenci\u00e1\u00e9.<\/p>\n
\u00c9rdemes teh\u00e1t figyelni az analitikai adatokat, \u00e9s ha azt l\u00e1tod, hogy a felhaszn\u00e1l\u00f3id t\u00f6bbs\u00e9g m\u00e1r HTTP\/2-k\u00e9pes b\u00f6ng\u00e9sz\u0151t haszn\u00e1l, akkor itt az id\u0151 a v\u00e1lt\u00e1sra. Ez a legt\u00f6bb esetben egy\u00e9bk\u00e9nt m\u00e1r most is \u00edgy van, \u00edgy ez nem akad\u00e1ly. K\u00fcl\u00f6n\u00f6sen fontos lenne l\u00e9pni akkor, hogy nagy a mobilr\u00f3l \u00e9rkez\u0151 forgalmad.<\/p>\n
Ha pedig \u00e9ppen most k\u00e9sz\u00edtesz egy \u00faj weboldalt, akkor m\u00e1r mindenk\u00e9ppen \u00e9rdemes a fejleszt\u00e9s sor\u00e1n HTTP\/2-re optimaliz\u00e1lni, m\u00e9g akkor is, ha az indul\u00e1sn\u00e1l HTTP\/1.1-et fogod haszn\u00e1lni a szerver-t\u00e1mogat\u00e1s hi\u00e1nya miatt, \u00e9s emiatt kompromisszumokra k\u00e9nyszer\u00fclsz.<\/p>\n
R\u00f6viden \u00f6sszefoglalva teh\u00e1t \u00fagy n\u00e9z ki a folyamat:<\/p>\n
\n
V\u00e1lts biztons\u00e1gos kapcsolatra m\u00e1r most!<\/li>\n
K\u00e9sz\u00fclj fel a HTTP\/2-re a fejleszt\u00e9s sor\u00e1n!<\/li>\n
Figyeld az analitik\u00e1t!<\/li>\n
Ellen\u0151rizd a hosting-szolg\u00e1ltat\u00f3d k\u00e9sz\u00fclts\u00e9g\u00e9t!<\/li>\n
V\u00e9g\u00fcl v\u00e1ltsd le a kor\u00e1bbi megold\u00e1sokat a HTTP\/2-n\u00e9l megfelel\u0151ekre!<\/li>\n<\/ol>\n
K\u00e9pek, CSS, JS \u00e9s a HTTP-lek\u00e9r\u00e9sek sz\u00e1ma HTTP\/2-n\u00e9l<\/h2>\n
A HTTP\/1.1 esetben a b\u00f6ng\u00e9sz\u0151nek egyszer\u0171bb egy nagy k\u00e9pf\u00e1jlt megjelen\u00edtenie, mint sok kicsit, a sok lek\u00e9r\u00e9s miatt. Ez\u00e9rt c\u00e9lszer\u0171 ezeket a kis f\u00e1jlokat egy sprite f\u00e1jlba rendezni. Ez ugyanis egyetlen HTTP-lek\u00e9r\u00e9st jelent, \u00edgy megel\u0151zi a sok lek\u00e9r\u00e9s okozta probl\u00e9m\u00e1t. Ugyanakkor, ha egy felhaszn\u00e1l\u00f3nak valamely oldalon mind\u00f6ssze egyetlen kis k\u00e9pet kell megjelen\u00edteni, ahhoz is az eg\u00e9sz sprite f\u00e1jlt le kell t\u00f6lteni.<\/p>\n
A HTTP\/2 eset\u00e9ben azonban ez m\u00e1r nem probl\u00e9ma a kor\u00e1bban is eml\u00edtett multiplex-k\u00e9pess\u00e9g miatt. A legt\u00f6bb esetben a kis k\u00e9pek egy\u00e9ni megjelen\u00edt\u00e9se jobb eredm\u00e9nyt hoz majd, a felhaszn\u00e1l\u00f3knak pont azt a k\u00e9pet kell megjelen\u00edteni, ami az \u00e1ltaluk megl\u00e1togatott weboldal megtekint\u00e9s\u00e9hez sz\u00fcks\u00e9ges.<\/p>\n
Ugyanakkor a sprite-ok haszn\u00e1lata sem elvetend\u0151 egyes esetekben, hiszen bizonyos k\u00e9pek sprite-okba rendez\u00e9s\u00e9vel jobb t\u00f6m\u00f6r\u00edt\u00e9s \u00e9rhet\u0151 el, \u00edgy a let\u00f6lt\u00e9si m\u00e9ret kisebb lesz. Els\u0151sorban teh\u00e1t akkor \u00e9rdemes haszn\u00e1lni a sprite f\u00e1jlokat, ha a k\u00e9pek mind a let\u00f6ltend\u0151 oldalon szerepelnek. Ugyanakkor az kijelenthet\u0151, hogy a HTTP\/2 eset\u00e9ben m\u00e1r nem minden esetben a sprite a lehet\u0151 legjobb megold\u00e1s.<\/p>\n
A CSS-ek \u00e9s a JavaScript f\u00e1jlok eset\u00e9ben ugyanez a helyzet, teh\u00e1t ezek \u00f6sszef\u0171z\u00e9se cs\u00f6kkenti a HTTP-lek\u00e9r\u00e9sek sz\u00e1m\u00e1t. Ugyanakkor ez a megold\u00e1s gyakran azzal j\u00e1r, hogy a felhaszn\u00e1l\u00f3knak akkor is le kell t\u00f6lteni az \u00f6sszes CSS-t \u00e9s JS-t, ha a legt\u00f6bbet soha nem fogj\u00e1k haszn\u00e1lni. Term\u00e9szetesen a dolgot lehet optimaliz\u00e1lni a f\u00e1jlok megfelel\u0151 elrendez\u00e9s\u00e9vel, ez azonban el\u00e9g sok munk\u00e1val j\u00e1r.<\/p>\n
Tov\u00e1bbi probl\u00e9ma ezekkel az \u00f6sszef\u0171z\u00e9sekkel, hogy ilyenkor egyszerre \u00fcr\u00fclnek ki a f\u00e1jlok\u00a0a cache-b\u0151l. Nem tudod megtenni, hogy egyes f\u00e1jlok eset\u00e9ben soha ne v\u00e1ltozzon a hossz\u00fa lej\u00e1rati id\u0151, mik\u00f6zben a k\u00f3d gyakran v\u00e1ltoz\u00f3 r\u00e9szein\u00e9l r\u00f6videbb lej\u00e1ratot hat\u00e1rozol meg. Mindegyik le fog j\u00e1rni, m\u00e9g ha csak a CSS egyetlen sora, egyetlen oldalon is megv\u00e1ltozik.<\/p>\n
De mivel a HTTP-lek\u00e9r\u00e9sek m\u00e1r nem jelentenek gondot a HTTP\/2 eset\u00e9ben, sokkal egyszer\u0171bb\u00e9 v\u00e1lik a CSS \u00e9s JavaScript elrendez\u00e9se is. El\u00e9g lesz csak annyit bet\u00f6lteni a k\u00f3db\u00f3l, amennyire a felhaszn\u00e1l\u00f3nak sz\u00fcks\u00e9ge van, nem fog sz\u00e1m\u00edtani, hogy sok-sok kis st\u00edluslapot kell let\u00f6lteni. Az alapj\u00e1n \u00e9rdemes majd szervezni ezeket a f\u00e1jlokat csoportokba, hogy milyen gyakran v\u00e1ltoznak.<\/p>\n
Emellett a HTTP\/1.1 eset\u00e9ben korl\u00e1tozott a nyitott kapcsolatok sz\u00e1ma. Amennyiben nagy a forr\u00e1sok sz\u00e1ma, akkor megold\u00e1s lehet, hogy t\u00f6bbf\u00e9le domain al\u00f3l k\u00e9rj\u00fck le \u0151ket. A domain sharding haszn\u00e1lat\u00e1val jobb let\u00f6lt\u00e9si id\u0151k \u00e9rhet\u0151k el, ami azonban \u00f6nmag\u00e1ban is probl\u00e9m\u00e1t okozhat, nem besz\u00e9lve arr\u00f3l, hogy ez milyen munk\u00e1val j\u00e1r. A HTTP\/2 eset\u00e9ben nincs sz\u00fcks\u00e9g erre a megold\u00e1sra, mivel a lek\u00e9r\u00e9sek sz\u00e1m\u00e1nak nincs korl\u00e1tja. S\u0151t, a sharding haszn\u00e1lata rontja a teljes\u00edtm\u00e9nyt, mivel tov\u00e1bbi TCP kapcsolatokat ig\u00e9nyel \u00e9s megakad\u00e1lyozza a HTTP\/2-t abban, hogy prioriz\u00e1lja a forr\u00e1sokat.
\n