Ingebakken style vs. externe stylesheet(s)

[stereohead]

Ik ben bezig met een cms waarbij de css die nodig is voor een pagina dynamisch wordt gegenereerd, dat wil zeggen, alleen de css die nodig is wordt meegestuurt.

Nu kan ik kiezen om die css in de <style> tags in de head van pagina te zetten, of de css in een aparte stylesheet te zetten, en in de html een link daarna te maken.

Ik vroeg me af wat nu eigenlijk beter is qua performance.

Als de css ingebakken is, hoeft er maar 1 bestand gedownload te worden door de browser, de vraag is: is dit sneller dan 2 aparte bestanden downloaden?

Ik hoop dat iemand hier een duidelijk antwoord op heeft


PS: staat het topic hier goed?

[Dennahz]

Met een extern bestand kan je 1 wijziging aanbrengen waarna het op alle pagina's veranderd is. Als je in elk bestand een ingebakken <style> zet moet je het alsnog per bestand aanpassen.

_{En nee, hij staat hier niet goed. Dit is meer webdesign dacht ik.}

[Haan]

Zodra je die stylesheet in meer dan 1 pagina gaat gebruiken, is het al efficiënter om een losse style sheet te gebruiken.

[Verwijderd]

Eterne CSS kan (mits onaangepast) gecached worden door de client-browser. Ik stuur dus het liefst alle css in 1 file, gescheiden van de html layout.

Bij dynamisch creëren van een CSS gaat dit niet op. Die (herhaaldelijke) tweede HTTP-request voorkom je wel door inline CSS, maar de data moet steeds weer over internet gestuurd worden. Een winst dus die nihil is.

[Tofu]

Volgens mij kan je beter je CSS opsplitsen in een aantal deeltjes. Bijvoorbeeld 1 hoofd CSS die je altijd nodig hebt en 3 sub-CSS-bestanden. Zo kan je alsnog dynamisch bepalen welke je meestuurt, en verlies kan er toch een cache van je CSS bestanden bij de client bewaard worden.

[Ramon]

Ik zou dat dynamisch genereren zeker niet doen. Wat hierboven gezegd wordt als jij een extern CSS bestand heb dan wordt dat door de browser gecached waardoor die het maar één keer hoeft te laden.
Als jij telkens een nieuw CSS bestand genereert werkt dat cachen niet en zal de browser elke keer de css opnieuw binnenhalen.

[stereohead]

Dank voor de snelle reacties!

@ Dennahz en Haan:
De css wordt dynamisch gegenereerd hè zowel als ik het inbak en als ik een externe stylesheet gebruik. Het gaat hier puur om de performance.


Ok, de hoeveelheid data is dus hetzelfde, maar zal je het verschil merken tussen het downloaden van 1 groot bestand en 2 kleinere bestanden?


De vraag wordt dus nu:

Als je 2 bestanden gebruikt moet de browser 2 keer een connectie maken met de server, moet je dan ook als totale tijd 2 x de ping + downloadtijd van de bestanden rekenen?

[ Voor 9% gewijzigd door stereohead op 10-05-2008 10:08 ]

[Tofu]

http://stevesouders.com/cuzillion/ daar kan je dat uitproberen voor verschillende browsers. Maar CSS dynamisch aanmaken is sowieso performance-technisch een slecht idee!

[NMe]

Waar hoort mijn topic?

SEA>>WEB

[Gomez12]

stereohead schreef op zaterdag 10 mei 2008 @ 10:06:
De vraag wordt dus nu:

Als je 2 bestanden gebruikt moet de browser 2 keer een connectie maken met de server, moet je dan ook als totale tijd 2 x de ping + downloadtijd van de bestanden rekenen?

Yep. Bij een eerste bezoek wel. Maar je kan door te tunen ervoor zorgen dat je externe css maar 1x geladen wordt ( geef hem een expiry date van ergens in 2010 mee en hij wordt niet meer gedownload tot 2010. Bij wijzigingen werk je met _GET parameters ( style.css?version=1 ) om een nieuwe versie te laten downloaden )

Zoals ik het altijd zie heeft site een 3 componenten, html, js en css. Dus splits ik het ook altijd in 3 files. Geef js / css files een verre expiry date en een versie mee en die worden niet meer gedownload totdat de versie veranderd.

[Dw1-nl]

Gewoon extern ik zelf maak nu al 4 jaar site's en zit ook op dagelijks met andere webmasters te kletsen heb nog nooit iemand de css in de site zelf zien doen altijd extern.
Vooral handig met een cms als je meerdere layout's wil natuurlijk...

[Civil]

stereohead schreef op zaterdag 10 mei 2008 @ 10:06:
Dank voor de snelle reacties!

@ Dennahz en Haan:
De css wordt dynamisch gegenereerd hè zowel als ik het inbak en als ik een externe stylesheet gebruik. Het gaat hier puur om de performance.

Waarom moet je die CSS dynamisch genereren. Is er geen vaste styling die in een cachebare stylesheet geplaatst kan worden? Als bij elke pageview nieuwe CSS over de lijn verstuurd gaat, ga je natuurlijk het hele doel van CSS voorbij.

Ik kan me ook niet zomaar een situatie indenken waar een stylesheet in zijn geheel dynamisch zou moeten zijn. Of waar je zou willen dat dat zo was.

Dus de vraag is, hoe dynamisch is die CSS, veranderen er enkele regels of echt (bijna) de complete CSS en kies jij wel voor de goede oplossing ?

Ok, de hoeveelheid data is dus hetzelfde, maar zal je het verschil merken tussen het downloaden van 1 groot bestand en 2 kleinere bestanden?

Minder requests is tijdswinst in de regel omdat de browser maar een x aantal connecties kan maken voor het binnenhalen van bestanden. En het opzetten van een connectie en wachten tot er connecties vrij komen nu eenmaal wat tijd kost.

[crisp]

De meeste browser paralelliseren downloads van hetzelfde domein, hoeveel requests er tegelijkertijd gedaan kunnen worden hangt af van je client - sommige doen nu nog 2 parallele downloads maar IE8 schroeft dat al op naar 6 an andere browsers zullen dit dus ook wel gaan doen.

Wat performance-technisch de beste aanpak is hangt een beetje af van hoe dynamisch het is: hoe vaak veranderd de CSS, is echt alles dynamisch of is er ook een groot deel statisch en is de CSS hetzelfde voor alle pagina's of is dat ook dynamisch?

Probeer in ieder geval zoveel mogelijk een eventueel statisch deel wel gewoon als extern stylesheet aan te beiden, liefst nog van een ander (cookie-less) domein.

Als het dynamisch deel klein is zou je dat kunnen inlinen, als dat wat groter is maar niet vaak veranderd en hetzelfde is voor alle pagina's dan zou ik zeggen: cachen naar disk en alsnog extern linken met een long-term expires header. Clientside cacheing kan je 'doorbreken' door in je link naar de stylesheet een variabele get-parameter op te nemen.

In het laatste geval zou je zelfs nog kunnen denken aan het mergen van je statische deel en het dynamische deel naar 1 stylesheet. Je kan daar dan zelfs nog minification op loslaten.
Gebruik in ieder geval HTTP compressie bij het serveren van je HTML, CSS en JS bestanden

[stereohead]

In het cms kunnen users per pagina bepaalde elementen kiezen, bv: een poll element, een tekst element e.d.

Tijdens het parsen van de pagina wordt gekeken welke elementen er op die pagina gekozen zijn, en daarvan wordt de css opgehaald, op die manier stuur ik dus geen overbodige css mee.

Ik heb nu 2 keuzes:
* De style extern doen, en het css bestand aanroepen met een GET parameter 'page' op die manier krijg je per pagina een aparte css bestand, maar wordt het toch gecached door de browser (toch?).
* Per element een extern stylesheet gebruiken, dan krijg je dus 1 html bestand, en meerdere style bestanden. Bijvoorbeeld: default.css, poll.css, newstracker.css, textblock.css. Dan zit je wel weer met veel aparte bestanden en dus veel connecties...

@crisp:
Hoe gaat dat comprimeren van html/css in zijn werk? met gzencode dus

@ Tofu:
Coole link, ik heb eens getest, en het gebruik van een externe stylesheet duurt veel langer!
> Inline: +/- 70 ms
> Extern +/- 400 ms
Maar dat kan natuurlijk heel goed liggen aan de host van die website e.d.

[ Voor 12% gewijzigd door stereohead op 10-05-2008 11:53 ]

[Verwijderd]

* Je neemt 1 style-bestand met de CSS van je complete site, zodat de user maar 1 bestand hoeft te cachen, de eerste keer dat hij je site bezoekt.

Lijkt me interessanter dan het niet laten parsen van 'overbodige css'.

[Ramon]

stereohead schreef op zaterdag 10 mei 2008 @ 10:53:
In het cms kunnen users per pagina bepaalde elementen kiezen, bv: een poll element, een tekst element e.d.

Tijdens het parsen van de pagina wordt gekeken welke elementen er op die pagina gekozen zijn, en daarvan wordt de css opgehaald, op die manier stuur ik dus geen overbodige css mee.

Ik heb nu 2 keuzes:
* De style extern doen, en het css bestand aanroepen met een GET parameter 'page' op die manier krijg je per pagina een aparte css bestand, maar wordt het toch gecached door de browser (toch?).
* Per element een extern stylesheet gebruiken, dan krijg je dus 1 html bestand, en meerdere style bestanden. Bijvoorbeeld: default.css, poll.css, newstracker.css, textblock.css. Dan zit je wel weer met veel aparte bestanden en dus veel connecties...

@crisp:
Hoe gaat dat comprimeren van html/css in zijn werk?

@ Tofu:
Coole link, ik heb eens getest, en het gebruik van een externe stylesheet duurt veel langer!
> Inline: +/- 70 ms
> Extern +/- 400 ms
Maar dat kan natuurlijk heel goed liggen aan de host van die website e.d.

De vraag is dan natuurlijk hoe groot is de totale CSS en is het binnenhalen van die CSS een serieus probleem als je rekening houdt met de caching en de snelle internetverbindingen van 2008?

[DrClaw]

je wil gewoon koste wat het kost je css dynamisch genereren he. wat denk je dan dat de reden is waarom je dat _moet_ doen?

is het, omdat je gebruikers een piepkleine bandwidth hebben, zodat elke bit telt?
of bestaat de css van jow individuele elementen uit gigantische sets aan styling instructies ?

mijn mening: stop alle css in 1 file, en maak die zo efficient mogelijk. en je individuele componenten genereer je dan automatisch.

er zijn tooltjes die je css en je bijbehorende code uiteindelijk kunnen comprimeren, maar dat doe je dus pas op het laatste moment. want wat ze doen is als je IDs en classes renamen tot .a .b .c .d enzovoort en dat is een crime om te debuggen.

[stereohead]

DrClaw schreef op zaterdag 10 mei 2008 @ 11:05:
je wil gewoon koste wat het kost je css dynamisch genereren he. wat denk je dan dat de reden is waarom je dat _moet_ doen?

Lol, nee ik denk/dacht op die manier ervoor te zorgen dat de pagina sneller laad, maar ik denk dat het een beter idee is om alles in een groot css bestand te doen.

er zijn tooltjes die je css en je bijbehorende code uiteindelijk kunnen comprimeren, maar dat doe je dus pas op het laatste moment. want wat ze doen is als je IDs en classes renamen tot .a .b .c .d enzovoort en dat is een crime om te debuggen.

Daar heb ik persoonlijk en hekel aan, ik vindt gewoon dat de source leesbaar moet zijn.


Wat ik waarschijnlijk ga doen:
> HTML comprimeren met gzip (gzencode +ob_***)
> Alle css van alle elementen in 1 bestand en comprimeren met gzip

[Gomez12]

stereohead schreef op zaterdag 10 mei 2008 @ 10:53:
Tijdens het parsen van de pagina wordt gekeken welke elementen er op die pagina gekozen zijn, en daarvan wordt de css opgehaald, op die manier stuur ik dus geen overbodige css mee.

Waarom niet gewoon je complete css bij 1e bezoek eruit spugen en dit bij de client laten cachen??? Jouw methode is bijna niet goed te cachen, dus bij bijna elk bezoek moet die css weer over de lijn heen.

Btw geef eens een indicatie van de totale grootte van de css? Want ik denk dat je je druk zit te maken over enkele tientallen bytes. 1x 10Kb downloaden en cachen is beter dan bij 12 paginabezoeken 1Kb css te ontvangen en niets te cachen.

Ik heb nu 2 keuzes:
* De style extern doen, en het css bestand aanroepen met een GET parameter 'page' op die manier krijg je per pagina een aparte css bestand, maar wordt het toch gecached door de browser (toch?).

Niet per pagina, gewoon 1 totaal bestand / 1 extra bestand voor een compleet ander gedeelte waar 90% van de bezoekers niets mee te maken heeft ( admin ). De client cached het totaal bestand en dit wordt voor elke pagina opnieuw gebruikt.

@crisp:
Hoe gaat dat comprimeren van html/css in zijn werk?

Zoeken naar apache deflate, mod_gzip etc.

Even nog een praktijkvoorbeeldje, ik heb een site met redelijk wat verschillende componenten en bijbehorende css files inclusief Comments etc. Ik heb serverside 1 classe die alle verschillende css-bestanden bij elkaar raapt, minified en een versie eraan geeft ( adhv last modified date van alle losse bestanden ), het geeft een expiry header mee tot in 2010, het gzipped het bestand voordat het naar de client wordt verzonden.
Op schijf heb ik 18Kb aan css staan, dit wordt bij een 1e page request omgezet naar een 4Kb download die geldig blijft tot in 2010 of tot de 1e verandering.

Voor js heb ik eenzelfde procedure en daar wordt van 300Kb 1 download van 30Kb gemaakt.

Alle plaatjes krijgen ook een versie mee en een expiry date tot 2010.

Dus bij een 1e pagerequest moet iemand 34Kb extra downloaden voordat hij de pagina ziet, bij elk volgende bezoek / pagerequest hoeft er niets meer aan css / js gedownload te worden tot aan 2010 of tot er iets wijzigt.

Gemiddeld voor mijn website kost een 1e pagerequest 2Mb, 2e en volgende pagerequests zijn nog maar gemiddeld 3Kb ( heb veel, heel veel plaatjes en js, navigatie is ook 90% plaatjes ). Ik verander iets aan de css, bij de volgende pagerequest is er een nieuw versienr en dus een nieuwe download.

En dynamisch, mijn css is bij elke bezoeker verschillend ( het is geen algemeen toegankelijke website ) maar blijft toch bij elke bezoeker gecached tot aan 2010 of tot er 1 wijziging in de css plaatsvind...

Oftewel, ga niet kijken naar bytes, ga kijken naar je bezoekers terugkeerpatroon, doet een gemiddelde bezoeker per week 10 page-requests dan kan je beter gaan kijken naar efficiente caching dan naar het besparen van enkele bytes. Bytes besparing ( op css / js ) is imho alleen zinvol als je alleen maar 1 pagerequest per bezoeker hebt..

stereohead schreef op zaterdag 10 mei 2008 @ 11:47:
[...]
Daar heb ik persoonlijk en hekel aan, ik vindt gewoon dat de source leesbaar moet zijn.

Voor wie moet de source leesbaar zijn? Voor iedereen, dan gooi je makkelijk een 20% compressie / downloadtijd weg. Voor jezelf, maak een _get-parameter dat de code niet minified zodat je nog steeds kan debuggen.

> HTML comprimeren met gzip (gzencode +ob_***)

Let er wel op of de browser gzip ondersteunt... Anders krijgt de gebruiker troep.

> Alle css van alle elementen in 1 bestand en comprimeren met gzip

Dit zou ik met een server-side scriptje gaan doen, ik heb liever een duidelijke dir-structuur met 25 css bestandjes dan 1 gigantisch css bestand waar ik alles maar bij elkaar moet zoeken...

[ Voor 11% gewijzigd door Gomez12 op 10-05-2008 12:24 ]

[stereohead]

Btw geef eens een indicatie van de totale grootte van de css?

Moeilijk te zeggen, het gaat tot nu toe eigenlijk alleen maar om het cms, de grootte van de css zal afhangen van de site die met het cms gemanaged wordt.

Voor wie moet de source leesbaar zijn? Voor iedereen...

Jep, voor iedereen, ikzelf vindt het erg vervelend als ik ergens op een site een mooi scriptje oid zie, maar niet kan zien hoe het werkt omdat de source onleesbaar is, natuurlijk is dat maar 0.1 % van de bezoekers, maar toch , ik hecht daar gewoon waarde aan.

Let er wel op of de browser gzip ondersteunt... Anders krijgt de gebruiker troep.

Zal ik doen

Dit zou ik met een server-side scriptje gaan doen, ik heb liever een duidelijke dir-structuur met 25 css bestandjes dan 1 gigantisch css bestand waar ik alles maar bij elkaar moet zoeken...

Aan de server kant is er per element een apart css file, dit wil ik dan met een scriptje samenvoegen tot 1 bestand.

[ Voor 3% gewijzigd door stereohead op 10-05-2008 13:08 ]

[Gomez12]

stereohead schreef op zaterdag 10 mei 2008 @ 13:00:
[...]

Moeilijk te zeggen, het gaat tot nu toe eigenlijk alleen maar om het cms, de grootte van de css zal afhangen van de site die met het cms gemanaged wordt.

Ook geen gok mogelijk? Moeten we denken aan 2Mb aan css, of blijft het altijd wel onder 100Kb.

[...]
Jep, voor iedereen, ikzelf vindt het erg vervelend als ik ergens op een site een mooi scriptje oid zie, maar niet kan zien hoe het werkt omdat de source onleesbaar is, natuurlijk is dat maar 0.1 % van de bezoekers, maar toch , ik hecht daar gewoon waarde aan.

Simpel gezegd, maak je dan ook niet druk om die 3Kb css die je uitspaart door het dynamisch te maken, waarschijnlijk verlies je dit al door het niet strippen van comments etc.
En ikzelf ben altijd van mening dat iedereen om mijn scriptjes mag gaan mailen, het simpelweg copieren / plakken van mijn scriptjes ben ik iets minder gecharmeerd van. Iedereen mag 90% van mijn scriptjes gebruiken, maar ik vind het wel leuk om te weten waar ze gebruikt worden, ego enzo...

[Verwijderd]

stereohead schreef op zaterdag 10 mei 2008 @ 11:47:
[...iets met comprimeren/compiled CSS code...]
Daar heb ik persoonlijk en hekel aan, ik vindt gewoon dat de source leesbaar moet zijn.

Hiervoor maak je natuurlijk een stylesheet.css (je orgineel) en een st001.css bijv. bestand die je include en die wel gecomprimeerd is.

Ook niet onbelangrijk, een externe stylesheet word 1x per x interval opgevraagd, een inline stylesheet elke pagina request.

Aan de server kant is er per element een apart css file, dit wil ik dan met een scriptje samenvoegen tot 1 bestand.

@import of @include of iets

[ Voor 13% gewijzigd door Verwijderd op 10-05-2008 13:21 ]

[stereohead]

@ Gomez:
Over het algemeen zal het aantal kb css onder de 100 kb blijven.

@ Paddoswam:
Ok, dan zal ik dus gewoon 1 externe stylesheet maken, waar alle css van de gehele site instaat.

Ik gebruik liever 1 stylesheet omdat er anders weer voor elke stylesheet een connectie moet worden gemaakt, en je weer vertraging hebt e.d.

[ Voor 27% gewijzigd door stereohead op 10-05-2008 13:27 ]

[Gomez12]

Verwijderd schreef op zaterdag 10 mei 2008 @ 13:19:
[...]


Hiervoor maak je natuurlijk een stylesheet.css (je orgineel) en een st001.css bijv. bestand die je include en die wel gecomprimeerd is.

Laat dit eens lekker server-side gebeuren. Ja, het is makkelijk, ja het versnelt de boel, nee ik heb geen zin om dit allemaal handmatig altijd weer gelijk te moeten trekken.
En btw, het ging om de code voor de client, voor jezelf hoef je hier nog niet een aan te denken...

[...]
@import of @include of iets

En dat is dus per bestand een extra request vanaf de client, 10 bestandjes samenvoegen server side leidt tot 1 request van de client ipv 10 request, zelfs ie8 doet parallel maar max 8 requests tegelijk op 1 server.
Dus zolang je server side sneller de bestandjes samenvoegt dan dat het kost om de overige 9 requests te doen ben je sneller.( Ga je server side on the fly minifyen / filteren en nog enkele andere dure bewerkingen dan kan je server side weer trager zijn dan 10 losse requests... Het is altijd een afweging als je verder en verder gaat optimaliseren )

stereohead schreef op zaterdag 10 mei 2008 @ 13:23:
@ Gomez:
Over het algemeen zal het aantal kb css onder de 100 kb blijven.

Grote css die waarschijnlijk wel kleiner valt te maken. Maar dan creeer je weer complexiteit bij het samenvoegen.
Maar met gzip gok ik dat er nog 40Kb overblijft wat echt over de lijn gestuurd wordt, nog altijd kleiner dan menig plaatje dus ik zou me hier niet al te druk over maken.

[ Voor 16% gewijzigd door Gomez12 op 10-05-2008 13:47 ]

[Verwijderd]

Gomez12 schreef op zaterdag 10 mei 2008 @ 13:33:
En dat is dus per bestand een extra request vanaf de client.

Plus dat ik laatst ergens las dat stylesheets die met @import gekoppeld zijn, als laatste worden gedownload. Er gaat dus van alles verspringen als er te veel requests zijn.

[Patriot]

Ik snap niet dat iedereen zegt dat deze dingen niet te cachen zijn. Als ik de TS goed begrijp, wijzigt de CSS voor een bepaalde pagina alleen bij het wijzigen van die pagina in de CMS. Als je op dat moment gewoon een stylesheet genereert (gewoon een bestand), een tabelletje in je database waar aangegeven staat welk bestand bij welke pagina hoort en je bent klaar.

Als je dan gewoon bij het wijzigen een nieuwe naam aan het bestand geeft, ben je er ook zeker van dat de client de nieuwe stylesheet gaat gebruiken.

[Verwijderd]

Misschien off topic maar een andere reden om CSS extern te plaatsen is vanwege de code content ratio ook wel code text ratio genoemd.

Zoekmachines vinden het niet prettig als ze 80kb aan inhoud moeten crawlen en slechts 10kb blijkt indexeerbare text te zijn.

Door je javascript en CSS files extern te houden scheelt dat de zoekmachines ploeteren en zal je site iets beter scoren.

[ Voor 22% gewijzigd door Verwijderd op 12-05-2008 13:21 . Reden: typo's ]

[Ramon]

Patriot schreef op maandag 12 mei 2008 @ 12:50:
Ik snap niet dat iedereen zegt dat deze dingen niet te cachen zijn. Als ik de TS goed begrijp, wijzigt de CSS voor een bepaalde pagina alleen bij het wijzigen van die pagina in de CMS. Als je op dat moment gewoon een stylesheet genereert (gewoon een bestand), een tabelletje in je database waar aangegeven staat welk bestand bij welke pagina hoort en je bent klaar.

Als je dan gewoon bij het wijzigen een nieuwe naam aan het bestand geeft, ben je er ook zeker van dat de client de nieuwe stylesheet gaat gebruiken.

Op jouw manier moet een gebruiker alsnog bij elke wijziging de CSS binnen halen. Daarnaast is op jouw manier de CSS voor elke pagina anders waardoor er bij elke pagina extra informatie binnengehaald moet worden. Lijkt het me nog steeds handiger om gewoon één groot CSS bestand te maken.

[Patriot]

Ramon schreef op maandag 12 mei 2008 @ 13:18:
[...]

Op jouw manier moet een gebruiker alsnog bij elke wijziging de CSS binnen halen. Daarnaast is op jouw manier de CSS voor elke pagina anders waardoor er bij elke pagina extra informatie binnengehaald moet worden. Lijkt het me nog steeds handiger om gewoon één groot CSS bestand te maken.

Bij een wijziging moet de gebruiker inderdaad de CSS opnieuw ophalen. Dat alle CSS ophalen beter is, daar ben ik het best mee eens.