Прочитал интересную историю переезда с Angular на Preact от Джорджа Фу — "Optimizing for the mobile web: Moving from Angular to Preact".

У ребят было приложение с 200 тысячими строк. Время загрузки страницы на мобильных устройствах занимало до 11 секунд. Время старта приложения в режиме разработки — 3 минуты.

Команда решила, что с этим надо что-то делать и для начала избавилась от больших библиотек: moment, lodash и core-js. После этого начался перевод листовых Angular-компонентов. Для интеропа с ангуляром был использован специальный компонент "angular-preact-bridge". Это позволило не останавливать разработку и переводить проект на Preact постепенно. В процессе переезда им очень помогал TypeScript. После всей работы (в статье не говорится о количестве затраченного времени, но у них был дедлайн в 4 месяца), размер приложения уменьшился в два раза, время загрузки снизилось до 3-4 секунд.

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

#jsframeworks #experience #migration

https://bytes.grubhub.com/optimizing-for-the-mobile-web-moving-from-angular-to-preact-f09ca61ea27c#8f83

Ребята из Slack продолжают радовать статьями про своё новое приложение. В этот раз они написали про использование сервис воркеров в web-версии — "Service Workers at Slack: Our Quest for Faster Boot Times and Offline Support".

При первой загрузке приложения в кеш сервис воркера помещаются html, звуковые файлы, шрифты, js и css-файлы. Для того чтобы хранящиеся файлы не устаревали, кастомный плагин webpack формирует манифест, который встраивается в установочный код сервис воркера. Изменение кода сервис воркера инициирует его установку, в результате которой происходит загрузка всех файлов из манифеста и их сохранение в кеш. При таком подходе всегда будет загружаться не самая последняя версия клиента. Но на этот шаг пошли осознанно, чтобы сократить время загрузки клиента. Теперь приложение с прогретым кешом стартует в два раза быстрее. Чтобы приложение не устаревало, в фоне регулярно происходит проверка наличия обновлений.

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

Статья хорошая, но, скорее всего, будет интересна не всем.

#serviceworker #experience

https://slack.engineering/service-workers-at-slack-our-quest-for-faster-boot-times-and-offline-support-3492cf79c88

Недавно в блоге Gitlab появилась небольшая статья о том, почему было принято решение о переходе на ECharts для построения графиков — "Why we chose ECharts for data visualizations".

В Gitlab есть раздел с мониторингами приложения. Ранее для построения графиков в этом разделе использовался D3. От него решили отказаться, так как D3 был сложен в изучении и в конечном счёте не использовался на полную. От него лишь требовалась возможность отображения данных в виде графиков, поэтому ребята решили перейти на более специализированное решение. Выбирали между многими библиотеками, включая ECharts, Britecharts и Plotly. В итоге остановились на ECharts, потому что библиотека оказалась гибкой и достаточно производительной.

ECharts стартовал как open source проект Baidu, поэтому документация в основном написана на китайском языке. Не смотря на эту особенность экосистема вокруг проекта развивается, и проект используют не только в Китае, но и в других странах.

#experience #charts

https://about.gitlab.com/2019/09/30/why-we-chose-echarts/

Корри Хаус — известный спикер в React-сообществе — поделился своим пятилетним опытом работы с React — "Lessons learned from 5 years in React".

Документ содержит 63 пункта про работу с компонентами, JSX, про управление состоянием приложения, производительность, переиспользование компонентов и их тестирование. Есть пара пунктов, которые хочется выделить. Не используйте во всех компонентах без исключения useMemo, shouldComponentUpdate, PureComponent. Используйте их только там, где они нужны. Если бы их использование не несло дополнительные накладные расходы, они были бы включены по умолчанию. Если есть в этом смысл, используйте в своих компонентах имена, которые используются в Web-платформе (`onBlur`, onChange и т.п.). Используйте as как пропс для модификации типа верхнеуровневого элемента.

Есть в списке пара пунктов, которые у меня вызвали вопросы. Например, полный отказ от тестирования снепшотами. Вместо них Корри предлагает использовать Percy или Chromatic. Это очень жёсткая позиция. Проблема со снепшотами возникает только тогда, когда их очень много. Если для компонента создаётся один снепшот, то этого вполне достаточно для отлавливания непреднамеренного изменения кода.

Как бы то ни было, если вы работаете с React, очень рекомендую посмотреть документ.

#react #list #experience

https://www.dropbox.com/s/tsid5bnphznbvjv/

Разработчики портала Telegraph рассказали про свой опыт оптимизаций на фронтенде — "Improving third-party web performance at The Telegraph".

Основная особенность большинства новостных порталов — большое количество сторонних рекламодателей, код которых необходимо добавлять на страницу. В начале пути ускорения проекта разработчики поставили всем загружаемым скриптам атрибут defer, что позволило ускорить скорость отрисовки сайта на 3 секунды. Также пишут о том, что основная проблема при решении проблем с производительностью была не в технологиях, а в устоявшихся организационных процессах. В итоге они создали рабочую группу, куда пригласили участников со всех подразделений (маркетинг, коммерция, реклама). Собираются вместе два раза в месяц, где обсуждают проблемы производительности и ищут способы их решения.

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

#performance #experience

https://medium.com/the-telegraph-engineering/improving-third-party-web-performance-at-the-telegraph-a0a1000be5

Валерий Щавель из Яндекс.Карт рассказал на хабре про опыт использования WebAssembly — "Как мы внедряли WebAssembly в Яндекс.Картах и почему оставили JavaScript".

В Яндекс.Картах объекты перед отрисовкой разбивают на треугольники прямо в браузере. Это ресурсоёмкая задача, которую решили попробовать вынести на уровень WebAssembly. Ребята сделали прототип, который использует wasm, и внедрили его в своё TypeScript-приложение. Скорость обработки тайлов выросла в несколько раз, но появилась просадка из-за накладных расходов на передачу данных из wasm в js. Также вырос размер бандла (в комментариях пишут, что это скорее всего из-за неиспользуемых фич emscripten). В итоге от WebAssembly на данный момент решили отказаться.

Статья интересная. Советую почитать, если интересуетесь темой WebAssembly.

#webassembly #experience #yandex

https://habr.com/ru/company/yandex/blog/475382/

Недавно команда eBay рассказала про опыт оптимизации своего сайта и приложений. Эдди Османи сделал рекап статьи в форме советов, которые могут быть полезны для всех проектов — "Shopping for speed on eBay.com".

Для eBay увеличение производительности было основной инженерной инициативой в 2019 году. Она затронула все части проекта: фронтенд, бэкенд и нативные приложения. Вот, что мне показалось наиболее интересным. Каждое ускорение страницы результатов поиска на 100 мс увеличивало число отправленных в корзину товаров на полпроцента. Данные для сагестера раздаются с помощью CDN, для этого пришлось пожертвовать персонализацией подсказок. Очень изобретательно подошли к ускорению отображения содержимого above-the-fold. В архитектуре системы есть слой "Experience Services". Этот слой отвечает за быструю отдачу данных для сущностей, которые попадают во viewport устройства пользователя при инициализации страницы (для web) или view (для нативных приложений). Такое решение позволило отображать данные быстрее при открытии страницы. Контент ниже above-the-fold подгружается лениво или дополнительными чанками.

В статье есть много интересных решений. Рекомендую почитать.

#performance #experience

https://web.dev/shopping-for-speed-on-ebay/

Сегодня на хабре появилась статья Александра Воронянского про опыт модернизации фронта Маркета — "Как переписать фронтенд нагруженного проекта и не потерять главного".

Очень интересно было почитать статью, так как я непосредственно участвовал в описанных событиях. Изначально Маркет работал на xml-based технологиях. Серверная часть фронтенда обслуживалась xscript — технологией Яндекса, практически вышедшей из употребления в компании. Представьте, что если бы вы писали node.js приложение, но с помощью xml со вставками на JavaScript. Примерно так выглядела работа с xscript. Сейчас серверный фронт работает на Node.js, на клиенте используется React.

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

В общем, интересная и полезная статья. Почитайте, если у вас планируется что-то подобное.

#yandex #experience #migration

https://habr.com/ru/company/yandex/blog/486146/