Вы меня поняли, я обожаю тики-бары! 🍹 Особенно рядом с моим домом в Хейс-Вэлли, Сан-Франциско.

Обновление от 5 ноября 2018 года: измерьте TTI с помощью маяка и измерьте FID в дикой природе с помощью Perfume.js (http://perfumejs.com/#/first-input-delay).

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

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

Основное различие между двумя показателями двоякое:

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

API-интерфейсы веб-производительности - это инструменты, используемые для сбора полевых данных, и они доступны во многих браузерах. В моей предыдущей статье Первая (содержательная) отрисовка мы представили два реальных измерения пользователя и сосредоточились на начальной загрузке, чтобы ответить на вопрос: Это происходит?. Теперь перейдем к вопросу "Можно ли его использовать?" в следующий ключевой момент навигации и использования веб-страницы.

Это можно использовать?

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

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

Одним из основных параметров для определения метрики является порог Долгая задача. Это относится к задаче цикла обработки событий, превышающей 50 мсек, что соответствует директиве ожидания RAIL. Во время загрузки страницы длинные задачи часто связывают основной поток и не позволяют пользователю взаимодействовать со страницей, даже если страница уже визуально визуализирована. Модель производительности RAIL предполагает, что приложения должны реагировать на ввод пользователя менее чем за 100 мс.

Это число взято из исследования, проведенного Робертом Миллером в 1968 году (время отклика в диалоговых транзакциях человек-компьютер), и это число было подтверждено в 1991 году сначала исследованием в Xerox-PARC, а затем в 1994 году Якобом Нильсеном в его книга Юзабилити-инженер г.

На практике алгоритм TTI представляет собой комбинацию наблюдения за основным потоком и сетевой активностью. Три шага для определения метрики:

  1. На временной шкале основного потока мы определяем нижнюю границу для TTI (нижний предел, который не может быть раньше), например FirstContentfulPaint или DomContentLoadedEnd;
  2. С нижнего предела ищем тихое сетевое окно продолжительностью 5 секунд (не содержащее длинных задач);
  3. Как только мы его нашли, мы оглядываемся назад до конца последней длинной задачи и указываем время как «Время до интерактивности».

Примечания, которые следует учитывать при измерении времени до интерактивного взаимодействия:

  • Если DOMContentLoadedEnd происходит после начала окна, он сообщает об этом как TTI;
  • Мы не можем использовать First Meaningful Paint в качестве нижней границы, поскольку она еще не стандартизирована;
  • Мы не можем обнаружить TTI, пока сеть не перестанет работать, но фактическое значение TTI всегда находится в конце длинной задачи;
  • Мы должны подождать не менее 5 секунд после того, как страница действительно станет интерактивной, прежде чем мы сможем сообщить об этом;
  • Мы не будем измерять TTI в простом статическом веб-приложении, мы, вероятно, будем измерять общее время отклика.

Теперь давайте посмотрим, как полифил TTI поможет нам измерить метрику с помощью полевых данных и применить на практике некоторую RUM. Ура снова! 🍹

TTI Полифилл

Прямо сейчас вы можете измерить время до взаимодействия с помощью полифилла, доступного в npm, который работает в любом браузере, поддерживающем Long Tasks API (на данный момент только в Chrome 58+). Использование tti-polyfill - это двухэтапный процесс:

  1. Во-первых, вам нужно добавить фрагмент кода в заголовок вашего документа, который создаст экземпляр PerformanceObserver и начнет наблюдать за длинными задачами в вашем основном потоке.
  2. В своем приложении вызовите метод getFirstConsistentlyInteractive () из модуля ttiPolyfill, который принимает необязательное значение нижней границы для запуска прямого поиска окна молчания в сети, значение по умолчанию - DOMContentLoaded.

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

Чтобы имитировать среднюю интерактивную задержку в одностраничном приложении, существует цикл манипуляции с DOM с более чем 40 тыс. Итераций после 500 мс после первого рисования. Длинные задачи, сгенерированные из цикла, идеальны в качестве демонстрации, потому что при начальной загрузке, если мы попытаемся щелкнуть кнопку «+1», ничего не изменится в документе, пока основной поток не освободится от длинных задач и браузер не будет свободен для расписывать последние изменения.

Perfume.js

Давайте добавим немного Perfume.js в нашу живую демонстрацию. Вместо прямого использования tti-polifyll мы будем использовать небольшую библиотеку JavaScript (https://github.com/Zizzamia/perfume.js) для измерения TTI. Результаты будут такими же, как и в предыдущей демонстрации, с двумя существенными преимуществами:

1. Кроссбраузерная поддержка будет использовать современные собственные API-интерфейсы, когда они доступны, и избегать выполнения длинных задач в противном случае;

2. Отправка результатов в Google Analytics как пользовательское время будет поддерживать настраиваемую переменную пользовательского времени timeVar: ”name”.

Аналитика

Лучшая часть RUM - это возможность сообщать о результатах в Google Analytics, где предоставленные полевые данные являются реальной метрикой производительности вашего SPA с полным пониманием того, когда страница готова, и без долгих задач. Начните оптимизацию, уделяя особое внимание не только видимости контента, но и дополнительному вниманию к взаимодействию с пользователем, сокращению длительных задач и измерению как синтетических, так и RUM.

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

Удачи 🔥 🚀 🌕

Если у вас возникнут дополнительные вопросы, отправьте мне твит или личное сообщение в Twitter @zizzamia.