Přejít k navigační liště

Zdroják » Zprávičky » Zmenšujeme velikost HTML souboru

Zmenšujeme velikost HTML souboru

Zprávičky Webdesign

Pokud vyvíjíme web, u něhož záleží na velikosti přenášených souborů, sáhneme pravděpodobně po kompresní metodě gzip, která je dnes v prohlížečích široce podporována. Zajímavou alternativou však může být i zmenšení velikosti kódu vypuštěním prázdných znaků, které parser ignoruje. Tento postup je známý a celkem běžně používaný u CSS i u JavaScriptu, ale lze jej použít i pro HTML. Nástrojů pro zmenšování kódu (minify – minifier) existuje jak pro JS, tak pro CSS velké množství, ale pro HTML téměř žádný. Obsáhlý článek na weblogu Perfection Kills s názvem Experimenting with  HTML minifier rozebírá postup při zmenšování velikosti HTML souboru a na praktických příkladech ukazuje výsledky takové optimalizace, která leckdy sníží velikost výsledného kódu mnohem víc než gzip.

Komentáře

Odebírat
Upozornit na
guest
4 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
Zobrazit všechny komentáře
Ruthion

Dovolím si nesouhlasit s větou:

“ ..leckdy sníží velikost výsledného kódu mnohem víc než gzip…“

Správně měla být “ … nekomprimovaný dokument je zmenšen více, než jeho komprimovaná verze“, což je celkem očekávané.

Pro ty, kdo se nechtějí prokousávat odkazovaným článkem bych ještě vypíchnul, že mnohé optimalizace mají vliv na interpretaci a zobrazení dokumentu browserem či na jeho DOM reprezentaci a i sám autor uvádí jako nejlepší metodu napsat HTML jako čisté HTML a nikoli jako HTML + CSS + JS, což obvykle ušetří nejvíce. A samozřejmě výsledek pak posílat gzipnutý.

rooobertek

Ja prihodím, že v Smarty sa dá prostredníctvom {strip} poskracovať kadečo, ale môže to mať aj neblahé dôsledky, tak opatrne s tým.

František Kučera

Ono by hodně pomohlo, kdyby autoři do webů nedávali tolik divů a spanů – mnohdy jsou zbytečné a když se člověk podívá na zdroják nějaké stránky, často je vidět, že si s tím autor vůbec nelámal hlavu a prostě tam nasekal spousty elementů navíc („hlavně ať to vypadá dobře“), milion wrapperů.

jiri

prohnat validátory na W3C (před a po použití miniferu) a obavám se, že by při použití musely ze spousty stránek zmizet takové ty obrázky o kompatibilitě… :-)))

Baro vs. Claude Code: Když paralelní agenti prohrají s jedním sezením (a co s tím udělat)

AI
Komentáře: 0
Více agentů musí být rychlejší než jeden, ne? Miodrag Todorović z JigJoy postavil baro - CLI, které paralelně spouští pět Claude sezení místo jednoho - a postavil ho proti novému příkazu /goal v Claude Code. Čekal jasnou výhru paralelismu. Místo toho prohrál v čase, v tokenech i v kvalitě výsledného kódu. Z analýzy tří konkrétních selhání ale vyšel jeden nečekaný závěr: problém nebyl v koordinaci mezi agenty, ale v rozhodnutích, která padla ještě před tím, než se kdokoli z nich probudil. Oprava trvala 200 řádků kódu - a v odvetě baro porazilo /goal o 4 minuty.

WebGPU už mají všechny hlavní enginy. Hotový standard z něj W3C dělat nechce

Na jaře 2026 už WebGPU není jen záležitost Chromia nebo preview buildů. Chrome, Edge, Safari i Firefox ho dodávají v produkčních verzích, ale ne na stejných platfórmach a ne se stejnými limity. WebGPU navíc podle aktuální charty pracovní skupiny nemíří z Candidate Recommendation do W3C Recommendation. Pro vývojáře je proto důležitější konkrétní podpora, fallbacky a limity paměti než formální status standardu.