HTTP/2 és HTTP/3 a magyar tárhelyeken: mikor gyorsít, mikor nem

Scheo · 2026-09-14 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha a tárhelyed adminfelületén azt látod, hogy „HTTP/2 támogatott”, vagy a szolgáltató HTTP/3-mal hirdeti magát, jogos a kérdés: ettől tényleg gyorsabb lesz a weboldalad? A rövid válasz: néha igen, de sokkal kevésbé, mint amennyi időt egy rosszul kezelt kép vagy egy lassú bővítmény elvesz. Ebből a cikkből kiderül, hol tart a saját oldalad, mit kérj a tárhelyszolgáltatótól, és mivel foglalkozz előbb.

Mit jelent a HTTP/2 multiplexálás egy átlagos KKV-oldalon?

A HTTP/2 lényege, hogy a böngésző egyetlen kapcsolaton, párhuzamosan kéri le az oldal összes fájlját, és nem kell sorban állniuk. Egy átlagos magyar KKV-oldal (WordPress, néhány bővítmény, sablon, betűkészlet, pár kép) a nyitóoldal betöltésekor saját tapasztalatunk szerint jellemzően 40-120 kérést indít: CSS, JavaScript, képek, betűtípusok, ikonok.

Mi volt a baj a HTTP/1.1-gyel?

Hivatalosan igazolt: HTTP/1.1 alatt egy kapcsolaton egyszerre egy kérés-válasz megy. A böngészők ezt úgy kerülik meg, hogy hosztonként több (a gyakorlatban legfeljebb hat) párhuzamos TCP-kapcsolatot nyitnak. Ha ennél több fájl kell, a többi vár. Minden új kapcsolat saját TCP- és TLS-kézfogással jár, ami távoli szervernél vagy mobilhálózaton érezhető idő.

Mit old meg a HTTP/2?

Hivatalosan igazolt: a HTTP/2 (ma az RFC 9113 írja le) egy TCP-kapcsolaton belül több, egymástól független adatfolyamot (streamet) enged, a fejléceket tömöríti (HPACK), és bináris keretezést használ. A böngészők a gyakorlatban csak HTTPS-en beszélnek HTTP/2-t, a verzióról a TLS-kézfogás közben (ALPN) állapodnak meg. A korábban sokat emlegetett server push funkciót a Chrome kivezette, ezért arra ma már nem érdemes építeni.

És mi a HTTP/3, vagyis a QUIC?

Hivatalosan igazolt: a HTTP/3 (RFC 9114) már nem TCP-n, hanem a QUIC protokollon (RFC 9000) fut, amely UDP-re épül, és a TLS 1.3 be van építve. A HTTP/2 egy megmaradt gyengeségét oldja meg: TCP-n, ha egyetlen csomag elveszik, az összes stream vár az újraküldésre (TCP-szintű head-of-line blokkolás). QUIC alatt csak az érintett stream áll meg. Emellett a kapcsolat túléli a hálózatváltást (például amikor a telefon wifiről mobilnetre vált), és a kapcsolatfelvétel kevesebb oda-vissza üzenettel jár.

Fontos részlet: a böngésző az első látogatáskor általában HTTP/2-n kezd, és a szerver Alt-Svc fejlécéből (vagy egy HTTPS típusú DNS-rekordból) tudja meg, hogy HTTP/3 is elérhető. Csak ezután vált. Ha tehát elsőre h2-t látsz, attól még működhet a HTTP/3.

Mennyit gyorsít valójában a protokoll-váltás?

Saját tapasztalat: egy átlagos KKV-oldalon a HTTP/1.1-ről HTTP/2-re, majd HTTP/3-ra váltás jellemzően 50-200 ms körüli javulást hoz, főleg mobilon és sok apró fájlnál. Ez nem semmi, de nézzük mellette a másik tipikus problémát: egy 3 MB-os, optimalizálatlan JPEG nyitókép közepes mobilkapcsolaton könnyen 2 másodpercet vagy többet visz el a Largest Contentful Paint (LCP) időből. A protokoll a szállítás módján gyorsít, a fájl méretén nem.

Hivatalosan igazolt: a Google szerint az LCP 2,5 másodperc alatt jó (a látogatások 75. percentilisén mérve). Ha az oldaladon 4 másodperc az LCP, és ebből 2 másodperc a nyitókép, a protokoll-váltás egyedül nem visz át a határon.

Hivatalosan igazolt: a Googlebot 2020 óta HTTP/2-n is feltérképezheti az oldalakat, ha ez neki előnyös, de a Google Search Central kifejezetten leírta, hogy ebből nem származik rangsorolási előny. A protokoll tehát a felhasználói élményen és a szerverterhelésen keresztül hathat, közvetlen SEO-jelzésként nem.

Mikor nem hoz mérhető javulást a HTTP/2 vagy a HTTP/3?

Ha az oldal lassúságát nem a sok párhuzamos kérés okozza, hanem a szerver válaszideje, a fájlméret vagy a külső szkriptek, a protokoll-váltás alig látszik a mérésekben. A tipikus esetek:

• Lassú szerverválasz (TTFB). Ha a WordPress gyorsítótár nélkül 1,5 másodpercig rakja össze a HTML-t, az protokolltól függetlenül 1,5 másodperc marad. Itt oldalgyorsítótár, adatbázis-optimalizálás vagy erősebb tárhely segít.
• Kevés, nagy fájl. Egy 12 kérésből álló bemutatkozó oldal alig nyer a multiplexálással, mert nincs mit párhuzamosítani.
• Túlméretezett képek és videók. Ilyenkor a sávszélesség a szűk keresztmetszet, nem a kapcsolatok száma.
• Harmadik féltől származó szkriptek. Chat-widget, hirdetési címkék, beágyazott térkép: ezek más domainről jönnek, saját kapcsolatot igényelnek, és a te tárhelyed protokollja nem hat rájuk.
• Közeli szerver, stabil vezetékes net. Ha a szerver Magyarországon van, a látogató pedig optikai netről jön, a kézfogások ideje eleve néhány ezredmásodperc (szakmai feltételezés a tipikus hazai késleltetés alapján). A HTTP/3 előnye ott jön ki, ahol a hálózat csomagot veszít vagy nagy a késleltetés: mobilon, gyenge lefedettségnél, külföldről érkező látogatónál.
• Letiltott UDP. Egyes céges hálózatok vagy tűzfalak blokkolják az UDP 443-as portot. Ilyenkor a böngésző csendben visszaáll HTTP/2-re. Ez nem hiba, de a HTTP/3 előnye elmarad.

Szakmai feltételezés: osztott tárhelyen a HTTP/3 processzorigénye valamivel nagyobb lehet, mint a HTTP/2-é, mert a QUIC csomagkezelése és titkosítása jellemzően a felhasználói térben fut. Egy átlagos KKV-oldal forgalmánál ez jó eséllyel nem érezhető, egy nagy forgalmú webshopnál viszont érdemes egyeztetni a szolgáltatóval.

Hogyan derül ki, milyen protokollon megy az oldalad?

A leggyorsabb módszer a böngésző fejlesztői eszközeiben a Network panel Protocol oszlopa: kérésenként mutatja, hogy http/1.1, h2 vagy h3 ment-e.

Böngészőben (Chrome, Edge)

1. Nyisd meg az oldalt, és nyomd meg az F12 billentyűt (Macen Cmd+Option+I).
2. Válts a Network fülre.
3. Kattints jobb gombbal bármelyik oszlopfejlécre, és kapcsold be a Protocol oszlopot.
4. Jelöld be a „Disable cache” opciót, és töltsd újra az oldalt.
5. A saját domainedről jövő fájloknál h2 vagy h3 szerepeljen. Ha h3-at vársz, de h2-t látsz, töltsd újra még egyszer, mert a váltás gyakran csak a második betöltéstől látszik.

Parancssorból, curl-lel

HTTP/2: curl -sI --http2 https://pelda.hu. Ha a válasz első sora HTTP/2 200, a szerver tud HTTP/2-t. Ha HTTP/1.1 200, akkor nem.

HTTP/3: curl -I --http3 https://pelda.hu. Ehhez HTTP/3 támogatással fordított curl kell: a curl -V kimenetének Features sorában szerepelnie kell a HTTP3 szónak. A macOS és sok Linux-disztribúció gyári curlje ezt nem mindig tudja, ilyenkor a hibaüzenet nem az oldalad hibája. A --http3-only kapcsoló visszaesés nélkül, kizárólag HTTP/3-mal próbálkozik.

Az Alt-Svc fejléc: curl -sI https://pelda.hu | grep -i alt-svc. HTTP/3-ra kész szervernél ilyesmit látsz: alt-svc: h3=":443"; ma=86400.

TLS 1.3: openssl s_client -connect pelda.hu:443 -servername pelda.hu -tls1_3. Ha a kapcsolat felépül, és a kimenetben TLSv1.3 szerepel, rendben van. Kézfogási hibánál a szerver nem támogatja.

Online ellenőrzővel és a szervernaplóban

Parancssor nélkül is megy: online HTTP/2- és HTTP/3-ellenőrzők (például a KeyCDN HTTP/2 tesztje vagy a http3check.net) egy URL alapján megmondják, mit tud a szerver. A TLS-verziókat a Qualys SSL Labs szervertesztje részletezi. A tárhely hozzáférési naplójában (access log) is látszik a verzió: a kéréssorban HTTP/1.1, HTTP/2.0 vagy HTTP/3.0 áll.

Mit kérj a tárhelyszolgáltatótól, ha csak HTTP/1.1 megy?

Kérd, hogy kapcsolják be a HTTP/2-t a HTTPS-kiszolgálásnál, ellenőrizzék a TLS 1.3 támogatást, és ha a szerver képes rá, engedélyezzék a HTTP/3-at is (UDP 443 és Alt-Svc fejléc). 2026-ban a csak HTTP/1.1-et kiszolgáló tárhely elavult beállításra utal, ezt nyugodtan jelezheted.

Kérdések, amelyeket szó szerint átmásolhatsz a hibajegybe:

• „A pelda.hu domainen a böngésző és a curl szerint csak HTTP/1.1 megy. Kérem, kapcsolják be a HTTP/2-t (ALPN h2) a HTTPS-kiszolgáláshoz.”
• „Támogatja a szerver a TLS 1.3-at? Ha nem, tervezik-e?”
• „Elérhető a HTTP/3 (QUIC) a csomagomban? Ha igen, kérem, engedélyezzék, és nyissák meg az UDP 443-as portot.”
• „Milyen webszerver fut a tárhely alatt (Apache, Nginx, LiteSpeed), és melyik verzió?”

Háttérként érdemes tudni, mit jelent ez a szolgáltató oldalán (a hivatalos dokumentációk alapján):

• Apache: a mod_http2 modul és a Protocols h2 http/1.1 direktíva kell. A dokumentáció szerint a régi prefork feldolgozási modellel a HTTP/2 nem, vagy csak erős korlátokkal működik, ezért gyakran az event MPM-re váltás is a feladat része. HTTP/3-at a jelenlegi stabil Apache önmagában nem szolgál ki, ehhez elé tett proxy vagy CDN kell.
• Nginx: HTTP/2-höz az újabb verziókban a http2 on; direktíva kell. HTTP/3-hoz az 1.25-ös verziótól elérhető QUIC-modul, a listen 443 quic reuseport; sor és az Alt-Svc fejléc hozzáadása szükséges.
• LiteSpeed: a HTTP/2 és a HTTP/3 beépített, jellemzően a szerverbeállításokban kapcsolható.
• CDN (például Cloudflare): a böngésző a CDN-nel beszél, így egy HTTP/1.1-es tárhely előtt is lehet HTTP/3 a látogató felé. A tárhely és a CDN közötti szakasz ettől még lassú maradhat.

Saját tapasztalat: a hazai osztott tárhelyek jelentős részén a HTTP/2 már alapból megy, a HTTP/3 viszont szolgáltatónként és szervertípusonként eltér. Ha a szolgáltató nem tudja bekapcsolni, egy CDN jó eséllyel gyorsabb megoldás, mint a költözés.

Milyen sorrendben érdemes gyorsítani az oldalt?

Először a nagy tételek jönnek (képek, szerverválasz, blokkoló szkriptek), utána a protokoll. A sorrend azért számít, mert egy rosszul kezelt nyitókép akár tízszer annyi időt vihet el, mint amennyit a protokoll-váltás visszaad.

1. Mérj. PageSpeed Insights (valós felhasználói adattal, ha van) és a DevTools Network panelje: melyik a legnagyobb fájl, és mennyi a TTFB?
2. Nyitókép. Méretezd a megjelenített szélességre, használj WebP vagy AVIF formátumot, add meg a szélességet és a magasságot, és ne tedd lusta betöltésre. Például: <img src="/kepek/nyito-1600.webp" width="1600" height="900" fetchpriority="high" alt="Nyitókép">. Egy 3 MB-os JPEG így gyakran pár száz KB-ra csökkenthető (saját tapasztalat, a képtől függ).
3. Szerverválasz. Oldalgyorsítótár, felesleges bővítmények kivezetése, lassú adatbázis-lekérdezések rendbetétele.
4. Blokkoló CSS és JavaScript. A nem használt szkripteket vedd ki, a többit töltsd halasztva (defer).
5. Protokoll és kapcsolatok. HTTP/2, TLS 1.3, HTTP/3, a sharding megszüntetése, preconnect. Ez sokszor egyetlen hibajegy, tehát kevés munka, csak ne ettől várd a nagy áttörést.

Mi kerüljön az ellenőrzőlistára: protokoll, TLS 1.3, sharding, preconnect?

Négy ellenőrzés, amelyet egy délután alatt végig tudsz vinni, és amely protokoll-szinten rendbe teszi az oldalt.

1. Protokoll ellenőrzése

• DevTools Protocol oszlop: a saját domain fájljai h2 vagy h3 jelzést kapnak.
• A curl -sI --http2 válasza HTTP/2.
• HTTP/3 esetén megvan az Alt-Svc fejléc, és második betöltéskor h3 látszik.
• A www-s és a www nélküli változat, valamint az átirányítások is ugyanígy viselkednek.

2. TLS 1.3 megléte

• Az SSL Labs vagy az openssl s_client szerint elérhető a TLS 1.3.
• Hivatalosan igazolt: a TLS 1.3 (RFC 8446) teljes kézfogása egy oda-vissza körrel rövidebb, mint a TLS 1.2-é, a HTTP/3 pedig eleve csak TLS 1.3-mal működik.
• A TLS 1.0 és 1.1 legyen kikapcsolva, ezeket a nagy böngészők már nem fogadják el.
• A tanúsítványlánc legyen teljes (a köztes tanúsítványt is szolgálja ki a szerver), a hiányát az SSL Labs jelzi.

3. Domain-darabolás (sharding) eltávolítása

HTTP/1.1 idején bevett trükk volt a statikus fájlokat több aldomainre szórni (img1.pelda.hu, img2.pelda.hu), hogy a böngésző több párhuzamos kapcsolatot nyisson. Hivatalosan igazolt: HTTP/2 és HTTP/3 alatt egy kapcsolaton minden párhuzamosan megy, így minden extra hoszt csak újabb DNS-lekérdezést, TCP- és TLS-kézfogást jelent. Saját tapasztalat: régi sablonokban és egykori „static” aldomaines beállításokban ma is előfordul.

• A DevTools Domain oszlopában nézd meg, hány saját aldomainről jönnek fájlok.
• Ha a statikus fájlok csak azért mennek külön aldomainre, mert régen így volt gyorsabb, vezesd vissza őket a fő domainre, és indexelt képeknél állíts be 301-es átirányítást a régi címekről.
• Rokon örökség a mindent egy fájlba fűzés: mérsékelt összevonás a tömörítés miatt ma is hasznos lehet, de pusztán a kérésszám csökkentéséért már nem éri meg bonyolítani.

4. Előzetes kapcsolódás (preconnect)

Ha az oldal elején biztosan kell egy külső domain (betűkészlet, CDN, képkiszolgáló), jelezheted a böngészőnek, hogy előre építse fel a kapcsolatot: <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

• Csak az első képernyőhöz tényleg szükséges 2-3 külső domainre használd, mert a felesleges előzetes kapcsolat erőforrást vesz el a fontosabbaktól.
• A crossorigin attribútum a betűkészleteknél kell, mert azok CORS-módban töltődnek.
• Kevésbé fontos domainekre elég a dns-prefetch.
• Ha a betűkészletet saját tárhelyről szolgálod ki, erre a preconnectre nincs szükség, és eggyel kevesebb kapcsolat épül.

Mi hivatalos, mi tapasztalat és mi feltételezés ebben a témában?

A protokollok működése szabványokban rögzített, a hatásuk mértéke viszont oldalanként eltér, ezért mérni kell.

• Hivatalosan igazolt: a HTTP/2 multiplexálása, a HTTP/3 QUIC-alapú működése, a TLS 1.3 szükségessége HTTP/3-nál, az Alt-Svc alapú felfedezés, a Googlebot rangsorolási előny nélküli HTTP/2-es feltérképezése és a 2,5 másodperces LCP-határ.
• Saját tapasztalat: a protokoll-váltás tipikus 50-200 ms-os hatása KKV-oldalakon, a túlméretezett nyitókép 2 másodperc körüli költsége, a hazai tárhelyek HTTP/2-es alapállapota és a régi sablonokban maradt sharding.
• Szakmai feltételezés: a HTTP/3 többlet processzorigénye osztott tárhelyen, illetve hogy stabil, közeli vezetékes kapcsolatnál a HTTP/3 előnye jellemzően nem mérhető.

A protokoll-váltás jó eséllyel kicsi, de valós javulást ad, és nem garantál jobb Core Web Vitals-értéket vagy jobb helyezést. Ha csak egy dolgot jegyzel meg: előbb a kép, aztán a protokoll.

Források és további olvasnivalók

• IETF RFC 9113: HTTP/2
• IETF RFC 9114: HTTP/3
• IETF RFC 9000: QUIC
• IETF RFC 8446: TLS 1.3
• Google Search Central Blog: Googlebot crawling over HTTP/2
• web.dev (Google): Largest Contentful Paint; preconnect és dns-prefetch
• Chrome DevTools dokumentáció: Network panel
• MDN Web Docs: Alt-Svc, rel=preconnect
• curl dokumentáció: HTTP/3
• Apache HTTP Server dokumentáció: mod_http2
• nginx dokumentáció: ngx_http_v3_module