Nieuwsberichten & Blogs

Google's Sprite

In veel grote websites zoals Google, Amazon en Apple wordt er gebruik van gemaakt: CSS Sprites. Het grootste voordeel: aanzienlijk verminderen van het aantal ‘server requests’, dus een kortere laadtijd van pagina’s. Maar zijn ‘Sprites’ eigenlijk wel zo efficient als wordt gedacht?

 

Snelle laadtijd

In een Sprite zijn meerderen afbeeldingen in 1 afbeeldingsbestand verwerkt. Deze worden aangeroepen in de CSS door middel van de ‘background-position’; de x- en y-as. Zoals eerder gezegd, is hier door maar 1 server-request nodig. Hierdoor laadt de pagina sneller en zullen alle afbeelding uit die bepaalde Sprite in 1 keer zichtbaar zijn op de pagina. Ideaal voor onder andere buttons met een ‘hover-state’. Wanneer een gebruiker met de muis over een button navigeert, zal er geen vertraging optreden (‘blinking effect’), omdat de afbeelding al geladen is; alleen de coordinaten zijn anders. Als laatste resulteert het gebruik van Sprites vaak in een lagere file size dan alle losse afbeeldingen bij elkaar.

 

Langzame development?

Naast voordelen zoals kortere laadtijd en het voorkomen van ‘blinking’ bij buttons, zitten er ook nadelen aan het gebruik van Sprites. Het grootste nadeel is de omslachtige workflow, dat vaak leidt tot relatief langzame development.

 

Stel, ik maak een ontwerp voor een website en wil voor de icoontjes, logo’s en buttons een Sprite maken. Probleem 1: mijn icoontjes moeten transparant zijn, maar de logo’s en buttons hebben een witte achtergrond. De opties:

  • ik kan de afbeeldingen scheiden en meerdere Sprites maken (een .JPG Sprite en een transparante .GIF Sprite) met als nadeel extra server-requests;
  • ik kan sommige afbeeldingen uitsluiten voor de Sprite;
  • of ik doe concessies en stop toch alle afbeeldingen in een Sprite en maak er een transparante .PNG van. Voordeel: goede kwaliteit, nadeel: grotere filesize waar dat voor 80% van de afbeeldingen in de Sprite kleiner had gekund.
    Een transparante .GIF dan? Voordeel: kleinere filesize, nadeel: slechtere kwaliteit..

  

Goed: ik heb uiteindelijk m’n Sprite. De volgende stap is het toevoegen van de Sprite en de coordinaten in de CSS. Dit is tevens probeem 2: hoe ga ik simpel en snel achter de preciese coordinaten van de afbeeldingen komen? Een manier zou zijn: de Sprite in Photoshop openen en met de ‘Rectangular Marquee tool’ selecties trekken om met behulp van het ‘info-paneel’ achter de coordinaten te komen. Een tijdrovende klus met ongeveer 30 afbeeldingen!

 

Na een tijdje wil mijn klant een button vervangen voor een andere. Ik zal de Sprite moeten aanpassen: de oude button verwijderen en de Sprite verbreden, want de nieuwe button is breder dan de oude en past daardoor niet helemaal op de Sprite. Vanaf hier wordt het uitkijken: want wat als ik de Sprite nu zo radicaal heb verbreed en verhoogd dat de coordinaten van de afbeeldingen niet meer hetzelfde zijn!? Je zal er dus rekening mee moeten houden dat je een Sprite alleen aan de rechter- en onderkant vergroot en in de CSS alle afbeeldingen met uitgangspunt top-left uitlijnt.

 

Het onderhouden van Sprites is dus niet erg flexibel. Los van het feit dat hier met bepaalde vaste structuren wel mee te werken is, brengt het gebruik van Sprites ook gebreken met zich mee: het herhalen van afbeeldingen is niet mogelijk en Sprites zijn alleen te gebruiken in combinatie met elementen die een vaste breedte en hoogte hebben.

 

Los van het verhaal over Sprites, moet de afweging worden gemaakt welke afbeeldingen er uberhaupt in de CSS moeten komen (dus decoratief zijn) en welke in de source. Afbeeldingen van producten binnen een webshop zijn bijvoorbeeld redelijk cruciaal voor de content en zullen daarom in de source moeten. Indien de CSS om een bepaalde reden dan niet wordt geladen, zal de productfoto toch worden getoond. Een volgende afweging is bepalen welke afbeeldingen maar op enkele pagina’s zichtbaar zijn en deze uitsluiten voor de Sprite; want waarom elke gebruiker deze laten ophalen, als de meeste deze niet eens zullen zien?

 

Er zijn veel tools beschikbaar om sprites in elkaar te zetten: www.css-sprit.es / www.spriteme.org / spritegen.website-performance.org. Je kan alle losse afbeeldingen uploaden en de website maakt er automatisch een Sprite van en genereert zelfs de CSS.
Toch ben ik persoonlijk zeer huiverig voor het gebruik van dit soort tools, omdat je zeer weinig invloed hebt op kwaliteit van de afbeelding. Vaak kan je alleen aangeven of je Sprite .JPG, .GIF of .PNG moet worden, terwijl je in Photoshop je .JPG bijvoorbeeld nog flink kan optimaliseren met de optie ‘Save for Web’. Daarnaast zijn ook deze tools niet flexibel in het onderhoud: wat als ik er een afbeelding bij wil hebben? Moet ik dan alle afbeeldingen opnieuw door de generator halen? Of de reeds gemaakte Sprite met Photoshop handmatig aanpassen? Nadeel hiervan is kwaliteitsverlies door het steeds opnieuw opslaan van een afbeelding. Kwaliteitsverlies die je niet hebt met een bronbestand (.PSD).

 

Afweging

Je zou je dus sterk kunnen afvragen of de implementatie van een Sprite qua development niet langer duurt dan het gebruik van losse afbeeldingen. Alle argumenten in overweging nemende, lijkt het dus ook lang niet altijd efficient om Sprites te gebruiken. Een passende afweging per project lijkt noodzakelijk om in te kunnen schatten waar het meeste rendement uit valt te halen. Over het algemeen gebruik ik Sprites vooral voor buttons (en andere elementen met ‘hover-states’) en icons waarvan ik weet dat deze nauwelijks onderhoud nodig zullen hebben. Daarnaast heb ik mezelf aangeleerd om altijd ‘top-left’ te positioneren en Sprites alleen aan de rechter- en onderkant te vergroten.

Toch blijft het voorlopig per project inschatten in hoeverre er gebruik moet worden gemaakt van Sprites, want echt uitstekend blijkt het in de praktijk niet te werken.