Vlákno názorů k článku Google a Cloudflare chtějí postkvantově zajistit certifikáty a nerozbít přitom web od Mmmartan - Doopravdy je problém těch pár desítek KB při...

Doopravdy je problém těch pár desítek KB při přenostu dat? Běžné js/css u frameworků mají stovky KB, reklamní shit má dneska megabajty...

Spíš to bude o tom výkonu na straně serverů, to by se asi poznalo víc než samotný přenos...

Pre server su to tiez staticke data, navyse ich posiela len pri navezovani spojenia (nie pre kazdy request).

Problém není samotný objem, ale to, že se to musí přenést na začátku spojení před tím, než se přenese cokoli „užitečného“. Nebo-li když uživatel klikne na webu (třeba ve vyhledávači) na odkaz na jiný web, bude přesně o přenos těchto pár desítek kB navíc čekat déle, než se zobrazí stránka (posunou se o to všechny fáze zobrazení (první zobrazení, LCP, INP).

Velikost souborů můžete optimalizovat, můžete zmenšovat kritické CSS, můžete renderovat HTML na serveru, a tím vším urychlovat první zobrazení stránky. To, že se pak na pozadí přenášejí další velká data (další styly, skripty, obrázky) nevadí, pokud uživatel vidí co potřebuje a ideálně i může se stránkou interagovat. Pro další načítání z téhož webu si může prohlížeč držet otevřená spojení, může číst z cache, může si TLS spojení otvírat dřív, než uzavře staré spojení. Ale s úvodním navázáním spojení neuděláte nic, to tam musí být vždy. A zrovna je to kritická část, která výrazně ovlivňuje první dojem uživatele.

Proto je snaha to co nejvíce urychlit – proto prohlížeče řeší i rychlost dotazování DNS (a proto odmítají DANE), proto byl do DNS přidán HTTPS záznam (aby prohlížeč jednou odpovědí získal všechny potřebné informace a rovnou na první pokus se připojil správným způsobem), proto HTTP/3 používá UDP místo TCP (aby se obešlo pomalý TCP handshake následovaný TLS handshakem).

Jak vidíte, řeší se při tom navázání spojení jednotlivé pakety a jejich velikost, takže „pár desítek kB“ je opravdu citelná rána.