Кто пишет
Привет! Я Максим, фронтенд-разработчик. Пишу про производительность фронтенда и помогаю её улучшать.
Я пришёл в профессию, когда React уже стал стандартом, поддержку Internet Explorer начали сворачивать, а производительность чаще обсуждали разработчики, чем продукт. С тех пор многое изменилось: появились Core Web Vitals, полевые данные стали доступны каждому, а скорость стала метрикой, которую можно связать с деньгами.
Почему сайты становятся медленнее
Интерфейсы всё чаще подтормаживают даже на хороших устройствах: при скролле пропадают кадры, кнопки отвечают с задержкой, вёрстка прыгает при загрузке.
Одна из причин хорошо видна в данных. По Web Almanac 2024 от HTTP Archive, медианная мобильная страница загружает 558 КБ JavaScript. В 2019 году было 359 КБ — рост больше чем в полтора раза за пять лет. При этом около 200 КБ из этого объёма на медианной странице не используется вовсе.
Логика понятна: бизнес растёт, появляются новые фичи, растёт код. Но пользователи не обновляют телефоны каждый год, а терпения у них не прибавляется. Каждая новая фича, добавленная без оглядки на производительность, понемногу съедает запас скорости.
Почему этим сложно заниматься
Производительность редко становится приоритетом, и причины обычно одни и те же.
Сложно начать диагностику. Вкладка Performance в DevTools выглядит перегруженной: таймлайны, flame chart, десятки треков. Без опыта непонятно, куда смотреть и что из этого — проблема.
Сложно доказать эффект. «Стало быстрее» — это ощущение. Чтобы аргументировать изменения, нужны метрики, сравнение до и после, контроль условий и понимание, какое изменение что дало.
Нужно знать, как работает браузер. Главный поток, layout, paint, композитинг, приоритеты загрузки, кэш — без этого трудно понять, почему страница тормозит.
Это не выглядит срочным. Производительность часто воспринимается как техдолг, который можно отложить. Чтобы до неё дошли руки, проблему нужно найти, описать, оценить, приоритизировать и потом доказать, что исправление помогло и ничего не сломало.
О чём этот блог
Хочу показать, что скорость можно измерить, что она связана с деньгами и что чинить её часто проще, чем кажется.
Статьи сгруппированы по темам:
- LCP — как быстро появляется главный контент первого экрана;
- INP — насколько быстро интерфейс отвечает на клики и ввод;
- CLS — почему контент прыгает и как это остановить;
- TTFB — время ответа сервера, кэширование и CDN;
- Измерения — RUM, CrUX, web-vitals.js и чтение Performance-панели.
Помимо статей, здесь будут кейсы «было/стало», чек-листы, разборы реальных сайтов и перф-индекс рунета — рейтинг скорости крупнейших интернет-магазинов, сервисов доставки и маркетплейсов по полевым данным Chrome.
В статьях будут такие вставки — с аргументами для продукта и бизнеса:
Для кого
Для фронтенд-разработчиков, которые хотят разобраться в производительности глубже Lighthouse. Для тимлидов, которым нужно встроить скорость в процессы и защищать её перед продуктом. И для владельцев и продакт-менеджеров интернет-магазинов, которым важно понимать, сколько стоит медленный сайт.
Как следить за обновлениями
Новые статьи сначала появляются в Telegram-канале frontendperf, там же короткие разборы и дайджесты. Блог можно читать и через RSS-ленту.
Если нужна помощь с конкретным сайтом, посмотрите услуги и цены — начать можно с экспресс-аудита.