wieso soll less / sass schneller sein?

[afr0kalypse]

moin zusammen,
ich habe jetzt einige artikel zum thema website / webserver optimierung gelesen und bei den meisten steht dann immer, dass man der ressourcen und der geschwindigkeit wegen einen css precompiler wie sass oder less nutzen soll.

ich verstehe aber absolut nicht, wo die jetzt schneller sein sollen gegenüber sauber geschriebenem css code.
ich habe mir jetzt mal less auf meinem webserver installiert und nutze das auch nur serverseitig. das heißt ich erstelle mir eine style.less datei, schreibe da irgendwas rein und compiliere daraus eine style.css datei. auf die style.css datei greift dann meine index.html zu. das ist dann doch völlig egal ob ich less nutze oder nicht.

wie kommen die nun alle darauf, dass das ressourcenschonender und schneller sein soll? kann mir das mal wer erklären?

 

[Duddle]

AW: wieso soll less / sass schneller sein?

Kannst du bitte die Seite verlinken, die behauptet, ein CSS Preprocessor mache die Seite schneller? Wie du schon sagst macht das keinen Sinn. Nur eine Optimierung des CSS-Codes (Regeln zusammenfassen u.ä.) kann die Dateigröße verkleinern, aber das ist maximal ein Extra-Feature des Preprocessors.

Edit: ich korrigiere mich. Wenn du es clientseitig verwendest und die Summe aus Preprocessor-Script + (LE/SA)SS-Datei kleiner als eine (erzeugte) CSS-Datei ist, ist zumindest die Übertragung schneller. Ob die clientseitige Umwandlung dann immer noch performanter ist als die direkte Interpretation des CSS weiß ich nicht. Es gibt da sicher irgendwo Benchmarks.


Duddle

 

[afr0kalypse]

AW: wieso soll less / sass schneller sein?

Hey duddle, danke für die Info. Das bezog sich tatsächlich auf die clientseitige Lösung. Ansonsten ist wohl nur die Kompimierung auf Serverseite etwas ressourcenschonender

 

[cythux]

AW: wieso soll less / sass schneller sein?

http://css-tricks.com/sass-vs-less/

was wirklich der performence gut tut, ist gzip aktiervierung
style.css.min/
js.js.min

gelesen wird dann bei less :
eine style.less - benötigt jeoch less,js ebenfalls
aus zb. style.scss - wird eine style.css sass schreibt diese dann, sauber und auch prefixes für die anderen Browser rein.

bin mir hier da wenn die Zeit da ist sass an am eignen, jedoch noch nicht im Produktiven Workflow

 

[mindraper]

AW: wieso soll less / sass schneller sein?

moin,

wer schnellere interpretation von css haben möchte, sollte sich mit themen wie "OOCSS" und/oder "SMACSS" befassen, sowie mit der performance, mit der selektoren interpretiert werden als auch welche performance einbußen bestimmte CSS3 eigenschaften (bspl. border-radius) auf repaint/reflow haben.

SMACSS
artikel zu OOCSS



in aller regel führt der einsatz eines preprocessors nicht zu schnellerem css, eher das gegenteil ist der fall: durch mixins, etc. werden code-teile dupliziert/in verschiedene classes erneut eingerendert. beispiel:

/* mixin in LESS */
.radius(@rad: 10px) {
    border-radius: @rad;
}

/* classes */
.button {
    .radius;
}

#header {
    .radius;
}

#nav {
    .radius(20px);
}

#main {
    .radius(20px);
}

#footer {
    .radius;
}

erzeugt folgenden css code:

.button {
    border-radius: 10px;
}

#header {
    border-radius: 10px;
}

#nav {
    border-radius: 20px;
}

#main {
    border-radius: 20px;
}

#footer {
    border-radius: 10px;
}

korrekt? der "OOCSS" (ebenso der "SMACSS", wenn auch nicht ganz so "strikt" wie bei "OOCSS") ansatz ist hier, einfach zwei classes zu setzen und diese auf die entsprechenden elemente zu werfen:

.radius-10px {
    border-radius: 10px;
}

.radius-20px {
    border-radius: 20px;
}

das ist – css seitig betrachtet – sehr viel kürzer als der einsatz eines preprocessors, egal ob LESS/SASS/Stylus/wie-immer-die-auch-alle-heissen.

allerdings sind das nur tropfen auf den heißen stein – die wirklich performance intensiven CSS geschichten haben mit reflows und repaints des browsers zu tun. und das beginnt, wie kangax bewiesen hat, schon beim ersten laden der seite.