Раскрытие потенциала веб-производительности: глубокое погружение в Performance Observer API

В современном быстро меняющемся цифровом мире веб-производительность — это не роскошь, а необходимость. Медленный или не отвечающий веб-сайт может привести к разочарованию пользователей, более высоким показателям отказов и прямому негативному воздействию на бизнес-цели, будь то продажи, доход от рекламы или вовлечение пользователей. В течение многих лет разработчики полагались на инструменты, измеряющие производительность в одной точке времени, обычно во время начальной загрузки страницы. Хотя этот подход и полезен, он упускает из виду критическую часть истории: весь опыт пользователя во время его взаимодействия со страницей. Именно здесь вступает в игру мониторинг производительности во время выполнения, и его самым мощным инструментом является Performance Observer API.

Традиционные методы часто включают опрос данных о производительности с помощью таких функций, как performance.getEntries(). Это может быть неэффективным, подверженным пропуску важных событий, происходящих между опросами, и даже может добавить накладные расходы на производительность, которую он пытается измерить. Performance Observer API революционизирует этот процесс, предоставляя асинхронный механизм с низкими накладными расходами для подписки на события производительности по мере их возникновения. Это руководство проведет вас вглубь этого важного API, показывая, как использовать его мощь для мониторинга Core Web Vitals, выявления узких мест и, в конечном итоге, создания более быстрых и приятных веб-интерфейсов для глобальной аудитории.

Что такое Performance Observer API?

По своей сути Performance Observer API — это интерфейс, который предоставляет способ наблюдать и собирать события измерения производительности, известные как записи производительности. Думайте об этом как о специальном прослушивателе для действий, связанных с производительностью, в браузере. Вместо того, чтобы активно спрашивать браузер: «Что-нибудь уже произошло?», браузер активно сообщает вам: «Только что произошло новое событие производительности! Вот подробности».

Это достигается с помощью паттерна Observer. Вы создаете экземпляр observer, сообщаете ему, какие типы событий производительности вас интересуют (например, крупные отрисовки, ввод пользователя, сдвиги макета), и предоставляете функцию обратного вызова. Всякий раз, когда новое событие указанного типа записывается во временную шкалу производительности браузера, вызывается ваша функция обратного вызова со списком новых записей. Эта асинхронная модель на основе push-уведомлений гораздо более эффективна и надежна, чем старая модель на основе pull-запросов, заключающаяся в многократном вызове performance.getEntries().

Старый способ против нового способа

Чтобы оценить инновации Performance Observer, давайте сравним два подхода:

• Старый способ (опрос): Вы можете использовать setTimeout или requestAnimationFrame для периодического вызова performance.getEntriesByName('my-metric'), чтобы узнать, была ли записана ваша метрика. Это проблематично, потому что вы можете проверить слишком поздно и пропустить событие или проверять слишком часто и тратить впустую циклы ЦП. Вы также рискуете заполнить буфер производительности браузера, если не будете регулярно очищать записи.
• Новый способ (наблюдение): Вы настраиваете PerformanceObserver один раз. Он тихо сидит в фоновом режиме, потребляя минимальные ресурсы. Как только будет зарегистрирована соответствующая запись о производительности — будь то через одну миллисекунду после загрузки страницы или через десять минут после начала сеанса пользователя — ваш код будет немедленно уведомлен. Это гарантирует, что вы никогда не пропустите событие, а ваш код мониторинга будет максимально эффективным.

Почему вам следует использовать Performance Observer

Интеграция Performance Observer API в ваш процесс разработки предлагает множество преимуществ, которые имеют решающее значение для современных веб-приложений, стремящихся к глобальному охвату.

• Ненавязчивый мониторинг: Обратный вызов observer обычно выполняется в периоды простоя, гарантируя, что ваш код мониторинга производительности не будет мешать взаимодействию с пользователем и не будет блокировать основной поток. Он разработан, чтобы быть легким и иметь незначительный след в производительности.
• Полные данные времени выполнения: Интернет динамичен. Проблемы с производительностью возникают не только во время загрузки. Пользователь может запустить сложную анимацию, загрузить больше контента путем прокрутки или взаимодействовать с тяжелым компонентом спустя долгое время после того, как исходная страница успокоилась. Performance Observer фиксирует эти события времени выполнения, предоставляя вам полную картину всего сеанса пользователя.
• Перспективный и стандартизированный: Это рекомендованный W3C стандарт для сбора данных о производительности. Новые показатели производительности и API предназначены для интеграции с ним, что делает его устойчивым и перспективным выбором для ваших проектов.
• Основа мониторинга реальных пользователей (RUM): Чтобы действительно понять, как ваш сайт работает для пользователей в разных странах, на разных устройствах и в разных сетевых условиях, вам нужны данные из реальных сеансов. Performance Observer — идеальный инструмент для создания надежного решения RUM, позволяющего собирать жизненно важные показатели и отправлять их в службу аналитики для агрегирования и анализа.
• Устраняет состояния гонки: При опросе вы можете попытаться получить доступ к записи о производительности до того, как она была зарегистрирована. Модель observer полностью устраняет это состояние гонки, поскольку ваш код выполняется только после того, как запись станет доступной.

Начало работы: основы Performance Observer

Использовать API просто. Процесс включает в себя три основных этапа: создание observer, определение обратного вызова и указание observer, за чем следить.

1. Создание observer с обратным вызовом

Сначала вы создаете экземпляр объекта PerformanceObserver, передавая ему функцию обратного вызова. Эта функция будет выполняться всякий раз, когда обнаруживаются новые записи.

const observer = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log('Entry Type:', entry.entryType); console.log('Entry Name:', entry.name); console.log('Start Time:', entry.startTime); console.log('Duration:', entry.duration); } });

Обратный вызов получает объект PerformanceObserverEntryList. Вы можете вызвать метод getEntries() в этом списке, чтобы получить массив всех новых наблюдаемых записей о производительности.

2. Наблюдение за определенными типами записей

Observer ничего не делает, пока вы не укажете ему, что отслеживать. Это делается с помощью метода .observe(). Этот метод принимает объект со свойством entryTypes (или, в некоторых современных случаях, просто type для одного типа), который представляет собой массив строк, представляющих типы записей производительности, которые вас интересуют.

// Начните наблюдение за двумя типами записей observer.observe({ entryTypes: ['mark', 'measure'] });

Некоторые из наиболее распространенных типов записей включают:

• 'resource': Подробная информация о сетевых запросах для ресурсов, таких как скрипты, изображения и таблицы стилей.
• 'paint': Время первой отрисовки и первой отрисовки контента.
• 'largest-contentful-paint': Метрика Core Web Vital для воспринимаемой скорости загрузки.
• 'layout-shift': Метрика Core Web Vital для визуальной стабильности.
• 'first-input': Информация о первом взаимодействии пользователя, используемая для Core Web Vital First Input Delay.
• 'longtask': Определяет задачи в основном потоке, которые занимают более 50 миллисекунд, что может вызвать неотзывчивость.
• 'mark' & 'measure': Пользовательские маркеры и измерения, которые вы определяете в своем собственном коде, используя User Timing API.

3. Остановка observer

Когда вам больше не нужно собирать данные, рекомендуется отключить observer, чтобы освободить ресурсы.

observer.disconnect();

Практические варианты использования: мониторинг Core Web Vitals

Core Web Vitals — это набор конкретных факторов, которые Google считает важными для общего пользовательского опыта веб-страницы. Мониторинг их является одним из самых мощных применений Performance Observer API. Давайте посмотрим, как измерить каждый из них.

Мониторинг Largest Contentful Paint (LCP)

LCP измеряет производительность загрузки. Он отмечает точку во временной шкале загрузки страницы, когда основной контент, вероятно, загрузился. Хорошая оценка LCP — 2,5 секунды или меньше.

Элемент LCP может изменяться по мере загрузки страницы. Изначально заголовок может быть элементом LCP, но позже может загрузиться большее изображение и стать новым элементом LCP. Вот почему Performance Observer идеален — он уведомляет вас о каждом потенциальном кандидате LCP по мере его отрисовки.

// Наблюдайте за LCP и регистрируйте окончательное значение let lcpValue = 0; const lcpObserver = new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); // Последняя запись является самым последним кандидатом LCP const lastEntry = entries[entries.length - 1]; lcpValue = lastEntry.startTime; console.log(`LCP updated: ${lcpValue.toFixed(2)}ms`, lastEntry.element); }); lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true }); // Рекомендуется отключать observer после взаимодействия пользователя, // поскольку взаимодействия могут остановить отправку новых кандидатов LCP. // window.addEventListener('beforeunload', () => lcpObserver.disconnect());

Обратите внимание на использование buffered: true. Это важный параметр, который указывает observer включать записи, которые были записаны *до* вызова метода observe(). Это предотвращает пропуск раннего события LCP.

Мониторинг First Input Delay (FID) и Interaction to Next Paint (INP)

Эти метрики измеряют интерактивность. Они количественно определяют опыт пользователя, когда он впервые пытается взаимодействовать со страницей.

First Input Delay (FID) измеряет время от момента первого взаимодействия пользователя со страницей (например, нажатия кнопки) до момента, когда браузер фактически сможет начать обработку обработчиков событий в ответ на это взаимодействие. Хорошее значение FID — 100 миллисекунд или меньше.

Interaction to Next Paint (INP) — это более новая, более полная метрика, которая заменила FID в качестве Core Web Vital в марте 2024 года. В то время как FID измеряет только *задержку* *первого* взаимодействия, INP оценивает *общую задержку* *всех* взаимодействий пользователя на протяжении жизненного цикла страницы, сообщая о самом худшем. Это дает лучшее представление об общей отзывчивости. Хорошее значение INP — 200 миллисекунд или меньше.

Вы можете отслеживать FID, используя тип записи 'first-input':

// Наблюдайте за FID const fidObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { const fid = entry.processingStart - entry.startTime; console.log(`FID: ${fid.toFixed(2)}ms`); // Отключитесь после сообщения о первом вводе fidObserver.disconnect(); } }); fidObserver.observe({ type: 'first-input', buffered: true });

Мониторинг INP немного сложнее, поскольку он рассматривает полную продолжительность события. Вы наблюдаете за типом записи «event» и рассчитываете продолжительность, отслеживая самую длинную.

// Упрощенный пример мониторинга INP let worstInp = 0; const inpObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // INP — это продолжительность события const inp = entry.duration; // Нас интересуют только взаимодействия, превышающие текущий худший результат if (inp > worstInp) { worstInp = inp; console.log(`New worst INP: ${worstInp.toFixed(2)}ms`); } } }); inpObserver.observe({ type: 'event', durationThreshold: 16, buffered: true }); // durationThreshold помогает отфильтровать очень короткие, вероятно, незначительные события.

Мониторинг Cumulative Layout Shift (CLS)

CLS измеряет визуальную стабильность. Он помогает количественно определить, как часто пользователи сталкиваются с неожиданными сдвигами макета — неприятным опытом, когда контент перемещается на странице без предупреждения. Хорошая оценка CLS — 0,1 или меньше.

Оценка представляет собой агрегирование всех индивидуальных оценок сдвига макета. Performance Observer здесь необходим, поскольку он сообщает о каждом сдвиге по мере его возникновения.

// Наблюдайте и рассчитайте общий балл CLS let clsScore = 0; const clsObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // Мы не хотим учитывать сдвиги, вызванные вводом пользователя if (!entry.hadRecentInput) { clsScore += entry.value; console.log(`Current CLS score: ${clsScore.toFixed(4)}`); } } }); clsObserver.observe({ type: 'layout-shift', buffered: true });

Свойство hadRecentInput важно. Оно помогает отфильтровать законные сдвиги макета, которые происходят в ответ на действие пользователя (например, нажатие кнопки, расширяющей меню), которые не должны учитываться при расчете оценки CLS.

Помимо Core Web Vitals: другие мощные типы записей

Хотя Core Web Vitals — отличное начало, Performance Observer может отслеживать гораздо больше. Вот несколько других невероятно полезных типов записей.

Отслеживание длительных задач (`longtask`)

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

// Наблюдайте за длительными задачами const longTaskObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log(`Long Task Detected: ${entry.duration.toFixed(2)}ms`); // Свойство 'attribution' иногда может сообщить вам, что вызвало длительную задачу console.log('Attribution:', entry.attribution); } }); longTaskObserver.observe({ type: 'longtask', buffered: true });

Анализ времени загрузки ресурсов (`resource`)

Понимание того, как загружаются ваши ресурсы, является основой для настройки производительности. Тип записи «resource» предоставляет вам подробные данные о времени сети для каждого ресурса на вашей странице, включая поиск DNS, подключение TCP и время загрузки контента.

// Наблюдайте за временем загрузки ресурсов const resourceObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // Давайте найдем медленно загружающиеся изображения if (entry.initiatorType === 'img' && entry.duration > 500) { console.warn(`Slow image detected: ${entry.name}`, `Duration: ${entry.duration.toFixed(2)}ms`); } } }); // Использование 'buffered: true' почти всегда необходимо для времени загрузки ресурсов // чтобы перехватить ресурсы, которые были загружены до запуска этого скрипта. resourceObserver.observe({ type: 'resource', buffered: true });

Измерение пользовательских отметок производительности (`mark` и `measure`)

Иногда вам нужно измерить производительность логики, специфичной для приложения. User Timing API позволяет создавать пользовательские отметки времени и измерять продолжительность между ними.

• performance.mark('start-operation'): Создает отметку времени с именем 'start-operation'.
• performance.mark('end-operation'): Создает другую отметку времени.
• performance.measure('my-operation', 'start-operation', 'end-operation'): Создает измерение между двумя отметками.

Performance Observer может прослушивать эти пользовательские записи 'mark' и 'measure', что идеально подходит для сбора данных о времени выполнения таких вещей, как время рендеринга компонентов в фреймворке JavaScript или продолжительность критического вызова API и последующая обработка данных.

// В коде вашего приложения: performance.mark('start-data-processing'); // ... некоторая сложная обработка данных ... performance.mark('end-data-processing'); performance.measure('data-processing-duration', 'start-data-processing', 'end-data-processing'); // В вашем скрипте мониторинга: const customObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntriesByName('data-processing-duration')) { console.log(`Custom Measurement '${entry.name}': ${entry.duration.toFixed(2)}ms`); } }); customObserver.observe({ entryTypes: ['measure'] });

Продвинутые концепции и лучшие практики

Чтобы эффективно использовать Performance Observer API в профессиональной производственной среде, рассмотрите эти лучшие практики.

• Всегда учитывайте `buffered: true`: Для типов записей, которые могут возникать в начале загрузки страницы (например, 'resource', 'paint' или 'largest-contentful-paint'), использование флага buffered необходимо, чтобы избежать их пропуска.
• Проверьте поддержку браузером: Хотя она широко поддерживается в современных браузерах, всегда полезно проверить ее существование перед использованием. Вы также можете проверить, какие типы записей поддерживаются конкретным браузером.
• if ('PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes.includes('longtask')) { // Безопасно использовать PerformanceObserver для длительных задач }
• Отправляйте данные в службу аналитики: Ведение журнала данных в консоль отлично подходит для разработки, но для реального мониторинга вам необходимо агрегировать эти данные. Лучший способ отправки этой телеметрии с клиента — использовать API navigator.sendBeacon(). Это неблокирующий механизм, предназначенный для отправки небольших объемов данных на сервер, и он надежно работает даже при выгрузке страницы.
• Группируйте observer по области интересов: Хотя вы можете использовать один observer для нескольких типов записей, часто удобнее создавать отдельные observer для разных областей интересов (например, один для Core Web Vitals, один для времени загрузки ресурсов, один для пользовательских метрик). Это улучшает читаемость и удобство сопровождения кода.
• Поймите накладные расходы на производительность: API разработан для очень низких накладных расходов. Однако очень сложная функция обратного вызова, выполняющая сложные вычисления, потенциально может повлиять на производительность. Сделайте обратные вызовы observer простыми и эффективными. Отложите любую сложную обработку в веб-работник или отправьте необработанные данные в свой бэкэнд для обработки там.

Заключение: построение культуры, ориентированной на производительность

Performance Observer API — это больше, чем просто еще один инструмент; это фундаментальный сдвиг в том, как мы подходим к веб-производительности. Он переводит нас от реактивных, разовых измерений к проактивному, непрерывному мониторингу, который отражает истинный, динамичный опыт наших пользователей по всему миру. Предоставляя надежный и эффективный способ захвата Core Web Vitals, длительных задач, времени загрузки ресурсов и пользовательских метрик, он дает разработчикам возможность выявлять и устранять узкие места в производительности до того, как они повлияют на значительное число пользователей.

Принятие Performance Observer API — это важный шаг к построению культуры, ориентированной на производительность, в любой команде разработчиков. Когда вы можете измерить то, что имеет значение, вы можете улучшить то, что имеет значение. Начните интегрировать эти observer в свои проекты сегодня. Ваши пользователи — где бы они ни находились в мире — будут благодарны вам за более быстрый, плавный и приятный опыт.