Blog
Help! Mijn dataverkeer rijst de pan uit!!
31 mei 2010

Zoals in een eerdere tweet al viel te lezen, hebben we onlangs een actiewebsite voor Nescafé opgeleverd. Het is een mooie website geworden, die 2 belangrijke doelen heeft:
- Bezoekers de mogelijkheid geven om via social netwerk sites (zoals hyves, facebook, twitter e.d.) vrienden te vertellen dat ze Nescafé Latte Vanilla aan het proberen zijn
- Via de website een gratis probeer pakketje Nescafé Latte Vanilla aanvragen
Al direct na het eerste weekend dat de website live stond, bleek de website een groot succes. En dan vooral, hoe kan het ook anders met Nederlanders, het gratis proberen onderdeel.
Natuurlijk was iedereen zeer tevreden met dit onverwacht goede resultaat. Maar ruim 15.000 bezoekers in zo'n korte tijd heeft ook een keerzijde: het dataverkeer voor www.wilwatmetjedelen.nl bleek gigantisch te groeien!
Tijd voor actie!
Natuurlijk zorgen we er standaard voor dat onze websites een niet al te grote aanslag op het dataverkeer leggen. Maar in gevallen waarin een website minder vaak bezocht wordt, gaat het simpelweg om een afweging tussen het te verwachten dataverkeer en de extra uren die nodig zijn om de website te optimaliseren.
Om te voorkomen dat in dit geval het dataverkeer écht de pan uit zou rijzen, was het tijd voor actie! In deze blogpost zullen we uit de doeken doen hoe we er in zijn geslaagd om de website te optimaliseren en het dataverkeer hebben weten terug te dringen.
Dataverkeer, wat is dat eigenlijk?
Wanneer een bezoeker een website opvraagt, dan moet er allerlei data van de webserver naar de browser van de bezoeker worden gestuurd. In de html staat welke bestanden allemaal nodig zijn om de website op te bouwen (plaatjes, javascript, stylesheets etc.).
Ieder van deze bestanden heeft een bepaalde bestandsgrootte in kilobytes en al deze bestanden bij elkaar opgeteld geven de 'footprint' van de website voor 1 persoon (bijvoorbeeld 100 kilobyte). Voor het totale dataverkeer moet je het vorige getal vermenigvuldigen met het totaal aantal bezoekers. Zo kom je met 1000 bezoekers voor een website met een 'footprint' van 100 kilobyte als snel op zo'n 100 MB aan dataverkeer.
Op onderzoek uit
Stap 1 in het optimaliseren, is onderzoeken wat de 'footprint' van de website is. Een handige tool hierbij is de Firefox extensie 'Firbug'. Deze geeft exact inzicht in welke bestanden allemaal worden opgevraagd bij het laden van de website, hoe groot ze zijn en wat de totale laadtijd is.

Uit het bovenstaande plaatje kunnen we afleiden dat er 24 requests nodig zijn om de website voor het eerst te laden. Verder blijkt dat de totale footprint van de website 1012,9 Kilobytes is en de totale download time is (bij een snelle verbinding) bijna 2 seconden. En dan is hierin nog niet meegerekend dat er voor vervolg pagina's meer verkeer en requests nodig zijn. Voldoende mogelijkheden dus voor verbeteringen dus!
Onze aandachtspunten naar aanleiding hiervan zijn:
- Het aantal requests drastisch verminderen. Voor iedere request moet er namelijk opnieuwe verbinding met de server gemaakt worden. En dat kost tijd en dataverkeer
- De totale grootte van de bestanden proberen te verkleinen, en dan met name die van de plaatjes.
Onze oplossingen
Een van de verbeterpunten betrof de javascript die op de actiewebsite wordt gebruikt. We hebben daar de volgende acties genomen:
- Om te beginnen hebben we ervoor gezorgd dat alle javascript bestanden van de website gecombineerd werden in 1 bestand. Oorspronkelijk waren er 3 losse bestanden. Door deze te combineren verminder je het aantal requests met 2, en ook de totale bestandsgrootte wordt iets kleiner.
- De Nescafé actiewebsite maakt gebruik van Mootools als Javascript framework. Dit framework is, in gecomprimeerde vorm, al behoorlijk klein (27 kilobyte). Maar, zoals we eerder hebben gezien, 20.000 keer 27 kilobyte is toch al snel meer dan 500 MB dataverkeer. Gelukkig biedt Google een service aan, waarbij je het Mootools framework via hun netwerk kunt laden. Oftewel: Google neemt onze 500 MB dataverkeer over! Mooi meegenomen.
De grootste verbeterpunten waren mogelijk op het gebied van de website plaatjes. We hebben hierbij gekeken naar manieren om de plaatjes zelf kleiner te maken en het aantal requests te verkleinen.
- Een aantal achtergrond plaatjes bleek vrij groot van formaat te zijn. Tot over 300kb. Het ging in dit geval om PNG-images. De initiële keuze voor PNG is ingegeven door het feit dat PNG transparantie ondersteund en een hoge kleur resolutie heeft. Uiteindelijk hebben we deze grote PNG images omgezet naar GIF images. Dit formaat ondersteund wel transparantie, maar kan slechts 256 kleuren weergeven. Het is een kwestie van testen, maar uiteindelijk hebben de plaatjes succesvol om kunnen zetten naar GIF. Met als resultaat plaatjes die tot 3 keer zo klein zijn.
- Om het aantal requests drastisch te verkleinen hebben we een handige techniek gebruikt, die bekend is onder de naam 'CSS sprites'. Dit houdt kort gezegd in dat je verschillende plaatjes in één bestand combineerd. Vervolgens vervang je de <IMG>-tag door een <DIV>-tag, met het gecombineerde bestand als achtergrond plaatje. Met behulp van background-positioning kun je ervoor zorgen dat het juiste gedeelte van het achtergrond plaatje wordt getoond. Het resultaat is dat je in plaats van 10 plaatjes, slechts 1 (groter) plaatje hoeft te downloaden.
Als je op een slimme manier plaatjes met eenzelfde kleur combineert, kun je zelfs de totale bestandsgrootte nog verkleinen. Het grote plaatje is in totaal minder kilobytes dan alle afzonderlijke plaatjes!
Het resultaat
Uiteindelijk gaat het er natuurlijk om wat onze acties daadwerkelijk hebben uitgehaald. Om dit te bekijken hebben we opnieuw een test gedaan met Firebug, met zeer positieve resultaten!

We hebben het aantal requests naar beneden weten te brengen van 24 naar 6! De totale footprint is met meer dan de helft verkleind en de totale laadtijd is van 1,96 seconden naar 180 miliseconden gebracht.
Conclusie
We kunnen concluderen dat we met onze acties een goede stap gemaakt hebben om het dataverkeer voor deze actiewebsite terug te brengen. Dit leidt uiteindelijk tot een WIN-WIN-WIN situatie:
- De klant is blij, omdat een extra rekening voor het overschrijden van het dataverkeer misschien niet nodig is, of in ieder geval lager zal zijn
- De bezoeker is blij, omdat de website aanzienlijk sneller zal laden
- En wij zijn blij, omdat we onze klant en haar bezoekers goed van dienst hebben kunnen zijn




