In un post avevo già  portato all'attenzione dei lettori i vantaggi/svantaggi che si ottengono dalla minimizzazione del codice CSS e JavaScript. L'obiettivo è sempre lo stesso: tentare di velocizzare lo scaricamento dei file e quindi ottenere una maggiore rapidità  d'esecuzione. Fino a qui gli strumenti degli sviluppatori si sono concentrati principalmente sulle librerie Javascript e sui fogli di stile. Oggi invece tentiamo di capire se può essere buona cosa eseguire lo stesso procedimento su un file HTML.

Di per sé al browser poco importa del grado di leggibilità  di un documento HTML. Esattamente il contrario di quanto direbbe uno sviluppatore che ha bisogno di un codice pulito da leggere, ben indentato e magari anche commentato opportunamente. Cià si traduce in un utilizzo massiccio di spazi bianchi e commenti che Juriy Zaytsev definisce puro overhead per la banda e la dimensione finale del file. Così l'autore dell'articolo ha pensato bene di scrivere, in Javascript, un tool che minimizza anche un sorgente HTML eliminando spazi bianchi, commenti e attributi deprecati. Già  perché Zaytsev punta il dito pure sull'utilizzo di CSS inline e di molti attributi definiti depracated dallo standard. Tramite il suo tool un programmatore può anche decidere il grado di minimizzazione.

Ora il problema è capire quanto questo approccio può essere fattibile e/o utile.

19 CommentiDi' la tua

Il tuo indirizzo email non sarà mostrato pubblicamente. I campi obbligatori sono contrassegnati da *

Qui parlate solo del risparmio in termini di banda. Ma non e' l'unico risparmio! Ci sono ambienti dove ogni singolo byte risparmiato "su disco" diventa importantissimo, addirittura essenziale. Un esempio e' una admin interface web che sto sviluppando per un dispositivo deeply embedded ( su una MCU a 8bit ), dove in TOTALE ho 128k di spazio su eeprom, e ci devo far stare bootloader, firmware con tanto di stack tcp/ip e webserver, spazio per le configurazioni dinamiche e, ovviamente, TUTTO il sito web, js, html e immagini comprese. In un ambiente come questo minificare in maniera estrema e' un MUST assoluto.

nextime
nextime

Giusto. E' difficile che i css\js cambiano mentre é molto probabile che i contenti vengano aggiornati (tipo nelle home page o nelle pagine di sezione), quindi un sistema di ottimizzazione\cache come per i css\js avrebbe poco senso per l'html puro.

TaTaC
TaTaC

TaTaC, quello che dici ha senso... però a questo punto il discorso vale anche per la minificazione di js e css... si elemosinano comunque pochi kb... e pochi kb di fronte a un jpg di mezzo mega messo lì per decorare uno sfondo... insomma... se la cosa ha senso, ha senso come buona pratica... e in prospettiva macroscopica... pochi kb moltiplicati per tutti gli utenti... ad ogni modo... porsi il problema é già  qualcosa...

EsseZeta
EsseZeta

@EsseZeta Per me é TOTALMENTE inutile, e sul campo nessun network ad oggi si é spinto a questo livello di compressione. Prendete come esempio: http://www.nytimes.com http://www.corriere.it Queste tecniche rasentano il la Nerd-Fantascienza quando i siti che hanno milioni di accessi sono obesi da banner flash, animazioni, e un sacco di immagini che cambiano ad ogni refresh e quindi non godono dei vantaggi della cache del browser. In quest'ottica dove una home page può arrivare e superare i 400-500 KB stiamo elemosinando poche decine di KB che tra l'altro vengono gestite dalla cache del browser dal secondo accesso!!! Va bene la compressione dei javascritp e css... va bene unire tutti questi file per ridurre le chiamate http... ma mettersi a toccare anche i nomi delle classi\id mi sembra INUTILE.

TaTaC
TaTaC

ecco, finalmente qualcuno l'ha detto... DAG nell'11

E poi, se proprio vogliamo sottilizzare, molti byte sono occupati dai “name” e dagli “id” dei tag
oltre all'eliminazione degli spazi e dei commenti ecc... non sarebbe male sostituire a "header" "footer" "entry" rispettivamente "he" "fo" "en"... naturalmente in produzione... DOPO aver scritto un master con indentazione e con tutti i commenti che si vuole... uno scriptino che riassegna accorciati-e-senza-sovrapposizione i nomi delle classi e degli id?

EsseZeta
EsseZeta

@gzip per come la vedo farlo non da nessun fastidio quindi perché no? Vediamo 100byte per 2.500.000 richieste giornaliere (e non sono nemmeno tutte perché parli di accessi e non di pagine visitate dove presumo, lo script viene sempre richiamato, ma la cache... va be' lasciamo da parte il discorso) fanno esattamente 244.144,625 Kbyte giornalieri risparmiati, cioé un quarto di megabyte al giorno che per 30 giorni (conto commerciale) fanno 7.324.218,75 Kbyte, cioé circa 7 mega di banda risparmiata al mese. Indubbiamente una miseria! E sarebbe poco più di una miseria se oltre al javascript ci metti anche il foglio di stile e lo xhtml delle pagine, insomma poca roba. Forse il sito si velocizzerebbe e di molto se togli 100K di Javascript, ma davvero uno script così lungo? :-O A parte gli scherzi, i sitemi di minifier non riducono di molto la dimensione del file, meglio comprimere o come già  detto e ribadito da @scienza.... implementarvi anche un sistema di caching, il fatto é che ci siamo dimenticati che in Italia ad esempio solo il 50% dei "naviganti" ha l'adsl e quindi scaricare da internet anche 100byte in meno significa leggere prima la pagina richiesta, e poi le limature si fanno anche così, d'altronde se no non sarebbero limature. Infine il farlo o il non farlo cosa cambia? Nulla? Io lo faccio almeno fino a quando non scopro che fa male :-) M.

Marco Grazia
Marco Grazia

Lavoro per un'azienda che ha un sito che fa 2.500.000 accessi mensili e vi assicuro che nessun javascript, css o html é minificato. Anzi... sono belli identati e larghi! A che servirebbe poi? Ad esempio: se ho un javascript da 100k che gzippato risulta di 4k se dovessi minificarlo arriverei a quanto? Facciamo anche 80k? che gzippati risultano essere 3,9k. Quindi? dovrei continuamente minificare e massimizzare i files (altrimenti illeggibili) per un risparmio di 100 bytes??? Assurdo.

gzip
gzip

Secondo me una cosa del genere potrebbe essere utile se applicata ad un sistema di caching lato server: non pregiudicherebbe la manutenzione del codice e non porterebbe lavoro extra. Altrimenti lo vedo come qualcosa di sostanzialmente inutile, da fare a tempo perso. Difficile che quel 2% sia un tale problema.

scienzedellevanghe
scienzedellevanghe

@Kiko

Riassumendo la pratica porta reali benefici in termini di guadagno di tempo e di spazio?
Dipende. 1. da quanto é messo male il codice di partenza 2. da quanto traffico fa il sito 3. da quanta banda hai a disposizione 4. ... Se la pagina é piena zeppa di spazi inutili, commenti chilometrici e attributi deprecati il risparmio c'é; ma se fai 5 visite al mese e non arrivi a coprire neanche il 2% della banda massima disponibile non serve a nulla minimizzare. Ma forse, anche se facessi 1.000.000 di accessi mensili, risparmiare il 2% non avrebbe alcun valore... Probabilmente con un numero di accessi tale, faresti così tanto traffico da rendere comunque insignificante la presenza o meno di quel 2% di banda occupata. E poi, se proprio vogliamo sottilizzare, molti byte sono occupati dai "name" e dagli "id" dei tag... Ricordate "quel pazzo" che ha riscritto Super Mario Bros in javascript con un codice di soli 14Kb? Le variabili usate erano a, b, c, etc.

DAG
DAG

Interessante il tuo calcolo, @DAG. Io fra un po' provo lo stesso meccanismo sui lunghi manuali della GNU, così per vedere l'effetto che fa. Intendo il manuale contenuto in un unico file HTML. Riassumendo la pratica porta reali benefici in termini di guadagno di tempo e di spazio?

Kiko
Kiko