Naast de PageSpeed Insights test biedt Google ook de zogenaamde Google PageSpeed Module aan. Dit is een opstelling die websites automatisch optimaliseert volgens de specificaties van Google. In onze test had de module echter precies het tegenovergestelde effect: hij vrat de prestaties van onze pagina's genadeloos op. Een veldverslag.
De meeste websitebeheerders zijn ermee bekend: de Google PageSpeed Insights test. Het onthult op betrouwbare wijze het optimalisatiepotentieel van de geteste websites en laat tegelijkertijd zien hoe je je eigen site kunt optimaliseren. optimaliseer je eigen je eigen site. Het is daarom vaak een van de eerste plaatsen waar de prestaties worden geoptimaliseerd.
De tips en hints waarmee Google PageSpeed Insights de gebruiker aanvankelijk relatief met rust laat, worden automatisch uitgevoerd door de Google PageSpeed Module. Als het op de webserver wordt geïnstalleerd, brengt het programma niet alleen optimalisatiemogelijkheden aan het licht, maar voert het de verbeteringen ook direct uit.
Vooral gezien het feit dat Google onlangs de laadtijd tot een officieel rangschikkingscriterium heeft gemaakt, lijkt de mogelijkheid om de pagina automatisch te optimaliseren meer dan aantrekkelijk. De module wordt zo een verondersteld geheim wapen van prestatieoptimalisatie. En ook voor ons was het natuurlijk heel verleidelijk.
Daarom hebben we het een goed jaar geleden en op verzoek van verschillende klanten uitgebreid getest. Onze conclusie: Voor ons als hoster heeft de module geen zin.
Complexiteit van de projectkiller
Om een lang verhaal kort te maken: De complexiteit van de combinatie van WordPress en de uiteenlopende filteropties van de PageSpeed Module maakte implementatie voor ons onmogelijk. Let wel, niet de al te complexe werking van de module is hier debet aan, maar het grote aantal configuratiemogelijkheden. De module zelf kan vrij comfortabel en intuïtief bediend worden.
De Page Speed Module biedt twee door Google vooraf gedefinieerde filtersets: De zgn. kernfilters en de Optimaliseren voor bandbreedte filters. De Kernfilters zijn een verzameling regels die het Google PageSpeed team heeft samengesteld en waarvan ze aannemen dat ze veilig kunnen worden toegepast op de meeste pagina's. Daar is echter geen garantie voor. Aan de kernset worden steeds nieuwe filters toegevoegd, waardoor de geoptimaliseerde pagina's voortdurend sneller worden - althans in theorie.
De kernfilterset is dus altijd actueel, maar ook vrij instabiel. In de praktijk betekent dit dat je de stabiliteit en laadtijd van de pagina na updates moet controleren. Anders bestaat het risico dat de pagina vastloopt.
De filters Optimaliseren voor bandbreedte bieden meer loopstabiliteit en kunnen voor nog meer verschillende paginatypes worden gebruikt als een standaard filterset.
In onze test gebruikten we vooral de stabielere filterset om beter in te spelen op de modulaire structuur van WordPress. Niettemin: Als de PageSpeed Module voor de ene pagina correct was ingesteld, brak het de lay-out of verlamde het belangrijke functies, zoals het winkelwagentje, op de andere pagina.
Naast deze standaardsets kan elke gebruiker zijn eigen configuratie samenstellen - afhankelijk van wat en hoeveel er al geoptimaliseerd is. De filters kunnen bijvoorbeeld gebruikt worden om CSS-documenten te comprimeren (Google verwijdert dan automatisch witruimte en commentaar in de stylesheets). De cache-tijden van afzonderlijke bronnen kunnen ook worden ingesteld of afbeeldingen kunnen worden gebundeld in sprites.
Juist deze overvloed aan instelmogelijkheden maakt de PageSpeed Module onpraktisch vanuit het oogpunt van de hoster.
Optimalisatie via HTML - live en via cache
Maar hoe werkt de Google PageSpeed Module precies? In principe worden dezelfde of zeer vergelijkbare optimalisatiemaatregelen uitgevoerd als aanbevolen door Google PageSpeed Insights . De optimalisatiestappen worden uitgevoerd via een cache of live. Daartoe haalt de PageSpeed Module de HTML-code van de pagina op en zoekt naar optimalisatiemogelijkheden, die hij dan uitvoert.
De uitvoering van optimalisatiemaatregelen via de cache is de complexere oplossing. Want hier moet je instellen welke optimalisaties via de webserver en zijn cache moeten lopen en welke door de module zelf moeten worden uitgevoerd. Daardoor moet de uitvoering van de optimalisatiemaatregelen eigenlijk voor elke paginaconfiguratie afzonderlijk worden ingesteld.
De live versie daarentegen vereist een enorme hoeveelheid RAM en processorkracht. Dit betekent dat de optimalisatie zelf zoveel prestaties opslokt dat de pagina's veel langzamer laden. Live optimalisatie is daarom zowel geschikt voor zeer krachtige servers als voor pagina's met slechts enkele bezoekers.
Bijna eindeloze mogelijkheden
Zuiver wiskundig gezien leveren de 50 bestaande filters een zeer, zeer groot aantal mogelijke combinaties op (een getal met 15 nullen). Natuurlijk is dit in wezen een voordeel, omdat je de PageSpeed Module kunt configureren zoals je die nodig hebt voor je eigen website. Voor ons was deze overvloed aan combinaties echter de projectkiller.
Afzonderlijke pagina's kunnen via de module heel goed geoptimaliseerd worden - als je weet hoe. Want er is hier maar één eisenpakket. Als hoster moeten we echter rekening houden met een heleboel verschillende WordPress-configuraties. En dit is de kern van de zaak: Omdat de instelling van de module zo algemeen zou moeten zijn dat alle bestaande pagina's eronder vallen, evenals het merendeel van de mogelijk nieuwe pagina's.
Dan blijft er maar een heel klein aantal mogelijke filters over. Deze hebben dan echter weer slechts minimale invloed op de laadtijd van de pagina.
Dit is precies wat er in onze test gebeurde. En wat meer is: sommige pagina's werden zelfs trager door het gebruik van de module.
De Page Speed Module heeft onze prestaties opgegeten
De PageSpeed module vraagt relatief veel stroom. Bij onze BOXES kan dit ertoe leiden dat de module meer prestaties opeist dan hij door optimalisatie kan winnen. Dit komt omdat de inhoud van de website wordt gecomprimeerd, maar de compressie vergt op zijn beurt rekenkracht. Zo kan de totale laadtijd van de pagina lijden onder de optimalisatie. Dit is precies wat ons in sommige gevallen overkwam, vooral als de pagina's onder belasting werden getest.
Beeldoptimalisatie is gemakkelijker en beter via plug-ins
Deze onevenwichtigheid is vooral merkbaar bij beeldoptimalisatie: In onze test waren WordPress plugins niet alleen in staat om afbeeldingen sterker te comprimeren, maar liepen ze ook stabieler en verbruikten ze slechts een fractie van het vermogen.
Hoewel de beeldoptimalisatie van Google in principe niet slecht is, merkten we in onze test dat afbeeldingen die eerder door de PageSpeed-module waren geoptimaliseerd, vervolgens door de PageSpeed-test werden beoordeeld als afbeeldingen die nog geoptimaliseerd moesten worden. Deze paradoxale uitspraken zijn helaas typerend voor Google PageSpeed Insights.
Conclusie: Onze hosting is de verkeerde use case voor de Google PagesSpeed Module
De twee projectkillers voor de implementatie van een centrale configuratie van de Google PageSpeed Module waren dus de diversiteit van de door ons gehoste sites in combinatie met de prestatiehonger van de module. Een implementatie op onze Nginx webserver heeft daarom op dit moment geen zin.
Voor individuele projecten met de bijbehorende rekenkracht blijft de PageSpeed Module echter zeker een optie.
Welke ervaringen heb je met Google's PageSpeed module? Of heb je vragen over het gebruik van de module? Schrijf ons een opmerking of neem direct contact met ons op via de supportchat op raidboxes.de.
