WordPress-benchmark: de prestaties van hosting op reproduceerbare wijze testen

Wat een WordPress-benchmark laat zien

A WordPress-benchmark begint met een concrete vraag: laadt een bepaalde pagina onder vastgestelde omstandigheden snel? Hiervoor laadt een browser HTML, afbeeldingen, scripts en andere bronnen en geeft de pagina weer. Het resultaat beschrijft het samenspel van deze onderdelen, niet alleen de snelheid van de hostingserver.

Een tweede vraag betreft het Reactiegedrag onder belasting: Hoe veranderen de responstijden en het aantal fouten wanneer er verzoeken binnenkomen die aan een bepaald profiel voldoen? Eén enkele paginaweergave geeft hier geen antwoord op. Omgekeerd laat een HTTP-belastingstest niet direct zien hoe snel een browser de volledige pagina zichtbaar laadt.

Bij een openbaar blogartikel kan een paginacache kant-en-klare HTML leveren; een CDN kan bronnen of antwoorden dichter bij de meetlocatie beschikbaar stellen. Tegelijkertijd beïnvloeden het thema, de plug-ins, afbeeldingen en externe scripts het resultaat. Welke andere oorzaken een pagina kunnen vertragen, wordt uitgelegd in het artikel over verborgen prestatiekillers in WordPress.

Om de invloed van de hosting te beoordelen, kunnen twee vergelijkende vragen helpen. Bij de Stack-vergelijking Je stemt de website en instellingen zo veel mogelijk op elkaar af en legt de resterende verschillen vast. Bij het vergelijken van pakketten controleer je de aangeboden configuraties, inclusief de bijbehorende caches en diensten. Dit is nuttig voor een aankoopbeslissing, maar geeft geen puur beeld van de serverprestaties.

Noteer daarom welke pagina, welk tarief en welke omgeving bij een resultaat horen. Een voordeel voor het geteste blogartikel kan bij een weergave vanuit een aangemeld account anders uitvallen. De meting geldt voor de gedocumenteerde voorwaarden en de betreffende periode; deze vormt geen basis voor een algemene testwinnaar noch voor een prestatiegarantie.

Inzicht krijgen in browsermetingen en veldgegevens

Een WordPress-snelheidstest met Lighthouse levert een Laboratoriumopname van de pagina onder bepaalde meetomstandigheden. Het browserprofiel, het apparaat of de emulatie, het netwerkprofiel, de meetlocatie en de versie van de tool moeten daarom in het logboek worden opgenomen. Alleen zo kan later worden beoordeeld of twee metingen daadwerkelijk vergelijkbaar zijn.

De Lighthouse-prestatiescore is een gewogen samenvatting van verschillende meetwaarden. Deze score kan fluctueren door veranderende inhoud en meetomstandigheden en maakt niet duidelijk welke afzonderlijke meetwaarde is veranderd. Herhaal de meting met hetzelfde profiel en leg de afzonderlijke waarden van alle runs vast, in plaats van alleen de beste score te selecteren.

Een van de belangrijke statistieken is LCP: deze geeft aan wanneer het grootste relevante inhoudselement zichtbaar is geladen. CLS registreert onverwachte verschuivingen in de lay-out tijdens het gebruik. INP beschrijft de reactiesnelheid op interacties; hiervoor zijn daadwerkelijk geregistreerde interacties nodig en wordt deze niet alleen bepaald door het simpelweg laden van de pagina.

Het Chrome UX Report, kortweg CrUX, biedt daarentegen, indien beschikbaar, Veldgegevens op basis van bezoeken van deelnemende echte gebruikers. Deze ervaringen zijn onder andere afhankelijk van hun apparaten en netwerken. Ze zijn niet voor elke pagina beschikbaar en geven een ander antwoord dan een laboratoriumtest die onder gecontroleerde omstandigheden wordt uitgevoerd.

Geef bij elke waarde aan of deze afkomstig is uit het laboratorium of uit de praktijk. Een puur HTTP-verzoek kan bijvoorbeeld de status en de responstijd vastleggen, maar voert niet automatisch de weergave en de interacties van een browser uit. Daarom kunnen LCP, CLS en INP hieruit niet worden afgeleid als browserervaring.

Cache-niveaus correct onderscheiden

A Pagina cache kan kant-en-klare HTML opslaan voor herhaalde verzoeken. Een objectcache slaat daarentegen applicatiegegevens op die WordPress nodig heeft bij de verwerking. Daarnaast kan de browser reeds geladen bronnen lokaal hergebruiken; een CDN kan inhoud op een extra niveau buiten de oorspronkelijke server tijdelijk opslaan.

Bij een ‘warme’ paginacache roep je een openbare pagina herhaaldelijk op na een gedocumenteerde opwarmfase. Dit is relevant voor veelbezochte inhoud, maar zegt weinig over hoe duur de dynamische generatie ervan is. Noteer welke URL is opgewarmd en welke cache-regels en CDN-instellingen van toepassing waren.

Voor een verzoek zonder cache moet je de Cache omzeilen controleer het op een begrijpelijke manier, in plaats van het zomaar te accepteren. Een aangemelde sessie kan andere regels volgen en gepersonaliseerde inhoud weergeven. Controleer bij die sessie het daadwerkelijke antwoord: een snelle opvraging heeft weinig waarde als deze onjuiste of verouderde inhoud oplevert.

Een eerste bezoek in een nieuwe browserstatus duidt niet op een lege server- of CDN-cache. Evenzo betekent een CDN-fout niet automatisch dat de applicatiecache is leeggemaakt. Cache-headers kunnen aanwijzingen geven, maar bewijzen, afhankelijk van de aanbieder, niet de status van elk betrokken niveau; documenteer daarom ook de beschikbare instellingen en controlemethoden.

Zonder een geschikte permanente uitbreiding is de WordPress-objectcache in principe beperkt tot het betreffende verzoek. De constante WP_CACHE Dit activeert op zichzelf noch Redis, noch een automatisch werkende cachingoplossing. Welke rol Redis en Memcached kunnen spelen als persistente objectcache, wordt uitgelegd in het artikel over Redis en Memcached bij WordPress-hosting.

Vergelijking en goedkeuringen voorbereiden

Om hostingaanbieders te vergelijken, heb je eerst een vergelijkbare stand van zaken op de website. Maak een opgeschoonde kopie met dezelfde inhoud, dezelfde dataset, hetzelfde thema en dezelfde plug-ins, inclusief hun versies. Verwijder of vervang persoonsgegevens en productieve inloggegevens zodanig dat de testpagina toch het gewenste gebruiksscenario weergeeft.

Zorg ervoor dat de PHP- en databaserversies, evenals de relevante instellingen, zoveel mogelijk overeenkomen. Noteer verschillen die niet kunnen worden weggewerkt of die bij het geboekte pakket horen. Een vergelijking van de respectievelijke standaardpakketten geeft een ander antwoord dan een vergelijking van zo gelijk mogelijk gestelde stacks: het resultaat kan niet zonder meer uitsluitend aan de serverprestaties worden toegeschreven.

Stel vóór de eerste test een meetplan op. Dit moet zo gedetailleerd zijn dat een andere persoon de opzet kan begrijpen en afwijkingen bij een herhaling kan herkennen. De volgende checklist maakt een onderscheid tussen de kenmerken van het hostingaanbod, die van de website en die van de meting.

• Tarief, limieten voor bronnen, serverlocatie en softwareversies van beide omgevingen.
• Test-URL's en paginatypen, aanmeldingsstatus, cookies en gebruikte testaccounts.
• CDN, paginacache en objectcache, inclusief regels, opwarmfase en geplande bypass.
• Meetlocatie, gereedschapsversie, browser- en apparaatprofiel, netwerkomstandigheden, tijdstippen en herhalingen.
• Belastingsprofiel, verantwoordelijkheden, overeengekomen testperiode en concrete afbreekdrempels.

Voor belastingstests spreek je de Vrijgave Overleg met alle verantwoordelijken en, indien van toepassing, de hoster voordat je belasting op het systeem veroorzaakt. Leg vast wie de contactpersonen zijn, wat de limieten voor de resources zijn en hoe er bij storingen moet worden gehandeld. Sluit externe diensten uit zonder hun toestemming; voorkom met name echte betalingen, bestellingen en meldingen. Controleer vooraf of de testversie dergelijke processen daadwerkelijk blokkeert.

Meetconcept voor typische pagina's

Kies het gereedschap op basis van de vraag, niet op basis van de best mogelijke afzonderlijke waarde. Een Meetconcept wijst aan elke rij een paginatype en een cachetoestand toe. De tabel laat zien welke resultaten met de betreffende benaderingen kunnen worden verkregen en waar hun geldigheid ophoudt.

Voor een openbaar blogartikel meet je dezelfde representatieve URL meerdere keren met een vast browser- en netwerkprofiel. Noteer of CDN en paginacache zijn ingeschakeld en hoe de pagina vóór de metingen is opgewarmd. Zo kun je de laadervaring van deze openbare pagina beoordelen, en niet automatisch die van een aangemelde sessie.

Een dynamische zoekopdracht of accountweergave krijgt een eigen reeks met vrijgegeven testgegevens en, indien nodig, een testaccount. Controleer niet alleen de statuscode: het antwoord moet overeenkomen met de zoekopdracht of het aangemelde account en actueel zijn. Controleer bovendien of een geplande Cache omzeilen daadwerkelijk werkt; een cookie alleen is daarvoor geen bewijs.

Als de responstijden verschillen, is de oorzaak daarmee nog niet gevonden. Applicatielogica, databasetoegang, een persistente objectcache en de hostingomgeving kunnen allemaal bijdragen aan het resultaat. Leg de verschillen vast en onderzoek ze vervolgens gericht, in plaats van één enkele trage verzoek als bewijs voor een bepaalde bottleneck te beschouwen.

De belastingstest geleidelijk opbouwen

Begin op een uitdrukkelijk goedgekeurde testpagina met een klein aantal afzonderlijke verzoeken. Controleer de status en de inhoud en zorg ervoor dat er geen ongewenste bijwerkingen optreden. Pas daarna volgt een afzonderlijk afgestemde belastingstest, bijvoorbeeld voor goedgekeurde productpagina’s van een webwinkel. Echte bestellingen, betalingen en meldingen blijven uitgesloten.

Plan een geleidelijke belasting met startniveau, duur en stapsgewijze verhogingen. Spreek vooraf meetbare afbreekdrempels af voor fouten, reactietijden of andere beschikbare bedrijfswaarden, evenals een contactpersoon voor het afbreken. Houd je aan de uitdrukkelijk toegestane processen; een productweergave zegt niets over een niet-geteste afrekenprocedure.

In het gesloten belastingsmodel wacht een virtuele gebruikersinstantie op het einde van haar huidige iteratie voordat ze aan de volgende begint. Als de applicatie trager wordt, kan de aangeboden belasting daardoor dalen. Het model is geschikt voor processen waarbij juist dit wachten een essentieel onderdeel is; het handhaaft echter geen vaste aankomstsnelheid.

A open lastmodel plant daarentegen nieuwe iteraties, ongeacht of eerdere iteraties zijn afgerond. Hiervoor moet de belastinggenerator over voldoende capaciteit en beschikbare virtuele gebruikersinstanties beschikken. Als de belastinggenerator geen iteraties kan starten, bereikt de test het geplande profiel niet; documenteer daarom ook deze niet-gestarte iteraties.

Noteer zowel de ingestelde als de daadwerkelijk bereikte snelheid. Iteraties per seconde komen alleen overeen met verzoeken per seconde als elke iteratie precies één verzoek genereert. Leg daarnaast de verdeling van de responstijden, fouten en time-outs vast, evenals de controle op correcte inhoud: een hoge doorvoer met foutieve antwoorden is geen succesvolle belastingstest.

Meetreeksen op een begrijpelijke manier analyseren

Een reeks metingen is alleen zinvol in combinatie met de omvang ervan. Noteer daarom voor elke geteste pagina en elke belastingsstap het aantal geëvalueerde verzoeken en het aantal fouten en time-outs. Maak een onderscheid tussen succesvolle antwoorden en mislukte antwoorden, zonder dat uitval uit het rapport verdwijnt: een lage responstijd bij veel fouten duidt niet op een betrouwbaar snelle dienstverlening.

De Mediaan geeft de gemiddelde waarde weer van de gesorteerde geslaagde metingen. Het 95e percentiel, kortweg p95, geeft aanvullend een drempelwaarde aan waaronder ongeveer 95 procent van deze meetwaarden ligt. Bij een klein aantal verzoeken is p95 sterk afhankelijk van individuele waarnemingen; vermeld daarom altijd de steekproefomvang en wees terughoudend bij het interpreteren van verschillen.

Noteer voor elke run ook het belastingsmodel en de daadwerkelijk bereikte snelheid. Een geconfigureerde snelheid alleen geeft niet aan of de generator alle geplande iteraties heeft kunnen starten. Het volgende sjabloon blijft leeg totdat de meting is uitgevoerd; meerdere runs krijgen elk een eigen logboek.

Sla de ruwe gegevens, het testscript en de configuratie samen met het logboek op. Zo kan later worden gecontroleerd welke verzoeken in een analyse zijn meegenomen en of twee reeksen überhaupt vergelijkbaar zijn. Kies achteraf niet alleen de snelste run: als de resultaten sterk overlappen, kan het waargenomen verschil binnen de schommelingen vallen.

Vermeld naast de kengetallen ook opvallende zaken in de inhoud, zoals een onverwachte inlogpagina in plaats van het verwachte accountoverzicht. Een technisch succesvolle status bewijst nog niet dat de juiste pagina is weergegeven. Dergelijke afwijkingen moeten apart in de foutbeschrijving worden vermeld en kunnen een reeks metingen onbruikbaar maken voor de geplande beslissing.

Oorzaken in kaart brengen en opnieuw meten

Begin met het opsporen van fouten in het geleverde antwoord: kloppen de inhoud, de aanmeldingsstatus en de geteste URL? Controleer vervolgens de gedocumenteerde Cache-status en de meetomgeving. Verschillende cookies, een andere meetlocatie of een gewijzigde CDN-regel kunnen ervoor zorgen dat twee metingen van elkaar verschillen, zonder dat de prestaties van de eigenlijke applicatiestack zijn veranderd.

Pas daarna kunnen de beschikbare bedrijfsgegevens helpen bij het inkaarten van het probleem: het gebruik van resources en wachtrijen kunnen wijzen op knelpunten, terwijl applicatie- of database-informatie kan duiden op tijdrovende verwerking. Een enkele trage HTTP-waarde geeft niet de oorzaak aan. WordPress noemt naast de hosting ook software, configuratie en inhoud als factoren die van invloed zijn.

Voor een voor-en-na-vergelijking wijzig je bewust slechts één instelling, bijvoorbeeld het inschakelen van een persistente objectcache. De status van de website, de testpagina, het belastingsprofiel en de meetlocatie blijven zoveel mogelijk hetzelfde; documenteer ook de respectievelijke cache-opwarmtijd. Zonder een geschikte persistente implementatie is de WordPress-objectcache beperkt tot het afzonderlijke verzoek, zodat de daadwerkelijke integratie ervan moet worden gecontroleerd.

Voer meerdere tests uit voor en na de wijziging en spreid deze in de tijd. Zo kun je beter vaststellen of een verschil herhaaldelijk optreedt of mogelijk samenvalt met normale schommelingen. Vergelijk daarbij niet alleen de mediaan en p95, maar ook fouten, de inhoud van de antwoorden en het behaalde percentage; anders kan een schijnbare versnelling te wijten zijn aan gewijzigde testomstandigheden.

Zelfs een zorgvuldige vergelijking houdt niet rekening met alle factoren. Bij shared hosting kunnen andere gebruikers en niet-inzichtelijke infrastructuur het resultaat mede beïnvloeden. Als je geen gegevens over resources of wachtrijen hebt, vermeld deze leemte dan uitdrukkelijk en formuleer een vermoedelijke oorzaak als hypothese in plaats van als bewezen bevinding.

Het hostingresultaat op de juiste manier interpreteren

Bepaal je hostingkeuze op basis van de pagina’s en processen die belangrijk zijn voor je website. Een openbaar blogartikel met een ‘warm’ paginacache kan een andere belasting veroorzaken dan het bekijken van een ingelogd account. Goede cache-hits op openbare pagina’s zijn daarom geen bewijs van snelle, gepersonaliseerde reacties of een robuust afrekenproces.

Bepaal vóór de vergelijking welke responstijden, foutpercentages en welk belastingsprofiel voor het betreffende proces aanvaardbaar zijn. Controleer vervolgens of de gedocumenteerde meetreeksen onder de overeengekomen voorwaarden aan deze eisen voldoen. Hierbij gaat het ook om correcte inhoud en een stabiel verloop; een hoge verzoekfrequentie alleen is geen voldoende basis voor een beslissing.

Stel in virtuele gebruikers niet hetzelfde als daadwerkelijk aanwezige bezoekers. Hun gedrag vloeit voort uit het testscript en het belastingsmodel: in het gesloten model wacht een instantie op het einde van haar iteratie voordat ze aan de volgende begint. Uit hun aantal kan daarom zonder een passend gedragsmodel geen reëel bezoekersaantal worden afgeleid.

Geef het resultaat weer, samen met het tarief, de status van de website, de geteste URL’s, de cache- en CDN-regels, de meetlocatie en de periode. Geef bovendien aan of je zo veel mogelijk vergelijkbare stacks hebt vergeleken of de aangeboden totaalpakketten. Bij een pakketvergelijking kunnen configuratieverschillen van invloed zijn op het resultaat; deze vergelijking geeft niet automatisch een beeld van de pure serverprestaties.

Als de reeksen elkaar sterk overlappen of als de omgeving onvoldoende kan worden gecontroleerd, is „er is geen betrouwbaar verschil aangetoond“ een mogelijke en nuttige conclusie. Dat betekent niet dat beide aanbiedingen onder alle omstandigheden even snel zijn. Het betekent alleen dat de onderhavige test het gewenste onderscheid niet aantoont.

Voor operationele controles bewaar je het meetprofiel en herhaal je geselecteerde browser- en belastingmetingen na ingrijpende wijzigingen of met vooraf afgesproken tussenpozen. Vergelijk nieuwe resultaten alleen met overeenkomstige eerdere reeksen en documenteer wijzigingen in inhoud, versies en cache-regels. Belastingstests vereisen nog steeds een goedgekeurd tijdsvenster en overeengekomen afbrekingsdrempels.