WordPress-benchmark: Reproducerbara prestandatester för webbhotell

Vad en WordPress-benchmark ger svar på

En WordPress-jämförelse börjar med en konkret fråga: Laddas en viss sida snabbt under fastställda förhållanden? För detta laddar webbläsaren HTML, bilder, skript och andra resurser och visar sidan. Resultatet beskriver samspelet mellan dessa komponenter, inte enbart webbserverns hastighet.

En andra fråga gäller detta Svarbeteende under belastning: Hur förändras svarstider och fel när förfrågningar enligt en fastställd profil kommer in? Ett enskilt sidbesök ger inget svar på den frågan. Å andra sidan visar ett HTTP-belastningstest inte direkt hur snabbt en webbläsare laddar upp hela sidan så att den blir synlig.

I ett offentligt blogginlägg kan en sidcache leverera färdig HTML; ett CDN kan tillhandahålla resurser eller svar närmare mätplatsen. Samtidigt påverkar tema, plugins, bilder och externa skript resultatet. Vilka andra orsaker som kan bromsa en sida förklaras i inlägget om Dolda faktorer som försämrar prestandan i WordPress.

Två jämförande frågor kan vara till hjälp för att bedöma hostingens inverkan. När det gäller Jämförelse av stackar Du anpassar webbplatsen och inställningarna så mycket som möjligt och dokumenterar kvarvarande skillnader. Vid jämförelsen av paket granskar du de erbjudna konfigurationerna, inklusive deras respektive cacher och tjänster. Detta är praktiskt för ett köpbeslut, men isolerar inte den rena serverprestandan.

Notera därför vilken sida, vilket pris och vilken miljö som hör till ett resultat. En fördel för den testade bloggartikeln kan se annorlunda ut vid visning från ett inloggat konto. Mätningen gäller för de dokumenterade villkoren och tidsperioden; den utgör varken en allmän testvinnare eller en prestandagaranti.

Att förstå webbläsarmätningar och fältdata

Ett WordPress-hastighetstest med Lighthouse ger ett Laboratorieundersökning sidan under vissa mätförhållanden. Webbläsarprofil, enhet respektive emulering, nätverksprofil, mätplats och verktygsversion ska därför anges i protokollet. Endast på så sätt går det att senare bedöma om två körningar verkligen är jämförbara.

Lighthouse Performance Score är en viktad sammanställning av flera mätvärden. Den kan variera beroende på förändringar i innehåll och mätförhållanden och döljer vilka enskilda mätvärden som har förändrats. Upprepa mätningen med samma profil och dokumentera de enskilda värdena för alla körningar, istället för att bara välja det bästa resultatet.

En av de viktiga måtten är LCP: det beskriver när det största relevanta innehållselementet har laddats och blivit synligt. CLS mäter oväntade layoutförskjutningar under användningen. INP beskriver responsen på interaktioner; för detta krävs faktiskt registrerade interaktioner och bestäms inte enbart av en enkel sidhämtning.

Chrome UX Report, eller CrUX förkortat, tillhandahåller däremot de uppgifter som finns tillgängliga Fältdata från besök av deltagande verkliga användare. Dessa erfarenheter beror bland annat på deras enheter och nätverk. De är inte tillgängliga för alla sidor och besvarar en annan fråga än ett laboratorietest som utförs under kontrollerade förhållanden.

Ange för varje värde om det härrör från laboratoriet eller från fältet. En ren HTTP-förfrågan kan till exempel registrera status och svarstid, men utför inte automatiskt webbläsarens rendering och interaktioner. Därför kan man inte utläsa LCP, CLS och INP som en webbläsarupplevelse utifrån den.

Att skilja mellan olika cache-nivåer på rätt sätt

En Cache för sidor kan lagra färdig HTML för upprepade förfrågningar. En objektcache lagrar däremot applikationsdata som WordPress behöver vid bearbetningen. Dessutom kan webbläsaren återanvända redan nedladdade resurser lokalt; ett CDN kan cachelagra innehåll på ytterligare en nivå utanför den ursprungliga servern.

När sidcachen är uppvärmd hämtar du en offentlig sida upprepade gånger efter en dokumenterad uppvärmningsfas. Detta är relevant för ofta besökt innehåll, men säger inte mycket om hur kostsamt det är att generera det dynamiskt. Notera vilken URL som har värmts upp och vilka cache-regler och CDN-inställningar som gällde.

För en icke-cachad förfrågan måste du Cache-bypass granska den på ett begripligt sätt, istället för att bara ta den för given. Ett anmält möte kan följa andra regler och leverera anpassat innehåll. Kontrollera det faktiska svaret där: En snabb hämtning är inte mycket värd om den ger felaktigt eller föråldrat innehåll.

Ett första besök i ett nytt webbläsartillstånd innebär inte nödvändigtvis att server- eller CDN-cachen är tom. På samma sätt innebär ett CDN-fel inte automatiskt att applikationscachen har tömts. Cache-headers kan ge vägledning, men beroende på leverantör bevisar de inte tillståndet för varje berörd nivå; dokumentera därför även de tillgängliga inställningarna och kontrollmetoderna.

WordPress-objektcachen är i princip begränsad till den aktuella förfrågan om det inte finns någon lämplig permanent tilläggsfunktion. Konstanten WP_CACHE I sig själv aktiverar det varken Redis eller någon automatisk cachelösning. Vilken roll Redis och Memcached kan spela som en persistent objektcache förklaras i artikeln om Redis och Memcached vid WordPress-hosting.

Förbereda jämförelser och godkännanden

För att jämföra webbhotell behöver du först en motsvarande webbplatsstatus. Skapa en ren kopia med samma innehåll, samma datamängd, samma tema och samma plugins, inklusive deras versioner. Ta bort eller ersätt personuppgifter och produktiva inloggningsuppgifter så att testsidan ändå återspeglar det önskade användningsfallet.

Använd i möjligaste mån samma versioner av PHP och databasen samt relevanta inställningar. Notera skillnader som inte går att åtgärda eller som ingår i det bokade paketet. En jämförelse av respektive standardpaket ger ett annat svar än en jämförelse av så likartade stackar som möjligt: resultatet kan inte utan vidare tillskrivas enbart serverns prestanda.

Upprätta en mätplan innan den första körningen. Den måste vara så konkret att en annan person kan förstå uppbyggnaden och upptäcka avvikelser vid en upprepning. Följande checklista skiljer egenskaperna hos värdtjänsten från dem som gäller webbplatsen och mätningen.

• Prisplan, resursbegränsningar, serverplats och programvaruversioner för båda miljöerna.
• Test-URL:er och sidtyper, inloggningsstatus, cookies samt använda testkonton.
• CDN, sidcache och objektcache, inklusive regler, uppvärmningsfas och planerad förbikoppling.
• Mätplats, verktygsversion, webbläsar- och enhetsprofil, nätverksförhållanden, tidpunkter och upprepningar.
• Lastprofil, ansvarsområden, överenskommen testperiod och konkreta gränsvärden för avbrytande.

För belastningstester kommer du överens om Release med alla ansvariga och, i förekommande fall, webbhotellet innan du skapar belastning. Klargör vem som är kontaktperson, vilka resursbegränsningar som gäller och hur man ska agera vid störningar. Uteslut externa tjänster utan deras samtycke; förhindra framför allt riktiga betalningar, beställningar och meddelanden. Kontrollera i förväg om testversionen verkligen förhindrar sådana händelser.

Mätkoncept för typiska sidor

Välj verktyget utifrån frågan, inte utifrån att det ska ge ett så bra enskilt värde som möjligt. Ett Mätkoncept tilldelar varje rad en sidtyp och ett cache-tillstånd. Tabellen visar vilka resultat som kan uppnås med de olika metoderna och var deras giltighet slutar.

För en offentlig bloggartikel mäter du samma representativa URL flera gånger med en fast webbläsar- och nätverksprofil. Notera om CDN och sidcache är aktiverade och hur sidan förvärmdes före mätningarna. På så sätt kan du utvärdera laddningsupplevelsen för denna offentliga sida, inte automatiskt den för en inloggad session.

En dynamisk sökning eller kontoöversikt tilldelas en egen mätserie med godkända testdata och, vid behov, ett testkonto. Kontrollera inte bara statuskoden: Svaret måste stämma överens med sökfrågan respektive det inloggade kontot och vara aktuellt. Kontrollera dessutom om en planerad Cache-bypass faktiskt fungerar; en cookie i sig är inte tillräckligt bevis för detta.

Även om svarstiderna skiljer sig åt betyder det inte nödvändigtvis att orsaken har hittats. Applikationslogik, databasåtkomst, en persistent objektcache och värdmiljön kan alla bidra till resultatet. Dokumentera skillnaderna i uppbyggnaden och undersök dem sedan noggrant, istället för att betrakta en enskild långsam förfrågan som bevis på en viss flaskhals.

Gradvis uppbyggnad av belastningstest

Börja på en uttryckligen godkänd testsida med några få enskilda hämtningar. Kontrollera status och innehåll och försäkra dig om att inga oönskade biverkningar uppstår. Först därefter följer ett separat anpassat belastningstest, till exempel för godkända produktvisningar i en webbutik. Verkliga beställningar, betalningar och meddelanden är fortfarande uteslutna.

Planera en gradvis belastning med startnivå, varaktighet och stegvis ökning. Kom överens i förväg om mätbara gränsvärden för avbrytande vid fel, svarstider eller andra tillgängliga driftsvärden samt en kontaktperson för avbrytande. Håll dig till de uttryckligen tillåtna processerna; en produktvisning ger ingen information om en otestad utcheckningsprocess.

I den slutna belastningsmodellen väntar en virtuell användarinstans på att den aktuella iterationen ska avslutas innan den påbörjar nästa. Om applikationen blir långsammare kan detta leda till att den tillgängliga belastningen minskar. Modellen lämpar sig för processer där just denna väntan är en del av uppgiften; den upprätthåller dock ingen fast ankomstfrekvens.

En öppen lastmodell planerar däremot nya iterationer oavsett om tidigare iterationer har avslutats. För detta måste belastningsgeneratorn ha tillräcklig kapacitet och tillgängliga virtuella användarinstanser. Om den inte kan starta iterationer uppnår testet inte den planerade profilen; dokumentera därför även dessa iterationer som inte har startats.

Notera både den inställda och den faktiskt uppnådda hastigheten. Iterationer per sekund motsvarar endast förfrågningar per sekund om varje iteration genererar exakt en förfrågan. Registrera dessutom svarstidsfördelningen, fel och timeouts samt kontrollen av att innehållet är korrekt: En hög genomströmning med felaktiga svar är inte ett framgångsrikt belastningstest.

Att utvärdera mätserier på ett överskådligt sätt

En mätningsserie är endast meningsfull i kombination med sin omfattning. Notera därför för varje testad sida och varje belastningssteg antalet utvärderade förfrågningar samt antalet fel och timeouts. Särskilj framgångsrika svar från misslyckade, utan att utelämna avbrott från rapporten: En låg svarstid med många fel är inte ett tecken på en tillförlitligt snabb tjänst.

Der Median beskriver medelvärdet för de sorterade lyckade mätningarna. Den 95:e percentilen, förkortat p95, visar dessutom ett tröskelvärde under vilket ungefär 95 procent av dessa mätvärden ligger. Vid ett litet antal förfrågningar beror p95 i hög grad på enskilda observationer; ange därför alltid urvalsstorleken och tolka skillnader med försiktighet.

Notera även belastningsmodellen och den faktiskt uppnådda hastigheten för varje körning. En konfigurerad hastighet i sig visar inte om generatorn kunde starta alla planerade iterationer. Följande mall förblir tom fram till mätningen; flera körningar får var och en ett eget protokoll.

Spara rådata, testskript och konfiguration tillsammans med protokollet. På så sätt går det senare att kontrollera vilka förfrågningar som ingick i en utvärdering och om två serier överhuvudtaget är jämförbara. Välj inte i efterhand endast det snabbaste körningen: Om resultaten överlappar varandra kraftigt kan den observerade skillnaden ligga inom variationerna.

Utöver nyckeltal bör du även ange avvikelser i innehållet, till exempel en oväntad inloggningssida istället för den förväntade kontovyn. En tekniskt lyckad status bevisar inte i sig att rätt sida har levererats. Sådana avvikelser ska redovisas separat i felbeskrivningen och kan göra en mätsekvens oanvändbar för det planerade beslutet.

Begränsa orsakerna och mäta på nytt

Börja felsökningen med det levererade svaret: Stämmer innehållet, inloggningsstatusen och den testade URL:en? Kontrollera därefter den dokumenterade Cache-status och mätmiljön. Olika cookies, en annan mätplats eller en ändrad CDN-regel kan göra att två körningar skiljer sig åt, utan att prestandan hos själva applikationsstacken har förändrats.

Först därefter kan tillgängliga driftsdata hjälpa till att avgränsa problemet: resursutnyttjande och köer kan tyda på flaskhalsar, medan applikations- eller databasinformation kan tyda på resurskrävande bearbetning. Ett enskilt långsamt HTTP-värde anger inte orsaken. WordPress nämner, förutom webbhotellet, även programvara, konfiguration och innehåll som faktorer som påverkar prestandan.

För en före-efter-jämförelse ändrar du medvetet endast en inställning, till exempel aktiveringen av en persistent objektcache. Webbplatsens tillstånd, testsidan, belastningsprofilen och mätplatsen ska i möjligaste mån förbli oförändrade; dokumentera även respektive caches uppvärmningstid. WordPress-objektcachen är utan lämplig persistent implementering begränsad till enskilda förfrågningar, varför dess faktiska integrering måste kontrolleras.

Genomför flera körningar före och efter ändringen och sprid ut dem över tiden. På så sätt kan du bättre avgöra om en skillnad uppträder upprepade gånger eller om den kan bero på normala variationer. Jämför inte bara medianvärdet och p95, utan även fel, svarsinnehåll och uppnådd träffsäkerhet; annars kan en till synes snabbare utveckling bero på förändrade testförhållanden.

Även en noggrann jämförelse kan inte ta hänsyn till alla faktorer. Vid delad hosting kan andra användare och infrastruktur som inte går att överblicka påverka resultatet. Om du saknar data om resurser eller köer bör du uttryckligen notera denna brist och formulera en misstänkt orsak som en hypotes snarare än som ett bevisat resultat.

Att tolka hostingresultatet på rätt sätt

Basera ditt val av webbhotell på de sidor och processer som är viktiga för din webbplats. Ett offentligt blogginlägg med en aktiv sidcache kan skapa en annan belastning än visningen av ett inloggat konto. Bra cacheträffar på offentliga sidor är därför varken ett tecken på snabba, anpassade svar eller en stabil betalningsprocess.

Innan jämförelsen görs ska du fastställa vilka svarstider, felprocent och vilken belastningsprofil som är acceptabla för den aktuella processen. Kontrollera därefter om de dokumenterade mätserierna uppfyller dessa krav under de överenskomna villkoren. Detta innefattar även korrekt innehåll och en stabil drift; en hög förfrågningsfrekvens i sig är inte en tillräcklig grund för beslut.

Ställ in virtuella användare inte samma sak som verkliga besökare som är närvarande samtidigt. Deras beteende bestäms av testskriptet och belastningsmodellen: I den slutna modellen väntar en instans på att sin iteration ska avslutas innan den påbörjar nästa. Utifrån antalet instanser går det därför inte att härleda ett verkligt besökarantal utan en lämplig beteendemodell.

Rapportera resultatet tillsammans med prisplan, webbplatsstatus, testade URL:er, cache- och CDN-regler, mätplats samt tidsperiod. Ange dessutom om du har jämfört så likartade stackar som möjligt eller de respektive helhetspaketen som erbjuds. Vid jämförelse av paket kan konfigurationsskillnader påverka resultatet; jämförelsen isolerar inte automatiskt den rena serverprestandan.

Om raderna överlappar varandra kraftigt eller om omgivningen inte går att kontrollera tillräckligt väl, är „ingen pålitlig skillnad har påvisats“ ett möjligt och användbart uttalande. Det betyder inte att båda alternativen är lika snabba under alla förhållanden. Det betyder endast att det aktuella testet inte ger den önskade skillnaden.

För driftskontroller sparar du mätprofilen och upprepar utvalda webbläsar- och belastningsmätningar efter större ändringar eller med överenskomna intervall. Jämför nya resultat endast med motsvarande tidigare mätserier och dokumentera ändringar av innehåll, versioner och cache-regler. Belastningstester kräver fortfarande ett godkänt tidsfönster och överenskomna avbrottsgränser.