Tot dusver is er veel gezegd over frontend / client side optimalisatie, oftewel het reduceren en/of samenvoegen van http requests als ook bronnen. Maar ook verder onder de motorkap valt er vaak uitstekend te optimaliseren en dus winst te behalen. Afhankelijk van de afwikkeling, zal HTML pas in de browser terecht komen, als de code onder de motorkap klaar is met zijn taak.
Dit is een vervolg op website optimalisatie en Wordpress plugins
CMS als Wordpress
Wordpress lijkt erg flexibel met de vele plugin mogelijkheden, maar is daardoor van zichzelf vrij zwaar. Juist door de daarvoor benodigde programmatuur, vinden er veel functie-aanroepen plaats en is de interne opzet erg zwaar in geheugen. Zaken (externe bronnen in of uitschakelen, meta tags beinvloeden) dienen niet zelden 'met terugwerkende' kracht bijgesteld of aangevuld te kunnen worden door bijvoorbeeld plugins of thema's. Al eens eerder heb ik in de basis (dus zonder externe tools) een Wordpress zoekmodule 100 keer sneller gemaakt, doordat de database opzet niet ideaal was, en de programmatuur niet geoptimaliseerd. Dit zijn complicaties die snel kunnen optreden bij plugins doordat de kennis van een plugin-ontwikkelaar niet altijd op alle takken van sport ligt of de plugin als verkeerde basis voor een wens van de klant wordt gebruikt.
Achter de schermen
Logischerwijs staat het geheugen dat benodigd is om tot een resultaat in je scherm te komen, in directe verhouding met de hoeveelheid PHP code en/of functie aanroepen die gedaan worden. Uiteraard betekent meer classes en functies niet per definitie slechtere code, maar in mijn optiek, moet je altijd pogen overtollig code uit te sluiten. Waar het bij Wordpress dan mis gaat? In de basis. Het betrof van oorsprong een blogsysteem, door zijn populairiteit uitgegroeid tot meer. En vanaf dat moment is het passen en meten geweest om bestaande functionaliteiten overeind te houden, wat de kwaliteit van verdere programmatuur niet in de hand heeft gewerkt.
Wordpress geheugen en laadtijd
Hier liep iemand met zijn Wordpress site tegen 256MB aan benodigd geheugen aan. Uitendelijk heeft hij dit kunnen reduceren tot 60MB. Maar zelfs 256MB is niet uitzonderlijk. Een Wordpress met Woocommerce, neemt eenvoudig honderden MB's aan geheugen in beslag.
Recent mocht ik een Wordpress site verhuizen, waarbij ik direct een benchmark heb uitgevoerd (van die gelegenheid maak eigenlijk altijd gebruik). De site vergde ongeveer 80MB aan geheugen per hit en de uitvoertijd door PHP was niet onder de 1.3 seconden te krijgen. Let wel: daarna kan dus pas de browser beginnen met verwerken van HTML en inladen van bronbestanden als CSS en JS. Deze site zal dus nooit de SEO concurrentie aan kunnen gaan. Google's PageSpeed Insights zal een laadtijd boven de 0.2 seconden aankaarten als zijnde een te langzame server response tijd.
Het betrof een erg simplistische website (met hooguit verkeerde thema-keuze) en 4 menu-knoppen. Meest frappante was dat de hostingruimte waar de website vandaan verhuisd werd, zich juist toespitst op Wordpress hosting. Hier behaalde de site dan ook beduidend betere resultaten. Dertig (30) MB aan geheugen, waarbij de PHP de gehele website niet onder de 0.3 seconden boven water kon halen. Maar het kan gewoon optimaler (spoiler-alert: niet met Wordpress).
Re-actief in plaats van pro-actieve oplossing
Keerzijde van het gebruik van een framework of CMS, is dat het optimaliseren vaak onmogelijk is door de blauwdruk van het systeem, of te arbeidsintensief wordt. Je zult dus re-actieve oplossingen in de strijd moeten gooien, wat mijn inziens nooit de bedoeling zou moeten zijn.
Probeer je het geheugen-probleem voor Wordpress te tackelen? Dan zul je al snel beginnen met Googlen naar "php memory Wordpress". Echter, de type oplossingen die je krijgt, illustreert direct Wordpress zijn probleem. "Geheugen issues? Verhoog het limiet" lijkt helaas het credo.
Vertaal dit eens naar de voedsel industrie, waarbij 60% (Wordpress marktaandeel in Nederland) van de producten te veel zout bevat. Zout-gehalte limiet ophogen is dan niet de oplossing.
PHP geheugen en laadtijd van ons CMS
De pagina die je nu bekijkt, schommelt rond de 1MB aan geheugen per hit en door PHP binnen 0.05 seconden uitgevoerd. Wederom zonder caching mechanismen, waar de laatste Wordpress meting onder zeer optimale omstandigheden draaide. Dit CMS (bouwjaar 2010) is dus nog 10 keer sneller. Maar vooral het verschil in geheugen, heeft als gevolg dat we makkelijk 40 keer meer bezoekers dan Wordpress kunnen verwerken, namelijk ongeveer 2.800 ten opzichte van 70 gelijktijdige bezoekers binnen een Wordpress site binnen een hostingpakket van 2GB geheugen. Pijnlijk verschil.
De binnenkort uit te rollen upgrade van ons CMS, behaalt nog optimalere resultaten, waarbij Wordpress het helemaal af moet leggen. Tot dusver komen we tot een benodigd geheugen per page-hit van ongeveer 662kb en een laadtijd van 0.017 seconden. Ik durf te stellen dat gezien het draagvlak van Wordpress, dit sneller is dan dat 99,99% van de Wordpress sites ooit zal kunnen worden. En zelfs 100% is realistisch om te zeggen, doordat er binnen Wordpress vanaf een bepaald punt enkel nog re-actief geopereerd kan worden, bijvoorbeeld middels het inzetten van Varnish.
En in een SEO strijd, is dat een knelpunt. Deze pagina behaalt een Google PageSpeed score van 100%, met als aanvulling de door ons gepubliceerde optimalisatie technieken die zelfs niet allemaal door een pagespeed tests geanalyseerd worden, maar wel extra bevorderlijk werken.
Voor Wordpress heb je enkel aanvullende Wordpress plugins en aanpassingen nodig; je wint iets in pagespeed score, maar maakt je Wordpress website bovenal enkel zwaarder, langzamer, duurder en kans op conflicten en security-issues door gebruik van Wordpress plugins nemen toe.