Пользователи замечают, что сайты и приложения работают некорректно, поэтому оптимизация производительности рендеринга имеет решающее значение!
Пользователи сегодняшней сети ожидают, что страницы, которые они посещают, будут интерактивными и плавными, и именно на этом вам нужно уделять больше времени и усилий. Страницы должны не просто быстро загружаться, но и быстро реагировать на действия пользователя на протяжении всего своего жизненного цикла. Фактически, именно этот аспект пользовательского опыта и является тем, что измеряет метрика «Взаимодействие с следующей отрисовкой» (INP) . Хороший INP означает, что страница последовательно и надежно реагировала на потребности пользователя.
Хотя основным компонентом того, что делает страницу быстрой, является количество JavaScript, который вы выполняете в ответ на взаимодействие с пользователем, пользователи ожидают визуальных изменений в пользовательском интерфейсе. Визуальные изменения пользовательского интерфейса являются результатом нескольких типов работы, часто называемых рендерингом , и эта работа должна происходить как можно быстрее, чтобы пользовательский опыт казался быстрым и надежным.
Чтобы писать страницы, которые быстро реагируют на взаимодействие с пользователем, вам необходимо понимать, как HTML, JavaScript и CSS обрабатываются браузером, и гарантировать, что код, который вы пишете, а также любой другой сторонний код, который вы включаете, работает так же эффективно. насколько это возможно.
Примечание о частоте обновления устройства
Большинство современных устройств обновляют свои экраны 60 раз в секунду . Каждое обновление создает визуальный результат, который вы видите, и обычно называется фреймом . В следующем видео продемонстрирована концепция фреймов:
Хотя экран устройства всегда обновляется с постоянной частотой, приложения, работающие на устройстве, не всегда могут создавать достаточно кадров, чтобы соответствовать этой частоте обновления. Например, если выполняется анимация или переход, браузер должен соответствовать частоте обновления устройства, чтобы создавать один кадр при каждом обновлении экрана.
Учитывая, что типичный дисплей обновляется 60 раз в секунду, небольшой математический расчет покажет, что у браузера есть 16,66 миллисекунды для создания каждого кадра. В действительности, однако, у браузера есть свои собственные накладные расходы на каждый кадр, поэтому вся ваша работа должна быть завершена в течение 10 миллисекунд . Если вы не уложитесь в этот бюджет, частота кадров падает, а содержимое страницы на экране дрожит. Это явление часто называют джанком .
Однако ваши цели меняются в зависимости от типа работы, которую вы пытаетесь выполнить. Соблюдение порога в 10 миллисекунд имеет решающее значение для анимации , где объекты на экране интерполируются по серии кадров между двумя точками. Когда дело доходит до дискретных изменений в пользовательском интерфейсе — то есть перехода от одного состояния к другому без какого-либо движения между ними — рекомендуется добиваться таких изменений в сроки, которые кажутся пользователю мгновенными. В подобных случаях часто упоминается цифра 100 миллисекунд, но «хороший» порог метрики INP составляет 200 миллисекунд или ниже, чтобы охватить более широкий спектр устройств с различными возможностями.
Каковы бы ни были ваши цели — будь то создание большого количества кадров, необходимых для анимации, чтобы избежать зависаний, или просто как можно более быстрое создание отдельных визуальных изменений в пользовательском интерфейсе — понимание того, как работает пиксельный конвейер браузера, имеет важное значение для вашей работы.
Пиксельный конвейер
Есть пять основных областей, о которых вам необходимо знать и помнить в своей работе веб-разработчику. Эти пять областей — это те, над которыми вы имеете наибольший контроль, и каждая представляет собой ключевую точку в конвейере передачи пикселей на экран:
- JavaScript: JavaScript обычно используется для выполнения работы, которая приводит к визуальным изменениям пользовательского интерфейса. Например, это может быть функция
animatejQuery, сортировка набора данных или добавление элементов DOM на страницу. Однако JavaScript не является строго необходимым для запуска визуальных изменений: CSS-анимация , CSS-переходы и API веб-анимации способны анимировать содержимое страницы. - Расчеты стиля: это процесс определения того, какие правила CSS применяются к каким элементам HTML на основе соответствующих селекторов. Например,
.headline— это пример селектора CSS, который применяется к любому элементу HTML со значением атрибутаclass, который содержит классheadline. После того как правила известны, они применяются и рассчитываются окончательные стили для каждого элемента. - Макет: как только браузер узнает, какие правила применяются к элементу, он может начать рассчитывать геометрию страницы, например, сколько места занимают элементы и где они появляются на экране. Модель макета Интернета означает, что один элемент может влиять на другие. Например, ширина элемента
<body>обычно влияет на размеры его дочерних элементов вверх и вниз по дереву, поэтому этот процесс может быть весьма сложным для браузера. - Краска: Живопись — это процесс заполнения пикселей. Он включает в себя рисование текста, цветов, изображений, границ, теней и, по сути, каждого визуального аспекта элементов после расчета их расположения на странице. Рисунок обычно выполняется на нескольких поверхностях, часто называемых слоями.
- Составной: поскольку части страницы потенциально могут быть нарисованы на нескольких слоях, их необходимо применить к экрану в правильном порядке, чтобы страница отображалась должным образом. Это особенно важно для элементов, которые перекрывают другие, поскольку ошибка может привести к тому, что один элемент будет неправильно отображаться поверх другого.
Каждая из этих частей пиксельного конвейера предоставляет возможность внести рывки в анимацию или задержать отрисовку кадров даже при отдельных визуальных изменениях в пользовательском интерфейсе. Поэтому важно точно понимать, какие части конвейера запускает ваш код, и выяснить, можете ли вы ограничить свои изменения только теми частями пиксельного конвейера, которые необходимы для их рендеринга.
Возможно, вы слышали термин «растрировать», используемый в сочетании с «рисовать». Это потому, что рисование — это на самом деле две задачи:
- Создание списка вызовов отрисовки.
- Заполнение пикселей.
Последнее называется «растеризацией», поэтому всякий раз, когда вы видите записи рисования в DevTools, вам следует думать об этом как о включении растеризации. В некоторых архитектурах создание списка вызовов отрисовки и растеризация выполняются в разных потоках, но это не находится под вашим контролем как разработчика.
Вам не обязательно всегда касаться каждой части конвейера в каждом кадре. Фактически, при внесении визуальных изменений конвейер обычно работает тремя способами: с помощью JavaScript, CSS или API веб-анимации.
1. JS/CSS > Стиль > Макет > Краска > Композитный
Если вы измените свойство «макета», например такое, которое меняет геометрию элемента, например ширину, высоту или его положение (например, свойства CSS left или top ), браузеру необходимо проверить все остальные элементы и «перекомпоновать» страницу. . Любые затронутые области необходимо будет перекрасить, а окончательные окрашенные элементы необходимо будет скомпоновать обратно.
2. JS/CSS > Стиль > Краска > Композитный
Если вы изменили свойство «только рисование» для элемента в CSS — например, такие свойства, как background-image , color или box-shadow — шаг макета не требуется для фиксации визуального обновления на странице. Пропуская этап компоновки (там, где это возможно), вы избегаете потенциально дорогостоящей работы по компоновке, которая в противном случае могла бы привести к значительной задержке при создании следующего кадра.
3. JS/CSS > Стиль > Композитный
Если вы измените свойство, которое не требует ни макета, ни рисования, браузер может сразу перейти к этапу композиции. Это самый дешевый и наиболее желательный путь через пиксельный конвейер для точек повышенного давления в жизненном цикле страницы, таких как анимация или прокрутка. Интересный факт: Chromium оптимизирует прокрутку страницы так, что она происходит, где это возможно, исключительно в потоке компоновщика. Это означает, что даже если страница не отвечает, вы все равно можете прокручивать страницу и видеть ее части, которые ранее были прорисованы. экран.
Веб-производительность — это искусство избегать работы, максимально повышая эффективность любой необходимой работы. Во многих случаях речь идет о работе с браузером, а не против него. Стоит иметь в виду, что работа, ранее показанная в конвейере, отличается с точки зрения вычислительных затрат; некоторые задачи по своей сути дороже других!
Давайте углубимся в различные части конвейера. Мы рассмотрим распространенные проблемы, а также способы их диагностики и устранения.
Оптимизация рендеринга браузера
Производительность важна для пользователей, и для создания хорошего пользовательского опыта веб-разработчикам необходимо создавать веб-сайты, которые быстро реагируют на взаимодействия с пользователем и плавно отображаются. Эксперт по производительности Пол Льюис здесь, чтобы помочь вам устранить помехи и создать веб-приложения, поддерживающие производительность 60 кадров в секунду. Вы покинете этот курс с инструментами, необходимыми для профилирования приложений и выявления причин неоптимальной производительности рендеринга. Вы также изучите конвейер рендеринга браузера и обнаружите закономерности, которые упрощают создание быстрых веб-сайтов, которыми пользователи будут с удовольствием пользоваться.
Это бесплатный курс, предлагаемый Udacity , и вы можете пройти его в любое время .