Введение в веб-производительность и критический путь воспроизведения

vvedenie v veb proizvoditelnost i kriticheskij put vosproizvedeniya?v=1656618381

от Сибилл Зель

zHywuV7QGFtv6ctwrcFsDHv15AjK9utkdJHk
Фото Криса Ливерани на Unsplash

Большинство из нас каждый день работает с Интернетом. Для нас стало нормально получать всю необходимую информацию почти мгновенно. Но как эта веб-страница действительно собрана и доставлена ​​к нам – немного загадка.

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

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

Критический путь воспроизводства

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

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

Критический путь визуализации состоит из пяти разных шагов, которые лучше всего объяснять на графике.

ecrsi9JGRA-uLZxs1ojHe4eJmyig79eJr3Dj
Различные этапы критического пути воспроизведения (DOM и CSSOM ссылаются на модель объекта документа и модель объекта CSS соответственно)

Создание DOM и CSSOM

Большинство веб-страниц включают HTML, CSS и JavaScript, которые являются важной частью CRP. Чтобы прочитать и обработать ваш HTML, браузер создаст объектную модель документа (DOM). Браузер рассматривает HTML-теги (

,

,

и

и т.д.) в вашей разметке и превращает их в маркеры, которые, в свою очередь, параллельно создаются в узлы. Обрабатывая эти маркеры StartTag и EndTag в порядке и видя, что появится первым, браузер может установить их иерархию и установить родителей и детей.

Однако пусть эта терминология вас не пугает. Представьте DOM как большое дерево с ветвями, представляющими родительские узлы, и которые, в свою очередь, содержат листья, дочерние узлы. Это дерево будет представлять зависимости узлов в нашем HTML и выглядит несколько похоже на это:

N9bQMLisw9BAWK3bzjrrSILJx0rtabPFKKVg
Взято из школ W3 ( — Дерево объектов DOM

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

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

После создания DOM ваш браузер обработает CSS и построит объектную модель CSS (CSSOM). Этот процесс очень похож на создание DOM. Но в этом процессе, в отличие от предыдущего, дочерние узлы наследуют правила стиля своих родительских узлов – отсюда и название Cascading Style Sheets (CSS).

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

Наше дерево DOM и CSSOM будет содержать все узлы и зависимости, которые мы имеем на нашей странице.

Собрать все видимое содержимое – дерево визуализации.

Браузер должен знать, какие узлы действительно визуально представлять на странице. Дерево визуализации достигает именно этого и является репрезентацией видимый содержимое DOM и CSSOM.

Мы начинаем конструировать дерево визуализации, определяя корневой узел, а затем копируя все видимый информация по DOM и CSSOM. Для этого мы также проверяем, ищем ли теги, имеющие одинаковый селектор. Метаданные, ссылки и т.п. нет скопированы в дерево визуализации. То же касается CSS, который содержит «display: none;» поскольку это тоже невидимый элемент.

Как только мы завершим этот процесс, мы получим нечто подобное ниже (обратите внимание, как «веб-производительность» не копируется).

xTIwe6nvSWmROHLXZzTuOgOoS3Unzt8ccFGS
Авторские права на изображение принадлежат Google и Илье Григорику — взяты с https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction

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

Правильно подогнать – макет

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

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

Раскрасьте пиксели

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

KB1AjGRrtg1jv-2wn5Xz2sThlNBZt0vokPXt
Выполнение всех шагов CRP по порядку. (Фото ALP STUDIO на Unsplash)

Подведем итоги

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

  1. Веб-браузер начинается с создания DOM путем анализа всего соответствующего HTML.
  2. Затем он переходит к просмотру ресурсов CSS и JavaScript и спрашивает их, что обычно происходит в уме, куда мы обычно размещаем наши внешние ссылки.
  3. Затем браузер анализирует CSS и создает CSSOM, а затем запускает JavaScript.
  4. Затем DOM и CSSOM объединяются в дерево визуализации.
  5. Затем мы запускаем шаг макета и рисования, чтобы представить страницу пользователю.

Ладно, это хорошо знать, но почему это имеет значение?

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

Да мы делаем!

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

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

Но, к счастью, есть несколько способов обойти это, и мы можем сделать наши страницы быстрее!

4enXiRx7lUm5Rn7vJjC23ZDoQAaxMeFvdtDZ
Фото Питера Фингера на Unsplash

Оптимизация производительности

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

Когда мы говорим о стратегиях оптимизации, мы располагаем примерно тремя методами.

Минимизация, сжатие и кэширование

Все эти методы применимы к нашему HTML, CSS и JS. Затем, благодаря меньшему размеру, они снизят объем данных, которые мы отправляем между клиентом и сервером. Чем меньше байтов мы должны отправить, тем быстрее браузер получит данные и начнет обрабатывать и отображать страницу.

Сведите к минимуму использование блокирующих визуализацию ресурсов (CSS)

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

Однако мы можем смягчить большие файлы CSS, разблокировав визуализацию для определенных стилей и окон просмотра. Мы делаем это, используя правила печати в наших медиа-запросах, аналитике и ориентации устройства (если вы хотите знать, как я предлагаю вам ознакомиться с ресурсами ниже). Кроме того, мы можем уменьшить количество ресурсов, которые необходимо загрузить, вставив некоторые наши CSS при определенных обстоятельствах.

Сведите к минимуму использование ресурсов, блокирующих анализатор (парсер документов JS)

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

Так широко говоря, это дает нам 3 модели оптимизации:

  1. Минимизируйте количество байтов, которые вы отправляете
  2. Уменьшите количество критических ресурсов в критическом пути визуализации (возможно, не придется загружать аналитику в самом начале при создании страницы)
  3. Сократите важную длину пути визуализации (имеется в виду уменьшение количества обратной связи между вашим браузером и сервером, которое нужно нам для воспроизведения страницы)

Попробуйте сами

Если вы хотите попробовать это и начать оптимизацию, можно измерить эффективность своего веб-сайта или других с помощью ряда инструментов. Самые простые, пожалуй, продукты Google, такие как PageSpeedInsights или Google Lighthouse, удобное маленькое расширение Google Chrome, которое можно легко установить через Chrome App Store.

Просто нажмите на расширение, а затем создайте отчет, и вы получите отчет, содержащий следующее:

lyyGO2zINP098lQZ3h12kXIs4rR44zIjVhxt
Пример аудита эффективности в Google Lighthouse на моем личном веб-сайте — блокировка рендеринга CSS для двух разных наборов пиктограмм означает, что мой сайт снижает производительность (я бесспорно думаю, как снизить это в дальнейшем)

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

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

Вывод

Надеемся, это пролило свет на внутреннюю работу того, как ваш браузер отображает вам страницу, и тяжелую работу, которую ему нужно проделать в фоновом режиме, чтобы убедиться, что ваши HTML, CSS и JavaScript трансформируются правильно.

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

Ресурсы

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

  1. Оптимизация производительности сайта на Udacity
  2. Почему производительность имеет значение на Google Developers
  3. Высокопроизводительная сеть браузера Илья Григорик (https://hpbn.co/)
  4. Высокопроизводительные веб-сайты: необходимые знания для инженеров по интерфейсу Стив Соудерс

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *