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.