Van alle knoppen die u kunt omzetten om uw site sneller te maken, is er één die gratis is, een minuut kost en zelden wordt aangeraakt: de php versie snelheid van uw hosting. WordPress is geschreven in PHP, en die taal is de afgelopen jaren fors verbeterd. Draait u nog op een oudere versie, dan laat u rekentijd liggen die u nergens anders zo goedkoop terugkrijgt.
Hieronder leest u waar die winst vandaan komt, hoeveel het in de praktijk scheelt, en welke controles u doet voordat u overstapt.
Wat PHP eigenlijk doet bij elk bezoek
Vraagt iemand uw contactpagina op, dan staat die pagina niet als kant-en-klaar bestand op de server. WordPress bouwt hem ter plekke op: het haalt teksten uit de database, laadt uw thema, laat elke actieve plugin zijn stukje toevoegen en zet daar HTML van in elkaar. Al dat werk doet PHP.
Hoe sneller die taal die instructies verwerkt, hoe eerder de bezoeker antwoord krijgt. Dat merkt u vooral in de tijd tot het eerste antwoord van de server, en juist dat getal is bepalend voor hoe rap een site aanvoelt. Het zegt niets over uw afbeeldingen of scripts, die komen daarna pas.
PHP-versie, snelheid en wat u er werkelijk van merkt
Er zijn twee soorten sprongen. De grote sprong was die van PHP 5.6 naar 7.x, waarbij de manier waarop code werd uitgevoerd volledig op de schop ging. Sites die die stap maken worden vaak twee tot drie keer sneller in serververwerking. Draait u nog op 5.6, dan is dit het meest lonende kwartier van uw jaar.
De sprongen daarna zijn bescheidener maar reëel: van 7.4 naar 8.1 of 8.3 ziet u doorgaans tien tot dertig procent minder verwerkingstijd. Bij een pagina die op 7.4 in 500 milliseconden werd opgebouwd, komt u dan rond de 380 uit. Dat is geen wonder, maar het is wel gratis en het geldt voor elke pagina, ook voor uw beheerscherm.
Twee kanttekeningen zijn hier op hun plaats. Ten eerste raakt deze winst alleen het serverdeel; laadt uw startpagina zes megabyte aan foto’s, dan merkt de bezoeker er weinig van. Ten tweede: draait er een goede paginacache, dan slaat WordPress bij herhaalbezoeken een groot deel van dat werk over en is het effect kleiner op openbare pagina’s. Op een webshop, waar afrekenen en accountpagina’s nooit gecacht worden, is de winst juist het grootst. Wat caching precies doet, staat in de uitleg over caching in WordPress.
Waar het misgaat bij overstappen
Een nieuwere PHP-versie is strenger. Code die vroeger met een waarschuwing wegkwam, geeft nu een echte fout. In de praktijk struikelt het bijna altijd over dezelfde dingen:
- Een oud thema, vaak een gekocht thema dat al jaren geen update kreeg. Dit is de meest voorkomende oorzaak van een wit scherm na de omzetting.
- Verlaten plugins. Een formulierplugin of een sliderplugin die sinds 2019 stilstaat, gaat vrijwel zeker klagen.
- Eigen maatwerkcode in functions.php, ooit toegevoegd door een vorige bouwer.
- Verouderde koppelingen, bijvoorbeeld met een boekhoudpakket of een verzendpartij.
De fout die u dan ziet heet meestal “Fatal error: Uncaught Error” met daarachter een bestandsnaam. Die bestandsnaam verklapt precies welke plugin of welk thema de dader is, en dat is waardevolle informatie.
Wat u ook kunt tegenkomen is een site die het gewoon doet, maar met een stroom waarschuwingen op de achtergrond. Die ziet u niet, want ze staan standaard niet op het scherm. Ze belanden wel in het foutenlogboek van uw hosting, en op een drukke site groeit dat bestand dan met honderden megabytes per week. Naast de schijfruimte kost het schrijven van al die regels ook tijd bij elk bezoek, waardoor de site na de overstap juist trager kan aanvoelen. Kijk dus een week na de wijziging in dat logboek en ruim op wat er structureel in terugkomt.
Zo stapt u veilig over
- Maak eerst een volledige back-up van bestanden en database, en controleer of u die ook echt kunt terugzetten.
- Draai een compatibiliteitscontrole. Er zijn plugins die uw code scannen op verouderde functies. Ze geven vals alarm, maar een lijst met tien meldingen bij één oude plugin is een duidelijk signaal.
- Werk eerst alles bij. Kern, thema en plugins actueel maken lost het merendeel van de problemen op voordat ze ontstaan.
- Test op een kopie. Zet de site op een testomgeving, schakel daar de nieuwe versie in en klik alles na. Waarom dat de moeite waard is, leest u in het stuk over werken met een testomgeving.
- Stap één versie tegelijk op. Van 7.4 naar 8.0, kijken, dan verder. Zo weet u waar het misgaat.
- Zet de wijziging op een rustig moment. Dinsdagochtend, niet vrijdagmiddag.
- Controleer daarna het foutenlogboek, ook als de site er goed uitziet. Waarschuwingen die zich opstapelen vertragen de site en voorspellen problemen.
De knop zelf zit bij vrijwel elke provider in het beheerpaneel onder een naam als “PHP-instellingen” of “PHP-selector”. Terugzetten kan meestal net zo eenvoudig, wat deze ingreep een stuk minder eng maakt dan hij klinkt.
Wat u niet moet verwachten
Een nieuwere PHP-versie repareert geen zware startpagina, geen tien overlappende optimalisatieplugins en geen database vol overgebleven gegevens van verwijderde plugins. Wij zien bij WebMaintor geregeld sites waar de versie keurig op 8.2 staat en de laadtijd toch vier seconden is, simpelweg omdat er honderd verzoeken per pagina worden gedaan.
Zie het dus als hygiëne, niet als oplossing. Blijft uw site traag na de overstap, dan zit het elders, en helpt een gerichte analyse van wat uw pagina's werkelijk opvragen u verder dan het volgende versienummer.
Er is trouwens nog een reden om bij te blijven die niets met tempo te maken heeft: oude PHP-versies krijgen geen beveiligingsupdates meer. Een site op 7.4 draait op software die al jaren geen reparaties meer ontvangt, en dat weegt zwaarder dan die dertig procent.
Volgende stap
Kijk in uw beheerscherm onder Gereedschap en dan Websitestatus welke versie u draait; WordPress zet het daar gewoon in het rijtje serverinformatie. Staat er iets ouder dan 8.1, dan weet u wat er op de lijst komt voor deze maand.
