Gastblog van Bert Boerland
De meeste bedrijven die een website online hebben, hebben als doel om er geld mee te verdienen. Voor sommige websites is dat een directe manier van geld verdienen, omdat ze een webshop hebben, donaties verkrijgen of leadgeneratie hebben. En voor vele bedrijven is het een vorm van marketing, om gevonden te worden door hun prospects. Webperformance is dus niet een technisch trucje, maar een must voor een ieder. Als je geld verdient online, verlies je dat door een langzame website!
Snelle website
Content Management Systemen als Drupal zijn geweldig voor een gebruiker, zowel de redacteur als de bezoeker kan eenvoudig content toevoegen. Plaatjes worden automatisch geschaald en de tienduizenden modules leveren vaak de gevraagde functionaliteit. Maar dat komt met een prijs, ook in opensourceland. Voor elke pagina die het systeem samenstelt, moet de inhoud uit de database gehaald worden. Elke pagina die overzichtslijsten heeft (views) is een query naar de database. Elke pagina van een grotere website kan zo al snel honderden queries bevatten, enkel om een enkele pagina aan een enkele gebruiker te serveren. En dus ook met een snelle database vele seconden om de pagina aan de gebruiker te leveren. Een statische HTML-pagina serveren, is vele malen sneller.
Snelheid is de som van alle elementen
Dus aan de ene kant wil de business flexibiliteit om met een CMS content te kunnen veranderen. En aan de andere kant is het een eis dat een pagina binnen enkele seconden bij de gebruiker op het scherm staat. Om dit probleem op te lossen, is er niet een enkele actie die je kunt doen. Snelheid is de som van alle elementen tussen content en browser, de oplossing raakt dus ook alle elementen in deze keten; netwerk, operating systeem, het CMS, http en HTML. De enige oplossing om de performance te verbeteren van elke website – ongeacht het CMS – is dan ook er voor te zorgen dat de gehele keten wordt geanalyseerd en verbeterd waar noodzakelijk.
CSS en JS aggregate
Voor Drupal geldt dat het natuurlijk standaard is dat je CSS en JS aggregate gebruikt, hierdoor worden de tientallen CSS- en Javascript-bestanden samengevoegd en geminimaliseerd. Mooi. Tientallen minder hits is een aantal seconden sneller door een paar vinkjes. Maar nu begint het grijpen naar het hoger gelegen fruit. Hieronder staan enkel van de best practises, zoals deze geleerd zijn in de gemeenschap.
Minder hits
Vanuit de klant is het vaak gewenst om veel derde diensten te integreren, te meten met analystics en te delen via share this en a/b testing met Optimizely. Allemaal valide, maar elk Javascript-bestand is een extra DNS-request, een extra hit en extra parsing aan de browserzijde. Probeer de klant te overtuigen dat minder hits beter is Deze stap is waarschijnlijk het ingewikkeldste te realiseren, maar wel een die van belang is.
Caching in Drupal
Standaard heeft een CMS als Drupal caching staan in de database, het verste weg van de gebruiker vandaan. Dus alles wat deze caching kan verbeteren, is noodzakelijk. Dit kan door views en blokken te cachen.
Memcache en Varnish
Maar het verder ‘naar voren brengen’ van de cache, zodat deze niet in de database komt of zelfs Drupal ‘raakt’, is nog beter. Memcache is een goede methode, een platte tabel in het geheugen die direct door de webserver geraadpleegd wordt en waarvoor een Drupal module bestaat. Nog beter is het om Varnish te gebruiken, een reverse proxy, waardoor de verzoek nooit bij het CMS komt, maar direct geserveerd wordt. Dit werkt echter enkel voor niet ingelogde gebruikers en wil je in het CMS meten hoe vaak een artikel gelezen is in Drupal dan moet je hier dus omheen werken met een extra Javascript-call bijvoorbeeld. Typisch kan je met Varnish honderden keren meer gelijktijdig bezoek verwerken, terwijl het maken van de ‘index,html’-pagina onder deze druk van seconden naar 20 milliseconde gaat.
SSL-decrypter
Om er voor te zorgen dat de content zo ‘vers’ mogelijk blijft, dien je de expiratie-headers in de webserver zo te zetten dat de caching lang genoeg is, zonder dat de site gedateerd wordt en kan je de purge-module gebruiken. Je doet er goed aan om in de headers van de site te controleren dat het verzoek ook daadwerkelijk gecachet wordt en uit Varnish geserveerd wordt. Sommige modules en maatwerk willen dit nog wel eens voorkomen. Als jouw website https gebruikt, kan deze niet door Varnish gecachet worden. Hiervoor kan je een SSL-decrypter gebruiken voor Varnish, bijvoorbeeld pound, zodat Varnish toch gewoon http-verkeer ziet.
Zoekfunctionaliteit
Als de website een zoekfunctionaliteit heeft en je deze eigenlijk wil uitbreiden naar zoeken in binaire bestanden (PDF, MS-Word etc), neem dan een extra virtuele server met SOLR, installeer de module. En meest van belang, zorg dat de interne search de content niet meer indexeert, want de searchtabel is vaak de helft van de omvang van de database.
SPDY
Als je https gebruikt, denk dan ook aan de optie SPDY te gebruiken, de opvolger van het oude stateless http-protocol en de kandidaat voor http/2.0. Talloze browsers ondersteunen dit protocol al. Met SPDY worden de elementen van de pagina in een keer in een request gecomprimeerd geserveerd en dit kan zeker bij netwerken met een hoge latency het laden van een pagina halveren. Voor vele webservers (waaronder Apache en Nginx) zijn modules voor SPDY beschikbaar. Als dit nog geen optie is, kan je kijken naar de Google module ‘pagespeed’. Deze beschikt over een keur van opties; on the fly Javascript en CSS in de HTML injecteren als dat sneller is, lazyloading van plaatjes ‘onder de vouw’, het genereren van sprites en talloze andere opties die je site aanzienlijk sneller kunnen maken.
CDN
Een CDN kan een oplossing zijn voor tal van problemen: DDoS-bescherming, lagere roundtrip-tijden voor internationale gebruikers, maar ook meerdere requests serieel doen om de site sneller te laden. Dit kan je ook doen, zonder een echt CDN te gebruiken. De meeste browsers hebben een laag maximum aan het aantal requests dat men een dergelijke tijd kan doen naar een enkele server. Dus voor een pagina met 40 plaatjes vuurt de browser bijvoorbeeld 16 requests op de webserver af en wordt het volgende request pas geplaatst als er een succesvol is verwerkt. Hiervoor zou men dus kunnen werken subdomainen, om de pagina voor example.com te serveren gebruikt men CNAMES als images1.example.com en images2.example.com en doet men round robin loadlbalancing over deze namen. Hierdoor kan de browser nu 16 requests naar images1 sturen en 16 naar images2 op het zelfde moment. Er is een Drupal-module die dit voor je doet en ook kan integreren met de grote echte CDN’s als Akamai. Deze truc heeft enkele nadelen, je moet voorkomen dat searchengines images1.example.com gaan indexeren en er is een tradeoff omdat een extra DNS-request ook tijd vergt. Daarbij zal in de toekomst mede door SPDY deze techniek snel overbodig zijn.
Tips op servergebied
Op het gebied van de server zelf zijn er ook tal van tips van toepassing, al is dit verre van laaghangend fruit. Door bijvoorbeeld het renderbare deel van de pagina binnen de 1400 bytes te houden, kun je ervoor zorgen dat dit binnen een packet valt voor een ethernetverbinding. Het veranderen van de TCP slowstart-paramaters is een kernel hacking-ervaring, maar draagt ook bij aan een snellere website. Als gesteld, op elk gebied van business tot ethernet-frames dient men integraal webperformance te analyseren en verbeteren.
Meten van de snelheid
Er zijn vele tools die je kunnen helpen bij het meten van de snelheid en dit te verbeteren. Webpagetest en Yslow! zijn goede punten om te beginnen. Steve Souders is de autoriteit op dit gebied wereldwijd en zijn blog heeft tal van goede aanknopingspunten, 2bits heeft veel Drupal-specifieke artikelen online.
Over Bert Boerland
Bert Boerland is sales manager en partner bij Wunderkraut Nederland, onderdeel van de Wunderkraut Group. Wunderkraut is met 150 mannen en vrouwen het grootste Europese bedrijf dat gespecialiseerd is in Drupal en aanverwante technieken als AngularJS. Bert is gepassioneerd gebruiker van Drupal sinds de begindagen van het CMS, nu 14 jaar geleden, mede-oprichter en bestuurslid van de Stichting Drupal Nederland en organiseerde talloze DrupalJams waar meer dan 300 gebruikers en ontwikkelaars samenkomen. Bert is mede organisator van de Splash Awards, die gesponsord worden door True.
