что такое прогрессивный рендеринг
Прогрессивный рендеринг для лучшей производительности веб-приложений
Понимание концепций рендера веб-страниц и измерение производительности рендера с помощью Chrome DevTools
Не важно, насколько хорош ваш сайт; если его загрузка занимает слишком много времени, никто не будет ждать, чтобы его увидеть. Если ваш сайт загружается более 3 секунд, есть большая вероятность, что вы потеряете часть посетителей. Но знаете ли вы, что можно значительно улучшить время загрузки своего веб-приложения, используя прогрессивный рендеринг? Прогрессивный рендеринг не только увеличивает скорость загрузки, но и решает некоторые серьёзные проблемы в методах рендеринга на стороне клиента и на стороне сервера. Чтобы лучше понять прогрессивный рендеринг, давайте посмотрим, как работает рендеринг на стороне клиента и на стороне сервера.
Рендеринг на стороне клиента
Рендеринг на стороне клиента (CSR) – это метод, при котором контент рендерится в браузере с помощью JavaScript. Вместо того чтобы получать весь контент из самого HTML-файла, сервер отправляет HTML с пустым body и тегами script, в которых содержатся ссылки на JavaScript-бандлы, с помощью которых браузер будет рендерить контент. Теперь давайте посмотрим, как происходит рендеринг страницы на стороне клиента:
CSR имеет небольшое преимущество благодаря кэшированию загруженных JS-бандлов и статического HTML, поэтому навигация между страницами становится очень быстрой. Однако в CSR контент начинает загружаться только после выполнения всего JavaScript-бандла, а пользователям приходится сидеть сложа руки, просто наблюдая за пустым экраном без понимания, что происходит. По мере увеличения размера бандла пользователям придется ждать всё больше и больше, прежде чем они увидят что-нибудь осмысленное или начнут использовать страницу. Но что, если мы сможем рендерить контент независимо от JS-бандла? Здесь на помощь приходит рендеринг на стороне сервера (SSR)!
Рендеринг на стороне сервера
При рендеринге на стороне сервера HTML-код рендерится на сервере и отправляется клиенту. Контент, который нам нужно отобразить на экране, становится доступен сразу после анализа HTML; следовательно, первичный рендеринг контента происходит быстрее, чем у CSR. Теперь давайте разберёмся, как работает SSR:
Хотя мы и получаем быструю отрисовку контента, страница не будет интерактивной, пока мы не загрузим и не выполним JS.
Мы можем справиться с недостатками CSR с помощью SSR. Но остаются другие серьёзные недостатки, такие как рендеринг критического и некритического контента перед его отправкой клиенту. Я знаю, о чём вы сейчас думаете. Есть ли подход, в котором мы можем объединить оба упомянутых метода, верно? У меня есть хорошие новости для вас! Используя прогрессивный рендеринг, вы объедините преимущества CSR и SSR. Теперь давайте посмотрим, как мы можем сделать впечатления ваших клиентов приятнее с помощью техники прогрессивного рендеринга.
Прогрессивный рендеринг на стороне сервера
«Прогрессивный рендеринг на стороне сервера: ключом к ускорению веб-страницы является метод последовательного рендеринга частей веб-страницы на стороне сервера и отправки их клиенту по частям, не дожидаясь, пока будет отрисована вся страница».
Прогрессивный рендеринг на стороне сервера (PSSR) основан на концепции потоковой передачи HTML. PSSR разбивает страницы на осмысленные компоненты с помощью разделения кода. Эти части страницы управляются разными скриптами, и теперь у нас есть возможность сделать гидратацию независимо. Давайте посмотрим, как работает PSSR:
Критические этапы рендеринга
Оптимизация критических этапов рендеринга относится к приоритизации расположения контента, который связан с текущей деятельностью пользователя. Браузер выполняет много негласной работы, чтобы впечатления от работы со страницей были приятнее. Критические этапы рендеринга – это непосредственные шаги между получением HTML, CSS и JS и обработкой, необходимой для их преобразования в видимые пиксели.
Вы можете сократить время первичного рендеринга вашего веб-приложения, оптимизировав критические этапы рендеринга
Поскольку теперь у вас есть хорошее понимание клиентского, серверного и прогрессивного рендеринга, вы, наверное, думаете, есть ли способ оценить производительность рендеринга. Ответ – есть! Chrome DevTools предоставляет отдельную вкладку для мониторинга и оценки производительности рендеринга. Давайте посмотрим, как мы можем её использовать.
Анализ производительности с помощью Chrome DevTools
Даже в небольшом приложении под капотом выполняется много рендеринга. Вкладку «Rendering» в Chrome DevTools можно использовать для выявления проблем, связанных с рендерингом в JavaScript приложениях.
Инструмент Paint flashing
По мере того как интерфейс становится более многофункциональным и сложным, жизненно важно рассмотреть способы оптимизации взаимодействия с пользователем за счёт уменьшения как времени загрузки, так и критического пути компонентов. Рендер контента на экране – один из самых дорогостоящих процессов. Чтобы визуализировать этот процесс, можно использовать удобный инструмент Paint Flashing, доступный на вкладке «Rendering».
Текущие области рендеринга будут подсвечены зелёным цветом, если эта опция включена в Chrome. Если вы видите области, которые вы не планировали рендерить, можно копнуть немного глубже.
Scrolling performance issues в Chrome DevTools
Scrolling performance issues – это ещё один удобный инструмент, который вы можете использовать для выявления любых проблем, связанных с производительностью во время прокрутки страницы. Когда эта опция включена, она вешает на компоненты метку «Repaints on scroll» и подсвечивает зелёным цветом те компоненты, которые рендерятся при прокрутке страницы.
Отслеживая такие проблемы с производительностью, вы сможете гарантировать, что ваше веб-приложение даёт вашим пользователям наилучшие впечатления.
Заключение
При разработке веб-приложения очень важно понимать основные принципы рендеринга. Эти знания помогут вам оптимизировать производительность вашей веб-страницы. По статистике, задержка загрузки страницы на одну секунду снизит ваш коэффициент конверсии на 7 %. С другой стороны, длительная загрузка может оказать разрушительное влияние на конверсию приложения. В этой статье я рассказала о трёх методах рендеринга и объяснила, почему прогрессивный рендеринг на стороне сервера имеет больше преимуществ по сравнению с двумя другими методами, а также как он помогает повысить производительность вашего веб-приложения.
3 способа рендеринга больших списков в Angular
В 2020 году фронтенд-фреймворки стали лучше, эффективнее и быстрее. Но, даже учитывая это, рендеринг больших списков без «замораживания» браузера всё ещё может оказаться сложной задачей даже для самых быстрых из существующих фреймворков.
Это — один из тех случаев, когда «фреймворк является быстрым, а код — медленным».
Существует множество подходов, позволяющих выводить большое количество элементов, не блокируя взаимодействие пользователя с веб-страницей.
Автор статьи, перевод которой мы сегодня публикуем, хочет исследовать существующие способы вывода больших списков на веб-страницах и поговорить о сферах их применения.
Хотя этот материал направлен на Angular, то, о чём здесь пойдёт речь, применимо к другим фреймворкам и к проектам, которые написаны на чистом JavaScript. В частности, здесь будут рассмотрены следующие подходы к рендерингу больших списков:
Виртуальный скроллинг
Виртуальный скроллинг — это, возможно, самый эффективный способ работы с большими списками. Правда, у него есть и некоторые недостатки. Виртуальный скроллинг, благодаря Angular CDK и другим плагинам, очень легко реализовать в любом компоненте.
Идея, лежащая в основе виртуального скроллинга, проста, но реализовать его не всегда легко. Суть тут заключается в том, что у нас имеется контейнер и список элементов. Элемент рендерится только в том случае, если он находится в пределах видимой области контейнера.
Воспользуемся модулем scrolling из Angular CDK, который предназначен для организации виртуального скроллинга. Для этого сначала нужно установить CDK:
Затем нужно импортировать модуль:
После этого в компонентах можно использовать cdk-virtual-scroll-viewport :
Вот пример проекта, в котором используется такой подход к организации виртуального скроллинга.
Как видите, стандартные механизмы Angular позволяют, без особых сложностей, достичь впечатляющих результатов. Компонент в примере без каких-либо проблем рендерит многие тысячи элементов.
Если виртуальный скроллинг так хорош, и если его так легко реализовать, возникает вопрос о том, зачем заниматься изучением других способов рендеринга больших списков. Меня этот вопрос тоже интересовал. Как оказалось, у такого положения дел есть несколько причин:
Ручной рендеринг
У нас имеется простой шаблон, в котором используется цикл, организуемый с помощью директивы * ngFor
Для измерения производительности рендеринга 10000 простых элементов я воспользовался бенчмарком, основанным на js-frameworks-benchmark.
Исследование производительности списка, при выводе которого используется *ngFor
Элементы списка можно рендерить вручную, воспользовавшись API Angular:
Поговорим о том, как изменился код контроллера.
Мы объявили шаблон и контейнер:
При формировании данных мы рендерим их с использованием метода createEmbeddedView сущности ViewContainerRef :
В результате показатели, характеризующие производительность списка, удалось немного улучшить. А именно — на выполнение кода ушло 734 мс., на рендеринг — 1443 мс., на рисование — 2 мс.
Исследование производительности списка, при выводе которого используется API Angular
Правда, на практике это означает, что список всё ещё работает крайне медленно. При нажатии на соответствующую кнопку браузер «замерзает» на несколько секунд. Если бы такое появилось в продакшне, пользователям это точно не понравилось бы.
Вот как это выглядит (тут я, с помощью мыши, имитирую индикатор загрузки ).
Медленная работа списка
Теперь, чтобы улучшить показатели ручного рендеринга списка, попытаемся применить технологию прогрессивного рендеринга.
Прогрессивный рендеринг
Идея прогрессивного рендеринга проста. Она заключается в том, чтобы отрендерить подмножество элементов прогрессивно, отложив в цикле событий рендеринг других элементов. Это позволяет браузеру вывести все элементы без «подтормаживаний».
Код, приведённый ниже, реализующий прогрессивный рендеринг списка, устроен совсем несложно:
Измерив производительность этого решения, я получил результаты, которые выглядят хуже, чем те, что получал раньше. Выполнение кода — 907 мс., рендеринг — 2555 мс., рисование — 16 мс.
Исследование производительности списка, при выводе которого используется прогрессивный рендеринг
Но вот пользователь, работая с таким списком, испытает куда более приятные ощущения, чем раньше. Хотя время, необходимое на рендеринг списка, увеличилось, пользователь этого не заметит. Мы, за один заход, рендерим 500 элементов. При этом рендеринг выполняется за пределами границ контейнера.
Тут могут возникнуть некоторые проблемы, связанные с тем, что в ходе рендеринга контейнер меняет размеры, или с тем, что меняется позиция скроллинга содержимого. Если это случится — с подобными проблемами придётся бороться.
Вот как выглядит работа с таким списком.
Список работает быстро
Итоги
Методики ручного и прогрессивного рендеринга больших списков, безусловно, полезны в некоторых ситуациях. Я использовал их в тех случаях, когда виртуальный скроллинг по каким-то причинам мне не подходил.
Учитывая вышесказанное, можно сказать, что чаще всего виртуальный скроллинг, построенный на базе хорошей библиотеки, вроде Angular CDK, это — лучший способ вывода больших списков. Но если виртуальным скроллингом почему-то воспользоваться нельзя — у разработчика есть и другие возможности.
Уважаемые читатели! Как вы выполняете вывод больших списков в своих веб-проектах?
Руководство для прохождения интервью по фронтенду
Хочешь проверить свои знания по фронтенду?
Подпишись на наш канал с тестами по HTML/CSS/JS в Telegram!
Что это такое?
В отличие от типичного собеседования с разработчиками ПО, на собеседованиях фронтенд-разработчиков меньше внимания уделяется алгоритмам. Большая часть вопросов касается специфичных знаний и компетенций в таких областях, как HTML, CSS, JavaScript.
Несмотря на то, что существуют ресурсы, призванные помочь в подготовке к собеседованию, они сильно отличаются по полноте материалов от тех же ресурсов для разработчиков ПО. Среди того, что существует на сегодняшний день, наиболее полезным может быть сборник вопросов Front-end Developer Interview Questions. К сожалению, на многие вопросы я не смог найти в сети полные и удовлетворяющие ответы. Поэтому в документе ниже я постарался самостоятельно ответить на них. Будучи открытым репозиторием, этот проект может жить и развиваться благодаря сообществу, поскольку интернет эволюционирует.
Нужна более общая подготовка?
Вас может заинтересовать Tech Interview Handbook, в котором содержится информация для прохождения общих технических интервью, в частности описаны алгоритмы, даны ответы на вопросы по софт-скиллс. Также есть Interview Cheatsheet!
Вопросы по HTML
Ответы на вопросы из списка Front-end Job Interview Questions — HTML Questions. Комментарии с предложениями по улучшению и дополнению приветствуются!
Что делает DOCTYPE?
— это сокращение от « document type» (тип документа). Он объявляется в HTML для того, чтобы различать стандартный режим или режим совместимости ( quirks mode). Его наличие говорит браузеру работать со страницей в стандартном режиме.
Мораль истории — просто добавляй в начало страницы.
Ссылки
Как поддерживать страницу на нескольких языках?
Вопрос немного расплывчатый. Полагаю, что речь о наиболее частом случае: как поддерживать страницу с содержимым на нескольких языках, где одновременно должен отображаться только один язык.
Ссылки
На что обратить внимание при разработке мультиязычных сайтов?
Ссылки
Для чего отлично подойдут data-атрибуты?
Ссылки
Представьте HTML5 как открытую веб-платформу. Из каких блоков состоит HTML5?
Ссылки
Объясните разницу между cookie, sessionStorage и localStorage.
Все вышеупомянутые технологии являются механизмами хранения типа ключ-значение на клиентской стороне. Они могут хранить данные только как строки.
Прогрессивный рендеринг для повышения производительности веб-приложений
Дата публикации: 2021-02-22
От автора: неважно, насколько хорош ваш сайт; если загрузка занимает слишком много времени, никто не будет ждать, чтобы увидеть его. Если ваш сайт загружается более 3 секунд, велика вероятность, что вы потеряете почти половину посетителей.
Но знаете ли вы, что вы можете значительно улучшить время загрузки страницы своего веб-приложения, используя прогрессивный рендеринг?
Прогрессивный рендеринг не только увеличил скорость загрузки страницы, но также решил некоторые серьезные проблемы в методах рендеринга на стороне клиента и на стороне сервера. Чтобы лучше понять прогрессивный рендеринг, давайте посмотрим, как работает рендеринг на стороне клиента и на стороне сервера.
Рендеринг на стороне клиента
Рендеринг на стороне клиента или CSR — это метод, при котором контент отображается в браузере с использованием JavaScript. Вместо того, чтобы получать все содержимое из самого файла HTML, сервер отправляет HTML с пустыми тегами body и тегами скриптов, включая пакеты JavaScript в head, через которые браузер может отображать содержимое.
Теперь давайте посмотрим, как происходит рендеринг страницы на стороне клиента:
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Когда пользователь переходит на веб-страницу, запускается первоначальный запрос на получение HTML-документа.
Сервер отправляет HTML-код с тегами сценария для загрузки пакета JS с пустым телом.
Браузер анализирует HTML и делает HTTP-запросы для получения пакета JS. Пользователь видит только частичное содержимое оболочки HTML, либо пустую страницу, либо индикатор загрузки.
Только после того, как основной пакет JS получен и визуализирован, пользователь видит реальный, значимый контент.
В CSR после загрузки начального JS содержимое может загружаться асинхронно. Мы можем сначала загрузить критический контент, а потом некритический.
CSR может принести пользу пользователям, кэшируя первоначально загруженные пакеты JS и статический HTML-код в браузере, поэтому навигация между страницами становится очень быстрой.
Однако в CSR содержимое начинает загружаться только после завершения выполнения всего пакета JavaScript. А до тех пор пользователи должны сидеть утомившись, просто смотреть на пустой экран без обновлений о том, что происходит.
По мере увеличения размера пакета пользователям придется ждать все больше и больше, прежде чем они увидят что-нибудь значимое или начнут использовать страницу.
Что, если мы сможем отображать контент в браузере независимо от пакета JS? Здесь на помощь приходит рендеринг на стороне сервера!
Рендеринг на стороне сервера
При рендеринге на стороне сервера полный HTML-код отображается на сервере и отправляется клиенту. Контент, который нам нужно отображать на экране, становится доступен сразу после анализа HTML; следовательно, первая отрисовка контента загружается быстрее, чем CSR.
Теперь разберемся, как работает SSR:
Браузер запрашивает HTML с сервера.
Сервер делает запросы API и отображает HTML-контент.
Скомпилированный HTML-код затем отправляется в браузер.
Как только браузер загружает и анализирует HTML, веб-приложение становится доступным для конечного пользователя, не дожидаясь загрузки пакетов JS.
Затем браузер загружает и запускает пакеты JS, чтобы сделать страницу интерактивной.
Поскольку API-интерфейсы обычно размещаются на сервере, а исходный JavaScript не блокирует контент, в SSR исходный контент загружается очень быстро.
В SSR, хотя мы получаем быструю первую отрисовку содержимого, страница не является интерактивной, пока мы не загрузим пакеты JS и не выполним их в браузере.
Мы действительно можем преодолеть недостатки CSR с помощью SSR. Но все же, есть некоторые серьезные недостатки, такие как рендеринг как критического, так и некритического контента перед его отправкой клиенту.
Я знаю, о чем вы сейчас думаете. Как здорово, если есть подход, в котором мы можем смешать обе упомянутые выше техники, верно? У меня есть хорошие новости для вас! Используя прогрессивный рендеринг, вы можете объединить преимущества как CSR, так и SSR.
Теперь давайте рассмотрим, как мы можем улучшить взаимодействие с пользователем, используя технику прогрессивного рендеринга.
Прогрессивный рендеринг на стороне сервера
«Прогрессивный рендеринг на стороне сервера — ключом к ускорению веб-страницы является метод последовательного рендеринга частей веб-страницы на стороне сервера и отправки их клиенту по частям, не дожидаясь, пока будет отрисована вся страница».
Прогрессивный рендеринг на стороне сервера (PSSR) основан на концепции HTML streaming. PSSR разбивает страницы на значимые компоненты с помощью разделения кода. Эти части страницы управляются отдельным скриптом, и теперь у нас есть возможность гидратировать их независимо на основе некоторого приоритета, который мы определили ранее.
Давайте быстро посмотрим, как работает PSSR:
Браузер запрашивает у сервера HTML-код.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Сервер делает запросы API и сначала обрабатывает критический контент, а затем отправляет его клиенту.
Браузер анализирует HTML и рисует его на экране.
Сервер отображает некритический контент и передает его браузеру.
Затем браузер анализирует и отрисовывает некритичный контент.
Между тем, пакеты JS загружаются и выполняются в фоновом режиме, а браузер передает интерактивность элементам DOM.
PSSR повышает производительность вашего веб-приложения за счет параллельной выборки и рендеринга компонентов страницы. Этот подход известен как метод прогрессивной гидратации. Этот метод прогрессивной гидратации приводит к:
Задержке гидратации компонента до тех пор, пока он не появится в поле зрения или не понадобится для взаимодействия с пользователем.
Загрузке контента при взаимодействии с пользователем (прокрутка) — намного быстрее, чем CSR и SSR
Улучшению TTI, как показывает тестирование.
Лучшему пользовательскому опыту даже в медленных сетях.
В дополнение к этому вы можете использовать подход критического пути рендеринга с PSSR, чтобы еще больше оптимизировать производительность вашего приложения.
Критический путь рендеринга
Оптимизация критического пути рендеринга относится к приоритизации дисплеев контента, которые связаны с текущей деятельностью пользователя. Браузер выполняет много негласной работы, чтобы предоставить пользователю быстрый доступ в Интернет. Критический рендеринг — это непосредственные шаги между получением байтов HTML, CSS и JS и обработкой, необходимой для их преобразования в визуализированные пиксели.
Оптимизация критического пути рендеринга
Вы можете сократить время для первого рендеринга своего веб-приложения, оптимизировав критический путь рендеринга.
Поскольку теперь у вас есть хорошее представление о клиентском, серверном и прогрессивном рендеринге, вы должны думать, что есть способ оценить эти характеристики рендеринга. Ответ ДА!
Chrome DevTools предоставляет отдельную вкладку для мониторинга и оценки производительности рендеринга, и давайте посмотрим, как мы можем ее использовать.
Анализ производительности с помощью Chrome DevTools
Даже в небольшом приложении под капотом выполняется множество действий, связанных с рендерингом. Вкладку «Рендеринг» в Chrome DevTools можно использовать для выявления проблем, связанных с рендерингом, в приложениях JavaScript.
По мере того как интерфейс становится более многофункциональным и сложным, жизненно важно рассмотреть способы оптимизации взаимодействия с пользователем за счет уменьшения времени загрузки и оптимизации критического пути компонентов. Отрисовка пикселей на экране — один из самых дорогостоящих процессов. Вы можете использовать Paint Flashing, удобный инструмент, доступный во вкладке Rendering Chrome DevTools, чтобы визуализировать его.
Параметр «Paint flashing» на вкладке «Визуализация»
На экране будут зеленые квадраты вокруг текущих областей рендеринга, эта опция включена в Chrome. Если вы видите места, которые не планировали красить, можете копнуть немного дальше.
Paint Flashing на домашней странице Medium
Проблемы с производительностью прокрутки в DevTools — еще один удобный инструмент, который можно использовать для выявления любых проблем, связанных с производительностью прокрутки. Когда этот параметр выбран, отображается метка «Перерисовывает при прокрутке» и выделяется зеленым цветом то, что отображается при прокрутке.
Проблема с производительностью прокрутки на главной странице Dribble
Отслеживая подобные проблемы с производительностью, вы можете быть уверены, что ваше веб-приложение предоставляет пользователям наилучшие возможности.
Заключение
При разработке веб-приложения понимание основных концепций того, как работает его отрисовка, поможет вам оптимизировать производительность веб-страницы.
Согласно статистике, задержка загрузки страницы в одну секунду снизит коэффициент конверсии на 7%. С другой стороны, длительное время загрузки может иметь разрушительное влияние на коэффициент конверсии приложения.
В этой статье я упомянула три метода рендеринга и объяснила, почему прогрессивный рендеринг на стороне сервера имеет больше преимуществ по сравнению с двумя другими методами и как он помогает повысить производительность вашего веб-приложения. Спасибо за внимание!
Автор: Nethmi Wijesinghe
Редакция: Команда webformyself.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Освойте востребованные навыки дизайн и верстки
Комплексный процесс дизайна и верстки на примере лендинга!