Тестування на стороні клієнта

Тестування на стороні клієнта — це експеримент, у якому оригінальна сторінка доставляється до браузера, а потім бібліотека JavaScript змінює її для створення варіанта. Інструмент тестування вирішує, який варіант має побачити відвідувач, застосовує відповідні зміни до документа та записує призначення. Оскільки зміни вносяться в браузері, а не в додатку, тести можна створювати та запускати без розгортання коду додатку, саме тому цей підхід домінує в комерційних інструментах оптимізації.

Перевага в швидкості є причиною його популярності. Команда маркетингу або оптимізації може створити, забезпечити якість та запустити тест за лічені години за допомогою візуального редактора, не потрапляючи в інженерний беклог. Для програми, яка потребує безперервного виконання експериментів з текстом, макетом, пропозицією та візуальною ієрархією, саме ця автономія робить значну швидкість експерименту взагалі можливою. Більшість організацій, які формують успішну звичку тестування, починають з цього, оскільки альтернатива вимагає інженерних інвестицій, які важко виправдати, перш ніж практика доведе свою цінність.

Компроміси також добре задокументовані. Варіант застосовується після оригінальних рендерів, тому, якщо тестовий скрипт не блокує рендеринг, відвідувачі ненадовго бачать елемент керування, перш ніж з’явиться зміна, дефект, відомий як мерехтіння або спалах оригінального контенту. Блокування рендерингу для запобігання мерехтіння додає затримку до кожного завантаження сторінки, зокрема для відвідувачів контрольної групи. Блокувальники реклами та конфігурації браузера, орієнтовані на конфіденційність, запобігають виконанню скрипта для частини аудиторії, і ця частина не є випадковою вибіркою. Повільні пристрої та погане з’єднання посилюють усі ці ефекти, що систематично спотворює результати на мобільних пристроях.

Клієнтське тестування також структурно обмежене в тому, що воно може змінити. Воно може переставляти, переробляти та переписувати те, що сервер вже створив, але не може змінити те, що сервер обчислює. Правила ціноутворення, релевантність пошуку, наявність запасів, логіка рекомендацій та будь-яке бізнес-правило, оцінене перед генерацією відповіді, є недосяжним. Спроби імітувати такі зміни в браузері, як правило, призводять до варіантів, які поводяться інакше, ніж поводилася б реальна функція, якщо її створити, а це означає, що тест відповідає на запитання про макет, а не про пропозицію.

Таким чином, отримання хороших результатів тестування на стороні клієнта значною мірою залежить від якості реалізації. Фрагмент тестового коду повинен завантажуватися синхронно в заголовок документа з обмеженим тайм-аутом, механізм запобігання мерехтінню слід налаштовувати навмисно, а не залишати за замовчуванням, вплив скрипта на продуктивність слід вимірювати, а не припускати, і кожен тест слід перевіряти на невідповідність співвідношення вибірки, щоб виявити випадки, коли скрипт непропорційно провалювався для однієї групи. Тести також повинні бути якісно перевірені на реальних пристроях та повільних з'єднаннях, а не лише на комп'ютері розробника.

Забезпечення якості для цих тестів вимагає певної процедури, оскільки варіант існує лише як модифікація, застосована під час виконання, і може порушувати роботу таким чином, що це не видно в редакторі. Контрольний список, який виявляє більшість проблем, включає перевірку варіанта на реальних пристроях у всіх браузерах, які фактично використовує аудиторія, перевірку поведінки, коли сторінка завантажується повільно та коли тестовий скрипт блокується, підтвердження того, що зміна витримує динамічні оновлення контенту та односторінкову навігацію, тестування з різною шириною області перегляду та підтвердження того, що відстеження спрацьовує рівно один раз на відповідну подію в обох варіантах. Тести також слід перевіряти на відповідність власному графіку випусків сайту, оскільки розгортання, яке змінює базову розмітку, непомітно порушить роботу варіанта, який від нього залежить, що призведе до періоду, протягом якого деякі відвідувачі бачать пошкоджену сторінку, і ніхто не отримує сповіщення.

Використане в межах своїх можливостей, клієнтське тестування залишається робочою конячкою більшості програм оптимізації. Типовий оптимізація рейтингу конвертації Engagement проводитиме більшість своїх експериментів таким чином, спрямовуючи питання логічного рівня до реалізації на стороні сервера, та постійно переглядатиме вартість продуктивності стеку тестування як частину... веб-продуктивність робота, оскільки інструмент тестування, який уповільнює кожну сторінку на триста мілісекунд, може легко призвести до більшої кількості конверсій, ніж ті, що зможуть повернути експерименти, які він дозволяє використовувати.