Ресурсы · 06
Безопасный и высокопроизводительный веб: руководство по аудиту на основе пользовательского пути
Аудит скорости, доступности, безопасности и конверсии с учетом действий, которые пользователям действительно необходимо выполнить.
Обновлено · 3 min
Чего помогает достичь это руководство
- Приоритизация реальных блокирующих действий пользователей
- Сокращение веса, зависимостей и поверхности атаки
- Связь производительности с конверсией
- Проверка исправлений в реалистичных условиях
Быстрая проверка
- Названы ли три наиболее ценных пользовательских пути?
- Сегментированы ли данные полей для мобильных устройств?
- Можно ли использовать сайт с помощью клавиатуры?
- Есть ли у каждого стороннего скрипта владелец?
- Помогают ли ошибки в форме пользователям завершить действие?
Пошаговый метод
- 1
Выбор критически важных сценариев взаимодействия
Выбор поиска, чтения, контактов, регистрации, покупки или администрирования на основе бизнес-ценности. Опишите устройство, сеть, контекст и ожидаемый результат.
Результат: приоритетные сценарии тестирования.
- 2
Измерение в полевых и лабораторных условиях
Объединить агрегированные данные реальных пользователей с воспроизводимыми тестами. Наблюдать за загрузкой, отзывчивостью, стабильностью, ошибками и отказом от использования, не сводя анализ к одному показателю.
Результат: сегментированный базовый уровень.
- 3
Проверить критический путь.
Проверить исходный HTML, шрифты, изображения, JavaScript, кэширование, ответ сервера и блокирующие ресурсы. Выделить явный бюджет для элементов, обслуживающих пользовательский опыт.
Результат: бюджет производительности.
- 4
Уменьшить открытую поверхность.
Провести инвентаризацию сторонних скриптов, зависимостей, заголовков, cookie, сессий, форм и административных интерфейсов. Удалить ненужное и усилить защиту на сервере.
Результат: реестр зависимостей и защиты.
- 5
Протестировать инклюзивный опыт.
Выполнить каждое действие с помощью клавиатуры, программы чтения с экрана, малого экрана, масштабирования и состояния ошибки. Проверить метки, фокус, контраст и сообщения о восстановлении.
Результат: отчет о доступности и проблемах.
- 6
Выпуск с защитными механизмами.
Автоматизация стабильных элементов управления, наблюдение за результатами для бизнеса после выпуска и подготовка отката. Исправление закрывается, когда реальный пользовательский опыт улучшается без регрессии.
Результат: план непрерывной валидации.
Вымышленный пример
Иллюстративная ситуация
Страница бронирования работает быстро в лабораторных условиях, но кнопка подтверждения медленно реагирует на мобильных устройствах. Команда сегментирует измерения полевых данных по устройствам и сценариям использования, а затем тестирует меньше JavaScript и поведения клавиатуры.
Решение и ожидаемые доказательства
Изменение принимается только в том случае, если задача остается доступной, взаимодействие улучшается, а средства контроля безопасности сценария по-прежнему работают.
Показатели управления
| Показатель | Что он измеряет | Первое действие |
|---|---|---|
| Успешное завершение процесса | Пользователи завершают действие без блокирующей ошибки | Сначала устраните сбои, общие для нескольких сегментов |
| Производительность в полевых условиях | Загрузка, взаимодействие и стабильность на реальных устройствах | Сегментируйте перед устранением основного узкого места |
| Стоимость сторонних сервисов | Байты, время основного потока и запросы, находящиеся вне прямого контроля | Удалите, отложите или замените каждый несущественный сторонний сервис |
| Частота ошибок | Технические и входные сбои по этапам | Улучшите предотвращение, сообщения и восстановление |
Распространенные ошибки
- Оптимизация только главной страницы
- Путаница между оценкой в лаборатории и реальным опытом
- Добавление инструмента безопасности без устранения ненужного риска
- Нарушение доступности или измерения для экономии миллисекунд
Часто задаваемые вопросы
Конфликтуют ли производительность и безопасность?
Нет. Сокращение зависимостей, JavaScript и ненужных запросов часто улучшает и то, и другое. Компромиссы следует оценивать с учетом реальных сценариев использования и рисков.
На какой показатель следует ориентироваться?
Один пороговый уровень не заменяет данные о действиях пользователей. Установите бюджеты по сценариям использования, устройствам и аудитории, а затем отслеживайте их вместе с результатами бизнеса.
Почему необходимо включать доступность в аудит?
Потому что быстрое действие, которое нельзя выполнить с помощью клавиатуры, понять или восстановить, остается неудачей как для пользователей, так и для бизнеса.
Официальные ссылки
Ссылки подтверждают метод. Адаптируйте проверки к вашему контексту; они не являются сертификацией. Оригинальные названия ссылок и исходные документы могут быть на другом языке.
