HTTP/3 Priority: Jak prohlížeče a servery určují pořadí načítání obsahu
Prohlížeč při načítání stránky žádá o HTML, CSS, JavaScript, obrázky i další soubory. Některé z nich potřebuje k prvnímu zobrazení, jiné mohou počkat. HTTP/3 umožňuje přenášet více požadavků současně, samo ale neurčuje pevné pořadí, v jakém musí server jejich obsah odeslat. O prioritě rozhoduje souhra odhadů prohlížeče, signálů v protokolu a plánovače serveru.
HTTP/3 přenáší požadavky souběžně
HTTP/3 běží nad protokolem QUIC. Každá dvojice požadavek–odpověď využívá vlastní proud, takže více odpovědí může postupovat současně. Ztráta paketu na jednom proudu sama o sobě nezastaví přenos na ostatních. To však neznamená, že všechny prostředky dostávají stejný díl přenosové kapacity. Server musí rozhodnout, kterým odpovědím bude data posílat dříve nebo ve větším množství.

Důležité je rozlišit pořadí požadavků od pořadí odesílání jejich dat. Prohlížeč může požadavky na několik zdrojů zahájit téměř zároveň. Server pak podle priorit a vlastního plánovače rozhoduje, jak bude jejich obsah průběžně posílat.
Nejprve rozhoduje prohlížeč
Ještě před odesláním požadavku musí prohlížeč zjistit, které soubory stránka potřebuje. HTML mu může odhalit například CSS nebo obrázek přímo v dokumentu, zatímco obrázek uvedený až v externím souboru CSS objeví později, píše server web.dev.
Na výsledné prioritě se podílí také typ prostředku, jeho umístění v dokumentu, vlastnosti skriptů a to, zda obrázek leží v právě viditelné části stránky. Konkrétní pravidla se mohou mezi prohlížeči lišit.
Prohlížeč například obvykle upřednostní CSS potřebné k vykreslení stránky. Obrázky mohou zpočátku dostat nižší prioritu a po zjištění jejich polohy na stránce ji prohlížeč upraví. Vývojář může prohlížeči napovědět pomocí atributu fetchpriority. U důležitého úvodního obrázku může použít například:
<img src=“/images/uvodni-fotografie.webp“
fetchpriority=“high“
alt=“Úvodní fotografie“>
Hodnoty high, low a auto vyjadřují relativní pokyn. Nejde o příkaz, který by přebíjel všechna pravidla prohlížeče. U obrázku, který není pro první zobrazení důležitý, může naopak pomoci fetchpriority=“low“.
Jak prioritu vyjadřuje HTTP
Současný standard pro priority HTTP popisuje RFC 9218. Zavedl hlavičku Priority, která může nést informaci o počáteční prioritě napříč verzemi HTTP, a rámec PRIORITY_UPDATE pro její pozdější změnu.
U HTTP/3 se tento rámec posílá na řídicím proudu a může se vztahovat ke konkrétnímu požadavku. Prohlížeč tak může prioritu upravit i poté, co požadavek zahájil.
Základní parametry jsou dva:
| Parametr | Co vyjadřuje |
| u – urgency | Naléhavost odpovědi. Hodnota je od 0 do 7; nižší číslo znamená vyšší prioritu. |
| i – incremental | Zda lze obsah průběžně zpracovávat po částech. |
Požadavek Priority: u=0 tedy signalizuje vysokou naléhavost. Zápis Priority: u=5, i označuje méně naléhavou odpověď, kterou lze zpracovávat postupně. Pokud parametr u chybí, jeho výchozí hodnota je 3. Výchozí hodnota i znamená, že odpověď není označena jako průběžně zpracovatelná. Tyto hodnoty jsou vodítkem pro plánování přenosu, nikoli zárukou pořadí.
Server může signály zohlednit, nebo ignorovat
Priorita od prohlížeče představuje jeho odhad, které odpovědi pomohou stránku zobrazit dříve. Server má ale vlastní informace a omezení. Může například zohlednit konfiguraci aplikace, dostupnost dat nebo pravidla CDN.
Standard mu proto dovoluje rozhodnout, jak požadavky obslouží, a signály klienta případně ignorovat. Podle RFC 9218 slouží priority serveru jako vodítko při plánování odpovědí. Server je může zohlednit, ale výsledné pořadí odesílání určuje jeho vlastní plánovač.
Pokud má více požadavků stejnou prioritu, může server například posílat nejprve celé odpovědi, které klient potřebuje vcelku, a u jiných odpovědí rozdělovat kapacitu mezi více proudů. Přesná strategie závisí na implementaci.
Změnit pohled na prioritu může také prostředník, například CDN mezi prohlížečem a původním serverem. RFC 9218 počítá i s hlavičkou Priority v odpovědi, kterou může server sdělit svůj pohled dalšímu prostředníku.
Proto může prohlížeč požadavek označit jako důležitý, aniž by server skutečně odeslal jeho data jako první. A naopak server či CDN mohou při plánování využít znalost aplikace, kterou samotný prohlížeč nemá.
Jak priority ověřit při ladění webu
V Chrome lze při testování otevřít DevTools → Network a zobrazit sloupec Priority. Panel Performance navíc ukazuje počáteční i výslednou prioritu požadavku. Pokud se jejich hodnoty liší, prohlížeč ji během načítání změnil.
Při ladění má smysl ověřit, zda se důležitý obsah objeví v HTML dostatečně brzy, zda se klíčové obrázky nenačítají líně a zda fetchpriority nepřiděluje vysokou prioritu příliš mnoha souborům.
Vyplatí se také porovnat výsledek při opakovaných měřeních a sledovat nejen pořadí požadavků, ale i dobu, kdy dorazí jejich první a poslední data. Prioritizace pomáhá lépe rozdělit dostupnou kapacitu. Sama však nenahradí optimalizaci velikosti souborů, serveru ani vykreslování stránky.








