Противоречие между увеличением количества экспериментов и скоростью загрузки реально. Но это не бинарный выбор, как думают многие. Команды, проводящие больше всего экспериментов в месяц, не жертвуют ради этого производительностью. Они просто стали умнее подходить к тому, как они доставляют эти эксперименты.
В этом руководстве разбирается механика производительности клиентских экспериментов, показывается, как именно ее измерять, и описывается, как архитектура Optimizely сохраняет скорость ваших страниц, пока вы тестируете всё подряд.
Что на самом деле происходит при запуске клиентского эксперимента
Клиентское тестирование работает путем загрузки фрагмента JavaScript (snippet) в браузере посетителя. Этот фрагмент оценивает, какие эксперименты активны, решает, какой вариант показать, и применяет изменения — и все это до того, как посетитель увидит страницу.
Два фактора определяют, сколько времени это займет:
1. Время загрузки
Фрагмент кода должен попасть из CDN в браузер посетителя. География, тип устройства и скорость соединения — все это играет роль. Мобильные соединения медленнее. Посетителям в регионах с низкой пропускной способностью требуется больше времени.
Optimizely обеспечивает высокую скорость, сжимая фрагмент с помощью gzip и агрессивно кэшируя его в браузере. Если загрузка первой страницы занимает 60 мс, но посетитель просматривает четыре страницы, кэширование снижает среднее влияние примерно до 15 мс. Вы можете увеличить TTL кэша сверх стандартных двух минут для еще большей производительности между сессиями.
2. Время выполнения
После загрузки браузер должен оценить и применить эксперименты. Это зависит от скорости устройства посетителя (процессоры настольных компьютеров справляются быстрее, чем мобильные) и количества одновременно запущенных экспериментов.
Больше экспериментов означает больше кода для оценки, что требует больше времени. Это компромисс традиционных клиентских фрагментов кода. Но так быть не должно.
Остерегайтесь инструментов, которые заявляют о своей «неблокирующей» природе. Они часто вызывают видимое мерцание (flicker) после загрузки страницы, и контент меняется прямо на глазах у посетителя. Кратковременная блокировка при применении изменений лучше, чем показ неверного варианта вначале.
Остерегайтесь инструментов, которые заявляют о своей «неблокирующей» природе. Они часто вызывают видимое мерцание (flicker) после загрузки страницы, и контент меняется прямо на глазах у посетителя. Кратковременная блокировка при применении изменений лучше, чем показ неверного варианта вначале.
Как правильно измерять производительность
Интуитивные ощущения о скорости сайта бесполезны. Вам нужны данные. И вам нужны правильные данные, измеренные правильным способом.
Optimizely совместно с командой Google Chrome разработала строгую методологию измерения влияния экспериментов на производительность. Вот этот подход.
Шаг 1: Контролируйте условия оценки
Измерение производительности — это сам по себе эксперимент. Вам нужны чистые условия.
- Управление изменениями имеет значение. В течение окна измерений не вносите изменения в код, не добавляйте и не удаляйте JavaScript и не запускайте кампании, которые меняют состав вашего трафика. Любое из этих действий может исказить ваши показатели.
- Охватите полный недельный цикл. Структура трафика сильно меняется в зависимости от времени суток и дня недели. Десктопный трафик преобладает в рабочее время. Мобильный трафик резко возрастает по вечерам и выходным. Окно измерений в несколько часов во вторник днем мало что скажет вам о ваших мобильных посетителях в субботу.
- Измеряйте по одной странице за раз. У разных страниц разные наборы ресурсов, профили JavaScript и характеристики посетителей. Смешивание их в одном анализе размывает сигнал.
Шаг 2: Выберите правильные метрики
Здесь большинство команд совершают ошибку. Традиционные метрики, такие как DOMContentLoaded, измеряют внутренние процессы браузера, а не то, что на самом деле видит посетитель.
Core Web Vitals от Google теперь являются стандартом.
Три метрики фиксируют то, что действительно важно для ваших посетителей:
LCP — это метрика, на которую фрагменты кода для экспериментов влияют наиболее непосредственно, и она должна быть вашей основной метрикой. Она заменила старые показатели, такие как First Contentful Paint, потому что лучше отражает то, что посетители на самом деле воспринимают как «страница готова».
Но не останавливайтесь на метриках производительности. Измеряйте также влияние на бизнес: показатель отказов, вовлеченность, коэффициент покупок, доход. Цель — быстрая страница, которая приносит конверсии.
Шаг 3: Смотрите на распределение, а не на среднее значение
Данные о производительности веб-сайта имеют «длинный хвост». У одних посетителей страница загружается за 800 мс. У других это занимает 12 секунд на 3G-соединении. Среднее значение этих двух чисел не скажет вам ничего полезного ни об одном из этих посетителей.
Используйте медиану (p50) и 90-й процентиль (p90). Медиана показывает типичный опыт. p90 показывает, с чем сталкиваются 10% ваших самых медленных посетителей, и эти посетители часто заходят с мобильных устройств, где конверсии важнее всего.
Шаг 4: Сегментируйте всё
Производительность неоднородна. Разбейте свои данные по:
- География: скорость широкополосного доступа сильно варьируется в зависимости от страны и региона
- Тип устройства: мобильные устройства имеют более медленные процессоры и соединения
- Скорость соединения: 4G, WiFi и 3G показывают совершенно разные результаты
Единое усредненное число скрывает сегменты, в которых на самом деле существуют проблемы с производительностью.
Шаг 5: Используйте мониторинг реальных пользователей
Мониторинг реальных пользователей (RUM) — единственный надежный подход. RUM фиксирует фактические данные о производительности реальных посетителей на реальных устройствах и соединениях. Инструменты, такие как ваша текущая аналитическая платформа или специализированные RUM-решения, дают истинную картину.
Инструменты синтетического тестирования (например, лабораторные тесты скорости страниц) могут быть полезны для отладки, но они генерируют искусственный трафик, который не отражает реальный состав ваших посетителей. Не основывайте решения по производительности только на синтетических данных.
Как Optimizely обеспечивает скорость экспериментов
Optimizely предлагает три подхода к экспериментам, и самые продвинутые команды комбинируют их в зависимости от того, что они тестируют и где чувствительность к производительности наиболее высока.
Web Experimentation (на стороне клиента)
Установите одну строку JavaScript. Запускайте столько экспериментов, сколько захотите. Web Experimentation создана для скорости — как скорости тестирования, так и производительности страниц.
Это идеальный вариант для тестирования визуальных изменений: текстов, изображений, навигации, макета страницы и персонализированного контента. Технические и нетехнические пользователи могут создавать и запускать тесты, не дожидаясь развертывания кода.
Затраты на производительность реальны, но ими можно управлять: посетители загружают и выполняют дополнительный JavaScript для запуска экспериментов. Именно здесь вступают в игру разумные решения по внедрению (и Edge Delivery).
Feature Experimentation (на стороне сервера)
Для команд с ресурсами разработчиков и максимальной чувствительностью к производительности Feature Experimentation работает полностью на вашем бэкенде. Никакого дополнительного JavaScript на стороне клиента. Никаких сетевых задержек от внешних вызовов.
Вы получаете полный контроль над выполнением кода, включая флаги функций (feature flags), тестирование алгоритмов и изменения логики бэкенда, с нулевым влиянием на загрузку страницы. Компромисс: каждый эксперимент требует участия разработчика и развертывания кода.
Практический подход: комбинируйте оба варианта
Большинство высокопроизводительных команд используют сочетание обоих методов. Feature Experimentation берет на себя глубокие тесты бэкенда и наиболее критичные с точки зрения производительности страницы. Web Experimentation обеспечивает высокую скорость визуального тестирования во всех остальных случаях.
Выбирайте правильный инструмент для каждого теста. В этом и заключается вся стратегия.
Edge Delivery: скорость клиентской стороны, интеллект на стороне edge
Вот в чем заключается самое интересное. Edge Delivery коренным образом меняет способ доставки клиентских экспериментов и доступна как для клиентов Web Experimentation, так и Personalization.
Проблема традиционных сниппетов
Стандартный клиентский сниппет содержит все: все конфигурации экспериментов, все вариации, все правила таргетинга. Браузер вашего посетителя скачивает все это, обрабатывает все и применяет лишь ту крошечную часть, которая актуальна для конкретного посетителя на конкретной странице.
Это неэффективно. И по мере масштабирования числа экспериментов сниппет увеличивается, загрузка занимает больше времени, а время выполнения возрастает.
Как Edge Delivery решает эту проблему
Edge Delivery переносит принятие решений об экспериментах из браузера в Cloudflare Workers — граничные серверы, распределенные по всему миру и находящиеся физически близко к вашим посетителям.
Вот как это работает:
Без Edge Delivery (стандартный сниппет):
- Посетитель запрашивает вашу страницу
- Браузер скачивает полный сниппет с CDN (все эксперименты, все вариации)
- Браузер оценивает, какие эксперименты применимы к данному посетителю
- Браузер применяет победившую вариацию
- Браузер отслеживает события
С Edge Delivery:
- Посетитель запрашивает вашу страницу
- Cloudflare Worker перехватывает запрос
- Граничный сервер оценивает эксперименты, выбирает целевую аудиторию и распределяет посетителя по группам еще до того, как HTML доберется до браузера
- В браузер отправляется код только актуальной вариации
- Браузер применяет изменения с минимальным количеством JavaScript
- Отслеживание событий загружается асинхронно (без блокировки рендеринга)
Разница: браузер вашего посетителя практически ничего не делает. Основная нагрузка ложится на быстрые серверы рядом с ним, а в браузер поступает только тот код, который действительно необходим.
Результат
- Существенно меньший объем данных: браузер получает только то, что имеет значение, а не полную конфигурацию эксперимента.
- Более быстрое выполнение: меньше кода для парсинга и запуска.
- Неблокирующее отслеживание событий: отслеживание конверсий и кликов загружается асинхронно через отложенный сниппет трекинга.
- Масштабирование без замедления: добавление новых экспериментов не приводит к заметному росту объема данных, которые должен обрабатывать браузер.
Начало работы с Edge Delivery
Edge Delivery работает на базе Cloudflare Workers. Вам потребуется:
- Учетная запись Cloudflare, через которую маршрутизируется ваш сайт
- Установленный интерфейс командной строки Wrangler
- Активный проект Web Experimentation или Personalization
Установите SDK:
Интегрируйте его в ваш Cloudflare Worker:
let control = await fetch(request);
const options = { "control": control };
await applyExperiments(request, ctx, options)
Метод applyExperiments отвечает за распределение по группам, таргетинг и применение вариаций. Все, что не удается разрешить на граничном сервере, корректно передается в браузер в качестве резервного варианта.
Контрольный список производительности для быстрого проведения экспериментов
Независимо от того, используете ли вы стандартные сниппеты или Edge Delivery, эти практики помогут сохранить высокую скорость экспериментов:
Внедрение сниппета
- Размещайте сниппет в теге <head>, никогда не размещайте его ниже видимой области экрана
- Загружайте синхронно во избежание мерцания (или используйте Edge Delivery, чтобы полностью избавиться от этого компромисса)
- Никогда не загружайте через менеджер тегов. Это добавляет задержки и вызывает заметные сдвиги контента.
- Добавьте теги preconnect и preload для ускорения синхронной загрузки.
Оптимизация сниппета
- Увеличьте TTL кеша по умолчанию (2 минуты). Для большинства команд оптимально 10 или 20 минут.
- Используйте пользовательские сниппеты, чтобы разделить ваш проект на более мелкие бандлы для конкретных страниц
- Архивируйте неиспользуемые страницы и события. Они увеличивают размер сниппета, даже если их не используют эксперименты.
- Минимизируйте пользовательский JavaScript и CSS в ваших вариациях
Дизайн эксперимента
- По возможности используйте визуальный редактор вместо сложного кастомного кода
- Запускайте изменения ниже видимой области экрана асинхронно. Им не нужно блокировать начальный рендеринг.
- Используйте расширения для совместного использования кода между экспериментами вместо его дублирования
- Используйте Feature Experimentation для страниц, наиболее критичных к производительности
Измерения
- Непрерывно отслеживайте основные показатели эффективности (Core Web Vitals — LCP, INP, CLS) с помощью RUM
- Сегментируйте данные о производительности по устройствам, географии и типу подключения
- Запустите A/B-тест для самого процесса внедрения сниппета. Тестируйте стратегию доставки так же, как и все остальное.
Итог...
Эксперименты и производительность — это две стороны одной медали: предоставление вашим посетителям наилучшего пользовательского опыта.
Побеждают те команды, которые неустанно тестируют и одержимы идеей скорости. Благодаря правильной архитектуре, объединяющей Web Experimentation для скорости, Feature Experimentation для контроля и Edge Delivery для получения лучших преимуществ обоих подходов, вам не придется выбирать.
Тестируйте больше. Загружайтесь быстрее. И то, и другое одновременно.
Для получения подробных инструкций по внедрению посетите документацию по установке Edge Delivery и рекомендации по повышению производительности сайта.
