⚡️ А 8 ноября на HolyJS в Москве проведу воркшоп про то, как делать Реакт-приложения быстрее. Поговорим про профайлинг в девтулах Хрома и Реакта и подебажим медленные приложения вживую. Заходите :)

2 свежих статьи в блоге web.dev:
- Preloading responsive images — о фиче, появившейся в Chrome 73 и позволяющей ускорить загрузку сайта за счет предзагрузки изображений нужного размера
- Fixing layout instability — о том, как сократить время, которое требуется на сдвиг из-за асинхронного релэйаутинга

⁠📚 По мотивам лондонского доклада сделал репо с курируемой подборкой вебпак-тулов для перформанса.

В репо:
— Оптимизация JS, CSS, картинок и шрифтов
— Предзагрузка и script async/defer
— Сервис-воркеры и PWA
— Инструменты для анализа бандла

Мои два любимых инструмента оттуда — это purgecss-webpack-plugin, который умеет удалять из билда CSS, который нигде не используется; и Webpack Analyse, мощнейший официальный тул для анализа бандла, который помогает понять, как в бандле оказался какой-то странный модуль.

Короче, кайф, куча малоизвестных и клёвых штук.

➡️ https://github.com/iamakulov/awesome-webpack-perf

Поболтал с организаторами HolyJS про частые проблемы перформанса, плюсы от Google Developer Expert, новые браузерные фичи и чуть-чуть про жизнь: https://habr.com/ru/company/jugru/blog/472838/

​​У меня есть два любимых абсурдистских доклада о разработке: The Birth and Death of JavaScript и The Future of Programming. Оба смешные и не очень серьёзные, но натолкнули меня на новые мысли.

🎙 The Birth and Death of JavaScript — доклад об истории JS-а с 1995 по 2035 г.

JS — самый популярный язык программирования; его сделали для веба, но cейчас он используется в серверах, микроконтроллерах, куче других мест — и продолжает расти. Гэри Бернхардт выступает историком из 2035-го года и рассказывает, как JS развивался и повлиял на индустрию после появления asm.js и WebAssembly.

🎙 The Future of Programming — доклад о будущем разработки после 1970-х годов.

В 1960-х программирование пережило бурный всплеск идей и подходов. Тем не менее, мы всё равно продолжаем программировать так же, как в 1950-м — пишем инструкции в процедурах, сохраняем в текстовые файлы и выполняем в одном потоке. Брет Виктор размышляет, как выглядело бы программирование сегодня, если бы идеи 60-70-х годов завоевали популярность.

Рекомендую, короче.

​​Два небольших анонса.

💻 Во-первых, я переехал на мак и поэтому продаю любимый Lenovo Yoga 920, на котором год оптимизировал фронтенды.

Состояние 9/10, смогу отдать в Минске, Москве или Киеве (в декабре).
Детали и фотки: https://telegra.ph/Lenovo-Yoga-920-11-02
Писать мне — @iamakulov

🔍 Во-вторых, Илья Бирман ищет нового мейнтейнера в Лайкли (https://github.com/ilyabirman/Likely). Я помогал Илье разрабатывать Лайкли в 2016-17-м, но потом у меня закончилось время.

Лайкли — это клёвая возможность поработать с опенсорс-проектом со звёздочками и порешать реальные задачи реальных пользователей. Пишите Илье на почту ↓

Разыскивается мейнтейнер Лайкли

Лайкли — клёвые социокнопки.

Проект есть на Гитхабе, но сейчас остался без мейнтейнера. Три года его поддерживал Иван Акулов, но больше не может уделять этому время.

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

Кто хочет? Напишите мне письмо: ilyabirman@ilyabirman.ru.

Иван готов ввести в курс дела.

​​Клёвый пример, почему нельзя измерять рантайм-перформанс только через FPS (кадры в секунду) ↓

В гифке ниже все три круга вращаются с одинаковым средним FPS — 15 кадров в секунду. При этом левый вращается плавно, а правый постоянно зависает — в нём почти все кадры быстрее, но каждый шестой кадр длится 200 мс. Правый вариант гораздо неприятнее, чем левый, но FPS у них одинаковый.

Что делать с этим? Измерять (и оптимизировать) не только средний FPS, но и самые длинные кадры. Именно так делает Figma, из статьи которой эта гифка: https://www.figma.com/blog/figma-faster/

Одна из частых проблем с перформансом в Реакте — это когда компоненты ререндерятся слишком часто

(Из заметок с завтрашнего воркшопа на HolyJS)

Ещё одна частая перформанс-проблема в Реакт-приложениях — это тяжёлый DOM или стили

(Из заметок к воркшопу)

Наконец-то настоящий кейс-стади CSS-in-JS-библиотек и того, как они влияют на рантайм-производительность: https://calendar.perfplanet.com/2019/the-unseen-performance-costs-of-css-in-js-in-react-apps/

⁠Узнал про HTTP/2 connection coalescing — механизм, когда браузер подключается к нескольким доменам по одному и тому же соединению.

В эпоху HTTP/1 было популярно использовать domain sharding — загружать ресурсы с несколько доменов типа cdn1.website.comcdn1.website.com и cdn2.website.comcdn2.website.com, которые ссылались на один и тот же сервер. С HTTP/1 это помогало обойти лимит на количество подключений к серверу и загрузить сайт быстрее, но с HTTP/2 это, наоборот, стало вредить.

Connection coalescing — это то, как браузеры обходят ограничения domain sharding-а, переиспользуя одно и то же соединение для cdn1.website.comcdn1.website.com и cdn2.website.comcdn2.website.com. Вот как это работает на практике: https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/

Ещё две частые перформанс-проблемы с Реакт-приложениями:
— когда Реакт используется там, где не нужен
— и когда приложение навешивает тяжёлые обработчики событий

(Из заметок к воркшопу)

Филипп Валтон рассказывает, как он кеширует куски HTML-страниц с помощью сервис-воркеров:

— HTML-страницы на каждом сайте во многом похожи: одинаковый <head>, одинаковые шапка/футер
— Если научить сайт отдавать одинаковые <head>, шапку и т.д. отдельно от контента, их можно закешировать
— С закешированным началом страницы сервис-воркер сможет мгновенно отправлять его в ответ на все запросы. А браузер сможет мгновенно начать рендеринг. Основная часть страницы продолжит грузиться с сервера
— На сайте Филиппа такая оптимизация уменьшила First Contentful Paint вдвое

→ https://philipwalton.com/articles/smaller-html-payloads-with-service-workers/

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

«Quick apps in 3 steps» — четко и коротко про три штуки, которые помогают сделать приложение быстрее, если у вас на перформанс вообще нет времени → https://3perf.com/blog/perf-for-startups/

(Спойлер: Next.js, CDN и ревью зависимостей каждые 3-6 месяцев)

> Спойлер: ревью зависимостей каждые 3-6 месяцев

А вообще, раз мы про это — давайте поразвлекаемся:

1) Установите webpack-bundle-analyzer
2) Пришлите скриншот бандла в ответ на https://twitter.com/iamakulov/status/1223188926787178497
3) Я посмотрю, что можно улучшить, и отвечу!

Как подключать полифиллы

В личке спросили:
— Привет! Как сейчас решают проблему подключения полифиллов только в тех браузерах, где они нужны?

Начал отвечать сообщением, а получилась статья: https://3perf.com/blog/polyfills/

Тред! Самые частые проблемы в присланных бандлах — и как их чинить:

1) Дубликаты библиотек
Часто в бандл попадает несколько версий одной и той же библиотеки (обычно lodash или core-js) — из-за того, что её по-разному используют разные зависимости. Пример: