Performantie Drupal website voor Google optimalisatie

Ingediend door Donny op do, 05/05/2011 - 19:49

Zoals de meeste ontwikkelaars onder ons wel weten heeft Google een tijd geleden laten verstaan dat de laadtijden/performantie van websites steeds belangrijker zullen worden om goed te scoren binnen de zoekmachine.

Misschien heb je op de deze website de voorbije maanden ook geregeld wat zien veranderen en dan voornamelijk verdwijnen zoals bv de Facebook login. Aangezien dit buiten mijn blog ook nog steeds mijn 'experimenteer' website is ben ik enkele maanden aan het uittesten geweest op welke manier ik voor mezelf de beste resultaten kon krijgen qua performantie.

Sinds ik van hosting verandert ben was ik zelf vrij tevreden over de laadtijden van mijn website. Aangezien alles weer vlot kon laden installeerde ik geregeld nieuwe modules bij. Voor mij bleef alles vlot draaien maar echter bij het controleren en vergelijken van verschillende websites in Google Webmaster Tools, bleek dit niet het geval te zijn voor Google. Balen dus en dringend op zoek naar een oplossing.

Tijd voor wat grondiger experimenteerwerk leek me en zo ging ik dus op zoek naar een manier welke mij het beste leek om dit allemaal te kunnen opvolgen. Om de laadtijden te kunnen opmeten en vergelijken deed ik beroep op:

  • Firefox: Firebug (Net tab)
  • Firefox: YSlow
  • Chrome: PageSpeed
  • Chrome: Ingebouwd hulpprogramma voor ontwikkelaar (Network tab)

Bij de eerste metingen zag ik echter niet veel problemen, alles laadde binnen de 2 seconden. Google geeft zelf aan dat indien je onder de 2 seconden blijft, dat het goed zit. Mooi dus zou je denken, niet dus bleek niet veel later.

Er bleken grote verschillen merkbaar te zijn wanneer ik de website bezocht van thuis of op het werk, er waren zelfs grote verschillen te zien wanneer ik en mijn collega op Prosite op het zelfde moment de website bezochten met elk onze eigen laptop. Het meten van deze resultaten met browser plugins leek me dus niet langer de juiste optie.

Daarna schakelde ik over op tools zoals bv: http://tools.pingdom.com en soortgelijken maar ook hier bleken de resultaten niet overeen te komen.

Aangezien we de snelheid voor Google aan het verbeteren waren besloot ik om dit te gaan opvolgen via de Google Webmaster Tools zelf, op het moment van testen bleek Google toch elke 2 weken de nieuwe stand van zaken te voorzien.

Voor mobiele websites  had ik mijn theme A Cloudy Day Mobile draaien dus kon ik Drupal's ingebouwde cache systeem niet inschakelen. (Ongeacht de bezoeker mobiel kwam of niet, de versie uit het cache werd opgeroepen)

Daarop ging ik eens grondig mijn ingeschakelde modules nakijken en verwijderen wat mij overbodig leek. Met behulp van de Devel module is het ook eenvoudig om trage queries naar de database op te sporen. Eén van de eerste Drupal modules die verdween was de Facebook login module. Deze werkte echter prima maar bleek alles sterk te vertragen aangezien alle scripts van Facebook diende ingeladen te worden. Hetzelfde voor de 'Vind ik leuk' buttons.

In totaal verdwenen er 13 modules die me echter niet langer nodig leken en gerust konden verdwijnen. Dit zorgde jammer genoeg niet voor het gewenste resultaat. Als bezoeker van de website leek alles nog wat vlotter te draaien maar dit had jammer genoeg geen effect op Google.

Na de website overlay optie in Google Analytics te bekijken om te zien waar er juist veel kliks plaats vinden op deze site, kon ik ook gerust enkele blokken met inhoud verwijderen aangezien deze niet echt veel gebruikt worden. Weer wat minder queries naar de Drupal database dus.

Op template niveau haalde ik ook nog de tags/labels/taxonomie weg uit de teaser 'view', aangezien dit ook telkens weer een hoop queries waren die moesten plaatsvinden. Zo telde de homepage ook al dadelijk een boel minder links. (Aangeraden is om onder de 100 unieke links te blijven op een pagina, maar aangezien mijn homepage een blog is wordt dit moeilijk)

Tijdens deze testfase besloot Google me blijkbaar een handje te helpen en bijna dagelijks nieuwe gegevens over de laadtijden vrij te geven, nice! Maar jammer genoeg nog geen verbetering merkbaar.

Dan maar tijd om er met de grove borstel door te gaan waarna ik besloot om volgende stappen uit te voeren:

  • Alle themes buiten 'Kanji' werden verwijderd
  • Daarop kon de theme switcher module worden uitgeschakeld
  • Op Drupal.org heb ik de 'demo' links verwijderd voor de A Cloudy Day versies (Deze zorgen wel voor heel wat bezoekers maar die hadden jammer genoeg ook een hoge bouncerate bij aangezien deze blog in het Nederlands is)
  • Mobile Tools voor de mobiele browsers/toestellen kon nu ook verwijderd worden

Door het verwijderen van alle themes, kon ik nu wel Drupal's caching gaan inschakelen. Dit stelde ik in op 'normaal' en de minimum duur op 2 uur. Dit had als resultaat dat als ik de site terug ging nakijken met Firebug en soortgelijken dat de pagina's op dat moment geladen werden rond de 800ms.

Eindelijk een deftig resultaat dacht ik, tijdens het browsen door de website was de snelheid echt wel merkbaar, nu nog even Google afwachten.

Na enkele dagen was het weer zover en kreeg ik de nieuwe resultaten te zien:

Het laden van pagina's op uw site duurt gemiddeld 6,1 seconden (bijgewerkt op 8 apr. 2011). Dit is langzamer dan 82% van de sites

WTF?? De dag later werd dit zelfs 7 seconden. Pffff de moed zakte me even in de schoenen. Als bezoeker werd alles heel vlot geladen maar blijkbaar had dit geen effect op Google. Toen stelde ik me de vraag wanneer de Google bots zouden langskomen, indien dit bv s'nachts zou zijn dan is het cache waarschijnlijk aan vernieuwing toe en dan zou dit opgebouwd worden tijdens het bezoek van die bots. Dat was de enige verklaring die ik kon bedenken maar het was in ieder geval een piste om te proberen.

Daarop besloot ik zelfs "Aggressive caching" in te schakelen en dit op het maximum te zetten nl 1 dag, zodat dit zeker niet tijdens de nacht opgebouwd zou moeten worden maar overdag wanneer ik zelf op de site aanwezig ben.

Standaard worden Views (blokken, pagina's, ...) ook niet gecached dus besloot ik deze ook te laten cachen voor enkele uren. (Van daar dus ook de vertraging in het blok 'Recente reacties' wanneer je een reactie indient)

Het aggressief cachen had als nadeel dat wanneer bezoekers een reactie zouden indienen dat ze deze zelf ook niet meer dadelijk zouden zien op de website maar hier bood de module 'Content refresh' een oplossing.

Wanneer ik nu zelf de website laadtijd nakijk met Chrome kom ik op gemiddeld op 300ms terecht, waar ik zelf wel heel tevreden mee ben als je in je achterhoofd meeneemt dat ik op een shared hosting zit met deze website. (Indien je beschikt over je eigen server zijn er natuurlijk tal van andere oplossingen zoals bv Memcache)

Na enkele dagen wachten kreeg ik op nieuw een rapport van Google met deze keer wel het gewenste resultaat:

Het laden van pagina's op uw site duurt gemiddeld 0,8 seconden (bijgewerkt op 19 apr. 2011). Dit is sneller dan 95% van de sites.

Eindelijk een deftige laadtijd voor Google. Of het nu effectief echt zo belangrijk is (of zal worden) valt natuurlijk nog af te wachten. Wel stel ik me zelf de vraag hoe Google juist zal omgaan met deze gegevens en hoe ze deze verzamelen. Vanaf welke locatie worden deze bv getest, indien dit vanaf een server uit de States is dan zijn natuurlijk alle sites die hun server daar hebben staan bevooroordeeld aangezien die laadtijd een pak lager zal liggen dan wanneer de Google server uit de States een website hier gehost in België komt bezoeken. Maar zoals meestal zal het wel weer een goed bewaard geheim blijven zeker :-)

Kun je dit nu op deze manier op elke website toepassen? Nee zou ik zeggen, het lijkt me belangrijk om een goed evenwicht te zoeken tussen de laadtijd optimalisatie en de Usability. Deze laatste mag natuurlijk niet verloren gaan.

Op het moment dat ik de gewenste laadtijd behaald verscheen er een mooi artikel wat over hetzelfde onderwerp handelde. Zelf had ik ook gemerkt tijdens het vergelijken met andere website uit Google Webmaster Tools dat Drupal sites die als homepage slechts 1 node bevatten ipv een blog betere resultaten hadden. Dus heel even heb ik er over getwijfeld dit ook op deze site toe te passen, maar aangezien het nog altijd over een 'Blog' gaat leek dit echter niet interessant voor de bezoeker.

Dat al dit testwerk de laatste maanden voor heel wat ups en downs in de grafiek bij Google Webmaster heeft gezorgd kan je wel zien.

Laadtijden Google Webmaster Tools

Indien er iemand nog andere suggesties heeft, deze zijn natuurlijk altijd welkom.