Zes tips voor een snellere Drupal website

Door Rick · Op 28 mei, 2015

Niets levert grotere irritatie op dan een trage site. Een snelle website zorgt dus voor een betere gebruikservaring, maar leidt als gevolg daarvan ook tot meer conversie en een hogere kwaliteitsbeoordeling door Google. Het is dus zaak om je website zo snel mogelijk te maken. Maar elk CMS is anders. Wat het ene CMS een flinke snelheidsboost geeft, hoeft bij het andere CMS een aanzienlijk minder goed resultaat geven. Wat zijn nu de ultieme tips om een Drupal site te versnellen?

In het kader van de themaweken Snelheid van webhoster Byte wilden we hier graag dieper op in zoomen. Maar zelf ben ik geen inhoudelijke Drupal specialist. Ik ben daarom de fora en sociale media ingedoken om mensen die dagelijks met Drupal werken te vragen wat zij als ultieme snelheidstip zouden geven. Zo heb ik handige tips van Drupal specialist Bas Vredeling gekregen, en is er een goede en vruchtbare discussie in de internationale Drupal LinkedIn-groep ontstaan. Het zijn niet per definitie waarheden, maar meningen en ervaringen van de gebruikers zelf. Des te nuttiger lijkt mij. In dit artikel geef ik er een samenvatting van.

 

Tip 1. Gebruik caching

Zonder alle tips te ranken, kan ik toch zeggen dat het gebruik van caching met stip op 1 staat als het gaat om meestgenoemde tips. Met het serveren van gecachete pagina’s aan je bezoekers kun je verreweg de beste resultaten behalen.

In de praktijk heb je echter vaak te maken met twee soorten content: de statische content die voor elke anonieme bezoeker gelijk is en de dynamische content die per bezoeker verschilt, denk aan de klantnaam in de welkomsttekst of gepersonaliseerde informatie achter een inlog.

Subtip 1: Cachingtechniek Varnish wordt als meest effectief benoemd. Wel met de kanttekening dat je het als full page cache moet gebruiken. Dat betekent dat de hele pagina als statische content wordt benaderd. Zodra je bepaalde blokken uit je site niet mee wilt cachen wordt het vaak een uitdaging en lever je ten opzichte van full page cache altijd in op de snelheidswinst. Niet zelden gehoord: de snelheidswinst is dermate groot dat het het waard is om kritisch te zijn op je content.

Maar in de discussie wordt nog tal van andere cachingtechnieken genoemd:

Subtip 2: Gebruik de generieke cache van Drupal. Zet deze op normal (agressive wordt niet aangeraden door de respondenten). Eén van de respondenten raadt deze cachingtool echter specifiek af voor dynamische content:

Subtip 3: De module Object Cache. Om Object Cache in te stellen heb je een tweede cache backend nodig. Een cache backend als Memcache of Redis werkt hiervoor goed, stelt Bas Vredeling. Definieer dan via Object Cache welke informatie je gaat cachen.

Subtip 4: Authcache (Authenticated User Page Caching). Eén van de developers noemt Authcache als goede optie voor het cachen van gepersonaliseerde pagina’s: “You can set it to cache for certain roles and you can load personalized blocks via ajax. It does take some config to get right. You can also use this with varnish, memcache, filecache, etc.”

Subtip 5: Entity cache: deze vorm van caching cachet alle core entities zoals node_load() calls in Drupal’s cache API. Zowel de respondenten als Drupal wijzen erop: gebruik deze niet in combinatie met de default database cache (= geen effect), maar met een cache backend als Redis of Memcache.

Tip van Drupal developer Bas Vredeling: ‘Vergeet niet dat alles wat je cachet ook een expiration nodig heeft. Met de Rules module en Expire module kun je gericht expiration rules instellen.’

 

Tip 2: Kies voor goede hosting

Een tip die wij als hostingpartij natuurlijk alleen maar kunnen beamen. Hoewel een hoster je site niet per definitie sneller maakt (een brakke site wordt nooit snel), geldt het omgekeerde wel: een langzame hoster kan je site flink vertragen. Eén van de respondenten stelt het zo:

‘Check your hosting! I’ve seen plenty of website get 2-3x more performance by using good providers instead of those overselling cheap OpenVZ containers.’

 

Tip 3: Zet de modules uit die je niet gebruikt

Bijna alle respondenten stippen aan dat het belangrijk is om af en toe eens kritisch naar je modules te kijken. Welke gebruik je eigenlijk niet of gebruik je maar op bepaalde momenten? Zet die dan uit zolang je ze niet gebruikt. Tips uit de praktijk:

‘For instance if you used Feeds to import content and no longer need it, disable it.’

‘Also make sure the developer didn’t leave Devel or Devel Themer turned on. I’ve run into a few sites where the dev team left development modules in the site and event left them rebuilding the theme cache on every page view.’

Meerdere keren wordt ook specifiek op de UI modules gewezen:

‘Disable any of the UI modules, like views_ui, context_ui, field_ui etc. They’re not needed in a production site and will bloat memory requirements.’

Zorg er dus voor dat er een zo klein mogelijk aantal modules geladen moet worden bij elke page request.

 

Tip 4: Ga zorgvuldig om met de module Views

De module Views maakt het mogelijk om op een flexibele manier de inhoud van je site in lijsten of tabellen te tonen. Zo kun je met Views bijvoorbeeld een lijst van de tien populairste boeken van je boekensite tonen met een titel, een kleine afbeelding en een korte beschrijving. Met Views wordt het mogelijk de informatie te filteren of te sorteren.

Subtip 1: Cache Views. Een tip die vaak terug komt. Maar doe het ook zorgvuldig:

‘If you use Views, set a short for each display, like five minutes. that way you have relatively fresh content, and your cache tables won’t get out of hand.’

Ook Bas Vredeling benadrukt dit: ‘Probeer voor alle Views en View Displays een geschikte en ambitieuze caching in te zetten. Maak eventueel ook gebruik van een module als views_content_cache.’

Subtip 2: Schakel de Views die je niet meer gebruikt uit. De module Views Maintenance geeft je een overzicht van alle inactieve Views. Alles verwijderd? Schakel dan je module weer uit (zie tip 3 ;-))

Subtip 3: Wees voorzichtig met grote data sets:

‘The queries are auto-generated by Drupal, so consider the filters carefully, for every filter will add complexity to the auto-generated queries and will increase the number of database calls in the process.’

 

Tip 5: Optimaliseer je MySQL en PHP performance

Deze tip komt specifiek van Bas Vredeling:

‘Als alle content dynamisch en oncachebaar is gaat het vooral om je MySQL en PHP performance. Denk dan aan geheugen voor beide services en service level caching.’

‘Wat betreft MySQL is het belangrijk om voor de meeste van je tabellen InnoDB te gebruiken en niet MyISAM. MySQL query cache en geheugeninstellingen kunnen enorme winst opleveren.’

Wat PHP betreft:

‘Recente PHP versies zijn veel sneller dan oudere. En Drupal draait meestal vlekkeloos op PHP 5.5 en hoger. Daarnaast kun je in oudere versies van PHP APC gebruiken om PHP te versnellen. Voor recente versies van PHP is OpCache de te verkiezen optie.’

 

Tip 6: Draai cronjobs buiten piekuren

Wellicht één van de basic tips, maar ik wilde ‘m toch graag benoemen. Eén van de gebruikers noemt dat haar Drupal site steevast langzamer werd zodra de cronjobs gaan lopen. Ze adviseert: ‘Be strategic and leave most of your cronjobs to run during non-peak hours.’

Tot zover de tips die developers die dagelijks met Drupal werken graag wilden delen. Het zijn zeker geen ‘waarheden’, maar ervaringen uit de praktijk. Dus heb je aanvullingen op deze tips, of heb je zelf nog handige tips die hier niet benoemd worden? Kom maar op!

Via emerce.nl