Большинство статей, на которые обращают внимание многие люди, в том числе некоторые статьи, опубликованные в Интернете, посвящены методам оптимизации производительности, а также индикаторам производительности и тому, как выполнять мониторинг производительности.Многие из них основаны на веб-стандартах производительности и реализации браузеров. стандартов веб-производительности.
Если у нас есть всестороннее понимание стандартов веб-производительности, мы можем знать, как определяются показатели производительности, как рассчитываются показатели производительности и какие стратегии оптимизации поддерживаются браузерами. Основываясь на этом понимании, мы можем говорить о том, как устранять проблемы с производительностью, как оптимизировать производительность и как собирать данные о производительности для мониторинга производительности.
от рабочей группы веб-производительностиДомаПолные критерии производительности можно увидеть, и мы также можем увидетьALL STANDARDS AND DRAFTSНайдите эти критерии.
Эта статья поможет вам систематически изучать эти стандарты веб-производительности. Я в целом делю критерии веб-производительности на две категории:показатели эффективностисвязанные иСтратегия оптимизацииСвязанный. Представляя каждый стандарт, я буду представлять его в следующем порядке:
Полезность стандарта
стандартная версия
Что включает в себя стандарт
Связь с другими стандартами
показатели эффективности
Производительность страницы, на которую мы ориентируемся, в основном включает время рендеринга страницы и плавность интерактивных операций. Мы считаем, что производительность страницы лучше, когда время рендеринга страницы короче, а взаимодействие более плавное.
Пользователи могут ощущать качество производительности, но нам, как разработчикам, необходимо измерять производительность и использовать индикаторы производительности для измерения производительности. Теперь основные браузеры уже поддерживают получение данных о производительности страницы через определенные API.
определено в спецификации HTMLWindowобъект, мы можем получить объект Window через окно, и многие знакомые API монтируются на окно, например:
window.document
window.history
window.localStorage
window.location
window.navigator
window.postMessage
...
Эти API определяются различными стандартами W3C, а стандарт Web Performance Standard добавляет свойство производительности к окну, которое возвращает объект Performance через window.performance.
Объекты содержат множество свойств и методов измерения производительности, которые определяются различными веб-стандартами производительности. Давайте представим эти спецификации, связанные с измерением производительности, одну за другой.
High Resolution Time
Эта спецификация определяет интерфейс JavaScript, который показывает текущее время с миллисекундным разрешением и не зависит от перекоса или корректировок системных часов.
Существует две версии этого стандарта, уровень 1 и уровень 2. Уровень 2 уже является официально выпущенным стандартом, поэтому уровень 1 устарел, и официально использовать его больше не рекомендуется, нам нужно только знать, какие спецификации определяются уровнем 2.
1. Определяет начальное время (происхождение времени) для измерения данных о производительности.
Данные о производительности, которые мы получаем, являются временными метками, и нам нужно начальное время, чтобы вычислить разницу во времени, то есть время, проведенное на определенном этапе.
2. Определяет высокоточную метку времени DOMHighResTimeStamp
Он используется для хранения значения времени в миллисекундах, а время, полученное API, определенное спецификацией веб-производительности, представляет собой высокоточную метку времени.
3. Определяет объект Performance, а также несколько свойств и методов объекта Performance.
now()
timeOrigin
toJSON()
Все данные о производительности получаются через объект Performance, возвращаемый функцией window.performance.Свойства и методы, определенные следующими стандартами производительности, связанными со временем, находятся в объектах window.performance и Performance.
Хорошо, теперь, когда вы понимаете, что определяет спецификация, вы все знаете, почему эта спецификация называется временем высокого разрешения, верно? Поскольку основное содержание спецификации связано свремя высокой точностиСвязанный.
Performance Timeline
Настоящий стандарт распространяется на вышеуказанныеHR-TIME-2Объект Performance, определенный в спецификации, расширен,Предоставляет интерфейс для получения показателей производительности на основе определенных критериев фильтрации (имя, тип записи)., с помощью этих интерфейсов мы можем получать временные шкалы измерения производительности по нескольким параметрам (страницы, ресурсы и т. д.).
В настоящее время существует две версии этого стандарта: уровень 1 и уровень 2. Уровень 1 в настоящее время находится в статусе REC, а спецификация уровня 2 все еще находится в стадии разработки.Когда спецификация уровня 2 будет официально выпущена, уровень 1 также будет объявлен устаревшим.
Мы можем ввести этот код в консоли браузера, чтобы увидеть, что такое Entry.
window.performance.getEntries();
Полученный результат:
Возвращается массив, содержащий такие типы объектов, каждый из которых наследуется от объекта PerformanceEntry, то есть содержит два поля PerformanceEntry: name и entryType.
PerformanceResourceTiming
PerformanceNavigationTiming
PerformancePaintTiming
PerformanceMark
PerformanceMeasure
PerformanceEventTiming
PerformanceServerTiming
...
Эти объекты содержат различные показатели производительности для всего жизненного цикла веб-приложения.
Эти объекты будут определены в других спецификациях, связанных со временем, поэтому эти спецификации, связанные со временем, будут использовать PerformanceEntry, определенную спецификацией временной шкалы производительности.
Следовательно, мы можем получить данные о производительности определенного имени и определенного типа записи в соответствии с getEntriesByType() и getEntriesByName(). Например:
Тип входа Представляет тип объекта Performanceentry, а рабочая группа производительности W3C разработала спецификацию регистрации для имена типов входа:Timing Entry Names Registry, спецификация в настоящее время находится на стадии рабочего проекта.
В настоящее время зарегистрированы следующие типы:
Объект PerformanceEntry имеет такие свойства, как имя, entryType, startTime, продолжительность и toJSON(), которые являются общедоступными свойствами PerformanceResourceTiming, PerformanceNavigationTiming и других объектов, поэтому они будут наследоваться объектами, определенными в других спецификациях, описанных ниже (таких как PerformanceResourceTiming, PerformanceNavigationTiming и т. д.).
Используется для наблюдения за графиком производительности для уведомления о записи новых показателей производительности, что часто используется при сборе данных о производительности. Например, в следующем примере просмотрите данные о производительности типа ресурса и распечатайте их.
<!doctype html>
<html>
<head></head>
<body>
<img id="image0" src="https://www.w3.org/Icons/w3c_main.png" />
<script>
const resourceObserver = new PerformanceObserver(list => {
list
.getEntries()
// Get the values we are interested in
.map(({ name, entryType, startTime, fetchStart, responseStart, responseEnd }) => {
const obj = {
"Name": name,
"Entry Type": entryType,
"Start Time": startTime,
"Fetch Start": fetchStart,
"Response Start": responseStart,
"Response End": responseEnd,
};
return JSON.stringify(obj, null, 2);
})
// Display them to the console.
.forEach(console.log);
// Disconnect after processing the events.
resourceObserver.disconnect();
});
// Subscribe to new events for Resource Timing.
resourceObserver.observe({type: "resource"});
// 多个 Entry Type
// userTimingObserver.observe({entryTypes: ["mark", "measure"]});
</script>
</body>
</html>
Хорошо, теперь, когда вы понимаете, что определяет эта спецификация, вы также понимаете, почему эта спецификация называется графиком производительности, верно? потому что в спецификации указаноПолучить различные типы(навигация, ресурс, краска и т.д.)график производительностиAPI.
Resource Timing
Полная спецификация API определяет информацию о времени для доступа к ресурсам документов, таких как DNS-запросы ресурсов, TCP, запрос и т. Д. Время начала и окончания времени, вы можете помочь нам собрать статические ресурсы времени загрузки документа, размер ресурсов ресурсов и ресурсов.
Эта спецификация имеет две версии УРОВНЯ 1 и Уровня 2, уровень 1 стал рекомендуемой версией кандидата в 2017 году, и сегодня он официально не выпущен. Уровень 2 в настоящее время находится в черновой работе, на 2020.02.18 все еще обновляется, но не описывает взаимосвязь с Уровнем 1 в документе.
От содержания двух версий содержание мало чем отличается, но уровень 2 добавил IANA ConsiderationsИспользуется для установки Timing-Allow-Origin в качестве временного заголовка и обновления модели обработки синхронизации ресурсов.
https://w3c.github.io/resource-timing/timestamp-diagram.svg Модель обработки времени ресурсов
Для междоменных запрошенных ресурсов значение свойства (время) в полученном объекте PerformanceResourceTiming, посколькуМеждоменные ограничения, браузер не будет предоставлять пользователю данные о производительности ресурса, эти значения времени будут установлены в 0.
Если сервер добавит Timing-Allow-Origin в заголовок ответа запрошенного ресурса, браузер предоставит пользователю значение времени выполнения этого ресурса.
Мы можем получить данные о производительности для всех ресурсов в документе с помощью следующего оператора:
performance.getEntriesByType('resource');
Или получить данные о производительности для определенного ресурса с помощью следующего оператора:
Хорошо, теперь, когда вы понимаете, что определяет эта спецификация, вы также понимаете, почему эта спецификация называется Resource Timing, верно? Поскольку спецификация описываетВремя запроса ресурсовпоказатели эффективности.
Navigation Timing
Этот стандарт определяетДокументацияПолное измерение производительности в процессе навигации, то есть время выполнения документа от инициации запроса до завершения загрузки.
В настоящее время существует две версии этого стандарта: уровень 1 уже является версией 2012 года, а уровень 2 последний раз обновлялся в январе 2020 года. В будущем уровень 2 заменит версию уровня 1.
В настоящее время во многих браузерах реализован уровень 2, и рекомендуется использовать API, определенный спецификацией уровня 2. Поскольку разница между уровнем 1 и уровнем 2 относительно велика, но API, определенный уровнем 1, по-прежнему используется многими людьми, поэтому ниже приводится подробное введение.
Navigation Timing Level 1
Как упоминалось ранее, API времени высокого разрешения определяет объект Performance, который можно получить с помощью window.performance. И Navigation Timing Level 1 добавляет на этой основе два свойства: синхронизацию и навигацию.
Спецификация включает в себя следующее:
1. Определите объект PerformanceTiming
Чтобы измерить производительность страницы, мы можем получить данные о производительности страницы через window.performance.timing, а значение каждого поля в возвращаемом объекте можно найти вPerformanceTiming | MDNПроверьте это.
В порядке событий временная шкала этих данных о производительности выглядит следующим образом:
Используемый для описания операций, связанных с загрузкой, полученный через window.performance.navigation, возвращаемый объект PerformanceNavigation хранит два свойства, которые указывают причину запуска загрузки страницы. Это могут быть перенаправления страниц, кнопки «вперед» и «назад» или простая загрузка URL.
Добавлены свойства производительности для объектов Window: синхронизация и навигация.
Navigation Timing Level 2
Рабочая группа по веб-производительности 2019 г.Navigation Timing Level 2, который заменит Navigation Timing Level 1. Два свойства performance.timing и performance.navigation, определенные на уровне времени навигации 1, устарели.
На уровне 2 добавлено следующее содержание. Мы можем понять, что было обновлено на уровне 2 после прочтения этого раздела, не понимая, что такое английский язык.
Этот объект используется для измерения производительности документа, мы можем получить данные о производительности документа следующими способами, все значения времени указаны вOrigin TimeИзмеряется для начальной точки.
Эти свойства не всеPerformanceNavigationTiming | MDNОбъект является собственным, и часть его наследуется от объекта-прототипа. Мы можем ввести следующий код в консоль, чтобы просмотреть цепочку прототипов этого объекта.
const [entry] = performance.getEntriesByType("navigation");
let proto = Object.getPrototypeOf(entry);
const protos = {};
while(proto.toString() != '[object Object]') {
protos[proto.toString()] = Object.keys(proto);
proto = Object.getPrototypeOf(proto);
}
console.log(protos);
Тип и redirectCount возвращаются функцией window.performance.navigation устаревшего стандарта Navigation Timing Level 1.PerformanceNavigationСодержание объекта.
На уровне синхронизации навигации 1 объект PerformanceTiming, полученный через window.performance.timing, содержит данные, описывающие производительность документа, который совместно описывается следующими объектами:
мы можем пройтиResource Timing Level 2API window.performance.getEntriesByType("resource"), определенный в стандарте Время, необходимое для получения определенного ресурса.
таким образом,Navigation Timing Level 2Дана новая временная шкала, которая отличается от уровня синхронизации навигации 1 тем, что она инкапсулирует время, описывающее загрузку ресурсов, с помощью объекта PerformanceResourceTiming.
Свойство SecureConnectionStart является необязательным на уровне 1, но должно быть установлено браузером на уровне 2
Хорошо, теперь, когда вы понимаете, что определяет эта спецификация, вы также понимаете, почему эта спецификация называется навигационной временной шкалой, верно? Поскольку спецификация определяет описаниеДокументацияНа протяженииПроцесс навигациисерединапоказатели эффективностиОбъект PerformanceNavigationTiming.
Paint Timing
Эта спецификация определяет API для записи показателей производительности в некоторых ключевых моментах во время загрузки страницы, таких как Первая отрисовка, Первая отрисовка с содержанием.
Существует только одна версия этой спецификации, которая является первой и последней версией, в настоящее время находящейся на стадии рабочего проекта.
Показатели производительности, используемые для описания некоторых ключевых моментов времени во время загрузки страницы, мы можем просмотреть в консоли с помощью следующего оператора:
performance.getEntriesByType('paint');
Результат возвращает массив, в котором каждый элемент имеет тип PerformancePaintTiming , один — first-paint, а другой — first-contentful-paint.
2. Предлагаются некоторые определения ключевых моментов времени, такие как «Первая отрисовка», «Первая содержательная отрисовка».
Первая отрисовка — это время от навигации до отображения браузером первого пикселя на экране, это не включает фоновую отрисовку по умолчанию, но включает фоновую отрисовку не по умолчанию. Это первый критический момент, когда разработчик заботится о загрузке страницы — когда браузер начинает рендерить страницу.
First Contentful Paint(FCP) — это первая обратная связь пользователю о том, что страница фактически загружена, когда браузер отображает первый контент из DOM. Это первый раз, когда пользователь начинает работать с содержимым страницы.
Хорошо, теперь, когда вы понимаете, что определяет эта спецификация, вы понимаете, почему эта спецификация называется «Время рисования», верно? Поскольку спецификация определяет получениеНарисуйте ключевые моменты времениизпредставлениеAPI данных.
User Timing
Эта спецификация определяет API, который позволяет веб-разработчикам измерять производительность. В настоящее время существует две версии: уровень 2 официально выпущен, уровень 3 все еще находится на стадии черновика и в будущем заменит уровень 2.
В уровень 3 внесены изменения на основе уровня 2. Ниже описывается содержание спецификации уровня 3.
1. датьPerformanceОбъект добавляет несколько методов
mark()
clearMarks()
measure()
clearMeasures()
Метод использования следующий: с помощью метода mark() можно добавить метку времени к указанной позиции, чтобы записать время, когда выполнение достигает этой позиции. Метка — это значение метки, и она даст этой метке имя.
Метод Measure() измеряет интервал между двумя моментами времени и присваивает ему имя.
Но использование mark() и Measure() отличается на уровне 2 и уровне 3.
Использование на уровне 2 выглядит следующим образом: startTime, возвращаемый методом mark(), — это время выполнения оператора mark.
На уровне 3 функция mark() поддерживает входящий второй параметр как объект, поле startTime этого объекта может поддерживать время начала определяемой пользователем метки, а также предоставляет поле сведений для описания другой информации для пользователя; Метод также получает второй параметр в качестве объекта.В дополнение к времени начала и времени окончания измерения, указанному вторым параметром и третьим параметром на уровне 2, он также предоставляет поле сведений для описания другой информации для пользователя.
Описать данные, возвращаемые методом mark(), которые можно получить через performance.getEntriesByType('mark'), а конкретное значение полей можно посмотреть здесь:Performance.mark() | MDN, где поле подробностей определено в спецификации уровня 3.
3. Определите объект PerformanceMeasure
Опишите данные, возвращаемые методом Measure(), performance.getEntriesByType('measure'). Конкретное значение полей можно найти вPerformance.measure() | MDNПосмотрите, где поле подробностей определено в спецификации уровня 3.
Хорошо, теперь вы знаете, почему эта спецификация называется User Timing? потому что это обеспечиваетПозвольте пользователям определять временные точки для измерения производительности, вместо того, чтобы браузер определял измеренный узел времени (например, redirectStart, domainLookupStart, connectEnd и т. д.), например время ресурсов, время навигации и время рисования.
Server Timing
Мы знаем, что спецификации Resource Timing, Navigation Timing, Paint Timing и User Timing, которые были введены ранее, описывают характеристики производительности веб-приложений, такие как время запуска запроса, время согласования соединения и время. когда ответ получен.Эти браузеры измерения производительности все могут быть собраны, но не то, как маршрутизируются запросы, где время тратится на сервер и т. д.
Эта спецификация описывает, как передавать метрики производительности на стороне сервера во время цикла запрос-ответ агентам пользователя, и определяет API, который позволяет приложениям собирать, обрабатывать и выполнять эти метрики.
Существует только одна версия этой спецификации, которая в настоящее время находится на стадии рабочего проекта.
Каждый PerformanceServertIming описывает метрику производительности сервера, все объекты PerformanceServertIming этих метрик помещаются в массив, и мы можем получить в следующем выражении:
Хорошо, теперь, когда вы понимаете, что определяет эта спецификация, вы также понимаете, почему эта спецификация называется Server Timing, верно? Поскольку спецификация определяет, какПолучите производительность каждого узла на сервереAPI.
Long Tasks API
Когда пользователь взаимодействует со страницей, и приложение, и браузер ставят в очередь различные события, которые затем выполняет браузер, например, пользовательский агент планирует события ввода на основе активности пользователя, приложение планирует обратные вызовы для requestAnimationFrame и другие обратные вызовы и т. д. После постановки в очередь эти события планируются браузером для исключения из очереди и выполнения по одному.
Однако выполнение некоторых задач может занять много времени, и если это произойдет, поток пользовательского интерфейса будет заблокирован, а все остальные задачи будут заблокированы. Для пользователя это зависшая страница, и браузер не может реагировать на пользовательский ввод, что сегодня является основным источником плохого взаимодействия с пользователем в Интернете.
Эта спецификация определяет API, который можно использовать для обнаружения наличия этих «длительных задач», которые монополизируют поток пользовательского интерфейса в течение длительного периода времени и предотвращают выполнение других важных задач, таких как ответ на ввод пользователя.
В настоящее время существует только одна версия этой спецификации, которая находится на стадии рабочего проекта.
Как определить, есть ли длинная задача? Мы можем использовать API PerformanceObserver.
var observer = new PerformanceObserver(function(list) {
var perfEntries = list.getEntries();
for (var i = 0; i < perfEntries.length; i++) {
// Process long task notifications:
// report back for analytics and monitoring
// ...
}
});
// register observer for long task notifications
observer.observe({entryTypes: ["longtask"]});
// Long script execution after this will result in queueing
// and receiving "longtask" entries in the observer.
Ну, разобравшись с содержанием этой спецификации, вы также понимаете, почему эта спецификация называется Long Task API, верно? Потому что спецификация определяет API для обнаружения длинных задач.
Стратегия оптимизации
В дополнение к вышеуказанным стандартам показателей производительности Рабочая группа по веб-производительности также разработала некоторые стандарты оптимизации производительности, которые могут реализовывать браузеры, и предоставляет нам API-интерфейсы для использования этих оптимизаций.
Подсказки по ресурсам — производительность загрузки
Многие веб-приложения уже используют различные методы предварительной выборки для повышения производительности загрузки, включая, помимо прочего, использование XMLHttpRequest для выборки и кэширования ресурсов до тех пор, пока они не потребуются. Однако эти реализации не могут обеспечить тот же уровень производительности, который поддерживается браузерами. Что еще хуже, эти реализации иногда конфликтуют с логикой браузера, что приводит к задержке или ненужной выборке ресурсов, что снижает общую производительность страницы.
Эта спецификация определяет HTML<Link>Значение атрибута rel элемента, включая dns-prefetch, preconnect, prefetch и prerender. Мы можем использовать эти подсказки ресурсов, чтобы пользовательский агент помог нам предварительно разрешить DNS, предварительную ссылку, ресурсы предварительной загрузки и ресурсы предварительной обработки для повышения производительности страницы.
В настоящее время существует только одна версия этой спецификации, которая все еще находится в стадии рабочего проекта.
<link rel=prefetch />Приказывает браузеру получить ресурсы, которые могут понадобиться для следующей навигации. В большинстве случаев это означает, что ресурсы будут извлекаться с чрезвычайно низким приоритетом (поскольку браузер знает, что все, что ему нужно на текущей странице, более важно, чем то, что, по нашему мнению, ему нужно на следующей странице). Это означает, что основное использование предварительной выборки — ускорить следующую навигацию, а не текущую.
Пользовательский агент не будет предварительно обрабатывать ресурс после его извлечения и не будет использовать ресурс на текущей странице.
Атрибут as является необязательным атрибутом, который соответствует [PRELOAD] в определении.
Атрибут параметров CORS перекрестного происхождения — это необязательный атрибут, указывающий политику CORS для указанного ресурса.
4. Подсказки по ресурсам: пререндеринг
Дает подсказку браузеру отображать указанную страницу в фоновом режиме, ускоряя загрузку страницы, если пользователь переходит на страницу. Используется для получения следующей возможной HTML-навигации и предварительной обработки HTML-ответа (т. е. предварительной визуализации страницы) путем получения необходимых подресурсов и их выполнения.
Многим приложениям требуется детальный контроль над тем, когда получать, обрабатывать и применять ресурсы к документам. Например, приложение может задержать загрузку и обработку определенных ресурсов, чтобы уменьшить конкуренцию за ресурсы и повысить производительность при начальной загрузке. Такое поведение обычно достигается путем переноса выборки ресурсов в настраиваемую логику загрузки ресурсов приложения, т. е. выборка ресурсов инициируется через введенный элемент или через XMLHttpRequest при соблюдении определенных условий.
Однако бывают случаи, когда некоторые ресурсы необходимо получить заранее, но логика их обработки и выполнения зависит от конкретных требований, таких как управление зависимостями, условная загрузка, гарантии упорядочения и т. д.
Эта спецификация определяет подсказку ресурса предварительной загрузки, которую можно использовать с элементом ссылки, чтобы сообщить агентам пользователя о предварительном чтении ресурсов без необходимости их выполнения, что позволяет отделить загрузку ресурсов от выполнения и точно контролировать, когда и как загружаются ресурсы. .
Например, приложение может использовать ключевое слово preload, чтобы инициировать раннюю, высокоприоритетную и не блокирующую визуализацию выборку ресурсов CSS, которую приложение затем может применить в соответствующее время:
Using markup
<!-- preload stylesheet resource via declarative markup -->
<link rel="preload" href="/styles/other.css" as="style">
<!-- or, preload stylesheet resource via JavaScript -->
<script>
var res = document.createElement("link");
res.rel = "preload";
res.as = "style";
res.href = "styles/other.css";
document.head.appendChild(res);
</script>
Using HTTP Header
Link: <https://example.com/other/styles.css>; rel=preload; as=style
Как показано в примере выше, это можно сделать с помощью декларативной разметки, HTTP-заголовка Link ([RFC5988]) или отправлять ресурсы через JavaScript. См. раздел «Случаи использования» для более практических примеров того, как и где использовать предварительную загрузку.
Примечание: взаимосвязь между предварительной загрузкой и предварительной выборкой
Как предварительная выборка, так и предварительная загрузка могут объявлять ресурс и его атрибуты выборки, но в пользовательском агентеСуществуют различия в том, как и когда приобретаются ресурсы.: предварительная выборка необязательна, обычно низкоприоритетная выборка ресурсов, которые могут использоваться последующими переходами; предварительная загрузка является обязательной выборкой ресурсов, необходимых для текущей навигации. Разработчики должны использовать их разумно, чтобы свести к минимуму конкуренцию за ресурсы и оптимизировать производительность загрузки.
Также в предзагрузкекак атрибутДля обеспечения правильного приоритета, сопоставления запросов и запроса, соответствующего правильной политике безопасности контента (Content-Security-Policy) и отправка правильного заголовка Accept в зависимости от типа ресурса.
Эта спецификация предоставляет API для наблюдения за состоянием видимости страницы, например, когда пользователь сворачивает окно или переключается на другую вкладку, API отправляетvisibilitychangeсобытие, чтобы сообщить слушателям, что состояние страницы изменилось, и мы можем обнаружить событие и что-то сделать.
Например, веб-сайт имеет эффект карусели изображений, и следующий слайд автоматически отображается только тогда, когда пользователь просматривает карусель; приложение, которое отображает информационную панель, не хочет опрашивать сервер на наличие обновлений, когда страница не видна.
следовательно,API видимости страницыдляэкономить ресурсыа такжеПовысить производительностьОсобенно полезно, это позволяет страницам избегать ненужных задач, когда документ не виден.
В настоящее время существует две версии этой спецификации, уровень 2 заменит второе издание на этапе предлагаемых рекомендаций.
Мы можем получить доступ к состоянию видимости страницы через document.hidden и document.visibilityState.
По историческим причинам поддержка скрытого атрибута сохраняется. Разработчики должны использовать visibilityState, когда это возможно, значение, возвращаемое document.visibilityState, определяется в перечислении VisibilityState.
Вы можете отслеживать, изменилось ли видимое состояние страницы с помощью события visibilitychange.Если есть изменение, вы можете получить измененное состояние страницы через document.visibilityState.
var videoElement = document.getElementById("videoElement");
// Autoplay the video if application is visible
if (document.visibilityState == "visible") {
videoElement.play();
}
// Handle page visibility change events
function handleVisibilityChange() {
if (document.visibilityState == "hidden") {
videoElement.pause();
} else {
videoElement.play();
}
}
document.addEventListener('visibilitychange', handleVisibilityChange, false);
Однако методы реализации основных производителей браузеров этой спецификации различаются, и возникают проблемы с совместимостью. Совместимость необходимо выполнять во время реализации. Конкретные методы совместимости можно найти вPage Visibility API | MDNПроверить.
API requestIdleCallback — используйте ресурсы по максимуму
Эта спецификация определяет API совместного планирования фоновых задач, обеспечивающий возможность автоматического выполнения поставленных в очередь задач во время простоя по усмотрению пользовательского агента.Background Tasks API | MDNподробно описаны.
Мы можем использовать requestIdleCallback() для запуска ресурсоемких задач с низким приоритетом, когда браузер бездействует.
2. Определите объект IdleDeadline
Это можно пояснить на этом примере в спецификации, метод requestIdleCallback получает функцию (задачу, которую нужно выполнить в простое) RefinePi, параметр крайний срок функции тип IdleDeadline, этот объект предоставляетtimeRemaining()Функция для получения времени простоя, доступного для задачи.
function refinePi(deadline) {
while (deadline.timeRemaining() > 0) {
if (piStep())
pointsInside++;
pointsTotal++;
}
currentEstimate = (4 * pointsInside / pointsTotal);
textElement = document.getElementById("piEstimate");
textElement.innerHTML="Pi Estimate: " + currentEstimate;
requestId = window.requestIdleCallback(refinePi);
}
function start() {
requestId = window.requestIdleCallback(refinePi);
}
Обратный вызов бездействия не должен превышать отведенное время, насколько это возможно.Вот несколько советов о том, как в полной мере использовать обратный вызов бездействия, но более рекомендуется перейти кBackground Tasks API | MDNПосмотреть детали.
Используйте бездействующие обратные вызовы для задач с низким приоритетом.
Бездействующие обратные вызовы должны стараться не превышать отведенное им время.
Избегайте изменения DOM в бездействующих обратных вызовах.
Избегайте задач с непредсказуемым временем выполнения.
Используйте тайм-аут, когда вам это нужно, но не забывайте использовать его только тогда, когда вам это нужно.
Маяк - отчетность данных
Нам часто нужно попытаться сообщить данные о производительности в веб-сервисе до разгрузки документа. Отправка данных слишком рано может привести к пропущенным возможностям для сбора данных. Но для разработчиков всегда было трудно убедиться, что данные отправляются во время разгрузки документа, потому что агенты пользователей частохалатное отношениеГенерируется в обработчике события выгрузкиАсинхронный XMLHttpRequest.
Чтобы решить эту проблему, обычно необходимо инициировать синхронный XMLHttpRequest***** в обработчике событий unload или beforeunload для отправки данных. Синхронный XMLHttpRequest заставляет пользовательский агент откладывать выгрузку документа, в результате чего следующая навигация появляется позже, и следующая страница ничего не может сделать с этой низкой производительностью загрузки.
Эта спецификация добавляет к навигатору метод, который использует метод navigator.sendBeacon(), чтобы заставить пользовательский агент асинхронно отправлять данные на сервер, когда у него есть возможность, без задержки выгрузки страницы или влияния на производительность загрузки следующей страницы. навигация.
window.addEventListener('unload', logData, false);
function logData() {
navigator.sendBeacon("/log", analyticsData);
}
Для совместимости с этим методом следует использовать другие методы для отправки данных, если браузер не поддерживает navigator.sendBeacon, например синхронный XMLHttpRequest.
резюме
В этой статье представлены стандарты производительности, разработанные Рабочей группой по веб-производительности, в том числе стратегии измерения производительности и оптимизации.
Отношения наследования объектов, связанные со временем:
Обратитесь к документации W3C для получения более подробной информации о стандарте веб-производительности. В следующем разделе я опишу, откуда берутся различные показатели производительности, определяю, различаю и измеряю их.
думать
Два вопроса на сегодня:
1. Почему?Frame Timing | W3Cбыл перенесен вFrame Timing | WICG, производители браузеров не могут это реализовать? Если бы вам нужно было рассчитать FPS страницы, как бы вы его рассчитали?
2. Связь между подсказками ресурсов и предварительной загрузкой. Почему предварительная загрузка не входит в стандарт подсказок ресурсов? У них есть история?