2010-08-19 2 views
5

Mi chiedo se posso dire che i pre-processori di LESS/SASS CSS "(penso che siano chiamati?)" sono l'opposto delle ottimizzazioni come la minificazione? Mi chiedo se ci sarà qualche impatto notevole sulle prestazioni? o pensi che sia facile lo sviluppo è più importante?LESS/SASS CSS opposto a minificazione/ottimizzazioni?

Lo chiedo perché ciò MENO CSS genera è qualcosa di simile

body #div1 #div2 p 
body #div1 #div2 p a:link, body #div1 #div2 p a:visited 
... 

e penso che può davvero gonfiare il mio CSS un bel po '. come potete vedere, tale specificità non è richiesta e rende difficile la lettura di CSS (almeno quello che vedo in firebug).

+0

'o pensi che sia facile lo sviluppo è più importante?" Dimmi, che è più importante: 5 millisecondi di una macchina che analizza il CSS (almeno in un browser moderno, è accurato), considerando che il tempo della CPU è così è quasi gratis, o dieci minuti in più per il giorno dello sviluppatore, che è il tempo umano? –

risposta

2

Sareste sorpresi, ma i file CSS compressi con blocchi ripetuti di codice non dovrebbero essere troppo più grandi di quelli con i selettori più brevi.

Ciò è dovuto al modo in cui l'algoritmo di compressione gestisce stringhe duplicate in un file. Invece di includere la stessa stringa due volte, sostituisce la seconda occorrenza con un riferimento al primo e in modo tale che la stringa venga visualizzata solo una volta nel file compresso. Dai un'occhiata a come sono ripetitivi i selettori nel tuo file CSS generato - questo dovrebbe farli comprimere abbastanza bene.

Naturalmente, la chiave per questo è assicurarsi che i file CSS siano compressi con gzip; se non vengono compressi, aumenteranno sicuramente le dimensioni del file.

1

A seconda dello options, SASS può fornire l'output in stili diversi. Per la produzione, ti consigliamo di impostare lo stile di output su 'compatto'.

4

In Sass è possibile controllare 'specificity bloat' capendo come funziona nesting. Non devi assolutamente fare nidificazione se non vuoi: è qualcosa che puoi controllare.

Utilizzando il nuovo @extend directive, si può effettivamente ridurre la ridondanza nel CSS applicando le priciples di OOCSS e possono quindi migliorare le prestazioni. Ecco un buon articolo per get you started with @extend. E un paio di risorse OOCSS:

Il grande vantaggio di @extend in Sass è che ci vuole lo sforzo manuale coinvolti nell'applicazione OOCSS e rende più meravigliosamente indolore e facile. Infine, come sottolineò Andrea, Sass ha una varietà di opzioni per la minifrazione dei CSS (vedi lo :compressed style), quindi in generale hai un kit di strumenti piuttosto potente per migliorare non solo le tue prestazioni come sviluppatore, ma anche migliorare le prestazioni del tuo CSS. Per un esempio di questo in azione, vedere come Chris Eppstein, autore di Compass e contributore principale di Sass, refactors the Digg stylesheet giù da 125 righe di codice a 85 righe di codice (una riduzione del 32%).

0

C'è un addon firebug per sass che dovrebbe rendere le cose più facili da leggere. Non hai davvero bisogno di leggere l'output direttamente comunque.

Sass, less e xCSS generano più output ma non lo chiamerei gonfio.

CSS scritto a mano, con le sue numerose ridondanze e le duplicazioni si degraderanno rapidamente mentre gli sviluppatori accumulano gli spazi dei nomi sopra gli altri durante il ciclo di vita del codice. Uno dei sintomi di software mal gestito, progettato o scritto è ingigantito. E dato che i CSS hanno alcune lacune progettuali sin dall'inizio, anche i migliori codificatori CSS sono influenzati da questa limitazione.

Quindi devi valutare l'impronta iniziale del tuo file ben formattato/meno rispetto a un file CSS scritto a mano che è stato modificato alcune volte.

Un altro vantaggio su sass è che il codice HTML diventa più snello. Non è necessario aggiungere nomi di classi nel codice per compensare la struttura piatta e globale dei CSS.