Klientsidestestning

Klienttestning är experiment där originalsidan levereras till webbläsaren och ett JavaScript-bibliotek sedan modifierar den för att producera varianten. Testverktyget bestämmer vilken variant en besökare ska se, tillämpar motsvarande ändringar i dokumentet och registrerar tilldelningen. Eftersom ändringarna görs i webbläsaren snarare än i applikationen kan tester byggas och startas utan att applikationskod behöver distribueras, vilket är anledningen till att denna metod dominerar kommersiella optimeringsverktyg.

Snabbhetsfördelen är anledningen till dess popularitet. Ett marknadsförings- eller optimeringsteam kan bygga, kvalitetssäkra och lansera ett test på några timmar med hjälp av en visuell redigerare, utan att hamna i en teknisk eftersläpning. För ett program som behöver köra en kontinuerlig kadens av experiment med text, layout, erbjudande och visuell hierarki, är det denna autonomi som gör en meningsfull experimenthastighet möjlig överhuvudtaget. De flesta organisationer som bygger upp en framgångsrik testvana börjar här, eftersom alternativet kräver tekniska investeringar som är svåra att rättfärdiga innan metoden har bevisat sitt värde.

Avvägningarna är lika väl dokumenterade. Varianten tillämpas efter de ursprungliga renderingarna, så om inte testskriptet blockerar rendering ser besökarna kontrollen kort innan ändringen visas, en defekt som kallas flimmer eller blixt av originalinnehåll. Att blockera rendering för att förhindra flimmer ökar latensen för varje sidinläsning, inklusive för besökare i kontrollgruppen. Annonsblockerare och integritetsfokuserade webbläsarkonfigurationer förhindrar att skriptet körs för en del av publiken, och den delen är inte ett slumpmässigt urval. Långsamma enheter och dåliga anslutningar förstärker alla dessa effekter, vilket systematiskt snedvrider mobilresultaten.

Klienttestning är också strukturellt begränsad i vad den kan ändra. Den kan omorganisera, omformulera och skriva om det som servern redan har producerat, men den kan inte ändra vad servern beräknar. Prissättningsregler, sökrelevans, lagertillgänglighet, rekommendationslogik och alla affärsregler som utvärderas innan svaret genereras är alla utom räckhåll. Försök att simulera sådana förändringar i webbläsaren tenderar att producera varianter som beter sig annorlunda än hur den verkliga funktionen skulle bete sig om den byggdes, vilket innebär att testet svarar på en fråga om en mock snarare än om förslaget.

Att få bra resultat från klientsidestestning beror därför starkt på implementeringskvaliteten. Testkodavsnittet bör laddas synkront i dokumenthuvudet med en snäv timeout, anti-flimmermekanismen bör konfigureras medvetet snarare än lämnas som standard, skriptets prestandapåverkan bör mätas snarare än antas, och varje test bör kontrolleras för avvikelser i samplingskvoten för att upptäcka fall där skriptet misslyckades oproportionerligt för en grupp. Tester bör också kvalitetssäkras på riktiga enheter och långsamma anslutningar, inte bara på en utvecklares maskin.

Kvalitetssäkring för dessa tester kräver en specifik rutin, eftersom varianten endast existerar som en modifiering som tillämpas vid körning och kan brytas på sätt som är osynliga i redigeraren. Checklistan som fångar upp de flesta problemen inkluderar att verifiera varianten på riktiga enheter i de webbläsare som publiken faktiskt använder, kontrollera beteendet när sidan laddas långsamt och när testskriptet blockeras, bekräfta att ändringen överlever dynamiska innehållsuppdateringar och navigering på en sida, testa vid flera viewport-bredder och bekräfta att spårning utlöses exakt en gång per relevant händelse i båda varianterna. Tester bör också kontrolleras mot webbplatsens eget releaseschema, eftersom en distribution som ändrar den underliggande markupen i tysthet kommer att bryta en variant som är beroende av den, vilket skapar en period under vilken vissa besökare ser en trasig sida och ingen varnas.

Om man använder klientsidans testning inom sina gränser är den fortfarande arbetshästen i de flesta optimeringsprogram. omvandlingshastighetsoptimering engagemanget kommer att köra majoriteten av sina experiment på detta sätt samtidigt som de dirigerar logiklagerfrågor till serversidesimplementering, och kommer att hålla prestandakostnaden för teststacken under kontinuerlig granskning som en del av webbprestanda arbete, eftersom ett testverktyg som saktar ner varje sida med trehundra millisekunder lätt kan kosta fler konverteringar än de experiment det möjliggör kommer att vinna tillbaka.