API длинных кадров анимации

Барри Поллард
Ноам Розенталь

API длинных кадров анимации (LoAF произносится как Lo-Af) — это обновление API длинных задач , позволяющее лучше понять медленные обновления пользовательского интерфейса (UI). Это может быть полезно для выявления кадров медленной анимации, которые могут повлиять на метрику Interaction to Next Paint (INP) Core Web Vital, которая измеряет скорость реагирования, или для выявления других ошибок пользовательского интерфейса, влияющих на плавность .

Статус API

Поддержка браузера

  • Хром: 123.
  • Край: 123.
  • Firefox: не поддерживается.
  • Сафари: не поддерживается.

Источник

После первоначального пробного перехода от Chrome 116 к Chrome 122 API LoAF был переведен из Chrome 123 .

Предыстория: API длинных задач

Поддержка браузера

  • Хром: 58.
  • Край: 79.
  • Firefox: не поддерживается.
  • Сафари: не поддерживается.

Источник

API Long Animation Frames — это альтернатива API Long Tasks, который уже некоторое время доступен в Chrome (начиная с Chrome 58). Как следует из названия, API длинных задач позволяет отслеживать длинные задачи, то есть задачи, которые занимают основной поток в течение 50 миллисекунд или дольше. Длинные задачи можно отслеживать с помощью интерфейса PerformanceLongTaskTiming с помощью PeformanceObserver :

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'longtask', buffered: true });

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

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

Поэтому при попытке улучшить скорость реагирования в первую очередь часто приходится запускать трассировку производительности и анализировать длинные задачи. Это можно сделать с помощью лабораторного инструмента аудита, такого как Lighthouse (который имеет функцию «Избегать длинных задач основного потока »), или путем просмотра длинных задач в Chrome DevTools .

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

Недостатки API длинных задач

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

Инструменты реального мониторинга пользователей (RUM) часто используют это для отслеживания количества или продолжительности длительных задач или определения страниц, на которых они выполняются, но без основных подробностей о том, что вызвало длительную задачу, это имеет лишь ограниченное применение. API длинных задач имеет только базовую модель атрибуции , которая в лучшем случае сообщает вам только контейнер, в котором возникла длинная задача (документ верхнего уровня или <iframe> ), но не сценарий или функцию, вызвавшую ее, как показано на рисунке. типичная запись:

{
  "name": "unknown",
  "entryType": "longtask",
  "startTime": 31.799999997019768,
  "duration": 136,
  "attribution": [
    {
      "name": "unknown",
      "entryType": "taskattribution",
      "startTime": 0,
      "duration": 0,
      "containerType": "window",
      "containerSrc": "",
      "containerId": "",
      "containerName": ""
    }
  ]
}

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

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

API длинных кадров анимации

Поддержка браузера

  • Хром: 123.
  • Край: 123.
  • Firefox: не поддерживается.
  • Сафари: не поддерживается.

Источник

API Long Animation Frames (LoAF) — это новый API, который призван устранить некоторые недостатки API Long Tasks, чтобы дать разработчикам возможность получить более полезную информацию, которая поможет решить проблемы с быстротой реагирования и улучшить INP.

Хорошая отзывчивость означает, что страница быстро реагирует на взаимодействия с ней. Это предполагает возможность своевременно создавать любые обновления, необходимые пользователю, и избегать блокировки этих обновлений. Для INP рекомендуется отвечать в течение 200 миллисекунд или меньше , но для других обновлений (например, анимации) даже это может быть слишком долго.

API длинных кадров анимации — это альтернативный подход к измерению работы блокировки. Вместо измерения отдельных задач API Long Animation Frames, как следует из названия, измеряет длинные кадры анимации . Длинный кадр анимации — это когда обновление рендеринга задерживается более чем на 50 миллисекунд (так же, как пороговое значение для API длинных задач).

Длинные кадры анимации можно наблюдать так же, как и длинные задачи, с помощью PerformanceObserver , но вместо этого обращая внимание на тип long-animation-frame :

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Предыдущие длинные кадры анимации также можно запросить на временной шкале производительности следующим образом:

const loafs = performance.getEntriesByType('long-animation-frame');

Однако для записей производительности существует maxBufferSize , после которого новые записи удаляются, поэтому рекомендуемым подходом является подход PerformanceObserver. Размер буфера long-animation-frame равен 200, как и для long-tasks .

Преимущества просмотра фреймов вместо задач

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

Еще одним преимуществом этого альтернативного подхода к длительным задачам является возможность разбивки по времени всего кадра. Вместо того, чтобы просто включать startTime и duration , как API длинных задач, LoAF включает гораздо более подробную разбивку различных частей длительности кадра, включая:

  • startTime : время начала длинного кадра анимации относительно времени начала навигации.
  • duration : продолжительность длинного кадра анимации (не включая время презентации).
  • renderStart : время начала цикла рендеринга, который включает в себя обратные вызовы requestAnimationFrame , расчет стиля и макета, обратные вызовы наблюдателя изменения размера и наблюдателя пересечения.
  • styleAndLayoutStart : начало периода времени, затраченного на расчеты стиля и макета.
  • firstUIEventTimestamp : время первого события пользовательского интерфейса (мыши/клавиатуры и т. д.), которое будет обработано в течение этого кадра.
  • blockingDuration : продолжительность в миллисекундах, в течение которой кадр анимации блокировался.

Эти временные метки позволяют разделить длинный кадр анимации на тайминги:

Тайминг Расчет
Время начала startTime
Конец Времени startTime + duration
Продолжительность работы renderStart ? renderStart - startTime : duration
Продолжительность рендеринга renderStart ? (startTime + duration) - renderStart: 0
Рендеринг: продолжительность предварительного макета styleAndLayoutStart ? styleAndLayoutStart - renderStart : 0
Рендеринг: продолжительность стиля и макета styleAndLayoutStart ? (startTime + duration) - styleAndLayoutStart : 0

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

Улучшенная атрибуция

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

Подобно API длинных задач, он будет предоставлен в виде массива записей атрибуции, каждая из которых содержит подробную информацию:

  • name и EntryType вернут script .
  • Осмысленный invoker , указывающий, как был вызван сценарий (например, 'IMG#id.onload' , 'Window.requestAnimationFrame' или 'Response.json.then' ).
  • invokerType точки входа скрипта:
    • user-callback : известный обратный вызов, зарегистрированный из API веб-платформы (например, setTimeout , requestAnimationFrame ).
    • event-listener : прослушиватель событий платформы (например, click , load , keyup ).
    • resolve-promise : Обработчик обещания платформы (например, fetch() . Обратите внимание, что в случае с обещаниями все обработчики одних и тех же обещаний смешиваются в один «скрипт») .
    • reject-promise : согласно resolve-promise , но для отклонения.
    • classic-script : оценка сценария (например, <script> или import() )
    • module-script : То же, что и classic-script , но для скриптов модуля.
  • Отдельные данные о времени для этого сценария:
    • startTime : время вызова функции входа.
    • duration : Продолжительность между startTime и моментом завершения обработки последующей очереди микрозадач.
    • executionStart : время после компиляции.
    • forcedStyleAndLayoutDuration : общее время, затраченное на обработку принудительного макета и стиля внутри этой функции (см. перебор ).
    • pauseDuration : общее время, потраченное на «приостановку» синхронных операций (предупреждение, синхронный XHR).
  • Детали источника скрипта:
    • sourceURL : имя ресурса скрипта, если оно доступно (или пустое, если не найдено).
    • sourceFunctionName : имя функции скрипта, если оно доступно (или пустое, если не найдено).
    • sourceCharPosition : позиция символа сценария, если она доступна (или -1, если не найдена).
  • windowAttribution : контейнер (документ верхнего уровня или <iframe> ), в котором произошел длинный кадр анимации.
  • window : Ссылка на окно того же происхождения.

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

Пример записи производительности long-animation-frame

Полный пример записи производительности long-animation-frame , содержащий один сценарий:

{
  "blockingDuration": 0,
  "duration": 60,
  "entryType": "long-animation-frame",
  "firstUIEventTimestamp": 11801.099999999627,
  "name": "long-animation-frame",
  "renderStart": 11858.800000000745,
  "scripts": [
    {
      "duration": 45,
      "entryType": "script",
      "executionStart": 11803.199999999255,
      "forcedStyleAndLayoutDuration": 0,
      "invoker": "DOMWindow.onclick",
      "invokerType": "event-listener",
      "name": "script",
      "pauseDuration": 0,
      "sourceURL": "https://web.dev/js/index-ffde4443.js",
      "sourceFunctionName": "myClickHandler",
      "sourceCharPosition": 17796,
      "startTime": 11803.199999999255,
      "window": [Window object],
      "windowAttribution": "self"
    }
  ],
  "startTime": 11802.400000000373,
  "styleAndLayoutStart": 11858.800000000745
}

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

Используйте API длинных кадров анимации в полевых условиях

Такие инструменты, как Chrome DevTools и Lighthouse, хотя и полезны для обнаружения и воспроизведения проблем, являются лабораторными инструментами, которые могут упускать из виду важные аспекты пользовательского опыта, которые могут предоставить только полевые данные.

API Long Animation Frames предназначен для использования в полевых условиях для сбора важных контекстных данных для взаимодействия с пользователем, которые не удалось получить с помощью API Long Tasks. Это может помочь вам выявить и воспроизвести проблемы с интерактивностью, которые иначе вы могли бы не обнаружить.

Функция определения поддержки API длинных кадров анимации

Вы можете использовать следующий код, чтобы проверить, поддерживается ли API:

if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
  // Monitor LoAFs
}

Наиболее очевидным вариантом использования API длинных кадров анимации является помощь в диагностике и устранении проблем взаимодействия с следующей отрисовкой (INP) , и это было одной из ключевых причин, по которой команда Chrome разработала этот API. Хороший INP – это когда все взаимодействия обрабатываются в течение 200 миллисекунд или меньше с момента взаимодействия до отрисовки кадра, а поскольку API Long Animation Frames измеряет все кадры, длительность которых составляет 50 мс или более, наиболее проблемные INP должны включать данные LoAF, чтобы помочь вам диагностировать эти взаимодействия.

«INP LoAF» — это LoAF, который включает взаимодействие INP, как показано на следующей схеме:

Примеры длинных кадров анимации на странице с выделенным INP LoAF.
На странице может быть множество LoAF, один из которых связан с взаимодействием INP.

В некоторых случаях событие INP может охватывать два LoAF — обычно, если взаимодействие происходит после того, как кадр начал часть рендеринга предыдущего кадра, и поэтому обработчик событий обработал его в следующем кадре:

Примеры длинных кадров анимации на странице с выделенным INP LoAF.
На странице может быть множество LoAF, один из которых связан с взаимодействием INP.

В некоторых редких случаях возможно даже, что он может охватывать более двух LoAF.

Запись данных LoAF, связанных с взаимодействием INP, позволяет получить гораздо больше информации о взаимодействии INP, чтобы помочь в его диагностике. Это особенно полезно для понимания задержки ввода : вы можете увидеть, какие другие сценарии выполнялись в этом кадре.

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

Прямого API для связывания записи INP с связанной с ней записью или записями LoAF не существует, хотя это можно сделать в коде, сравнивая время начала и окончания каждой из них (см. пример сценарияWhyNp ).

Библиотека web-vitals включает все пересекающиеся LoAF в свойстве longAnimationFramesEntries интерфейса атрибуции INP из версии 4.

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

Отчеты о LoAF для взаимодействия с INP — это хороший способ выявить наиболее актуальные проблемы интерактивности на вашей странице. Каждый пользователь может по-разному взаимодействовать с вашей страницей, и при наличии достаточного объема данных атрибуции INP в данные атрибуции INP будет включен ряд потенциальных проблем. Это позволяет сортировать сценарии по объему, чтобы увидеть, какие сценарии коррелируют с медленным INP.

Отправляйте более длинные данные анимации обратно в конечную точку аналитики.

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

Поэтому вместо того, чтобы обращать внимание только на INP LoAF, вы можете рассмотреть все LoAF на протяжении всего жизненного цикла страницы:

Страница с множеством LoAF, некоторые из которых происходят во время взаимодействия, даже если это не взаимодействие INP.
Рассмотрение всех LoAF может помочь выявить будущие проблемы INP.

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

Некоторые предлагаемые шаблоны включают в себя:

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

Наблюдайте за длинными кадрами анимации с взаимодействиями.

Чтобы получить информацию, выходящую за рамки длинного кадра анимации INP, вы можете просмотреть все LoAF с взаимодействиями (что можно обнаружить по наличию значения firstUIEventTimestamp ).

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

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

const REPORTING_THRESHOLD_MS = 150;

const observer = new PerformanceObserver(list => {
    for (const entry of list.getEntries()) {
      if (entry.duration > REPORTING_THRESHOLD_MS &&
        entry.firstUIEventTimestamp > 0
      ) {
        // Example here logs to console, but could also report back to analytics
        console.log(entry);
      }
    }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Наблюдайте за кадрами анимации, длина которых превышает определенный порог.

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

const REPORTING_THRESHOLD_MS = 150;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.duration > REPORTING_THRESHOLD_MS) {
      // Example here logs to console, but could also report back to analytics
      console.log(entry);
    }
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

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

Наблюдайте за худшими длинными кадрами анимации

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

MAX_LOAFS_TO_CONSIDER = 10;
let longestBlockingLoAFs = [];

const observer = new PerformanceObserver(list => {
  longestBlockingLoAFs = longestBlockingLoAFs.concat(list.getEntries()).sort(
    (a, b) => b.blockingDuration - a.blockingDuration
  ).slice(0, MAX_LOAFS_TO_CONSIDER);
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Эти стратегии также можно комбинировать — взгляните только на 10 худших LoAF с взаимодействиями продолжительностью более 150 миллисекунд.

В подходящее время ( в идеале при событии visibilitychange ) возвращайтесь к аналитике. Для локального тестирования вы можете периодически использовать console.table : 

console.table(longestBlockingLoAFs);

Выявление общих закономерностей в длинных кадрах анимации.

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

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

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

const observer = new PerformanceObserver(list => {
  const allScripts = list.getEntries().flatMap(entry => entry.scripts);
  const scriptSource = [...new Set(allScripts.map(script => script.sourceURL))];
  const scriptsBySource= scriptSource.map(sourceURL => ([sourceURL,
      allScripts.filter(script => script.sourceURL === sourceURL)
  ]));
  const processedScripts = scriptsBySource.map(([sourceURL, scripts]) => ({
    sourceURL,
    count: scripts.length,
    totalDuration: scripts.reduce((subtotal, script) => subtotal + script.duration, 0)
  }));
  processedScripts.sort((a, b) => b.totalDuration - a.totalDuration);
  // Example here logs to console, but could also report back to analytics
  console.table(processedScripts);
});

observer.observe({type: 'long-animation-frame', buffered: true});

И пример этого вывода:

(index) sourceURL count totalDuration
0 'https://example.consent.com/consent.js' 1 840
1 'https://example.com/js/analytics.js' 7 628
2 'https://example.chatapp.com/web-chat.js' 1 5

Используйте API длинных кадров анимации в инструментах

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

Поверхностные данные кадров длинной анимации в DevTools

Вы можете отображать длинные кадры анимации в DevTools с помощью API performance.measure() , которые затем отображаются на дорожке пользовательского времени DevTools в трассировках производительности, чтобы показать, на чем сосредоточить свои усилия для повышения производительности: 

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    performance.measure('LoAF', {
      start: entry.startTime,
      end: entry.startTime + entry.duration,
    });
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

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

Используйте данные длинных кадров анимации в других инструментах разработчика.

Расширение Web Vitals продемонстрировало ценность регистрации сводной отладочной информации для диагностики проблем с производительностью.

Теперь он также отображает данные длинных кадров анимации для каждого обратного вызова INP и каждого взаимодействия:

Ведение журнала консоли расширения Web Vitals.
Журналирование консоли Web Vitals Extension отображает данные LoAF.

Используйте данные длинных кадров анимации в инструментах автоматического тестирования.

Аналогичным образом инструменты автоматического тестирования в конвейерах CI/CD могут выявить подробную информацию о потенциальных проблемах с производительностью, измеряя длинные кадры анимации во время выполнения различных наборов тестов.

Часто задаваемые вопросы

Некоторые из часто задаваемых вопросов по этому API включают в себя:

Почему бы просто не расширить или не усовершенствовать API длинных задач?

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

Хотя API длинных задач может извлечь выгоду из некоторых функций LoAF (например, улучшенной модели атрибуции), мы считаем, что сосредоточение внимания на кадрах, а не на задачах, дает множество преимуществ, которые делают этот API фундаментально отличным от существующего API длинных задач.

Почему у меня нет записей сценария?

Это может указывать на то, что длинный кадр анимации возник не из-за JavaScipt, а из-за большой работы по рендерингу.

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

Почему у меня есть записи сценария, но нет или ограничена исходная информация?

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

Информация о скриптах также будет ограничена для скриптов no-cors cross-origin , хотя это можно решить, извлекая эти скрипты с помощью CORS, добавив crossOrigin = "anonymous" к вызову <script> .

Например, скрипт Диспетчера тегов Google по умолчанию, добавляемый на страницу: 

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->

Можно улучшить, добавив j.crossOrigin = "anonymous" чтобы обеспечить предоставление полной информации об авторстве для GTM.

Заменит ли это API длинных задач?

Хотя мы считаем, что API Long Animation Frames является лучшим и более полным API для измерения длинных задач, в настоящее время мы не планируем прекращать поддержку API Long Tasks.

Требуется обратная связь

Отзывы можно оставить в списке проблем GitHub , а ошибки в реализации API Chrome можно зарегистрировать в системе отслеживания проблем Chrome .

Заключение

API Long Animation Frames — это потрясающий новый API со многими потенциальными преимуществами по сравнению с предыдущим API Long Tasks.

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

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

Благодарности

Миниатюрное изображение Генри Би на Unsplash .