Что такое внешний мониторинг данных?

внешний интерфейс JavaScript

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

данные производительности

Программа статистики

  • мониторинг кода
    • Вставьте код мониторинга на страницу, рассчитайте разницу во времени вручную или используйте API браузера для статистики данных.
  • Мониторинг инструмента
    • Не вводите статистический код на страницу, обычно используйте виртуальную машину для анализа данных о производительности страницы.
Типы преимущество недостаток Пример
Неинвазивный Полные показатели, активный мониторинг клиентов, мониторинг конкурентных продуктов Невозможно узнать количество пользователей, на которые влияет производительность, меньшая выборка подвержена искажениям, невозможно отслеживать сложные приложения и функции подразделения. Pagespeed, PhantomJS, UAQ
навязчивый Реальные массивные пользовательские данные, могут отслеживать сложные приложения и бизнес-функции, клики пользователей и рендеринг областей. Необходимо вставить статистику сценариев, сетевые индикаторы неполные, а конкурирующие продукты нельзя отслеживать. ДП, Google Статистика

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

временной период

Расположите все свойства в порядке срабатывания: (Для более подробного стандартного объяснения см.:W3C Editor's Draft)

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

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

  • unloadEventEnd: соответствует unloadEventStart, возвращает отметку времени, когда выполняется функция обратного вызова, связанная с событием выгрузки предыдущей веб-страницы.

  • redirectStart: время первого перенаправления HTTP. Только если есть редирект и это редирект внутри того же доменного имени, иначе значение равно 0

  • redirectEnd: время, когда было завершено последнее перенаправление HTTP. Только если есть редирект и это редирект внутри того же доменного имени, иначе значение равно 0

  • fetchStart: время, когда браузер готов получить документ с помощью HTTP-запроса, это происходит до проверки локального кеша.

  • domainLookupStart: время, когда начинается запрос имени домена DNS.Если используется локальный кеш (т. е. без запроса DNS) или постоянное соединение, оно равно значению fetchStart.

  • domainLookupEnd: время завершения запроса имени домена DNS.Если используется локальный кеш (т. е. без запроса DNS) или постоянное соединение, оно равно значению fetchStart.

  • connectStart: время, когда HTTP (TCP) начинает устанавливать соединение. Если это постоянное соединение, оно равно значению fetchStart. Если возникает ошибка на транспортном уровне и соединение восстанавливается, время, когда здесь отображается только что установленное соединение.

  • connectEnd: HTTP (TCP) Время установления соединения (завершения рукопожатия). Если это постоянное соединение, то равно значению fetchStart. Если на транспортном уровне возникает ошибка и соединение переустанавливается. установлено, здесь отображается только что установленное соединение.

    Примечание. На этом рукопожатие заканчивается, включая завершение установки защищенного соединения, авторизацию SOCKS через

  • secureConnectionStart: время начала HTTPS-соединения или 0, если это небезопасное соединение.

  • requestStart: Время, когда HTTP-запрос начинает чтение реального документа (установление соединения завершено), в том числе чтение кеша из локального, и когда происходит переподключение при ошибке соединения, здесь же отображается время вновь установленного соединения.

  • responseStart: время, когда HTTP начинает получать ответ (извлекается первый байт), включая чтение из локального кеша.

  • responseEnd: время получения всех HTTP-ответов (до последнего байта), включая чтение из локального кеша.

  • domLoading: время начала разбора и рендеринга дерева DOM.В это время начинается загрузка Document.readyState, и будут генерироваться события, связанные с readystatechange

  • domInteractive: когда синтаксический анализ дерева DOM завершен, Document.readyState становится интерактивным и вызывает события, связанные с readystatechange.

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

  • domContentLoadedEventStart: после завершения синтаксического анализа DOM время, когда ресурс на веб-странице начинает загружаться, и время, когда в документе происходит событие DOMContentLoaded.

  • domContentLoadedEventEnd: после завершения синтаксического анализа DOM время загрузки ресурсов на веб-странице (например, когда загружается и выполняется скрипт JS), время окончания события DOMContentLoaded документа

  • domComplete: когда синтаксический анализ дерева DOM завершен и ресурс готов, Document.readyState становится завершенным, и будут сгенерированы события, связанные с readystatechange.

  • loadEventStart: Событие загрузки отправляется в документ, то есть время, когда функция обратного вызова загрузки начинает выполняться.Если событие загрузки не привязано, значение равно 0

  • loadEventEnd: время выполнения функции обратного вызова события загрузки, если событие загрузки не привязано, значение равно 0.

О разнице между DOMContentLoaded и событиями загрузки см. подробности.Разница между DOMContentLoaded и load.

Статистические методы

Navigation Timing API

Вы можете напрямую использовать интерфейс Navigation Timing для получения начальной точки статистики и времени, затрачиваемого на каждом этапе процесса загрузки.window.performanceЭто новый API, представленный W3C Performance Group, и в настоящее время поддерживается браузерами выше IE9.

Общие расчеты:

  • Время запроса DNS: domainLookupEnd - domainLookupStart
  • Длительное TCP-соединение: connectEnd - connectStart
  • Запрос занимает много времени: responseEnd - responseStart
  • Требуется много времени для разбора дерева dom: domComplete - domInteractive Время белого экрана: responseStart - navigationStart
  • время domready (узел времени, управляемый пользователем): domContentLoadedEventEnd - navigationStart
  • время загрузки (общее время загрузки): loadEventEnd - navigationStart

Resource timing API

API синхронизации ресурсов используется для подсчета информации о времени, связанной со статическими ресурсами.W3C Resource timing. Здесь мы вводим только метод performance.getEntries

Показатели и методы расчета

показатель

  • Общий показатель
    • Время взаимодействия с DOM
    • Общее время Timing.loadEventEnd - Timing.navigationStart Время до окончания поиска в DNS
    • Время до окончания запроса Timing.responseEnd - Timing.navigationStart
    • Время первого рендеринга time.msFirstPaint
  • Индикаторы этапа (по порядку)
    • Тайминг перенаправления
    • время выгрузки события
    • time.domainLookupStart - time.fetchStart
    • Время поиска DNS
    • время подключения
    • время запроса
    • Запрос интерактивного времени DOM (включая синтаксический анализ HTML, скрипт без отсрочки и время css)
    • DOM может взаимодействовать до времени DOMReady (включая время обработки скриптов отсрочки)
    • время загрузки события

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

ключевой индикатор

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

Определить отправную точку для статистики

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

время белого экрана

Время белого экрана — это время, когда пользователь впервые видит содержимое, также известное как время первого рендеринга.Высокая версия Chrome имеет интерфейс firstPaintTime для получения этого времени, но большинство браузеров его не поддерживают, и другие методы должны быть найдены для мониторинга. Внимательно наблюдайте за анализом представления WebPagetest и обнаружите, что время белого экрана появляется рядом с загрузкой ресурсов внешней ссылки в заголовке, потому что браузер будет отображать страницу только после загрузки и анализа ресурсов заголовка. Исходя из этого, мы можем аппроксимировать время белого экрана, получив момент загрузки ресурса заголовка. Несмотря на то, что он неточен, он учитывает основные факторы, влияющие на белый экран: время первого байта и время загрузки ресурса заголовка.

Как посчитать загрузку ресурсов заголовка? Мы обнаружили, что JS, встроенный в заголовок, обычно должен ждать, пока загрузится предыдущий JS\CSS, прежде чем он будет выполнен.Можно ли добавить предложение JS в нижнюю часть заголовка браузера, чтобы подсчитать конечную точку загрузки ресурс заголовка? Это можно проверить на простом примере:

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="UTF-8"/>
    <script>
      var start_time = +new Date; //测试时间起点，实际统计起点为 DNS 查询
    </script>
    <!-- 3s 后这个 js 才会返回 -->
    <script src="script.php"></script>  
    <script>
      var end_time = +new Date; //时间终点
      var headtime = end_time - start_time; //头部资源加载时间    
      console.log(headtime);
    </script>
    </head> 
    <body>     
    <p>在头部资源加载完之前页面将是白屏</p>
    <p>script.php 被模拟设置 3s 后返回，head 底部内嵌 JS 等待前面 js 返回后才执行</p>
    <p>script.php 替换成一个执行长时间循环的 js 效果也一样</p>  
    </body>
</html>

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

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

 var firstPaint = 0;

  // Chrome
  if (window.chrome && window.chrome.loadTimes) {
      // Convert to ms
      firstPaint = window.chrome.loadTimes().firstPaintTime * 1000;
      api.firstPaintTime = firstPaint - timing.navigationStart;
  }
  // IE
  else if (typeof timing.msFirstPaint === 'number') {
      firstPaint = timing.msFirstPaint;
      api.firstPaintTime = firstPaint - timing.navigationStart;
  }
  // Firefox
  // This will use the first times after MozAfterPaint fires
  //else if (timing.navigationStart && typeof InstallTrigger !== 'undefined') {
  //    api.firstPaint = timing.navigationStart;
  //    api.firstPaintTime = mozFirstPaintTime - timing.navigationStart;
  //}

выше сгиба

Логика обработки встраивается перед рендерингом первого экрана, а таймер используется для непрерывного обнаружения изображения узла img. Определите, находится ли картинка на первом экране и загрузка завершена, найдите время, когда картинка с самым медленным временем загрузки на первом экране будет завершена, а затем рассчитайте время первого экрана. Если нет изображения на первом экране, если нет изображения, используйте время domready. Статистический процесс выглядит следующим образом:

首屏位置调用 API 开始统计 -> 绑定首屏内所有图片的 load 事件 -> 页面加载完后判断图片是否在首屏内，找出加载最慢的一张 -> 首屏时间

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

  • Когда на странице есть iframe, также необходимо судить о времени загрузки
  • GIF-изображения могут многократно вызывать событие загрузки в IE и должны быть исключены.
  • В случае асинхронного рендеринга первый экран должен рассчитываться после асинхронной вставки данных
  • Важные фоновые изображения css можно подсчитать, запросив URL-адрес изображения через JS (браузер не будет загружать его повторно)
  • Если картинки нет, то первый экран будет использоваться для отсчета времени выполнения JS, то есть времени появления текста.

Пользовательская статистика

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

performance.timing.domInteractive - performance.timing.navigationStart

Всего загрузок

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

performance.timing.loadEventStart- performance.timing.navigationStart

онлайн-исключение

Мониторинг исключений интерфейса

Метод очень прост: в случае ошибки интерфейса проявите инициативу, чтобы сообщить об ошибке.

Мониторинг исключений кода JS

  • попробуй поймай поймай

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

try{
//可能发生异常的代码段
}catch(e){
//将异常信息发送服务端
}
  • захват окна.onerror

Этот метод не требует от разработчиков написания в коде большого количества try...catch.Добавив в окно мониторинг ошибок, можно собирать информацию об ошибках, когда возникает исключение в js, а также можно захватывать синтаксические исключения и исключения времени выполнения. Однако прослушиватель window.onerror должен быть размещен перед всеми js-файлами, чтобы гарантировать, что вся информация об исключении может быть захвачена.

  • Отлов исключений в междоменных JS-файлах

В настоящее время можно сказать, что практически все веб-продукты устанавливают заголовок ответа Access-Control-Allow-Origin: * на стороне сервера для статических ресурсов, таких как js/css/image, что означает, что междоменные запросы разрешены. . В этой среде, если мы добавим атрибут перекрестного происхождения к тегу скрипта, запрашивающему ресурсы перекрестного происхождения:

<script src="http://static.toutiao.com/test.js" crossorigin></script>

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

использованная литература

  1. Производительность переднего плана -- отслеживание запуска
  2. Производительность — интерфейсный инструмент мониторинга производительности.
  3. Интерфейсное решение для мониторинга производительности window.performance research (передача)
  4. Исследуете время выше сгиба? Вы должны знать эти детали в первую очередь
  5. Первый взгляд на производительность — мониторинг веб-страницы и производительности программы
  6. 7 дней на создание фронтенд системы мониторинга производительности
  7. Разница между DOMContentLoaded и load
Категории