Een site kan traag zijn om twee redenen:

• De verbinding met de server is traag.
  Dit kan twee oorzaken hebben: de server zelf is traag (overbelast, teveel php en MySQL opdrachten,...), of
  de verbinding met het internet is onvoldoende (niet berekend op het dataverkeer).
• De website zelf wordt te traag verwerkt.
  Dit is een client-site probleem, maar het is eigenlijk het deel waarover je het meeste controle over hebt! We behandelen deze aspecten in detail.

Echter: het "huren" van een com of org domeinnaam bij internic (het equivalent van dns.be) kost bijna 10 dollar per jaar. Aan je 12€ op jaarbasis maakt de provider dus niet veel winst, hij moet het hebben van de aantallen. En daar wringt juist het schoentje. Er zijn teveel gebruikers, de servers draaien bijna constant op hun maximale capaciteit. PHP vraagt relatief veel rekenkracht. De meeste providers zoals telenet en skynet laten geen PHP toe, dus iedereen die PHP nodig heeft is verplicht naar one.com of soortgelijke providers uit te wijken. Daarbij komt nog dat de bandbreedte van de provider maar nipt toereikend is. De provider moet immers betalen voor de bandbreedte. En de bandbreedte wordt overwegend gebruikt voor uploads, dus speling is er nauwelijks. Als de limiet bereikt wordt, is je site voor een tijdje onbereikbaar.

Daartegenover is hosting bij je eigen provider (Telenet of Skynet) een betere alternatief: de klanten van Telenet en Skynet zijn overwegend "consumenten" (downloaders). Er blijft dus veel upload-bandbreedte over. De klassieke "users" account is niet ideaal. Je zit namelijk tussen duizenden andere gebruikers en Google maakt weinig onderscheid tussen deze gebruikers. Configuratie is er niet (een custom error pagina bijvoorbeeld bestaat niet). Beter is een eigen domein naam gekoppeld aan je "users" account. Telenet verdient er grof geld mee, maar je steekt tenminste uit tussen al de andere "users.telenet.be".

Voor ieder element op de pagina moet de cooresponderende renderer geladen worden. Voor een JPEG of GIF is dit geen probleem, die zitten in de browser ingebakken. Maar flash animaties, java,... vragen allemaal een helper applikatie. Daarbij komt nog dat Firefox en Microsoft allebei hun eigen versies hebben. Adobe heeft flash (dat nu redelijk ingeburgerd is), Microsoft moet daarom Silverlight hebben. Precies hetzelfde, maar niet compatibel.

Met mijn oude computers (windows 2000 en XP) verschijnt een pagina binnen de 5 seconden. Bij Vista (zelfs na een clean install) duurt het gemiddeld 30 seconden. De bezoeker weet echter niet waarom de pagina zo traag verschijnt (en het kan hem ook niet schelen). Maar als een pagina er meer dan 10 seconden over doet om te verschijnen, dan is 50% van de bezoekers die via een zoekrobot gekomen is al weer weg. Google en Microsoft kunnen "timen" hoe lang een bezoeker op een site is gebleven wanneer hij terug naar Google keert om een andere keuze te maken.

De conclusie is duidelijk: je site moet sneller geladen worden! Als je een belangrijke site bent (VRT, Coca Cola,...) zal dat geen grote rol spelen, maar als je moet vechten tussen duizenden concurrenten moet je ervoor zorgen dat je site zo snel mogelijk zichtbaar is. Een klant kan zijn frigo evengoed bij de mediamarkt, vanden borre of selexion kopen. Of misschien bij u?

Met deze manier van doen wilt Google de effektieve laadsnelheid meten gezien vannuit de gebruiker, niet gezien vannuit de server van Google, die waarschijnlijk in een ander land gelegen is. De snelheidsmeting is dan ook meer objectief en leunt beter aan bij de ervaring van de gebruikers.

Voor de compatibele browsers (zoals Firefox en consoorten) bestaan er plug-ins die de effektieve snelheid van de site berekenen. Zie screendump rechts:

• Hoe snel gebeurt de DNS resolutie? (het opzoeken van de adres van de server)
• Hoe lang duurt het vooraleer de server een antwoord geeft? (latency)
• Hoe snel komen de gegevens binnen? (bandbreedte)
• Hoe snel gebeurt de lokale verwerking, het "tekenen" van de pagina? (rendering)

• Gebruik eenvoudige kode, zeker op de landingspagina's (de pagina's die het eerst door de bezoeker bereikt worden), dit is minstens de index-pagina.
• Geen flash intro! Als het echt moet, gebruik dan een standaard (Flash), geen alternatief dat de bezoeker verplicht een plug-in te installeren (op dit ogenblik is dat vooral Silverlight).
• Gebruik compressie als dit mogelijk is (GZIP), comprimeer je afbeeldingen (logo's sla je op in GIF, foto's in JPEG): een hoge resolutie is niet nodig voor een thema dat op de achtergrond verschijnt (background)
• Gebruik een CSS file. Plaats alle formateringsopdrachten in een extern bestand (dat slechts éénmaal geladen moet worden), gebruik geen formateringsopdrachten in de HTML zelf (behalve in uitzonderlijke gevallen, bijvoorbeeld een formatering dat slechts enkele keren wordt gebruikt).
• Plaats niet teveel op je pagina. Zorg dat je pagina een afgewerkt geheel vormt. Zelfs al zijn bepaalde elementen van je site accessoir (versieringen en dergelijke), ze tellen mee bij de bepaling van de snelheid van de site.
• Beperk javascript Javascript wacht totdat de pagina geladen is om uitgevoerd te worden (wordt meestal met een onLoad event handler aangeroepen om fouten te vermijden 'object niet beschikbaar'). Als je pagina er lang over doet om alle elementen te laden, dan zijn bepaalde functionaliteiten onbeschikbaar of veroorzaken fouten.
• Geef de afmetingen van je elementen mee in de html van de pagina en forceer de client niet om de afbeeldingen te resizen (zet de afbeeldingen direct in de juiste afmetingen op de server) Daardoor kan de pagina sneller opgemaakt worden omdat er placeholders voorzien kunnen worden op de plaats waar de afbeelding zullen komen.

Volgende maand bespreken we de trends van de lente 2010: web 2.0 en zoekresultaten à la tête du client.