От автора: в сторонних сервисах произошел взрыв … И как Тим Кадлец однажды сказал: «Все должно иметь ценность, потому что все имеет стоимость». Итак, как мы оцениваем производительность всех сторонних сервисов, которые мы продолжаем добавлять на наши сайты? Хотя Chrome поддерживает блокирование отдельных запросов, мой любимый подход по-прежнему использует Web Page Test.
Если вас интересует подход Chrome, Umar рассмотрел, как использовать DevTools для блокировки сетевого запроса сразу после его выпуска в Chrome Canary — он по-прежнему работает, и теперь вы можете даже заблокировать целые домены.
Одной из причин, по которой я предпочитаю WebPageTest, является его параллельное сравнение диафильма — действительно мощный способ передать влияние сервисов на сотрудников, боссов и клиентов.
Создание сравнения
Первым шагом является проверка страницы без блокировки, т.е. в ее состоянии по умолчанию.
Не забудьте включить захват видео, и маркировка тестов упростит их различие при просмотре диафильма. В духе очевидности я часто отмечаю этот шаг «Оригинал» или «По умолчанию»!
Блокирование запросов
Затем нам нужно создать тест с некоторыми заблокированными запросами — я склонен обозначать это «заблокированные сторонние элементы» или как-то так в зависимости от того, что действительно заблокировано
Существует несколько способов блокировки запросов:
1. Использование поля блока
Самый простой способ блокировать запросы — добавлять записи в поле блока:
Поле блока принимает пространственно разделенный список значений и, как и его имя, предлагает блокировать любые запросы, содержащие одно из значений.
Поскольку это подстрочное совпадение, оно довольно велико с тем, что оно принимает, — от одной буквы до полного URL-адреса, поэтому, если вы добавите.com, WebPageTest, будут блокироваться все запросы с .com в любом месте URL-адреса.
Я использую подход блока поля чаще, чем подходы, основанные на сценарии ниже.
2. Использование скрипта
В качестве альтернативы есть три команды сценариев, которые можно использовать для блокировки запросов — они просты и понятны.
block — с последующим разделенным пробелом списком подстрок
Это работает так же, как поле блока в предыдущем примере.
block .com navigate https://andydavies.me
Пример теста с использованием команды block
Примечание: сценарию также нужна команда для перехода на страницу, которую вы хотите проверить.
blockDomains — за которым следует разделенный пробелом список доменов для блокировки
Блокирует все указанные домены.
blockDomains fonts.googleapis.com navigate https://andydavies.me
Пример теста с использованием команды blockDomains
blockDomainsExcept — за которым следует разделенный пробелом список доменов для блокировки
Блокирует все домены, кроме указанных.
blockDomainsExcept andydavies.me navigate https://andydavies.me
Пример теста с использованием команды blockDomainsExcept
Steve Souders охватывает использование blockDomainsExcept для тестирования Service Workers , и это отличный пример того, где он может быть действительно полезен.
Примечание. Одна вещь, за которой нужно наблюдать при просмотре водопадов из сценариев, которые использовали blockDomains и blockDomainsExcept — это то, что запросы блокируются на сетевом уровне, поэтому вы увидите запрос в водопаде с кодом результата -1.
Сравнение результатов
Как только оба теста пройдут, мы перейдем на вкладку «Test History», выберем тесты, которые мы хотим сравнить, и просмотрим диафильм.
Выбор запросов для блокировки
Обычно я использую одну из двух стратегий для определения, какие запросы блокировать, в зависимости от того, хочу ли я повышать осведомленность о том, что тег со стороны является проблемой вообще, или я хочу определить стоимость одного тега.
1. Блокировать все
Опция, которая требует меньше всего, блокирует всё.
Один из способов сделать это — копирование доменов списка из представления доменов завершенного теста и использование этого в виде списка блоков.
Здесь немного ручной работы, поэтому я стараюсь использовать команду оболочки для создания списка.
Представление домена может также генерировать отформатированный ответ JSON, и один из способов, которым я составляю список доменов для блокирования, — это JSON-выход через jq, а затем скопировать его в буфер обмена с помощью pbcopy .
curl 'http://www.webpagetest.org/domains.php?test=180130_NH_4c83de2dfe315f19e5367b91b6ac4a37&run=1&cached=0&f=json' | jq -rj '.domains.firstView[].domain + " "' | pbcopy
Затем я вставляю список доменов в поле блока и удаляю все, которые не должны быть заблокированы — проверяемый домен и любые домены, на которые он опирается, например, статические или медиа-активы.
Примечание. Конечно, pbcopy -есть только для macOS, но есть альтернативы, такие как xclip на Ubuntu и т. д.
2. Заблокировать подпрограмму запросов
Блокировка всех сторонних элементов — это драматический способ показать их совокупную стоимость, но это почти бесполезно, когда речь заходит о дискуссиях о влиянии или ценности одного стороннего тега.
Блокирование одного тега, возможно то, что задерживает страницу от рендеринга или замедляет отображение другого критического контента, — это мощный способ понять его влияние.
И если у вас есть продукт Real User Monitoring (например, RUM группы NCC или mPulse Soasta), который моделирует влияние скорости на конверсии и другие бизнес-показатели, вы можете использовать разницу во времени, чтобы получить реальное показание того, сколько стоит потратить на потерянные конверсии.
Подводные камни
Блокирование сторонних тегов не является надежным процессом, и иногда блокирование стороннего партнера не оказывает ожидаемого воздействия или вводит побочные эффекты, которые замедляют работу «более тонкой» страницы.
Здесь сравнение debenhams.com без сторонних тегов, тесты с заблокированными сторонними тэгами на самом деле медленнее, чем те, у которых есть теги (вы можете заметить, что базовая страница запрашивается повторно как запрос № 12 в тестах с теги заблокированы)
Поэтому не удивляйтесь, если время от времени блокирование сторонних тегов не имеет того эффекта, которого вы ожидаете.
В этих случаях я стараюсь, чтобы список заблокированных сторонних тегов был заблокирован, пока я не выделил тот, который вызывает неожиданное поведение.
Заключение
Сравнение диафильмов — отличный способ показать, как сторонние элементы влияют на визуальный опыт, и им легко понять все.
Хотя диафильмы помогают немного понять, находится ли страница в состоянии, в котором посетитель может взаимодействовать с ним (или нет), WebPageTest имеет оценку того, когда страница является интерактивной в нижней части водопада.
Сравнение диаграмм с двух прогонов дает нам некоторое представление о том, удастся ли удалить страницу со сторонними элементами раньше.
Одна из проблем производительности, с которой мы сталкиваемся, помогает людям понять стоимость сторонних тегов с точки зрения пользовательского опыта, и способность WebPageTest блокировать запросы предлагает отличный способ помочь в этом.
Автор: Andy Davies
Источник: https://andydavies.me/
Редакция: Команда webformyself.
