Snellere website: Let goed op met Google Pagespeed

2 Juni 2010
0
 

Dit is het laatste blog in de serie over het meten van de snelheid van uw website. In het eerste deel van deze serie werd Google Pagespeed geïntroduceerd en in deel 2 en deel 3 werden een aantal adviezen gegeven. Dit blog laat zien waarom sommige Google Pagespeed adviezen niet perse absolute snelheidswinst garanderen.
 

Google Pagespeed is een technische meting

Google Pagespeed is een add-on die in Firefox gebruikt kan worden om de snelheid van een website te bepalen. Er wordt een score getoond en er worden adviezen gegeven. Maar de tests en adviezen die in Google PageSpeed zitten zijn alleen maar technische tests en adviezen. Dat wil zeggen dat er puur naar het aantal bestanden, de grootte van de bestanden, waar ze naartoe linken, etc.. wordt gekeken. Een groot deel van de tests zijn erg nuttig, zelf achter deze punten komen is anders een omslachtige klus.
Het nadeel aan puur technische testen is dat deze geen rekening houden met meerdere factoren. Hieronder een tweetal bevindingen die essentieel zijn als je de adviezen uit Google Pagespeed goed wil gaan implementeren.
 

Een CDN vs. de combineer techniek

Eerst een korte herhaling van wat de CDN doet en wat de ‘combineer’ techniek is.

  • Een CDN staat voor Content Delivery Network en is beschreven in deel 3 van deze serie. Een Content Delivery Network kan gezien worden als 1 wereldwijde ring van server die met elkaar in verbinding staan. Zodra er op 1 server een bestand geplaatst word, wordt deze gedupliceerd en op alle andere servers geplaatst. Zodra een gebruiker uit Hong Kong dat bestand opvraagt op de CDN wordt deze ingeladen vanuit Hong Kong. Als een andere gebruiker uit Haarlem hetzelfde bestand opvraagt, dan wordt deze van de server in Haarlem geleverd. Het voordeel is dat deze bestanden altijd snel bij de gebruiker zijn. Een CDN wordt niet zozeer aanbevolen door Google PageSpeed maar is een goede techniek om te gebruiken als het om het verbeteren van de websitesnelheid verbeteren gaat.
  • In deel 2 van deze serie staat punt 2: Combineer. Het combineren van bestanden tot 1 groot bestand heeft als voordeel dat er minder keren een verbinding met het internet gemaakt hoeft te worden om een bestand te downloaden. En als je veel verschillende Javascript of CSS bestanden gebruikt kan dit al snel tot 10 verbindingen per pagina schelen.

We hebben nu 2 goede adviezen. “Combineer je bestanden” en “Verspreid je bestanden(met een CDN)”. Wat de beste methode is hangt af van je website.
Heb je een website die enkel lokaal publiek trekt ( bijvoorbeeld een bakker) of een website die internationaal bezocht wordt ( bijvoorbeeld Auping)? In het eerste geval kun je beter alle bestanden bij elkaar combineren tot 1 bestand en op je webserver zetten. Omdat alle bezoekers toch uit de zelfde regio komen zal een CDN minder effect hebben. In het tweede geval kun je beter (delen van) de Javascript en CSS bestanden die niet meer wijzigen samenvoegen en op een CDN zetten.

Bij de 2de optie krijg je de “Minimize DNS lookups” melding van Google PageSpeed omdat de CDN maar 1 of bestanden levert en dat je dit “beter kunt combineren door het op je eigen server te zetten”. Zoals gezegd een technisch goede analyse maar qua snelheid voor zowel nationale als internationale bezoekers is de CDN een snelheidswinst die DNS lookup meer dan goed maakt. Helaas geeft Google PageSpeed hier wel ‘minpunten’ voor maar daar moeten we dan juist doorheen kijken.
 

Parallelize downloads across hostnames

Zoals aangegeven in deel 2 hebben browsers beperkingen. Een daarvan is dat er slechts 2 bestanden tegelijk van 1 (sub)domein gedownload kunnen worden. Als je dus veel downloads(plaatjes, javascript, css) hebt van 1 domein kan dit een vertragende factor zijn.

De verdeel techniek in deel 2 liet zien dat als we meerdere subdomeinen maken die naar dezelfde plek wijzen als het hoofddomein dat we dan meer downloads kunnen binnenhalen. Een voorbeeld: Advies van Google PageSpeed ”This page makes 165 parallelizable requests to www.uwdomein.nl. Increase download parallelization by distributing these requests across multiple hostnames:” We hebben dus 165 request en we kunnen per domein maar 2 downloads doen.
De logische gevolgtrekking van Google’s advies is dat als we 83 subdomeinen maken en we verdelen de boel eerlijk (dit kan vrij eenvoudig door een programmeur in elkaar gezet worden) dan kan alles in 1 keer binnen gehaald worden. Hier zitten helaas een aantal haken en ogen aan:

  • Teveel DNS lookups. Het opzoeken van een domein kost tijd. Een webbrowser die 83 subdomeinen moet opzoeken is hier erg lang mee bezig. Als een browser de weg naar 1 subdomein al een keer heeft opgevraagd dan hoeft hij dit niet nogmaals te doen. Maximaliseer dus niet direct het aantal subdomeinen alleen maar omdat het kan. Experimenteer hiermee en kijk wat voor jou het beste aantal is.
  • Bandbreedte en processorsnelheid. Stel dat je een website hebt met pagina waarop veel fotomateriaal gebruikt wordt. Een pagina met veel foto’s kan al snel 4 tot 10 megabyte groot worden. Hou er rekening mee dat er nog steeds bezoekers zijn, ook vanuit Nederland, die niet de allerzwaarste ADSL verbinding en de nieuwste PC’s hebben. Stel dat we een 8MB verbinding hebben, wordt er dus binnen 1,2 secondes 10MB in de webbrowser gepompt die dit moet verwerken. Bij een tragere PC kan dit voor een trage of een vastlopende browser zorgen.
  • Is alleen effectief bij kleine bestanden. Doordat de meeste bezoekers met een ADSL verbinding werken waarbij de upload niet heel hoog is, heeft deze techniek vooral effect bij kleinere bestanden. Grotere bestanden duren nu eenmaal lang om binnen te halen.

Een goede richtlijn bij geparalleliseerde downloads is dat 2 tot 4 subdomeinen voldoende zijn voor de meeste websites. Heb je een website met veel foto materiaal dan kun je dit uitbreiden naar 6 of 8. Meer subdomeinen gebruiken heeft weinig toegevoegde waarde. Pas dit principe toe op bestanden tot 10kb. Bij bestanden groter dan 10kb is het effect minder groot

Bovenstaande punten vragen dus om goede tuning van het webdevelopment team. Volg niet zomaar blind alle adviezen op maar kijk of uw programmeur u kan adviseren over welke technische strategie het handigste is.
Heeft u nog vragen over Google PageSpeed, reageer en kijk wat onze “reactie-snelheid” is.

Vincent Fabris
Vincent Fabris

Technisch Directeur

Vincent leest graag en heeft een passie voor techniek. Als technisch directeur is hij steeds op zoek naar technologisch hoogstandjes om Apollo CMS te verbeteren.






Reacties
0
Reageren
Naam
Email
Reactie

Website advies of een idee? Kom naar ons gratis spreekuur!

Eerstkomende plaats: Wanneer het u schikt!

Inschrijven