Een Zwitsers zakmes voor performance tuning van je WordPress site
Eén van de grote redenen van ’traag laden’ van WordPress is het feit, dat WordPress bij het laden van een pagina altijd alle plugins mee laadt. En dat kan afhankelijke van de plugin, een behoorlijke ballast zijn. Maar wanneer je niet op iedere pagina al die bestanden nodig hebt, wat dan?
In het verleden heb ik de plugin Plugin Organizer al eens besproken, en dat is een goede manier om plugins per pagina of post-type aan of uit te zetten, een plugin die dus het selectief laden van plugins ondersteunt. Ik gebruik deze plugin al jaren, maar om eerlijk te zeggen, het is een behoorlijk onoverzichtelijke plugin wanneer je een site met een groot aantal paginas hebt.
Enkele weken geleden liep ik door een aanbeveling van een collega WP Professional voor de plugin ‘FreeSoul Deactivate Plugins‘. Mijn eerste kennismaking was zeer positief. Maar omdat een dergelijke plugin toch wel goed voorbereid moet worden op een website, ben ik nog druk bezig met testen op een staging website, voor ik deze plugin ook live hier zal implementeren.
Maar ik wil de de kracht van deze plugin zeker niet onthouden. En om te beginnen -voor degenen die geen moeite met technisch Engels hebben, voeg ik een video toe van een internationaal bekende WP Professional.
Na de video meer uitleg
Ik kan WPTuts trouwens aanbevelen voor de ‘WordPress Power Users’ In dit kanaal vind je talloze goede suggesties hoe je meer uit WordPress kan halen.
Meer uitleg, zoals beloofd
WordPress laadt iedere plugin bij het laden van een pagina. Maar veel plugins zijn niet direct noodzakelijk.
Woocommerce
Wanneer je op bepaalde pagina’s geen WooCommerce nodig hebt, is er geen noodzaak, nee sterker nog, het is onwenselijk wanneer WooCommerce wordt geladen. Het is een zware toepassing, Vooral wanneer je ook allerlei plugins om WooCommerce te ondersteunen laadt. Wanneer je een webshop hebt, is het natuurlijk altijd wenselijk om WooCommerce te laden.
Wanneer je werkt met page- of theme builders, dan wil je natuurlijk in de header laten zien hoeveel producten in het winkelwagentje zijn. En daarvoor moet je WooCommerce laden. Maar is het zien van het aantal producten ook belangrijk, wanneer mensen aankomen via de blog? Als het goed is, staan er genoeg links naar WooCommerce producten om de bezoeker hem of haar daarheen te verwijzen?
Met een gewoon ‘standaard thema’ heb je vaak niet de mogelijkheid om echt te kiezen. Maar wanneer je een theme builder als Elementor Pro gebruikt, heb je vaak de keuze per onderdeel over waar WooCommerce wel of niet geladen moet worden.
Eén van de dingen die je -misschien- graag wilt zien is of mensen iets in hun winkelwagen hebben. Maar om dat te doen op een niet-WooCommerce pagina moet je WooCommerce in zijn totaliteit laden. Wanneer je site niet hoofdzakelijk een webwinkel is, maar je ‘ook dingen in een webwinkel verkoopt’, is het dan niet veel efficiënter om alleen op de echte winkelpagina’s het WooCommerce winkelwagentje te laten zien?
Pagebuilders zoals Elementor -en andere- geven je de mogelijkheid om in WooCommerce- paginas ‘winkelwagen’ met een product en/of prijs te tonen. Wanneer je in de ‘niet WooCommerce’ pagina’s alleen een ‘winkelwagen’ link zonder telling op zou nemen, zou je jouw site al behoorlijk kunnen versnellen.
Formulieren
En wanneer je een formulieren plugin gebruikt, waarom zou je de formulieren plugin laden op een pagina zonder formulieren?
En zo zijn er nog een groot aantal voorbeelden te noemen. Maar het komt er eigenlijk simpel op neer, dat je niet overal altijd dezelfde plugins nodig hebt, en WordPress dit standaard wel laadt. Door het selectief laden van plugins is het mogelijk het laden van je pagina’s aanzienlijk te versnellen.
Een blik op de plugin…
Wanneer we het openingsscherm van de plugin bekijken zien we ongeveer het volgende:
Hier in het voorbeeld zie je een standaard (locale, draaiend onder LocalWP) testwebsite van mij met een beperkt aantal pagina’s en een beperkt aantal plugins geactiveerd. In één oogopslag zie je welke plugins waar actief zijn.
Nu is het zo, dat er sowieso een aantal plugins is, dat we waarschijnlijk helemaal niet nodig hebben op de pagina’s. ‘Regenerate thumbnails’ en FakerPress, dit zijn allebei plugins die je vanuit het Dashboard als admin gebruikt. Deze kunnen we dus in ieder geval al op iedere pagina deactiveren. Dit geldt ook voor Yoast Duplicate post voor alle pagina’s die geen blogposts tonen (voor de blogposts is Yoast Duplicate Post wel nodig voor mogelijke redirects). ChildTheme wizard is al helemaal niet nodig (die gebruik je in principe maar één keer, bij het maken van het child theme en is dan overbodig.
In een eerste oogopslag hebben we dus heel wat plugins weten te elimineren. Een echte website zal meer plugins actief hebben, mar het principe is duidelijk.
Plugins per post-instantie activeren/deactiveren.
Maar dit selectief laden van plugins kan ook per -bijvoorbeeld- blogpost of winkelproduct gedaan worden. Je kan je bijvoorbeeld voorstellen, dat je misschien een PDF, Word-document of een Powerpoint presentatie wilt tonen in een blogpost. Maar aangezien je dit niet in iedere blogpost wilt, kan je dit per afzonderlijke blogpost of afzonderlijk product laden. In het topmenu klik je dan op ‘Enkele’ en daar komen de post-types naar voren die bij jou op het systeem voorkomen.
Klik ik hier dan op ‘Berichten’, krijg ik een lijst met al mijn blogposts. Zoals je hieronder kunt zien. Denk eraan, dit is een test site en de blog-titels zijn ‘onzin titels’ door de FakerPress plugin gegenereerd.
Hier kan ik dus per blogpost het laden van plugins uit of aan zetten. Zie je trouwens ook de handige X en Y assen, die duidelijk aangeven, waar je aan het werk bent?
Maar wanneer je die plugin uit of aan zet, wat heeft dat als gevolg voor je pagina? Wanneer ik op de + voor een blogpost klik, dan krijg ik een toolbar te zien met onder andere een vergrootglas.
Klik ik op dit vergrootglas, dan zie ik de pagina met daaronder een balk met wat pagina informatie.
Wat wil dit allemaal zeggen?
Disabled Plugins: Het aantal plugins wat je hebt uitgezet.
Q : Het aantal database queries wat naar de database is verstuurd om deze pagina te maken
IT: Initialisatie tijd, de totale tijd die nodig was om WordPress en alle plugins te laden
PGT: Page Generation Time, de totale tijd die nodig was om de HTML te genereren
MU: Memory Usage. Hoeveel geheugenruimte nam het totaal van de pagina in beslag. (In MB’s en percentage van de beschikbare ruimte).
Wanneer je bepaalde plugins uit of aan zet, kan je dus niet alleen zien, of ‘de pagina het nog steeds doet’, maar ook of het genereren van de pagina sneller is geworden. Laten we nog eens een paar plugins uit zetten. Ik heb ACF en Child Theme Wizard ook niet nodig.
Ik krijg nu de volgende waarden :
Disabled Plugins 5 | Q: 194 | IT: 0.22 | PGT: 0.62s | MU: 27.75 (10.8%)
Dat scheelt dus aardig wat. En nu zijn alle plugins die we hier uit hebben gezet ‘lichte’ plugins. Stel je voor wat dat kan betekenen voor een site waar je een zware toepassing als WooCommerce of een LMS kan deactiveren op de pagina’s waar je dit niet nodig hebt.
Opstart volgorde
Een andere aardige functie van deze plugin is dat je de opstartvolgorde van de plugins aan kan passen. Maar waarom zou je dat doen?
Eén van de belangrijkste redenen waarom ik dat zou kunnen willen, is in het geval van plugin conflicten. Eén veel voorkomend plugin conflict is, dat twee makers van een plugin allebei een bepaalde programma bibliotheek gebruiken. Zo’n ‘biblioteek’ kan bijvoorbeeld een bibliotheek zijn om functies van Facebook, een mail provider of een betalingsprovider aan te roepen.
Laten we die voor het gemak even MyWPLibrary noemen. Plugin A gebruikt MyWPLibary 1.0, en Plugin B gebruikt MyWPLibrary 2.0. Wanneer een WordPress plugin een library laadt is de juiste manier om dit te doen, te kijken of hij al niet door een andere plugin geladen is, en als dit niet zo is, de bibliotheek te laden. Is hij al wel geladen, wordt er niets gedaan.
Tot nu toe nog geen probleem. Maar je ziet het al aankomen. Wanneer Plugin A versie 1.0 van de bibliotheek al geladen heeft, dan zal Plugin B versie 2.0 niet meer laden. Maar omdat Plugin B wel functies uit 2.0 nodig heeft, zal het aanroepen van deze functies tot foutmeldingen leiden.
Een oplossing is hier te zorgen, dat Plugin B eerder dan plugin A wordt geladen.
Het aanpassen van de laadvolgorde van plugins kan soms – als je weet welke plugin de boosdoener is- tot een directe oplossing leiden.
Het is wel zo, dat je de laadvolgorde iedere keer na het installeren of verwijderen van een nieuwe plugin je die laadvolgorde opnieuw in zal moeten stellen. En natuurlijk is het altijd mogelijk dat plugin A MyWPLibrary 1.0 naar 3.0 update, Plugin B doet dat niet, en daardoor een ‘werkende’ laadvolgorde ineens niet meer werkt. Aanpassen van een laadvolgorde is een lapmiddel, maar wel één wat voor mij -bij mijzelf en klanten- in de loop der jaren tientallen problemen op heeft kunnen lossen.
Add-ons voor deze plugin
Het aardige is, dat er voor deze plugin ook een aantal add-ons beschikbaar is.
FDP Debug
FDP Debug voegt aan de actiebalk een ‘Debug’ knop toe. Dit is een plugin die je kan installeren, maar zolang niet nodig, beter niet activeren. Deze plugin is vooral bedoeld om FDP zelf te debuggen, waarna je de informatie door kan geven aan de support desk van de maker van de plugin.
Editor Cleanup plugins
Daarnaast heeft de maker van deze plugin een aantal ‘add ons’ gemaakt voor de FDP plugin. Dit zijn allemaal add-ons specifiek voor een bepaalde page builder. Deze maken het mogelijk om ook bij het werken met je editor voor je pagebuilder bepaalde plugins uit kan zetten om er sneller mee te kunnen werken.
Ten slotte
Iedereen wil natuurlijk een snellere website. En alles wat hierbij kan helpen is mooi meegenomen. Het mooie van deze plugin is dat het het performance probleem bij de kern aanpakt: Het verminderen van de ‘overload’.
Er zijn nog veel meer functies die deze plugin biedt, ik heb ze niet allemaal besproken, maar zoals je in het kleine voorbeeldje al hebt kunnen zien, het selectief laden van plugins voorkomt aardig wat ‘overgewicht’.
De maker van de bovengenoemde plugins heeft nog een aantal andere plugins die zeker in de toekomst besproken zullen worden.
Heb je een trage website en je wilt weten wat er bij jou gedaan kan worden, neem dan eens geheel vrijblijvend contract op via mijn video-spreekuur. Dan kunnen we samen kijken wat er gedaan kan worden. Of spreek me aan via de chat rechtsonder, wanneer ik online ben.