Vanuit ons netwerk ontvingen we de vraag of een 100% pagespeed op Wordpress basis mogelijk was, waarbij de snelheid als ook gebruikerservaring optimaal bleef, en niet enkel gemeten werd middels een getal.
Met enige regelmaat krijg ik vragen binnen onze expertise. Soms is het antwoord perfect om te zetten tot een artikel, zoals ook begin december omtrent OctoberCMS.
Grote kans dat ook uw (bedrijfs)website in Wordpress is opgetrokken, en alhoewel de praktijk leert dat Wordpress sites veelal geen 100% pagespeed score genieten, is het behalen van deze score op papier bij benadering mogelijk. Zij het op kwantitatieve wijze.
Dit komt deels door de type plugins en deels door de gebruikte thema's en dus templates. Ook zul je niet automatisch een 100% pagespeed score behalen over alle pagina's, en kan het per pagina nazorg vereisen. Sommige technieken zijn onvolledig, ongunstig en niet zelden incorrect toegepast door de inzet van (verzwarende) plugins.
De klacht in dit geval, was dat ondanks een redelijke score die reeds behaald was, sommige pagina's binnen de website nog vrij traag waren. Het betrof een website met een versimpeld assortiment/productaanbod en zoekmogelijkheid. Mij werd gevraagd of de langzame laadtijd te tackelen was, en de pagespeed te verbeteren was. Gereviseerd tot een artikel, was mijn antwoord ongeveer als volgt:
Optimale PageSpeed binnen Wordpress
Een !00% pagespeed score is dus mogelijk, echter arbeidsintensief. Sommige zaken kunnen namelijk niet geautomatiseerd worden (zoals een correcte Critical Render Path binnen Wordpress), en sommige zaken kunnen binnen Wordpress blijkbaar niet afdoende geautomatiseerd worden (het mergen en minimizen van bronbestanden, gebeurt zelden over alle bestanden) en sommige zaken vinden standaard op incorrecte wijze plaats.
Wordpress fundering en geheugen
Het kan dus wel met Wordpress, maar er gaat standaard zoveel mis met betrekking tot performance/pagespeed, dat je zowel PHP als CSS moet kunnen om tot een 100% PageSpeed te komen. En terwijl je denkt dat je dan aan het winnen bent, verlies je eigenlijk terrein, door de fundering van Wordpress. Voor de meeste SEO/optimalisatie zaken heb je namelijk plugins nodig, of moet je binnen de code van Wordpress bij-programmeren. Gevolg is dus meer code, meer functie aanroepen, meer benodigde PHP geheugen en dus langere PHP laadtijd binnen Wordpress (en dus responsetijd). Het verschil met bijvoorbeeld het LightBolt CMS, is dat alle benodigde SEO toepassingen niet aanwezig zijn in de basis, waar dit in het geval van LightBolt, de 100% pagespeed het uitgangspunt is.
En dit verschil merk je inderdaad heel goed wanneer je door klikt binnen sommige Wordpress websites. Buiten de meer reguliere pagina's om, gaan er zwaardere plugins, meer code en meer functie aanroepen mee gemoeid om een pagina via PHP op te bouwen. Gevolg: langere PHP laadtijd, en dus hogere responsetijd / TTFB. Aan deze plugin-architectuur van Wordpress, valt echter lastig te sleutelen. Je hebt gewoonweg een basis (die al niet optimaal geprogrammeerd is), waarin vervolgens plugins worden gehangen (die volgens de blauwdruk van Wordpress geprogrammeerd zouden moeten worden, wat zijn eigen impact op laadtijd heeft).
Wordpress hosting
Deze responsetijd is wellicht wel enigszins te tackelen door te kiezen voor een hosting partij dat zich toespitst op Wordpress. Dit kan in praktijk al een wezenlijk verschil betekenen voor de pagespeed van een Wordpress website. Veelal betekent dit echter een duurder hosting pakket. Dit is het gevolg van verhoogde risico binnen Wordpress, omtrent security, kwetsbaarheden en benodigde server geheugen (LightBolt kan gemiddeld 664 keer meer bezoekers aan).
Hoe valt een lange laadtijd binnen Wordpress dan nog te tackelen? Soms zijn overzichtspagina's of zoekmodules binnen Wordpress erg traag. Dit kan door een slecht geschreven codebase van de plugin komen, onjuiste implementatie of weinig creativiteit. Ter illustratie: ik heb eens een zoekmodule voor een Wordpress site 100 keer sneller kunnen maken.
Optimale SEO belangrijk? Dan geen Wordpress
Aan het eind van de rit, zal het arbeidsintensiever zijn en kan het bovendien een tegendraads effect hebben om Wordpress te optimaliseren. Optimaliseren binnen Wordpress kan dus, maar gebeurt vaak onvolledig en onachtzaam (denk aan Wordpress zijn oplossing voor critical path oplossing) of incorrect (denk aan Wordpress' toepassing van resource hints).
Doe je dit toch, dan zal dit grotendeels middels plugins moeten, en maak je onbewust de website zwaarder onder de motorkap. Middels WP Super Cache (voor hoge TTFB's) lever je in op dynamiek.
Dit heb ik in praktijk bij Wordpress projecten met benodigde onderhoud (client- en serverside optimalisaties) meegemaakt. Alhoewel een tussenbureau tussentijds vaak niet voor een koerswijziging durft te kiezen om gezichtsverlies naar de eindopdrachtgever te voorkomen, kan het in praktijk toch lonen. Praktischer is om de eisen omtrent optimale SEO, performance en pagespeed vooraf in kaart te brengen, om te voorkomen dat er gekozen wordt voor een CMS dat erg arbeidsintensief blijkt om aan de eisen te voldoen.
Wordpress omzetten naar LightBolt? Wij deden het, inclusief behoud van hyperlinks, voor onder meer SNIJ Noord.