[ALG] Hoe werken images sprites (met CSS)*

[Verwijderd]

Deze techniek heeft vast een naam. Ik ken hem niet, maar ik zie hem steeds vaker.

Neem als voorbeeld Hyves.nl. Die hebben vandaag een totaal nieuw design doorgevoerd en lijken helemaal op facebook en zijn echt slecht bezig. Maar that's not the point.

Als ik op de menu balk bovenin rechter-muisknop doe end an 'achtergrond bekijken', zie ik een soort 'skin' png bestandje waar alle elementen bij elkaar staan.
Deze: (alhoewel ik niet weet of die link bij iedereen werkt) http://cache4.hyves-stati...ds/nav-trans.4f9c7dd4.png

Ik neem aan dat je bij een div de coördinaten van de achtergrond opgeeft en dat zo de background bepaald wordt. ( ? )

Facebook doet het ook
http://static.ak.fbcdn.ne...e/MegaSprite_5005_ltr.png

of tweakers:
http://tweakimg.net/g/if/v2/header/menu_buttons.png

Nou, genoeg voorbeelden voor iets wat velen hier heel logisch vinden.

Hoe werkt dit? Wat is het voordeel van deze techniek? Hoe heet het? Waar komt het vandaan? Is het de moeite waard om toe te passen?

[Frash]

Techniek heet 'CSS sprites'.

[Verwijderd]

voordeel ervan is dat de rollover altijd klaar staat,
normaal kan je de afbeelding ook "vervangen", maar dan duurt het bij de eerste rollover even voordat de nieuwe image ingeladen is

[Gersomvg]

Het voordeel hiervan is dat alle onmouseovers gepreload worden. En het scheelt natuurlijk een heleboel losse afbeeldingen.
Die van hyves is trouwens wel slecht Je moet alles zo dicht mogelijk op elkaar zetten t.b.v. de grootte van de afbeelding.

Voor zover ik weet is Google een beetje degene die dit heeft uitgevonden. Zij doen dit al superlang met de zoekmachine enzo.
http://www.google.nl/images/nav_logo6.png

offtopic:
Is sowieso wel eens leuk om met firebug te spelen bij google-websites. Moet je bij gmail bijv. eens een thema instellen en dan de bronafbeelding voor de ronde hoeken bekijken

[ Voor 41% gewijzigd door Gersomvg op 02-07-2009 14:55 ]

[Verwijderd]

Ok, duidelijk en logisch ook. CSS sprites zal ik zeker naar gaan kijken.

Maar deze dan?

http://www.google.nl/firefox/

de achtergrond:

http://www.google.nl/images/firefox/sprite2.png

waarom is die rechterkan verschoven?

[Hertog]

Frash schreef op donderdag 02 juli 2009 @ 14:50:
Techniek heet 'CSS sprites'.

En het komt er kortweg op neer dat je in plaats van verschillende plaatjes één plaatje inlaadt en bij rollovers en dergelijke met aangepaste waarden voor left en top een ander gedeelte van het plaatje laat zien. Inderdaad met name om flikkeringen bij rollovers en dergelijke te voorkomen.

[Verwijderd]

Gersompie schreef op donderdag 02 juli 2009 @ 14:52:
Het voordeel hiervan is dat alle onmouseovers gepreload worden. En het scheelt natuurlijk een heleboel losse afbeeldingen.
Die van hyves is trouwens wel slecht Je moet alles zo dicht mogelijk op elkaar zetten t.b.v. de grootte van de afbeelding.

Voor zover ik weet is Google een beetje degene die dit heeft uitgevonden. Zij doen dit al superlang met de zoekmachine enzo.
http://www.google.nl/images/nav_logo6.png

offtopic:
Is sowieso wel eens leuk om met firebug te spelen bij google-websites. Moet je bij gmail bijv. eens een thema instellen en dan de bronafbeelding voor de ronde hoeken bekijken

Holy shit, dat ik dat nog nooit gezien heb :-) Wat geniaal.

[Bosmonster]

De voornaamste reden is overigens niet preloading, maar performance. Het scheelt een enorme bak requests naar de server, wat bij sites als Google en Facebook een flinke slok op een borrel scheelt (misschien zelfs wel een paar servers minder).

Voor de gemiddelde site is het vaak iets minder zinvol, want het kost wel iets meer tijd om te implementeren en in onderhoud dan losse afbeeldingen. Al kan het voor met name CSS-hovers natuurlijk wel flikkeringen voorkomen.

[ Voor 9% gewijzigd door Bosmonster op 02-07-2009 15:02 ]

[Verwijderd]

Gersompie schreef op donderdag 02 juli 2009 @ 14:52:
Het voordeel hiervan is dat alle onmouseovers gepreload worden. En het scheelt natuurlijk een heleboel losse afbeeldingen.
Die van hyves is trouwens wel slecht Je moet alles zo dicht mogelijk op elkaar zetten t.b.v. de grootte van de afbeelding.

Voor zover ik weet is Google een beetje degene die dit heeft uitgevonden. Zij doen dit al superlang met de zoekmachine enzo.
http://www.google.nl/images/nav_logo6.png

[ot]Is sowieso wel eens leuk om met firebug te spelen bij google-websites. Moet je bij gmail bijv. eens een thema instellen en dan de bronafbeelding voor de ronde hoeken bekijken [/ot]

Ik zie een heeele lange png van 1px breed ofzo?

[boe2]

Verwijderd schreef op donderdag 02 juli 2009 @ 14:56:
Ok, duidelijk en logisch ook. CSS sprites zal ik zeker naar gaan kijken.

Maar deze dan?

http://www.google.nl/firefox/

de achtergrond:

http://www.google.nl/images/firefox/sprite2.png

waarom is die rechterkan verschoven?

Omdat je plaatje zelf vierkant moet zijn, maar het logo komt wat hoger, plaatsbesparing dus .
Wanneer je het plaatje effectief gebruik offset je het gewoon wat naar boven. Zelf gebruikte ik dit tot nu toe enkel voor mouse-overs, maar ga het eens een stuk intensiever toepassen als ik die voorbeelden zo zie.

*edit* zonet even de ronde hoeken in gmail gechecked met opera dragonfly. Je moet eens spelen met die img url, ALLES is gewoon dynamisch gegenereerd, geniaal gewoon.

[ Voor 21% gewijzigd door boe2 op 02-07-2009 15:09 ]

[TERW_DAN]

Bosmonster schreef op donderdag 02 juli 2009 @ 14:59:
De voornaamste reden is overigens niet preloading, maar performance. Het scheelt een enorme bak requests naar de server, wat bij sites als Google en Facebook een flinke slok op een borrel scheelt (misschien zelfs wel een paar servers minder).

Voor de gemiddelde site is het vaak iets minder zinvol, want het kost wel iets meer tijd om te implementeren en in onderhoud dan losse afbeeldingen. Al kan het voor met name CSS-hovers natuurlijk wel flikkeringen voorkomen.

Mwah, plaatjes zoals deze gebruik ik zelf eigenlijk steeds vaker. Het scheelt naast requests ook schijfruimte (met testjes zit ik tegen de 50% besparing op in bytes als ik 1 plaatje met alle onderlinge plaatjes vergelijk met alle plaatjes gewoon los).
Updaten vind ik juist stukken makkelijker, je hoeft iedere keer maar 1 plaatje te uploaden. Kleuren veranderen gaat zo zelfs wat makkelijker.

[Gersomvg]

Boeboe schreef op donderdag 02 juli 2009 @ 15:02:
[...]


Omdat je plaatje zelf vierkant moet zijn, maar het logo komt wat hoger, plaatsbesparing dus .
Wanneer je het plaatje effectief gebruik offset je het gewoon wat naar boven.

*edit* zonet even de ronde hoeken in gmail gechecked met opera dragonfly. Je moet eens spelen met die img url, ALLES is gewoon dynamisch gegenereerd, geniaal gewoon.

Inderdaad.. Google is echt het perfecte voorbeeld van hoe je zoveel mogelijk in een png-skin-afbeelding kan proppen.
zie ook deze: http://s.ytimg.com/yt/img/master-vfl102488.png (hier snap ik dan alleen weer niet waarom er zoveel ruimte tussen die balken vanonder zit).

[Verwijderd]

Boeboe schreef op donderdag 02 juli 2009 @ 15:02:
[...]


Omdat je plaatje zelf vierkant moet zijn, maar het logo komt wat hoger, plaatsbesparing dus .
Wanneer je het plaatje effectief gebruik offset je het gewoon wat naar boven.

Hoe zinvol is dat bij PNG compressie? Ik neem aan dat er gewoon RLE gebruikt wordt, waardoor 560x50 extra witte pixels niets kosten.

[ Voor 16% gewijzigd door Verwijderd op 02-07-2009 15:10 ]

[TERW_DAN]

Bij PNG maken grote vlakken idd amper iets uit. Ik denk dat die paar bytes die je hooguit extra hebt wel opweegt tegen het feit dat alles overzichtelijker is.

[Pendaco]

Het staat ook al zo ongeveer in de naam van de Facebook afbeelding; megasprite

Verwijderd schreef op donderdag 02 juli 2009 @ 14:56:
http://www.google.nl/images/firefox/sprite2.png

waarom is die rechterkan verschoven?

Het Firefox logo steekt normaalgesproken een stuk uit boven de balk. Zoals Gersompie al aangaf gaat het erom de afbeelding zo klein mogelijk te houden. Anders zouden ze een heel stuk loze ruimte in hun afbeelding krijgen, wat toch weer een aantal bytes scheelt, zeker met een afbeelding die zo vaak wordt geladen.

Die van Hyves is idd een beetje raar Wel een goed idee om een transparante afbeelding te gebruiken en daaronder de background colors te laden, daar had ik nog niet aan gedacht

Edit: whoeps spuit11

Waar ik wel af en toe last van heb is dat er horizontaal 1px verschil zit tussen IE vs Firefox/Chrome/Opera. Zijn er meer mensen die hier last van hebben of ben ik gewoon iets vergeten te clearen?

[ Voor 21% gewijzigd door Pendaco op 02-07-2009 15:29 ]

[Gersomvg]

Pendaco schreef op donderdag 02 juli 2009 @ 15:15:
Het staat ook al zo ongeveer in de naam van de Facebook afbeelding; megasprite


[...]


Het Firefox logo steekt normaalgesproken een stuk uit boven de balk. Zoals Gersompie al aangaf gaat het erom de afbeelding zo klein mogelijk te houden. Anders zouden ze een heel stuk loze ruimte in hun afbeelding krijgen, wat toch weer een aantal bytes scheelt, zeker met een afbeelding die zo vaak wordt geladen.

Die van Hyves is idd een beetje raar Wel een goed idee om een transparante afbeelding te gebruiken en daaronder de background colors te laden, daar had ik nog niet aan gedacht

Edit: whoeps spuit11

Waar ik wel af en toe last van heb is dat er horizontaal 1px verschil zit tussen IE vs Firefox/Chrome/Opera. Zijn er meer mensen die hier last van hebben of ben ik gewoon iets vergeten te clearen?

Hoe bedoel je 1px verschil? Als het goed is moet de achtergrond met harde css-background-pixel-positionering in alle browsers goed zijn..

[Bosmonster]

TERW_DAN schreef op donderdag 02 juli 2009 @ 15:06:
[...]

Mwah, plaatjes zoals deze gebruik ik zelf eigenlijk steeds vaker. Het scheelt naast requests ook schijfruimte (met testjes zit ik tegen de 50% besparing op in bytes als ik 1 plaatje met alle onderlinge plaatjes vergelijk met alle plaatjes gewoon los).
Updaten vind ik juist stukken makkelijker, je hoeft iedere keer maar 1 plaatje te uploaden. Kleuren veranderen gaat zo zelfs wat makkelijker.

Bestandsgrootte en requests is niet zo heel boeiend bij een gemiddelde zakelijke website. Het onderhouden vind ik vaak iets lastiger, zeker als een plaatje ergens van grootte verandert. Daarnaast moet je overal de coordinaten van opzoeken/bijhouden. Dat maakt het zeker in een omgeving waar je soms met meerdere mensen aan een project werkt wat lastiger en onoverzichtelijker. Kleuren aanpassen gebeurt zelden, het ontwerp staat eigenlijk altijd al volledig klaar als ik eraan begin te werken.

Dat maakt dat ik het eigenlijk zelden toepas, omdat wij als bureau voornamelijk zakelijke sites bouwen.

Wil niet zeggen overigens dat ik het schuw. Als het nodig en nuttig is ergens pas ik het wel toe, maar dus niet per definitie voor ieder siteje dat we uit de grond stampen.

Verwijderd schreef op donderdag 02 juli 2009 @ 15:10:
[...]

Hoe zinvol is dat bij PNG compressie? Ik neem aan dat er gewoon RLE gebruikt wordt, waardoor 560x50 extra witte pixels niets kosten.

PNG maakt voor zover ik weet geen gebruik van RLE compressie, maar van iets ingewikkeldere algoritmes. Neemt niet weg dat een volvlak kleur niet al teveel ruimte zal kosten. Ik zou dus ook eerder kiezen om wat meer ruimte tussen afbeeldingen te houden, zo kun je nog eens iets een paar pixels groter maken zonder het te moeten verplaatsen naar een ander deel van de sprite en zo een leeg vlak over te houden.

[ Voor 26% gewijzigd door Bosmonster op 02-07-2009 15:37 ]

[Verwijderd]

Duidelijk verhaal en zeker interessant. Als het zoveel voordelen met zich mee brengt op gebied van bandbreedte en performance, zou er in een volgende css-versie nog verdere ondersteuning voor komen?

Zoals gezegd is dit een vrij arbeidsintensieve manier van werken en het komt mij best wel 'hackerish' over, om het zo maar te noemen...

[Janoz]

Valt mee, gewoon goede tooling gebruiken.

[Verwijderd]

Hou er overigens wel rekening mee dat er een hoger memory-gebruik met deze techniek meekomt, omdat browsers niet de gecomprimeerde image data renderen (en in geheugen houden) maar de uitgepakte bitmap. Zie http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/ voor meer info.

[kaesve]

vet man. ik kende het principe eigenlijk al van een tutorial-voor-ronde-hoekjes, maar had het nog nooit uitgebreidere manier gezien dan dat.. (stom eigenlijk).
een goede optie om eens van mijn knipperende rollovers af te komen :]

[Zakkenwasser]

hmm, ik gebruik alweer een tijdje css-sprites, als je eenmaal door hebt hoe het werkt, maak je ze gemakkelijk met photoshop/paintshop.

Je spreekt een sprite aan met de CSS-code: background: url(../pad_naar/sprite.jpg) 12px -12px)

waarvan de 12px -12px, de horizontale/verticale offset berekent over de sprite,
beetje mee spelen met de getallen om je plaatje goed zichtbaar te krijgen.

je kunt hier meer over lezen hoe je deze zelf kunt maken:
http://www.alistapart.com/articles/sprites/

[ Voor 25% gewijzigd door Zakkenwasser op 03-07-2009 08:37 ]

[Room42]

Goed verhaal! Deze techniek heb ik nog nooit toegepast. Ik ga me er eens in verdiepen. Ik bouw niet van die grote sites, maar het is gewoon leuk om te kunnen

[Gersomvg]

MrJey schreef op vrijdag 03 juli 2009 @ 07:36:
Je spreekt een sprite aan met de CSS-code: background: url(../pad_naar/sprite.jpg) 12px -12px)

Ik neem aan dat dat laatste haakje een ; moet zijn?
Er zit wel 1 nadeel aan deze techniek. Dat is wanneer je bijv. een div ter hoogte van 30 px een pictogram van 10px hoog als achtergrond wil geven. Dan moet je in de sprite-afbeelding boven en onder dat pictogram 10px wit of transparant maken.

[ Voor 28% gewijzigd door Gersomvg op 03-07-2009 11:07 ]

[Verwijderd]

Gersompie schreef op vrijdag 03 juli 2009 @ 11:06:
[...]

Ik neem aan dat dat laatste haakje een ; moet zijn?
Er zit wel 1 nadeel aan deze techniek. Dat is wanneer je bijv. een div ter hoogte van 30 px een pictogram van 10px hoog als achtergrond wil geven. Dan moet je in de sprite-afbeelding boven en onder dat pictogram 10px wit of transparant maken.

hmm, ik post nu op mijn werk, en daar staat er iemand anders ingelogd....mijn excuus.. (mrJey)
Dus geen cloon voor de duidelijkheid!

en niet tevergeten natuurlijk de ; na de laatste haakjes.

als je no-repeat toepast dan hoef je alleen ervoor te zorgen dat je sprite dezelfde kleur heeft als de div background

background: #FFF url(../pad_naar/sprite.jpg) 12px -12px;

of je maakt em transparant

[ Voor 8% gewijzigd door Verwijderd op 03-07-2009 12:06 ]

[_Thanatos_]

En natuurlijk:
http://www.alistapart.com/articles/sprites/

En in het kwadraat:
http://www.alistapart.com/articles/sprites2/

[Gersomvg]

Deze is pas vet

Ook een soort van sprite afbeelding en dan met jquery:
http://snook.ca/archives/...uery-bg-image-animations/

(hier gelijk het resultaat):
http://snook.ca/technical/jquery-bg/

[gitaarwerk]

Bosmonster schreef op donderdag 02 juli 2009 @ 14:59:
De voornaamste reden is overigens niet preloading, maar performance. Het scheelt een enorme bak requests naar de server, wat bij sites als Google en Facebook een flinke slok op een borrel scheelt (misschien zelfs wel een paar servers minder).

Denk ook grafisch gericht zoals je zegt, dat het best nuttig is.Hoewel veel mobile browsers toch nog niet echt veel van deze dingen ondersteunen.

Trouwens, background png's die ook nog eens transparantie bevatten, gaan ook niet helemaal okay nog. Sommige browsers hebben er nog moeite mee.

Buiten png's,... met gifjes kun je trouwens dmv gebruik jquery / scriptaculous etc aardig animeren. Als je preload kan je gewoon keihard animeren door framing. Geen flash, wel animatie Leuk om mee te spelen. Of het echt heel erg nuttig zou zijn, weet ik niet, je performance gaat wel weer achteruit client side.

overigens, klein beetje offtopic, wat ik dacht waar het topic over ging toen ik de titel las,
is echte png skins gebruiken (in de letterlijke zin van het woord, ala layering)

http://www.webleeddesign.com/

[ Voor 15% gewijzigd door gitaarwerk op 03-07-2009 19:49 ]

[H92!]

Heel interessante topic. Ik werk al 5 jaar met html en css, maar dit kende ik nog niet. Ik ga CSS sprites zo snel mogelijk op mijn site toepassen, want ik werk nog met afbeeldingen voor ronde hoekjes (16 stuks per pagina).

[Juup]

TERW_DAN schreef op donderdag 02 juli 2009 @ 15:13:
Bij PNG maken grote vlakken idd amper iets uit. Ik denk dat die paar bytes die je hooguit extra hebt wel opweegt tegen het feit dat alles overzichtelijker is.

Deze plaatjes worden echter uncompressed in het geheugen opgeslagen vermenigvuldigd met het aantal keer dat het plaatje gebruikt wordt.
Prober maar eens een 1000x1000 witte png 100x op een pagina te gebruiken en kijk naar hoeveel geheugen de browser dan gebruikt.

dat is dan 400MB bij PNG met full alpha channel (32 bit/pixel)

[.oisyn]

In welke browser heb je dat gemeten?

[André]

Daar ben ik ook wel benieuwd naar. Ik heb net snel een dirty test gedaan, maar verder dan 1000 kb kom ik niet met een 1000*1000 witte PNG die 100 keer op een pagina gebruikt word. En dan heb ik het als img en als background geprobeerd.

[.oisyn]

.oisyn schreef op zondag 05 juli 2009 @ 14:18:
In welke browser heb je dat gemeten?

[André]

Chrome 2.0.172.33, FF 3.5, IE 8.0.6001.18783

[ Voor 46% gewijzigd door André op 05-07-2009 19:27 ]

[torp]

Gersompie schreef op donderdag 02 juli 2009 @ 15:08:
zie ook deze: http://s.ytimg.com/yt/img/master-vfl102488.png (hier snap ik dan alleen weer niet waarom er zoveel ruimte tussen die balken vanonder zit).

Wellicht vanwege latere toevoegingen? Zodat je dan niet alle oude posities hoeft aan te passen?
Erg interessant dit. Ik kende dit wel voor roll-overs, maar om het ook voor statische plaatjes te gebruiken vind ik een erg frisse gedachte.* Typisch Google.

Terwijl ik dit intiep zie ik onder dit veld al die smilies staan. Stel dat je alle stilstaande smilies in 1 bestandje zou zetten...

*) edit: Bij nader inzien heb ik het zelf ook al eens toegepast, met 1 plaatje voor een aantal buttons. Ik kende alleen de naam voor deze techniek niet. En heb het later om onduidelijke redenen toch weer veranderd in losse plaatjes...

[ Voor 16% gewijzigd door torp op 09-07-2009 10:46 ]

[Voutloos]

Voorlopig zijn sprites enorm hip, maar iets van een resource archive zou uiteindelijk de mooiere oplossing zijn. Zie http://kaioa.com/node/99

[torp]

Het verschil is dat dit nu al werkt...

[Voutloos]

Uiteraard, 'uiteindelijk' is wellicht een behoorlijk lange termijn ja. Maar eigenlijk is dit gewoon de obvious oplossing voor de immer aanwezige waslijst aan amper wijzigende resources en dus jammer dat het niet al is.

[RobIII]

torp schreef op donderdag 09 juli 2009 @ 09:46:
Terwijl ik dit intiep zie ik onder dit veld al die smilies staan. Stel dat je alle stilstaande smilies in 1 bestandje zou zetten...

Bij animated gifs ( , etc.) is/wordt het al lastiger; ze moeten dan namelijk allemaal hetzelfde aantal frames (en timing van de frames) hebben

[.oisyn]

Op zich niet lastig, je houdt dan de kleinste gemene veelvoud over. En een hele grote smileys.gif

[torp]

RobIII schreef op donderdag 09 juli 2009 @ 10:46:
Bij animated gifs ( , etc.) is/wordt het al lastiger; ze moeten dan namelijk allemaal hetzelfde aantal frames (en timing van de frames) hebben

Misschien zijn er groepjes te maken met eenzelfde aantal frames? Timing-verschillen kun je soms oplossen met een aantal keren het zelfde plaatje – maar dat gaat wel erg ver.

De vraag is of het de moeite waard is. Ik kan me voorstellen dat bij zo'n grote site als t.net het verschil meetbaar is.

[Voutloos]

Bij een kleine site merk je het net zo goed als je op 100 losse resources moet wachten.

[.oisyn]

torp schreef op donderdag 09 juli 2009 @ 10:59:
[...]

Misschien zijn er groepjes te maken met eenzelfde aantal frames? Timing-verschillen kun je soms oplossen met een aantal keren het zelfde plaatje – maar dat gaat wel erg ver.

Zoals ik al zei, kleinste gemene veelvoud. Een gifje van 6 frames en een gifje van 4 frames kun je combineren in een gifje van 12 frames. Volgens mij hoeven duplicate frames niet apart opgeslagen te worden. Maar de animatie wordt wel erg lang als je heel veel verschillende frame-aantallen hebt (bij 8 animaties met elk een verschillend priemgetal aan frames heb je al minstens 9699690 frames maar da's natuurlijk worst case)

[torp]

Voutloos schreef op donderdag 09 juli 2009 @ 11:04:
Bij een kleine site merk je het net zo goed als je op 100 losse resources moet wachten.

Idee: alle statische usericons in 1 bestand? Dat scheelt!

[Zakkenwasser]

Vraag me by the way wel af hoe je spries toepast aan een alsmaar groeiend portfolio thumbnail foto's waarvan er altijd 12 op 1 pagina staan...

Het moet kunnen lijkt mij.

imagecreatejpeg() waarschijnlijk, ik ga het eens onderzoeken.

[ Voor 16% gewijzigd door Zakkenwasser op 09-07-2009 23:12 ]

[T-MOB]

MrJey schreef op donderdag 09 juli 2009 @ 23:11:
Vraag me by the way wel af hoe je spries toepast aan een alsmaar groeiend portfolio thumbnail foto's waarvan er altijd 12 op 1 pagina staan...

Het moet kunnen lijkt mij.

Dat het kan wil niet zeggen dat het een goed idee is. Als er 12 losse afbeeldingen gecached zijn dan hoeft je bezoeker alleen die ene nieuwe thumbnail op te halen. Zodra je de thumbnails in een sprite gooit dan zorgt het toevoegen van een foto ervoor dat de data van de 11 andere thumbnails opnieuw moet worden opgehaald. Als je regelmatig foto's toevoegd denk ik dat het je meer bandbreedte gaat kosten dan het oplevert...

[Zakkenwasser]

T-MOB schreef op donderdag 09 juli 2009 @ 23:46:
[...]


Dat het kan wil niet zeggen dat het een goed idee is. Als er 12 losse afbeeldingen gecached zijn dan hoeft je bezoeker alleen die ene nieuwe thumbnail op te halen. Zodra je de thumbnails in een sprite gooit dan zorgt het toevoegen van een foto ervoor dat de data van de 11 andere thumbnails opnieuw moet worden opgehaald. Als je regelmatig foto's toevoegd denk ik dat het je meer bandbreedte gaat kosten dan het oplevert...

you got a point there...

je maakt er eigenlijk een groter probleem mee.
besides: die thumbnails zijn maar 2,5kb

[ Voor 3% gewijzigd door Zakkenwasser op 10-07-2009 11:29 ]

[Guillome]

Bosmonster schreef op donderdag 02 juli 2009 @ 14:59:
De voornaamste reden is overigens niet preloading, maar performance. Het scheelt een enorme bak requests naar de server, wat bij sites als Google en Facebook een flinke slok op een borrel scheelt (misschien zelfs wel een paar servers minder).

Voor de gemiddelde site is het vaak iets minder zinvol, want het kost wel iets meer tijd om te implementeren en in onderhoud dan losse afbeeldingen. Al kan het voor met name CSS-hovers natuurlijk wel flikkeringen voorkomen.

Hoezo is het lastiger te implemeteren?

Cascading Stylesheet:

  background-image:url("./blaat_over.png");

of

Cascading Stylesheet:

  background-position:25px 35px;

En ik gebruik het alleen voor roll overs. Elk item in een los bestand. Dus menu.png heeft 4 statussen in die file. Idd voor roll over flickering te voorkomen.

[ Voor 9% gewijzigd door Guillome op 10-07-2009 11:49 ]

[Voutloos]

MrJey schreef op vrijdag 10 juli 2009 @ 11:26:
you got a point there...

je maakt er eigenlijk een groter probleem mee.
besides: die thumbnails zijn maar 2,5kb

Nogmaals, de optimalisatie gaat met name over het reduceren van requests ipv bandbreedte. Kennen dan zoveel mensen tools en bijbehorende adviezen als YSlow en Page Speed niet?


Maar dan nog is dat wellicht niet de ideale use case voor sprites.

[ Voor 50% gewijzigd door Voutloos op 10-07-2009 11:35 ]

[Cartman!]

YSlow ftw Ik gebruik YSlow voor elk project sinds ik Kings of Code 2008 waarbij een bekende gast van Yahoo ging vertellen over die dingen. Expireheaders, etags, sprites etc. werken echt heel goed om de gebruiker een snellere ervaring van pagina-opbouw te geven

[Onbekend]

Juup schreef op zondag 05 juli 2009 @ 13:08:
[...]

Deze plaatjes worden echter uncompressed in het geheugen opgeslagen vermenigvuldigd met het aantal keer dat het plaatje gebruikt wordt.
Prober maar eens een 1000x1000 witte png 100x op een pagina te gebruiken en kijk naar hoeveel geheugen de browser dan gebruikt.

dat is dan 400MB bij PNG met full alpha channel (32 bit/pixel)

Ik heb op een site de randen van een div ook in 1 figuur staan. In Firefox gebruikt een willekeurige pagina (voor de rest nauwelijks andere plaatjes) 33MB.
Het plaatje is 1024px × 6100px. (PNG 32bit/pixel) en heeft een grootte van 41KB. Die grootte heb ik nodig omdat de divs in grootte kunnen variëren.
De achtergrondafbeelding staat er dan wel meteen.