Валерий Шибанов написал статью про то, как он участвовал в конкурсе телеграма — "Как я не занял первое место в конкурсе для JavaScript-разработчиков от Telegram".

По условиям конкурса надо было написать быструю и компактную библиотеку отрисовки графиков. Существующие библиотеки использовать не разрешалось.

Для решения задачи автор выбирал между canvas и SVG. В итоге остановился на canvas, так как он даёт больше возможностей для оптимизаций. На первом этапе конкурса Валерий не занял призового места из-за проблем с производительностью. На втором этапе, где предлагалось добавить к существующему решению дополнительные виды графиков, автор поработал над оптимизацией. В предыдущем решении были использованы html-элементы, для управления областью просмотра графиков. Они располагались над canvas, и это снижало производительность прорисовки. В итоге он их убрал. Ещё была закеширована миникарта и исправлена не очень плавная анимация. После всех улучшений удалось занять 4-ое место.

Респектую автору и поздравляю с призовым местом.

#contest #rendering #svg #canvas

https://habr.com/ru/company/lanit/blog/460625/

Вчера на сайте web.dev Фил Волтон из Google опубликовал статью, посвящённую Largest Contentful Paint, — новому API, с помощью которого можно получить наиболее точное время появления основного содержимого сайта.

Необходимость в новом API возникла из-за того, что существующее событие DOMContentLoaded не всегда соответствует появлению содержимому, которое можно считать полезным. First Paint и First Contentful Paint тоже не очень хорошие кандидаты для получения времени, так как они отражают начало рендеринга. Метрики First Meaningful Paint и Speed Index, которые рекомендовались ранее, часто некорректно говорят про время отображения основного контента.

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

Для определения этого события предназначено API Largest Contentful Paint (LCP). Так как при загрузке страницы контент может меняться, браузер отправляет PerformanceEntry c типом largest-contentful-paint при каждом появлении нового большого элемента. Отправка метрики прекращается, после того как пользователь начинает взаимодействовать со страницей. Время самого последнего отправленного события является нужным значением.

Largest Contentful Paint доступен в Chrome 77. В этой версии также стал доступен Element Timing API, на базе которого построен LCP. С помощью него можно узнать время появления конкретных элементов на странице.

#web #performance #rendering #chrome

https://web.dev/largest-contentful-paint

После прочтения статьи "Responsible JavaScript" я рефлексировал на тему того, что было бы здорово иметь такой источник информации, в котором бы детально разбирались типы рендеринга и то как они влияют на метрики производительности web-приложений. Сегодня увидел твит от Эдди Османи, в котором он поделился ссылкой на статью, посвящённой этой теме — "Rendering on the Web".

В статье разбираются все виды рендеринга страниц: Server Rendering, SSR, SSR with Rehydration, CSR with Prerendering, Full CSR. Даётся оценка того, как они влияют на метрики приложения и даются советы, в каком случае лучше использовать тот или иной подход. Например, авторы статьи не рекомендуют использовать SSR с гидрированием, так как метрики производительности, собранные с реальных сайтов, использующих этот подход, говорят не в его пользу. Из статьи я впервые узнал про "Trisomorphic Rendering". Это такой подход, когда для рендеринга страниц используются сервис воркеры.

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

#performance #web #rendering

https://developers.google.com/web/updates/2019/02/rendering-on-the-web#top_of_page

Прочитал статью, в которой ребята из Miro поделились опытом работы с текстами в canvas — "Как мы учились рисовать тексты на Canvas".

Во время переезда Miro с Flash на JavaScript + Canvas появилась проблема при работе с текстами. Надо было бесшовно отображать текст и мини-редактор. Первое решение использовало foreignObject из svg. С его помощью можно "положить" любой html внутрь svg в качестве изображения. От этого решения пришлось отказаться, когда появилось новое требование — необходимо было добавить поддержку разных шрифтов. Как пишет автор, была проблема с тем, что происходила загрузка шрифтов для каждой внедряемой картинки. В итоге им пришлось реализовать свою библиотеку для отрисовки текста на canvas. На небольших объёмах текста библиотека работает быстрее решения с foreignObject. Похоже, что библиотека не open source, так как никаких ссылок на код не нашёл.

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

#rendering #canvas

https://habr.com/ru/company/miro/blog/458624/

Алексис Бинжесснер — инженер из команды Firefox — опубликовала пост про особенности рендеринга теста — "Text Rendering Hates You".

Процесс рендеринга текста непростая вещь: надо учитывать разные сценарии отрисовки шрифтов на разных системах, отключать стилизацию для эмоджи, правильно применять стили к лигатурам, делать фоллбек на системный шрифт, если запрашиваемых глифов нет в используемом шрифте и т.п. Чтобы текст выглядет хорошо (не на retina-дисплеях), надо использовать алгоритмы сглаживания (антиалиасинг), но не забывать его отключать в определённых ситуациях. Например, при субпиксельном сглаживании браузеры отслеживают анимацию текста и отключают антиалиасинг, иначе при движении глифы будут трястись.

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

#internals #rendering

https://gankra.github.io/blah/text-hates-you/#emoji-broke-color-and-style

Сурма написал статью про новое расширение ResizeObserver, с помощью которого можно получить размер элемента в физических пикселях — "Pixel-perfect rendering with devicePixelContentBox".

Иногда возникают ситуации, в которых размеры блока в пикселях могут получаться дробными. При рендеринге таких элементов CSS-пиксели "подгоняются" браузером к физическим пикселями с помощью pixel snapping. Проблема в том, что не было надёжного способа получения размера элемента в реальных физических пикселях. Из-за этого невозможно было реализовать pixel-perfect отрисовку в canvas — изображения могли получаться нечёткими, на них мог проявляться эффект Муара.

В Chrome 84 была добавлена новая опция ResizeObserver ['device-pixel-content-box']. С её помощью можно получить размер любого элемента в физических пикселях и добиться pixel-perfect рендернига canvas.

#rendering #api

https://web.dev/device-pixel-content-box/

Мэт Перри — автор библиотеки Framer Motion — рассказал о том, в каких случаях браузеры могут троттлить requestAnimationFrame — "Browsers may throttle requestAnimationFrame".

Метод requestAnimationFrame (rAF) — самый главный инструмент для создания плавных анимаций, контролируемых js-кодом. Мэт столкнулся с тем, что в Safari на iOS на двух одинаковых смартфонах, одна и та же анимация в одном случае работала в 30fps, а в другом 60fps. Проблема оказалась в том, что Safari включает троттлинг rAF в режиме сохранения энергии. Также Safari троттлит rAF в iframe'ах с контентом сторонних доменов.

Троттлинг rAF есть и в Firefox, но в нём он ограничивается из-за вопросов безопасности. Для отключения троттлинга сайт должен отправлять HTTP-заголовки: Cross-Origin-Opener-Policy: same-origin и Cross-Origin-Embedder-Policy: require-corp.

#rendering #js

https://mattperry.is/writing-code/browsers-may-throttle-requestanimationframe-to-30fps

Производительность рендеринга в браузерах

Мэт Перри — автор библиотек Framer Motion и Moion One — рассказал про особенности и трудности создания плавных анимаций.

Плавные анимации достигаются за счёт оптимизации рендеринга и использования аппаратного ускорения. При оптимизации рендеринга нужно учитывать, что некоторые свойства приводят к перерасчёту раскладки страницы. Но если эти свойства используются в изолированном контексте, например, с position: absolute, то вполне можно достичь 60 fps. В сети можно найти список этих свойств (CSS Triggers), но он долгое время не обновлялся. Так например, обработка SVG и CSS-свойства filter в Firefox и Chrome уже выносится на GPU, а в Chrome скоро появится поддержка ускорения анимаций clip-path и background-color.

Все браузеры для анимаций используют аппаратное ускорение. В Safari оно реализовано с помощью системной библиотеки Core Animation. Она несовместима с Web Animation API, из-за чего в некоторых случаях ускорение может отключаться.

Полезная статья. Рекомендую почитать всем, кто интересуется темой производительности рендеринга.

#performance #rendering

https://motion.dev/guides/performance