+7 (925) 507-98-19
к.э.н. Лавлинский Н. Е., технический директор ООО «Метод Лаб»
Видео доклада:
Слайды:
Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.
Здесь есть два принципиальных направления: синтетические тесты в тестовом окружении и сбор метрик у реальных пользователей. Оба этих направления важны, но мы сконцентрируемся на синтетических тестах и будем использовать их для оценки влияния изменений в приложении на клиентскую производительность как часть процесса тестирования.
За счет использования изолированного окружения можно на раннем этапе ловить проблемы со скоростью, причем до релиза кода реальным пользователям.
Нам нужно протестировать клиентскую часть веб-приложения. Конечно, можно пытаться создать некий программный эмулятор браузера, который будет парсить страницу, загружать ресурсы (картинки, шрифты, CSS, JS), возможно даже выполнять JS.
Но нас интересуют реальные браузеры, потому что сейчас в них зашито слишком много логики по оптимизации (приоритет запросов, предзагрузка и т. д.) и пытаться их эмулировать не представляется возможным.
Получается, нужен реальный браузер, желательно охватить основные виды браузеров реальной аудитории. Наиболее доступное решение: запуск браузеров на Windows. Мы получаем: Chrome, Firefox, IE.
Теперь встаёт вопрос: как автоматизировать запуск тестов и получение метрик для отчета? Нужно создавать обзязку для каждого браузера, придумать как сохранять метрики, обрабатывать их и отправлять обратно на платформу тестирования для анализа. Довольно сложная и дорогая задача.
К нам на помощь приходит широко известный WebPagetest. Однако, публичный вариант сервиса Webpagetest.org нам не подходит: мы не контролируем точки тестирования, часто можно получить большую очередь, ограничения в использовании (количество прогонов тестов).
Но мы можем запустить всё это у себя и получить полный доступ! Называется решение WebPagetest Private Instance, находится в open source (https://sites.google.com/a/webpagetest.org/docs/private-instances).
Архитектурно состоит из двух компонент: серверная часть (очередь задач и front-end) и тестовые агенты.
Тестовым агентом как правило выступает машина с Windows 7, часто это виртуальная машина. При этом настроить машину можно самостоятельно или использовать готовые образы в Amazon EC2. Мы выбираем самостоятельную установку, чтобы полностью управлять окружением и тестировать из нужной нам сети.
Для тестового агента уже разработана вся необходимая обвязка по автоматизации браузеров. Для ограничения скорости сети используется dummynet.
Один WebPagetest сервер может подключаться к нескольким тестовым агентам (как своим, так и публичным). На каждом агенте есть несколько браузеров.
Как только мы настроили тестовый агент и сервер, можно начинать тестирование через web-ui.
При этом мы сохраняем все стандартные возможности WPT:
Но нам нужно автоматизировать процесс.
Данное решение позволяет подключать мобильные устройства в качестве тестовых агентов (Android, IOS). Однако, в этой области мало документации. Кроме того, мобильные устройства добавляют еще один фактор хрупкости в достаточно сложную систему. Также есть сложности с шейпингом трафика для мобильных.
Как вариант замены тестирования на мобильных можно использовать эмуляцию мобильного устройства в Chrome (получаем аналог Chrome Mobile). Для эмуляции мобильного CPU можно ограничить ресурсы виртуальной машине. Сетевые параметры доступны любые — здесь проблем нет.
Для целей автоматизации тестов в WPT PI есть несколько возможностей:
Чтобы получить максимальную гибкость и настраивать процесс под себя, нужно использовать API. Так как оно реализовано в виде обычного HTTP-интерфейса, который на выходе даёт JSON или XML, то ограничений в языке программирования практически нет.
Что требуется для автоматизированного тестирования скорости.
Чтобы отправить запрос на тест, требуется сделать POST-запрос на https://wptdomain/runtest.php.
Основные параметры:
После успешного прохождения теста мы получаем ссылку на JSON (или XML), где есть подробная информация о каждом экземпляре теста, а также о среднем и медианном вариантах.
Примеры полезных метрик, которые можно получить:
Здесь мы видим TTFB, начало рендеринга, время загрузки страницы, время полной загрузки, объёмы трафика на страницу, отдельно по типам (CSS, JS, Fonts). В конце есть оценки по степени оптимизации: заголовки кэширования, использование сжатия, оптимизация картинок, % соединений с keep-alive.
При желании можно получать отдельные данные по каждому запросу, или интегральные характеристики: PageSpeedIndex, затраты CPU на рендеринг страницы и т. д.
Основная сложность при использовании WPT PI это нестабильность результатов. Погрешность может достигать 50-100%. До конца победить эту проблему не получится, но есть набор мер по снижению негативного влияния:
Второй недостаток: ресурсоёмкость для масштабирования тестов. Здесь можно увеличивать количество тестовых агентов и запускать ограниченные тесты часто (например, без сбора видео), а полные – реже.
Наконец, так как мы используем живые Windows машины, они требуют обслуживания и обеспечения безопасности. Нужно мониторить их состояние, перезагружать, ставить обновления (в том числе для агентов).
Предложенное решение можно применять для таких задач:
Для чего этот инструмент неприменим:
В результате мы получаем рабочее решение с минимальными затратами на запуск и поддержку. Несмотря на указанные минусы, оно вполне справляется с большим кругом задач по автоматизации тестирования скорости. Мы получаем инструмент для ручного тестирования через web-ui, а также удобный доступ по API в одном флаконе.
За профессиональным ускорением сайтов обращайтесь к нам.
