Front-End Performance 2021: тестирование и мониторинг

Это руководство было любезно поддержано нашими друзьями из LogRocket, службы, которая сочетает в себе мониторинг производительности внешнего интерфейса , воспроизведение сеанса и аналитику продукта, чтобы помочь вам повысить качество обслуживания клиентов. LogRocket отслеживает ключевые показатели, в т.ч. DOM завершен, время до первого байта, задержка первого ввода, использование клиентского ЦП и памяти. Получите бесплатную пробную версию LogRocket сегодня.

Оглавление

1. Подготовка: планирование и показатели
2. Постановка реалистичных целей
3. Определение среды
4. Оптимизация активов
5. Оптимизация сборки
6. Оптимизация доставки
7. Сеть, HTTP/2, HTTP/3
8. Тестирование и мониторинг
9. Быстрые победы
10. Все на одной странице
11. Скачать контрольный список (PDF, Apple Pages, MS Word)
12. Подпишитесь на нашу рассылку по электронной почте, чтобы не пропустить следующие руководства.

Тестирование и мониторинг

1. Оптимизировали ли вы свой рабочий процесс аудита?
   Это может показаться не таким уж большим делом, но наличие правильных настроек под рукой может сэкономить вам немало времени при тестировании. Рассмотрите возможность использования рабочего процесса Альфреда Тима Кадлека для WebPageTest для отправки теста в общедоступный экземпляр WebPageTest. На самом деле, в WebPageTest есть много неясных функций, поэтому найдите время, чтобы научиться читать диаграмму WebPageTest Waterfall View и как читать диаграмму WebPageTest Connection View, чтобы быстрее диагностировать и решать проблемы с производительностью.

   Вы также можете запустить WebPageTest из электронной таблицы Google и включить показатели доступности, производительности и SEO в свою настройку Travis с помощью Lighthouse CI или прямо в Webpack.

   Взгляните на недавно выпущенный модульный инструмент AutoWebPerf, который позволяет автоматически собирать данные о производительности из нескольких источников. Например, мы можем провести ежедневный тест на ваших критически важных страницах, чтобы получить полевые данные из CrUX API и лабораторные данные из отчета Lighthouse из PageSpeed ​​Insights.

   И если вам нужно что-то быстро отладить, но ваш процесс сборки кажется удивительно медленным, имейте в виду, что «удаление пробелов и изменение символов составляет 95% уменьшения размера минимизированного кода для большинства JavaScript, а не сложные преобразования кода. Вы можете просто отключите сжатие, чтобы ускорить сборку Uglify в 3-4 раза».

1. Вы тестировали в прокси-браузерах и устаревших браузерах?
   Тестирования в Chrome и Firefox недостаточно. Посмотрите, как ваш сайт работает в прокси-браузерах и устаревших браузерах. UC Browser и Opera Mini, например, занимают значительную долю рынка в Азии (до 35% в Азии). Измерьте среднюю скорость Интернета в интересующих вас странах, чтобы избежать больших сюрпризов в будущем. Протестируйте с регулированием скорости сети и эмулируйте устройство с высоким разрешением. BrowserStack отлично подходит для тестирования на удаленных реальных устройствах, и дополните его хотя бы несколькими реальными устройствами в вашем офисе — оно того стоит.

1. Вы проверяли производительность своих 404 страниц?
   Обычно мы не думаем дважды, когда дело доходит до 404 страниц. В конце концов, когда клиент запрашивает страницу, которой нет на сервере, сервер ответит кодом состояния 404 и соответствующей страницей 404. Там не так уж много, не так ли?

   Важным аспектом ответов 404 является фактический размер тела ответа , отправляемого в браузер. Согласно исследованию 404 страниц, проведенному Мэттом Хоббсом, подавляющее большинство ответов 404 исходит от отсутствующих фавиконов, запросов на загрузку WordPress, неработающих запросов JavaScript, файлов манифеста, а также файлов CSS и шрифтов. Каждый раз, когда клиент запрашивает несуществующий актив, он получает ответ 404 — и часто этот ответ огромен.

   Обязательно изучите и оптимизируйте стратегию кэширования для своих страниц 404. Наша цель — предоставлять HTML браузеру только тогда, когда он ожидает HTML-ответ, и возвращать небольшую полезную нагрузку с ошибкой для всех остальных ответов. По словам Мэтта, «если мы разместим CDN перед нашим источником, у нас будет возможность кэшировать ответ страницы 404 в CDN. Это полезно, потому что без этого попадание на страницу 404 может быть использовано как вектор атаки DoS, путем заставляя исходный сервер отвечать на каждый запрос 404 вместо того, чтобы позволить CDN отвечать кэшированной версией».

   Ошибки 404 могут не только снизить производительность, но и снизить трафик, поэтому рекомендуется включить страницу ошибки 404 в набор тестирования Lighthouse и отслеживать ее оценку с течением времени.

   
2. Проверяли ли вы эффективность своих запросов согласия GDPR?
   Во времена GDPR и CCPA стало обычным делом полагаться на третьих лиц, чтобы предоставить клиентам из ЕС варианты выбора или отказа от отслеживания. Однако, как и в случае с любым другим сторонним скриптом, их производительность может иметь разрушительное влияние на общую производительность.

   Конечно, фактическое согласие, вероятно, изменит влияние сценариев на общую производительность, поэтому, как заметил Борис Шапира, мы могли бы изучить несколько различных профилей веб-производительности:

   • В согласии было полностью отказано,
   • В согласии частично отказано,
   • Согласие было дано полностью.
   • Пользователь не отреагировал на запрос согласия (или запрос был заблокирован блокировщиком контента),

   Обычно запросы согласия на использование файлов cookie не должны влиять на CLS, но иногда они влияют, поэтому рассмотрите возможность использования бесплатных опций с открытым исходным кодом Osano или cookie-consent-box.

   В общем, стоит изучить производительность всплывающих окон, так как вам нужно будет определить горизонтальное или вертикальное смещение события мыши и правильно расположить всплывающее окно относительно точки привязки. Ноам Розенталь делится знаниями команды Викимедиа в статье «Пример веб-производительности: предварительный просмотр страниц Википедии» (также доступен в виде видео и минут).

3. Ведете ли вы CSS для диагностики производительности?
   Хотя мы можем включить все виды проверок, чтобы гарантировать, что непроизводительный код будет развернут, часто бывает полезно получить быстрое представление о некоторых низко висящих плодах, которые можно легко решить. Для этого мы могли бы использовать великолепный CSS для диагностики производительности Тима Кадлека (вдохновленный фрагментом кода Гарри Робертса, который выделяет изображения с отложенной загрузкой, изображения без размера, изображения в устаревшем формате и синхронные сценарии.

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

   /* Performance Diagnostics CSS */ /* via Harry Roberts. https://twitter.com/csswizardry/status/1346477682544951296 */ img[loading=lazy] { outline: 10px solid red; }

1. Вы проверили влияние на доступность?
   Когда браузер начинает загружать страницу, он строит DOM, а если есть вспомогательные технологии, такие как программа чтения с экрана, он также создает дерево специальных возможностей. Затем программа чтения с экрана должна запросить дерево специальных возможностей, чтобы получить информацию и сделать ее доступной для пользователя — иногда по умолчанию, а иногда по требованию. А иногда это требует времени.

   Говоря о быстром времени до интерактивности, обычно мы имеем в виду показатель того, как скоро пользователь может взаимодействовать со страницей, щелкая или нажимая на ссылки и кнопки. Контекст немного отличается от средств чтения с экрана. В этом случае быстрое время до интерактивности означает, сколько времени проходит, пока программа чтения с экрана не сможет объявить о переходе по данной странице, а пользователь программы чтения с экрана не сможет фактически нажать клавиатуру для взаимодействия.

   Леони Уотсон выступила с откровенным докладом о производительности специальных возможностей и, в частности, о влиянии медленной загрузки на задержки объявлений программ чтения с экрана. Программы чтения с экрана привыкли к быстро меняющимся объявлениям и быстрой навигации, поэтому потенциально могут быть даже менее терпеливыми, чем зрячие пользователи.

   Большие страницы и манипуляции с DOM с помощью JavaScript вызовут задержки в объявлениях программ чтения с экрана. Довольно неисследованная область, которая требует некоторого внимания и тестирования, так как программы чтения с экрана доступны буквально на каждой платформе (Jaws, NVDA, Voiceover, Narrator, Orca).

2. Настроен ли постоянный мониторинг?
   Наличие частного экземпляра WebPagetest всегда полезно для быстрых и неограниченных тестов. Однако инструмент непрерывного мониторинга, такой как Sitespeed, Caliber и SpeedCurve, с автоматическими оповещениями даст вам более подробную картину вашей производительности. Установите собственные временные метки пользователя, чтобы измерять и отслеживать специфические для бизнеса показатели. Кроме того, рассмотрите возможность добавления автоматических предупреждений о снижении производительности, чтобы отслеживать изменения с течением времени.

   Рассмотрите возможность использования RUM-решений для отслеживания изменений производительности с течением времени. Для автоматизированных инструментов нагрузочного тестирования, подобных модульному тестированию, вы можете использовать k6 с его API сценариев. Также обратите внимание на SpeedTracker, Lighthouse и Calibre.

Оглавление

1. Подготовка: планирование и показатели
2. Постановка реалистичных целей
3. Определение среды
4. Оптимизация активов
5. Оптимизация сборки
6. Оптимизация доставки
7. Сеть, HTTP/2, HTTP/3
8. Тестирование и мониторинг
9. Быстрые победы
10. Все на одной странице
11. Скачать контрольный список (PDF, Apple Pages, MS Word)
12. Подпишитесь на нашу рассылку по электронной почте, чтобы не пропустить следующие руководства.