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

Уже несколько лет Google продвигает неоднозначный показатель: Время до взаимодействия. Что это означает? Давайте дадим ему определение и объясним, как и когда его использовать (или не использовать).

TL;DR (краткое содержание)

Измерение интерактивности является серьезной проблемой для экспертов по веб-производительности. Поставщики решений для синтетического мониторинга, в частности, сталкиваются с трудностями при предоставлении вычисляемой метрики в отсутствие пользовательского ввода.

Google Time To Interactive — это сложная мера, предназначенная для определения идеальных условий для интерактивности путем мониторинга активности основного потока JS и сети. Он достаточно эффективен для определения времени, когда вы уверены, что взаимодействие будет бесшовным.

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

Реальный мониторинг пользователей (RUM) остается единственным способом фиксации действий пользователя, и даже здесь у нас до сих пор нет единого KPI, который просто отображает взаимосвязь между поведением пользователей и интерактивностью страницы во времени.

В поисках новой метрики

Что мы пытаемся измерить?

Доступ к веб-странице — это опыт, который мир веб-производительности обычно описывает как 4 момента:

  1. У пользователя есть подтверждение, что загрузка началась.
  2. У пользователя достаточно информации перед собой, чтобы думать, что он может взаимодействовать со страницей.
  3. Пользователь может взаимодействовать со страницей (этот конкретный момент зависит от типа взаимодействия).
  4. Взаимодействие пользователя со страницей происходит легко и интуитивно, без задержек и рывков.

Несколько сигналов дают пользователю признаки того, что загрузка началась: URL и заголовок меняются, браузер может анимировать вкладку и/или фавиконку, появляются первые непустые пиксели, затем остальная часть страницы…

Индекс скорости и Первая содержательная краска дают хорошее представление о визуальном восприятии посетителей. Они помогают понять воспринимаемую нагрузку страницы. У них есть ограничения, которые человек может определить с первого взгляда по видео или диафильму, потому что их алгоритм напрямую связан с тем, что отображается.

Однако когда речь идет об измерении интерактивности — пункты 3 и 4 — все становится сложнее. Правда в том, что мы на самом деле не знаем, как это измерить. Единственное, что мы умеем делать хорошо, — это собирать информацию, которая позволяет нам делать выводы об этих конкретных моментах.

Например, Akamai годами искала новые способы измерения активности пользователей. Они опираются на библиотеку Boomerang, созданную Филипом Теллисом. Филипп пришел на We Love Speed ​​2018, чтобы представить новые показатели пользовательского опыта, которые команда Boomerang собирала для измерения скорости отклика страницы: клики гнева, пропущенные клики, мертвые клики и удаление курсора. Анализируя распределение этих данных, характеризующих неудовлетворенность пользователя, мы можем приблизительно сделать вывод, когда пользователь ожидает, что страница или конкретный компонент будут интерактивными.

Этот тип корреляции требует больших объемов данных, собранных от реальных пользователей либо с помощью библиотек JavaScript, таких как Boomerang, либо с помощью RUM в браузере, такого как отчет Chrome UX. Эти данные можно собирать только в рабочих средах с большим количеством посетителей.

Тестирование оптимизации в этой среде рискованно. Без предварительного тестирования развертывание в рабочей среде может привести к регрессии/замедлению работы и нанести ущерб вашему бизнесу. Кроме того, вам придется подождать, чтобы собрать достаточно большой объем данных, и их будет сложно оценить, потому что данные RUM не так просто анализировать.

Решения синтетического мониторинга могут выполнять точные измерения производительности во всех средах, контролируя контексты тестирования. Они были бы еще полезнее, если бы могли предоставить метрику интерактивности.

Но поскольку они не привлекают реальных пользователей, они вынуждены заниматься махинациями…

Давайте представим… Время для (постоянного) взаимодействия

ПРИМЕЧАНИЕ
Хотя существует несколько определений, мы сосредоточимся на определении, предложенном Google с помощью своих инструментов и веб-сайтов.

Интерактивность можно рассматривать двояко: либо как переключение между двумя состояниями (неинтерактивным и интерактивным), либо как континуум. Знать, когда страница становится интерактивной в первый раз, интересно, но если интерфейс не реагирует быстро, UX будет сильно деградировать. Под «интерактивностью» мы подразумеваем здесь как тот факт, что страница является интерактивной, так и тот факт, что взаимодействие может происходить удовлетворительным образом.

Время до взаимодействия, ранее известное как «Время до последовательного взаимодействия», представляет собой экспериментальный синтетический показатель, который пытается измерить, когда ваше веб-приложение отображается как визуально, так и интерактивно.

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

Чтобы определить TTI, алгоритм продвигается по временной шкале, выполняет проверки и переопределяет значение-кандидат для TTI, пока не найдет момент, когда все условия выполняются. Во-первых, он выбирает в качестве нижнего предела, когда пользователь чувствует, что основной контент страницы виден. Для этого доступно несколько показателей: Время до интерактивного объяснения использует первую осмысленную отрисовку, но вы также можете использовать первую содержательную отрисовку, как это делает WebPageTest.

Затем алгоритм TTI проверяет, способен ли браузер обрабатывать взаимодействие. Поскольку многие пользовательские вводы обрабатываются клиентским JavaScript, работающим в среде с одним потоком, алгоритм должен затем гарантировать, что никакие длительные задачи JavaScript в настоящее время не занимают этот поток, не позволяя JS сразу обрабатывать пользовательские вводы. Для W3C задача считается длинной, если она длится дольше 50 мс (Long Task). TTI будет наблюдать за задачами JS и ждать 5-секундный период времени без длинных задач.

Однако все это бесполезно, если JS-код, необходимый для обработки взаимодействия, еще не загружен. Вместо того, чтобы внимательно следить за каждым HTTP-ответом, чтобы увидеть, загружены ли ресурсы JavaScript, алгоритм Time To Interactive будет использовать сигнал: он будет ждать, пока не заметит период не менее 5 секунд, в течение которого он никогда не увидит более 2 ресурсов (всех типов). комбинированные) загружаются параллельно.

Если одно из условий (длительная задача и сеть) не выполняется, алгоритм перемещает значение-кандидат для TTI вперед и возобновляет наблюдение, чтобы найти другую длинную задачу и еще одно 5-секундное сетевое окно после последней наблюдаемой длинной задачи. В этот момент значение-кандидат для TTI соответствует концу последней наблюдаемой длинной задачи.

Но мы не закончили! Наконец, алгоритм не считает страницу интерактивной до тех пор, пока браузер не закончит синтаксический анализ документа, поэтому, если событие DOMContentLoadedEnd происходит после нашего значения-кандидата для TTI, этот момент выбирается в качестве окончательного значения для времени до интерактивности.

Как использовать ТТИ?

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

Time To Interactive во многом похож на Visually Complete: отметка времени окончания чего-либо. Главный вопрос: «Что?». Тим Дрессер нашел наиболее адекватный способ определить это: TTI — это показатель «без скачков после этой точки», и это то, что вы хотели бы отслеживать и оптимизировать или, по крайней мере, не ухудшать без веских причин.

Действительно, TTI вычисляется на основе косвенного наблюдения как за процессором — через длинные задачи JS, так и за сетевой активностью. Если TTI увеличивается, это определенно означает, что длинная задача JS произошла позже, чем раньше, во время загрузки страницы, и важно знать, почему. Была ли введена новая длинная задача? Это ранее известные задачи, отодвигаемые новым фрагментом кода? Является ли это следствием какой-то недавно реализованной сторонней зависимости?

Как мы продемонстрируем позже в статье, эта длинная задача не обязательно вредна для вашего UX (например, если вы откладываете свои скрипты, то длинные задачи, которые они создали, будут выполняться позже), но вы, безусловно, можете оптимизировать, чтобы убедиться, что их не бывает (например, вы можете делегировать сложные алгоритмы JavaScript Веб-работникам, заставляя их выполняться в фоновых задачах, поэтому не занимая основной поток JavaScript).

Распространенное заблуждение о Time To Interactive

Время до интерактивности — это не время, пока страница не станет интерактивной.

Time To Interactive — очень двусмысленное название.

Даже в документации Lighthouse можно прочитать короткие вводящие в заблуждение определения вроде:

Метрика Time to Interactive (TTI) показывает, сколько времени требуется странице, чтобы стать интерактивной.

К счастью, за предложением следует определение того, что здесь означает «интерактивный», но для тех, кто не станет читать дальше, ущерб нанесен.

На самом деле время до интерактивности не измеряет, сколько времени требуется, чтобы страница стала интерактивной, а измеряет, сколько времени требуется, чтобы быть уверенным в том, что интерактивность может произойти удовлетворительным образом, т.к. не менее 5 секунд. Вот почему эта метрика ранее называлась «Время до постоянного взаимодействия».

Мы можем полностью получить очень быструю и удобную страницу, которая, однако, имеет огромный TTI. Для этого все, что вам нужно, это чтобы страница выполняла Длинные задачи как можно более короткой продолжительности с частотой, достаточной для прерывания окна наблюдения TTI. Эта страница, например, выполняет задачу на 51 мс каждые 2 секунды, в общей сложности 20 секунд, а ее TTI превышает 19 секунд.

Тем не менее, страница становится совершенно интерактивной раньше, чем предполагает TTI.

В алгоритме TTI подокно «тихая сеть» является только сигнальным

TTI всегда связан с последней длинной задачей JS. Эвристика «тихой сети» — это всего лишь сигнал. Я видел, как люди спрашивали, нужно ли им улучшить водопад, чтобы искусственно создавать каскады, содержащие менее двух одновременных запросов. Если ни один из этих запросов не связан с длинной задачей, вы можете расслабиться, ваш TTI не пострадает.

Однако, поскольку это только сигнал, это не гарантирует, что код JS, необходимый для обработки взаимодействия, вообще доступен. У вас может быть довольно хорошее время до интерактивности и страница, которая не является интерактивной — как ожидает пользователь — вообще.

TTI Google подходит не всем

Каждый раз, когда Google представляет новую концепцию, возникает большой рыночный спрос. Но будьте осторожны, Time To Interactive — это не стандарт!

Boomerang от Akamai, одно из самых известных решений для мониторинга реальных пользователей, имеет собственное определение времени до интерактивности, которое сильно отличается от определения Google. Они используют различные сигналы, такие как частота кадров, длительные задачи, занятость страницы (через `setInterval`) и отложенное взаимодействие с пользователем. Даже если они сохранят определение W3C Длинные задачи 50 мс, их окно покоя составляет всего 500 мс (вместо 5 секунд), что предотвращает увеличение TTI из-за изолированных задач.

В ходе моего исследования я также обнаружил, что некоторые решения синтетического мониторинга заявляют о поддержке метрики Time To Interactive, но, как и в случае с временем загрузки, вы всегда должны проверять их определение, потому что некоторые решения без колебаний обозначаются как TTI. метка на других показателях (таких как событие domInteractive), которые не имеют ничего общего с TTI Google.

Time to Interactive нелегко стабилизировать

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

Я попробовал это, и это был слишком нестабильный показатель для измерения Википедии. Вот пример: https://phabricator.wikimedia.org/T176369

– Питер Хеденског, инженер-программист (подрядчик), Фонд Викимедиа.

Мало отзывов о TTI.

Данных о корреляции TTI в дикой природе мало, и ни одна из них не позволяет сказать, что она более интересна, чем существующие метрики.

Основываясь на первом исследовании, проведенном Дипанджаном Роем (таблица результатов с 28 веб-сайтами), Time To Interactive позже была квалифицирована Тимом Дрессером, но без особого успеха. Честно говоря, эти корреляции очень трудно получить: как мы видим из анализа Тима, корреляция более стабильных метрик, таких как FCP, в дикой природе и в лаборатории тоже не очень хорошая.

Я нашел одно исследование 2017 года, проведенное Ником Янсмой, цитируется Эдди Османи, где он объясняет, что улучшение TTI оказывает реальное влияние на коэффициент конверсии в реальном сценарии использования, но слайды не дают доступа к данным. ни условий эксперимента.

Другие варианты использования, доступные в Интернете, часто заключаются в удалении всего JavaScript с целевых страниц, что является довольно частичным шагом, где можно было бы выбрать другие решения (например, загрузку и байтовое кэширование JS в Service Worker для будущего использования). Не поймите меня неправильно, я полностью за то, чтобы сократить долю JavaScript до наименьшей доли, но ни в коем случае не за счет путешествия пользователя.

Time To Interactive выходит на рынок веб-производительности, который уже предлагает несколько показателей, некоторые из которых легче понять и прокомментировать. Большинство вариантов использования, которые я читал о Time To Interactive, не уточняют, были ли существующие показатели достаточными для определения ситуации. Большинство владельцев сайтов отслеживают и сообщают только о 3 или 4 показателях веб-производительности. Прежде чем мы попросим их отказаться от одного из них для этого, я думаю, важно, чтобы они могли получить широкое представление об их релевантности.

Определение длинной задачи «50 мс» создает пороговый эффект.

Пороговые значения TTI заслуживают повышения осведомленности о важности бюджетов по результатам. TTI — это своего рода бюджет производительности: активность основного потока должна оставаться в рамках бюджета 50 мс.

Однако определение любого порога имеет значение.

Давайте возьмем очень простую страницу сообщения в блоге и протестируем ее на рабочем столе с помощью WebPageTest. Страница визуально готова и полностью интерактивна уже через 1,2 с. В этот момент и в течение нескольких секунд посетитель может свободно читать и листать. Примерно через 3,5 секунды выполнение скрипта reCaptcha создает задачу продолжительностью 150 мс (выделена красным на нижней панели), которая сдвигает время до взаимодействия вперед. Будет ли эта задержка воспринята посетителем? Кстати, через какое время посетитель почувствует задержку?

Согласно модели производительности RAIL (Response, Animation, Idle, Load), восприятие пользователем задержки производительности зависит от характера задержки. Задержки взаимодействия воспринимаются через ~ 100 мс. Значение, соответствующее сообщению Nielsen 1993 года, основанному на Miller & Card et al. исследования.

Если воспринимаемая задержка составляет 100 мс, зачем рассматривать задачу JS дольше 50 мс? Объяснение кроется в спецификации Long Task API:

Модель производительности RAIL предполагает, что приложения должны реагировать менее чем за 100 мс на ввод данных пользователем (для сенсорного перемещения и прокрутки менее 16 мс). Наша цель с этим API — отображать уведомления о задачах, которые могут помешать приложению достичь этих целей. Мы обнаруживаем задачи, которые занимают 50 мс и более. Веб-сайт без этих задач должен реагировать на ввод пользователя менее чем за 100 мс: потребуется менее 50 мс, чтобы завершить задачу, которая выполняется, когда получен ввод пользователя, и менее 50 мс, чтобы выполнить задачу, чтобы отреагировать на такой ввод пользователя.

- API длинных задач 1

Другими словами: обработка взаимодействия требует, чтобы браузер мог обрабатывать пользовательский ввод, не будучи уже занятым (интерактивность), и чтобы он мог достаточно быстро обрабатывать потенциальное выполнение кода JS, вызванное действием пользователя (отзывчивость). Поскольку мы не знаем фактического времени отклика браузера для обработки инициированной обработки, мы считаем, что это время должно быть меньше 50 мс. Это оставляет браузеру 50 мс, чтобы отреагировать на ввод.

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

Измерение интерактивности: достаточно ли TTI?

TTI как новый эталонный показатель?

Создание и продвижение метрики — это перформативное действие, особенно когда метрика определяется как эталонная метрика для интерактивности: когда Google продвигает метрику, метрика не только оценивает Интернет, но и формирует его. Эксперты SEO/SEM высоко ценят его для своих клиентов, компании используют его в рейтингах. Быстро все считают метрику эталоном, не подвергая сомнению ее обоснование.

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

Веха больше, чем оценка континуума

Время до интерактивности — это интерактивность, которую должна отображать визуальная завершенность: последняя веха. Чего нам не хватает, так это «индекса скорости взаимодействий», где каждая длинная задача будет взвешиваться по ее продолжительности и времени, в которое она выполняется, по отношению к другим показателям (например, показателям рендеринга), чтобы сделать вывод о разочаровании пользователя.

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

Между тем существует множество других метрик, касающихся интерактивности, в основном в RUM, где можно отслеживать реальную активность пользователя. Например, я думаю, что распределение First Input Delays — это чрезвычайно актуальная и не требующая пояснений информация, но это будет история для другого поста в блоге.

Помните: если вам нужно понять, что происходит с вашим JavaScript-кодом в синтетическом мониторинге, вы все равно можете использовать Custom Timings для развертывания полного инструментария. Это лучший способ понять, что важно для вашего бизнеса.

Подробнее об интерактивности и времени до интерактивности:

Прикосновение к археологии

Несколько презентаций для изучения индикаторов интерактивности

Спасибо Генри, Филиппу, Питеру и Тиму за то, что помогли мне сформировать мои идеи, и Дэмиену за его многократную корректуру и советы.

Первоначально опубликовано на https://blog.dareboost.com 16 мая 2019 г.