Ефект на трептене

Ефектът на трептене, наричан още проблясък на оригиналното съдържание, е краткият момент, през който посетителят вижда контролната версия на страница, преди клиентски скрипт за тестване да я замени с варианта. Това се случва, защото браузърът рендира оригиналната маркировка веднага щом тя пристигне, докато библиотеката за тестване все още се зарежда, инициализира, решава кой вариант се прилага и прилага промените. Резултатът е видим проблясък: текстът се променя, елементите се местят, изображенията се разменят и страницата се установява в крайното си състояние, след като посетителят вече е започнал да чете.

Трептенето не е козметично дразнене, а източник на грешка в измерването. Посетителите във вариантната група изпитват скок, който посетителите в контролната група никога не виждат, така че двете групи получават различни преживявания по начин, който няма нищо общо с тествания дизайн. Част от посетителите на варианта изоставят по време на или веднага след светкавицата, а други са достатъчно разсеяни, че последващото им поведение се различава. Това води до пристрастия срещу варианта, което означава, че реалните подобрения не са достатъчно забелязани и програмата за тестване систематично подценява стойността на промените, които оценява.

Стандартното средство за смекчаване е фрагмент против трептене, който скрива тялото на страницата, докато тестовият скрипт не приключи с прилагането на промените, след което я показва. Това заменя видимо светкавица с празен екран и замяната е благоприятна само ако скриптът се зареди бързо. Ако тестовата библиотека е бавна или не се зареди напълно, времето за изчакване на фрагмента определя колко дълго посетителите се взират в нищото, преди да се покаже оригиналът. Времето за изчакване често се оставя по подразбиране от две до четири секунди, което при бавна мобилна връзка означава, че корекцията против трептене струва повече реализации, отколкото трептенето, което предотвратява.

Следователно, правилното внедряване е свързано с последователност и скорост, а не само с фрагмента. Тестовият скрипт трябва да се зарежда синхронно от заглавката на документа, така че да стартира възможно най-рано, в идеалния случай от бърза, добре обезпечена крайна точка, а не от споделена. Времето за изчакване против трептене трябва да се задава агресивно, обикновено доста под секунда, така че неуспехът да се превърне в кратко светване, а не в продължително празно време. Промените на вариантите трябва да се прилагат чрез размяна на CSS класове, където е възможно, а не чрез манипулиране на много елементи поотделно. Тестовете, които изискват голямо структурно пренаписване, е по-добре да се изграждат от страна на сървъра, отколкото да се налагат чрез инструмент от страна на клиента.

Диагностицирането на трептенето изисква разглеждане на реални условия, а не на машина на разработчика. Профилите на ограничена мрежа, мобилните устройства от среден клас и данните за наблюдение на реални потребители разкриват какво всъщност преживява аудиторията. Несъответствието в съотношението на извадката е най-силният косвен сигнал: ако посетителите се губят, докато скриптът се инициализира, разделянето на трафика няма да съответства на конфигурираното разпределение и тази проверка трябва да се изпълнява при всеки тест, независимо дали има съмнение за трептене.

Измерването на трептенето, вместо да се приема за неговото отсъствие, е лесно и рядко се прави. Записването на зареждане на страница при ограничена връзка и преминаването през кадрите показва точно какво вижда посетителят и за колко време, а правенето на това на устройство от среден клас, а не на машина за разработка, обикновено води до неприятен резултат. Второ и все по-често срещано усложнение е взаимодействието между тестовите скриптове и платформите за управление на съгласието, тъй като и двете се конкурират за изпълнение първи и и двете могат да блокират рендирането. Когато инструментът за съгласие се зареди преди инструмента за тестване, прилагането на варианти се забавя, докато съгласието не бъде решено, което може да добави секунда или повече и се прилага неравномерно в региони с различни изисквания за съгласие. Необходимо е съзнателното подреждане на тези две зависимости и измерването на комбинирания ефект върху рендирането, преди да може да се довери каквото и да е заключение за производителността на даден вариант.

Основният проблем е, че инструментът за тестване е допълнителна зависимост, вмъкната в критичния път на рендиране на всяка страница. Управлението на тази зависимост е част от уеб изпълнение работа, а не нещо, което екипът по оптимизация може да реши сам, и двете дисциплини трябва да бъдат координирани. Когато трептенето не може да бъде контролирано по приемлив начин, подходящият отговор в рамките на CRO услуга Целта на програмата е да премести засегнатите експерименти към сървърна имплементация, вместо да приеме постоянно, невидимо отклонение срещу всеки вариант, който програмата тества.