Drupal page cache killers
Snelheid van websites is en blijft een hot topic. Terecht, want performance wordt altijd maar belangrijker. Zowel voor de score in Google als voor de conversion rate is performance van zeer groot belang. Lees meer.
Hoe de performance van uw Drupal website verbeteren?
Snelheid van websites is en blijft een hot topic. Terecht, want performance wordt altijd maar belangrijker. Zowel voor de score in Google als voor de conversion rate is performance van zeer groot belang.
Om de performance van Drupal sites te verbeteren bestaan er veel mogelijkheden waarover uiteraard al geschreven is. Drupal komt "out of the box" al met een zeer krachtig mechanisme om de performance te verbeteren: de page-cache. In dit blog bericht zal ik hierop wat dieper ingaan, het heeft immers geen zin om "advanced" te gaan als je de basics nog niet optimaal benut.
Indien page-cache is geactiveerd zal Drupal elke pagina die getoond wordt aan niet ingelogde bezoekers volledig opslaan. De volgende keer dat dezelfde pagina bezocht wordt, moet het CMS de pagina niet meer opnieuw samenstellen, maar kan die direct uit de database teruggevonden worden.
Op het eerste zicht een vrij eenvoudig principe, maar er zijn een aantal factoren die een optimale werking kunnen bemoeilijken, page-cache killers dus.
Query strings
Als we spreken van "dezelfde pagina" bedoelen we eigenlijk, "dezelfde url" en dat is inclusief de query string. Onnodige query strings moeten dus zeker vermeden worden. Een url met een query string wordt gezien als een aparte pagina, dus zal Drupal de gecachete versie niet kunnen weergeven.
Lange urls
Wanneer er bij het opslaan van gecachete pagina's gebruik gemaakt wordt van een database (en dat is standaard het geval), dan kunnen er enkel pagina's met een lengte tot 255 karakters (eigenlijk bytes) gecached worden. Dit is ook iets om rekening mee te houden bij het aanmaken van aliassen.
Random content
Voor een correcte werking van de page-cache, moet eenzelfde url altijd dezelfde HTML output terug geven. Random content is hierdoor dus niet mogelijk. Indien het toch nodig is om random content te hebben, doe dit dan via javascript, cookies of ajax.
Anonieme sessies
Naast inloggen biedt Drupal ook de mogelijkheid om sessiedata bij te houden van anonieme gebruikers. Denk hierbij aan favorieten-lijstjes, onthouden van zoekresultaten... Het probleem is dat Drupal ook in dit geval geen gecachete pagina's meer terug zal geven. Vermijd dus zeker het gebruik van anonieme sessies, en gebruik ook hier weer javascript of cookies.
POST
Indien een pagina opgevraagd wordt met de http method POST, dan zal Drupal deze ook nooit cachen. Logisch, aangezien een http call via POST normaalgezien als doel heeft iets te veranderen op de server. Het probleem zit hem echter bij ajax calls, hierbij wordt zeer vaak POST gebruikt, en niet altijd terecht. Dit is historisch gegroeid en de reden hiervoor is dat de oude Internet Explorers niet goed konden omgaan met lange urls en GET. Browsers met deze beperking worden ondertussen vrijwel niet meer gebruikt (thank god...), dus er is geen enkele reden meer om voor het ophalen van statische content geen gebruik te maken van GET.
Als er met deze zaken rekening gehouden wordt, dan zal de page-cache veel beter zijn werk doen, wat de performance van een site enkel ten goede komt.