что такое прогрессивный рендеринг

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, это — лучший способ вывода больших списков. Но если виртуальным скроллингом почему-то воспользоваться нельзя — у разработчика есть и другие возможности.

Уважаемые читатели! Как вы выполняете вывод больших списков в своих веб-проектах?

Источник

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

Понимание концепций рендера веб-страниц и измерение производительности рендера с помощью 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 %. С другой стороны, длительная загрузка может оказать разрушительное влияние на конверсию приложения. В этой статье я рассказала о трёх методах рендеринга и объяснила, почему прогрессивный рендеринг на стороне сервера имеет больше преимуществ по сравнению с двумя другими методами, а также как он помогает повысить производительность вашего веб-приложения.

Источник

Прогрессивный JPEG: новый best practice

С точки зрения пропускной способности канала, изображения — обжоры. В среднем, они занимают наибольший (62%) средний трафик сайтов и чаще всего их передача является узким местом. Загружаясь, изображения рвут страницу, расталкивая другие элементы вокруг и вызывая неуклюжую перерисовку (прим. перев.: от этого, конечно, можно избавиться определенной версткой, но тогда нужно хардкодить или ограничивать размеры картинок). Загрузка изображения на странице воспринимается или как «тик, тик, тик, тик, тик, готово», или же сначала вообще ничего нет, а потом внезапно «бум!» и оно появляется ниоткуда. Все понимают, что подразумевается под «тик, тик, готово» и «бум» и всех нас это немного раздражает, потому что мы чувствуем, сколько времени наших прелестных и коротких жизней потеряно в ожидании загрузки картинок.

Упущенная возможность

Фотографии — главный виновник медленного рендеринга. Они являются наиболее часто запрашиваемым типом изображений и в среднем весят больше остальных. В них миллионы цветов и количество бит на пиксель продолжает увеличиваться. Они красивы и мы не хотим компромиссов на качестве.

Оптимизированные для веба фото — это jpeg, а jpeg делится на два типа: базовый последовательный (baseline) и прогрессивный (progressive). Последовательный jpeg — это один скан изображения сверху вниз в полном разрешении, а прогрессивный jpeg — это серия сканов улучшающегося качества. Так они и рендерятся — последовательный jpeg отрисовывается сверху вниз («тик, тик, тик, …»), а прогрессивный быстро размечает свою территорию и затем совершенствуется (по крайней мере так задумано).

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

В локальном эксперименте — иллюстрация в начале поста — на задушенном канале, 80-килобайтный прогрессивный jpeg появляется на странице раньше, чем 5-килобайтный последовательный jpeg (то же самое изображение, уменьшенное в размере) в Firefox под Windows, что должно произвести впечатление. Конечно, на первом проходе прогрессивный jpeg имеет низкое разрешение, но он содержит столько же информации, сколько и маленькое изображение, или даже больше. А если масштаб страницы уменьшен, например, на мобильном устройстве, то низкое разрешение даже не заметно. Адаптивные изображения работают на нас прямо сейчас (прим. перев.: отсылка к responsive web design)!

По существу, прогрессивный jpeg лучше. Так какой же самый распространенный тип jpeg в сети? Угадали: последовательный, и с очень большим отрывом. В выборке из тысячи изображений, 92.6% — последовательные.

Не беспокойтесь, нам всего лишь нужно объявить, что прогрессивный jpeg — это best practice и затащить остальной мир к нам на борт. Но чтобы сделать такое объявление, нужно быть в нем уверенным. А для этого сначала необходимо понять, как сегодня обстоят дела с поддержкой прогрессивного jpeg браузерами.

Проверка реальностью №1

Прогрессивные jpeg отрисовываются во всех браузерах, об этом не стоит переживать. Нас волнует то, как они отрисовываются.

Поведение прогрессивных jpeg в браузерах

Результаты разочаровывающие, но в целом, доля рынка браузеров с прогрессивной отрисовкой прогрессивных jpeg идет вверх. Поддержка пока что составляет около 65% (Chrome + Firefox + IE9).

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

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

Проверка реальностью №2

Вы можете спросить «А не будут ли прогрессивные jpeg весить больше, чем обычные? Не платим ли мы за “слои”?». С некотороыми другими типами многослойных изображений — платим, но не с jpeg. Прогрессивный jpeg обычно на несколько килобайт меньше, чем его же последовательная версия. Стоян Стефанов в процессе построения графика конвертации 10000 случайных последовательных jpeg в прогрессивные, открыл ценное практическое правило: файлы больше 10Кб, чаще всего, будут весить меньше в прогрессивном варианте.

Убеждать стало бы проще, если бы можно было сказать, что прогрессивные jpeg всегда весят меньше, так что их и нужно всегда использовать. Стоян нам в этом помогает. Он говорит: «Еще одно наблюдение по поводу правила 10Кб: в тех случаях, когда вес последовательного jpeg меньше, он меньше с небольшой разницей. А когда меньше прогрессивный, то он обычно меньше намного. Так что говорить, что нужно всегда использовать прогрессивный и станет лучше — это нормально».

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

Причиной того, что последовательные jpeg наиболее распространены в сети, является, без сомнения, то, что инструменты оптимизации изображений создают их по умолчанию. Однако, все просмотренные мною — Photoshop, Fireworks, ImageMagick, jpegtran — имеют возможность сохранения и в прогрессивном варианте. Таким образом, чтобы отдавать прогрессивные jpeg, нужно сознательно модифицировать свой процесс оптимизации изображений.

Например, Smushit может переводить последовательные jpeg в прогрессивные. Smushit, кстати, можно запускать из командной строки и интегрировать в процесс оптимизации изображений.

Проверка реальностью №3

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

Лишние вычисления — недостаток, но не камень преткновения. Предоставление фотографий на слабом аппаратном обеспечении — сложная задача вне зависимости от этого. Я в курсе дела, потому что пишу приложение-фотогалерею с бесконечным скроллингом и оно падает на iPad’e. При обработке большого количества изображений на мобильных платформах сложные задачи возникнут в любом случае.

Как видно в таблице, мобильный Safari не отрисовывает прогрессивные jpeg прогрессивно и вероятно потому, что они нагружают ЦПУ. Прогрессивый jpeg не является новым форматом изображений. Следовательно, осознанно и без причин не поддерживать прогрессивный jpeg — не вариант для браузеров, даже для мобильных. Будем надеяться, что скоро мобильные браузеры станут справляться с прогрессивным рендерингом, но причины текущего отсутствия поддержки имеют смысл. Очень обидно, потому что как раз на мобильных устройствах прирост скорости и экономия в размерах файлов, которые предоставляет прогрессивный jpeg, пришлись бы очень кстати. Выше было упомянуто, что он как бы является решением для адаптивных изображений на данный момент. На самом деле он мог бы быть таковым, но время еще не пришло.

Глядя в будущее

Месяц назад, Google запрыгнул на борт со своим сервисом Mod_Pagespeed, сделав convert_jpeg_to_progressive основным фильтром. SPDY тоже не отстает, переводя jpeg более 10Кб в прогрессивные по умолчанию, согласно практическому правилу Стояна. Браузеры, поддерживающие инкрементальное отображение, от этого станут казаться намного быстрее. Как видно из таблицы выше, включающей Google Chrome, такие действия Google имеют смысл. Я не стану говорить, что если уж «не-причиняй-зла-делай-веб-быстрее» Гугл выбрал progressive jpeg как best practice, то и мы должны тем более. Но это лишнее подтверждение. И самое главное, это показывает, что прогрессивный jpeg — формат, который был в своего рода морозилке на протяжении десятилетия — начинает свое возвращение.

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

Источник

Рендеринг WEB-страницы: что об этом должен знать front-end разработчик

Приветствую вас, уважаемые хабравчане! Сегодня я бы хотел осветить вопрос рендеринга в веб-разработке. Конечно, на эту тему уже написано много статей, но, как мне показалась, вся информация довольно разрознена и отрывочна. По крайней мере, чтобы собрать всю картину в своей голове и осмыслить её, мне пришлось проанализировать немало информации (в основном — англоязычной). Именно поэтому я решил формализовать свои знания в статью, и поделиться результатом с сообществом Хабра. Думаю, информация будет полезна как начинающим веб-разработчикам, так и более опытным, чтобы освежить и структурировать свои знания.

Данное направление можно и нужно оптимизировать на этапе вёрстки/frontend-разработки, поскольку, очевидно, что разметка, стили и скрипты принимают в рендеринге непосредственное участие. Для этого соответствующие специалисты должны знать некоторые тонкости.

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

Процесс обработки WEB-страницы браузером

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

Repaint

Reflow

Если же изменения затрагивают содержимое, структуру документа, положение элементов — происходит reflow (или relayout). Причинами таких изменений обычно являются:

Оптимизация со стороны браузера

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

Ещё одна особенность — во время выполнения JavaScript браузеры кэшируют вносимые изменения, и применяют их в один проход по завершению работы блока кода. Например, в ходе выполнения данного кода произойдет только один reflow и repaint:

Однако, как описано выше, обращение к свойствам элементов вызовет принудительный reflow. То есть, если мы в приведённый блок кода добавим обращение к свойству элемента, это вызовет лишний reflow:

В итоге мы получим 2 reflow вместо одного. Поэтому, обращения к свойствам элементов по возможности нужно группировать в одном месте, дабы оптимизировать производительность (см. более подробный пример на JSBin).

Затем, попробуем реализовать задуманное следующим образом:

Данное решение не будет работать, как ожидается, т.к. изменения кэшируются и применяются только в конце блока кода. Нас выручит принудительный reflow, в результате код приобретёт следующий вид, и будет в точности выполнять поставленную задачу:

Практические советы по оптимизации

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

Надеюсь, каждый читатель извлёк из статьи что-нибудь полезное. В любом случае — спасибо за внимание!

UPD: Спасибо SelenIT2 и piumosso за верные замечания по поводу эффективности обработки CSS-селекторов.

Источник