Mogelijk duplicaat:
Waarom items verkleinen en niet de markup?
Ik heb veel sites gezien die verkleinde CSS en JavaScript gebruiken om de responstijd van websites te verhogen, maar ik heb nog nooit sites gezien die verkleinde HTML gebruiken. Waarom zou je niet willen dat je HTML wordt verkleind?
Antwoord 1, autoriteit 100%
Omdat als je de dingen goed doet, je HTML toch gegzipt aanbiedt, dus het laaghangende fruit van HTML-verkleining – witruimte – is niet zo relevant. Er zijn niet veel gemakkelijke doelen (bijvoorbeeld namen van variabelen) voor minificatie in HTML, die aanwezig zijn in CSS en JavaScript. Veel van de inhoud van HTML is de feitelijke inhoudvan de pagina, die waarschijnlijk niet kan worden verkleind (en, zoals anderen al hebben opgemerkt, zal vrijwel zeker vaker variëren dan uw CSS of JS).
Antwoord 2, autoriteit 99%
Ik vermoed dat de meeste sites statische CSS en Javascript hebben. Dit betekent dat ze slechts één keer kunnen worden verkleind wanneer ze worden bijgewerkt. Aan de andere kant wordt HTML meestal dynamisch gegenereerd, wat betekent dat het bij elk paginaverzoek moet worden verkleind, wat aanzienlijk duurder is dan het verkleinen van statische CSS- en Javascript-bestanden.
Antwoord 3, autoriteit 12%
Ik denk niet dat er zoveel ruimte is voor verkleining in HTML: je kunt spaties en regeleinden verwijderen, maar in wezen is dat het zo’n beetje zonder echt in de structuur van de pagina te komen.
JS-minificatie kan namen van variabelen en functies inkorten, waarschijnlijk de grootste nettowinst in termen van bespaarde ruimte. Met zijn vaste set tags biedt HTML die mogelijkheid niet.
De optie om HTML te gzippen elimineert waarschijnlijk een groot deel van de noodzaak om hoe dan ook te verkleinen, vooral omdat het meestal is ingeschakeld voor HTML, terwijl dit (onnodig) niet altijd is voor de CSS- en JS-bestandstypen.
Antwoord 4, autoriteit 7%
Voornamelijk omdat Javascript-bestanden en CSS-stylesheets vaak statische bestanden zijn die bij implementatie niet veranderen. Markup wordt daarentegen vaak on-the-fly gegenereerd (tenminste met database-gestuurde web-apps), en het aantal “pagina’s” is meestal groot en dynamisch, waardoor de voordelen van minificatie meer werk dan het waard is.
Antwoord 5, autoriteit 4%
Html-inhoud die wordt gegzipt, zorgt voor het grootste deel van de compressie, en bovendien zou verkleinen niet veel opleveren of veel bandbreedte besparen.
Javascript dat je kunt verkleinen als onderdeel van de build, de enige manier waarop dit zou gebeuren met de volledige HTML-inhoud zou zijn om elk stuk te verkleinen (wat als het wordt gegenereerd?) of om het de hele tijd te verkleinen (nachtmerrie om aan te werken ?)
Het is kosten versus voordeel, kosten: marginale bandbreedte, voordeel: gemakkelijker om aan te werken, gemakkelijker te genereren, gemakkelijker te debuggen, mooi in mijn bronvenster.