Да будет frontendperf.ru
TL;DR: frontendperf.ru - блог о фронтенд‑производительности. Буду показывать, как измерять скорость, находить узкие места, приоритизировать задачи и объяснять бизнесу, зачем это нужно. Обещаю практические разборы, чек‑листы и кейсы “было/стало”
Подписывайтесь на Telegram: https://t.me/frontendperf
Прелюдия
Привет, дорогой читатель!
У меня стойкое ощущение, что наши девайсы не успевают за темпом технологий. В эру коротких роликов и ИИ человек становится всё нетерпеливее: даже секунда ожидания уже ощущается как “ну камон”
Но если честно, ожидание — это ещё полбеды. Больше всего меня бесят фризы и неотзывчивость интерфейса. Недавно поймал себя на том, что сайт ChatGPT на моём iPhone 14 ощутимо лагает: дропает кадры, скролл дергается, клики как будто “не сразу”. И в этот момент у меня только одно желание — закрыть вкладку
И тут включается разработчик внутри: “Окей, я же могу на это влиять. Не на ChatGPT, конечно, но у себя в продукте — точно могу… ведь, да?”
Стоп.
А вы видели этот Performance tab?
Выглядит монструозно. Куда смотреть? Что вообще считается проблемой? Как понять, что именно тормозит?
А потом приходит реальность: “Оп, а продуктовые задачи делать когда? Сейчас нет времени. Не приоритет”
И так — по кругу
Почему производительность важна
Если посмотреть на данные httparchive.org, видно, что количество JS, которое мы отдаём на страницу, растёт год к году:
- 2018: ~380KB median (gzipped)
- 2021: ~450KB median
- 2023: ~500KB median
- 2026: ~580KB median
Это логично: бизнес растёт → появляются новые фичи → растёт код “Давайте добавим клипы в ленту, чтобы вырос таймспент” — звучит вполне рационально
Проблема в другом: не каждый пользователь может (и должен) покупать новый флагманский смартфон или обновлять ПК каждый год, чтобы наш свежий JS и новые фичи не просаживали текущий уровень производительности
А терпеливее пользователи не становятся. Скорее наоборот: ожидания растут, а толерантность к лагам падает
Почему это сложно
Перформанс почти всегда сложнее, чем кажется со стороны. Потому что:
- Диагностика фрустрирует. Открываешь DevTools, видишь графики, таймлайны, flame chart — и не понимаешь, что из этого “норма”, а что “пожар”
- Сложно доказать эффект. “Мы ускорили” — это не ощущение. Нужны метрики, сравнения, контроль условий, понимание, что именно изменилось
- Нужны знания о браузере. Main thread, layout, paint, compositing, network, cache, приоритеты ресурсов — всё это внезапно становится важным
- Это не выглядит срочным для бизнеса. В моменте перформанс часто воспринимается как техдолг: “давайте потом”. Но чтобы “потом” вообще наступило, нужно сначала: найти проблему → описать → оценить → приоритизировать → доказать, что фикс помог и ничего не сломал
И вот тут обычно всё и застревает
О чем я буду рассказывать в блоге
Мне платят за разработку сайтов уже больше 6 лет и продолжают это делать. Больше половины своего пути я работаю в крупной компании. Я пришел в эпоху реакт уже захватил мир, от поддержки Internet Explorer начали отказываться, продукт еще не парится о производительности, но разработчики уже начали задумываться
Вы читаете этот текст в блоге, собранном с помощью 11ty. В это же время кто-то сидит ковыряет бету новой версии solidjs, кто-то смотрит что такое Speculation Rules и как бы его можно было применить в своих проектах. Короче, разработчики думают и хотят сделать лучше
Вопрос только как
Манифест
Моя цель с frontendperf.ru простая:
- показать, что перформанс — это интересно и часто проще, чем кажется
- научить работать со “страшными” инструментами (да, включая Performance tab)
- объяснить, где тут деньги и почему бизнесу это реально надо
В блоге будет:
- как мерить и почему это важно (RUM, Web Vitals)
- как читать Performance tab без боли
- кейсы “было/стало”
- чек-листы и приоритизация
- про перф в React/Solid/SSR/картинках/шрифтах
Если вам это откликается и интересно, то подписывайтесь на мой Телеграм канал