Прогрессивный рендеринг для повышения производительности веб-приложений

Понимание концепций, лежащих в основе рендеринга страниц и измерение производительности рендеринга с помощью Chrome DevTools

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

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

Но знаете ли вы, что вы можете значительно сократить время загрузки страницы своего веб-приложения, используя прогрессивную визуализацию?

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

Отрисовка на стороне клиента

Рендеринг на стороне клиента или CSR - это метод, при котором контент отображается в браузере с использованием JavaScript. Вместо того, чтобы получать все содержимое из самого файла HTML, сервер отправляет HTML с пустым body и тегами сценария, включая пакеты JavaScript в head, через которые браузер может отображать содержимое самостоятельно.

Теперь давайте посмотрим, как происходит рендеринг страницы на стороне клиента:

1. Когда пользователь переходит на веб-страницу, запускается первоначальный запрос на получение HTML-документа.
2. Сервер отправляет HTML-код с тегами сценария для загрузки пакета JS с пустым телом.
3. Браузер анализирует HTML и отправляет HTTP-запросы для получения пакета JS. Пользователь видит только частичное содержимое оболочки HTML, либо пустую страницу, либо индикатор загрузки.
4. Только после того, как основной пакет JS получен и визуализирован, пользователь видит реальный, значимый контент.

В CSR после загрузки исходного JS контент можно загружать асинхронно. Мы можем сначала загрузить критический контент, а потом некритический.

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

Однако в CSR содержимое начинает загружаться только после завершения выполнения всего пакета JavaScript. А до тех пор пользователи должны сидеть сложа руки, просто глядя на пустой экран, не узнавая, что происходит.

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

Что, если мы сможем отображать контент в браузере вне зависимости от пакета JS? Здесь на помощь приходит рендеринг на стороне сервера!

Рендеринг на стороне сервера

При рендеринге на стороне сервера полный HTML-код отображается на сервере и отправляется клиенту. Контент, который нам нужно отобразить на экране, доступен сразу после анализа HTML; следовательно, первая отрисовка контента загружается быстрее, чем CSR.

Теперь давайте разберемся, как работает SSR:

1. Браузер запрашивает HTML с сервера.
2. Сервер делает запросы API и отображает HTML-контент на себе.
3. Скомпилированный HTML-код затем отправляется в браузер.
4. Как только браузер загружает и анализирует HTML, веб-приложение становится доступным для конечного пользователя, не дожидаясь загрузки пакетов JS.
5. Затем браузер загружает и выполняет пакеты JS, чтобы сделать страницу интерактивной.

Поскольку API-интерфейсы обычно расположены на сервере, а исходный JavaScript не блокирует контент, в SSR исходный контент загружается очень быстро.

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

Мы действительно можем преодолеть недостатки CSR с помощью SSR. Но все же есть некоторые серьезные недостатки, такие как рендеринг как критического, так и некритического контента перед его отправкой клиенту.

Я знаю, о чем вы сейчас думаете 😃 Как здорово, если есть подход, в котором мы можем смешать оба упомянутых выше метода, верно? У меня есть хорошие новости для вас! Используя прогрессивный рендеринг, вы можете объединить преимущества как CSR, так и SSR.

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

Прогрессивный рендеринг на стороне сервера

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

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

Давайте быстро посмотрим, как работает PSSR:

1. Браузер запрашивает у сервера HTML-код.
2. Сервер делает запросы API и сначала обрабатывает критический контент, а затем отправляет его клиенту.
3. Браузер анализирует HTML и рисует его на экране.
4. Сервер отображает некритический контент и передает его браузеру.
5. Затем браузер анализирует и закрашивает некритичный контент.
6. Тем временем пакеты JS загружаются и выполняются в фоновом режиме, а браузер передает интерактивность элементам DOM.

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

Этот метод прогрессивной гидратации приводит к:

• Отложите гидратацию компонента до тех пор, пока он не появится в поле зрения или не понадобится для взаимодействия с пользователем.
• Загружать контент при взаимодействии с пользователем (прокрутка) - намного быстрее, чем CSR и SSR
• Тестирование показывает, что это может улучшить TTI.
• Лучшее взаимодействие с пользователем даже в медленных сетях.

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

Критический путь рендеринга

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

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

Поскольку теперь у вас есть хорошее понимание клиентского, серверного и прогрессивного рендеринга, вы, должно быть, думаете, что есть способ оценить эти характеристики рендеринга. Ответ ДА ​​!!

В Chrome DevTools есть отдельная вкладка для мониторинга и оценки производительности рендеринга, и давайте посмотрим, как мы можем ее использовать.

Создавайте лучшие библиотеки компонентов и системы проектирования

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

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

Анализ производительности с помощью Chrome DevTools

Даже в небольшом приложении за сценой выполняется много рендеринга. Вкладку «Рендеринг» в Chrome DevTools можно использовать для выявления проблем, связанных с рендерингом, в приложениях JavaScript.

• Paint flashing Инструмент Chrome DevTool

По мере того, как интерфейс становится более многофункциональным и сложным, жизненно важно рассмотреть способы оптимизации взаимодействия с пользователем за счет увеличения как времени загрузки, так и критического пути компонентов. Раскрашивание пикселей на экране - один из самых дорогостоящих процессов. Вы можете использовать Paint Flashing, удобный инструмент, доступный на вкладке Chrome DevTools Rendering, чтобы визуализировать это.

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

• Scrolling performance issues в Chrome DevTools

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

Отслеживая подобные проблемы с производительностью, вы можете быть уверены, что ваше веб-приложение предоставляет пользователям наилучшие возможности.

Последние мысли

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

Согласно статистике, задержка в одну секунду во время загрузки страницы снизит ваш коэффициент конверсии на 7%.

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

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

Спасибо за чтение!! Не стесняйтесь сообщать мне свои мысли в разделе комментариев ниже 👇.

Учить больше