This is a longer description about your blog. 2025-04-13T00:00:00Z https://example.com/ Your Name 2025-04-13T00:00:00Z https://example.com/blog/frontend-perf-manifest/ <p>TL;DR: frontendperf.ru - блог о фронтенд‑производительности. Буду показывать, как измерять скорость, находить узкие места, приоритизировать задачи и объяснять бизнесу, зачем это нужно. Обещаю практические разборы, чек‑листы и кейсы “было/стало”</p> <p>Подписывайтесь на <a href="https://t.me/frontendperf">Telegram: https://t.me/frontendperf</a></p> <h2 id="prelyudiya">Прелюдия</h2> <p>Привет, дорогой читатель!</p> <p>У меня стойкое ощущение, что наши девайсы не успевают за темпом технологий. В эру коротких роликов и ИИ человек становится всё нетерпеливее: даже секунда ожидания уже ощущается как “ну камон”</p> <p>Но если честно, ожидание — это ещё полбеды. Больше всего меня бесят фризы и неотзывчивость интерфейса. Недавно поймал себя на том, что сайт ChatGPT на моём iPhone 14 ощутимо лагает: дропает кадры, скролл дергается, клики как будто “не сразу”. И в этот момент у меня только одно желание — закрыть вкладку</p> <p>И тут включается разработчик внутри: “Окей, я же могу на это влиять. Не на ChatGPT, конечно, но у себя в продукте — точно могу… ведь, да?”</p> <p>Стоп.</p> <p>А вы видели этот Performance tab?</p> <picture><source type="image/avif" srcset="https://example.com/blog/frontend-perf-manifest/usQK6TVCYL-1626.avif 1626w"><source type="image/webp" srcset="https://example.com/blog/frontend-perf-manifest/usQK6TVCYL-1626.webp 1626w"><img loading="lazy" decoding="async" src="https://example.com/blog/frontend-perf-manifest/usQK6TVCYL-1626.png" alt="монструозный performance devtools tab" width="1626" height="1186"></picture> <p>Выглядит монструозно. Куда смотреть? Что вообще считается проблемой? Как понять, что именно тормозит?</p> <p>А потом приходит реальность: “Оп, а продуктовые задачи делать когда? Сейчас нет времени. Не приоритет”</p> <p>И так — по кругу</p> <h3 id="pochemu-proizvoditelnost-vazhna">Почему производительность важна</h3> <p>Если посмотреть на данные httparchive.org, видно, что количество JS, которое мы отдаём на страницу, <b>растёт год к году</b>:</p> <ul> <li>2018: ~380KB median (gzipped)</li> <li>2021: ~450KB median</li> <li>2023: ~500KB median</li> <li>2026: ~580KB median</li> </ul> <p>Это логично: бизнес растёт → появляются новые фичи → растёт код “Давайте добавим клипы в ленту, чтобы вырос таймспент” — звучит вполне рационально</p> <p>Проблема в другом: не каждый пользователь может (и должен) покупать новый флагманский смартфон или обновлять ПК каждый год, чтобы наш свежий JS и новые фичи не просаживали текущий уровень производительности</p> <p>А терпеливее пользователи не становятся. Скорее наоборот: ожидания растут, а толерантность к лагам падает</p> <h3 id="pochemu-eto-slozhno">Почему это сложно</h3> <p>Перформанс почти всегда сложнее, чем кажется со стороны. Потому что:</p> <ul> <li>Диагностика фрустрирует. Открываешь DevTools, видишь графики, таймлайны, flame chart — и не понимаешь, что из этого “норма”, а что “пожар”</li> <li>Сложно доказать эффект. “Мы ускорили” — это не ощущение. Нужны метрики, сравнения, контроль условий, понимание, что именно изменилось</li> <li>Нужны знания о браузере. Main thread, layout, paint, compositing, network, cache, приоритеты ресурсов — всё это внезапно становится важным</li> <li>Это не выглядит срочным для бизнеса. В моменте перформанс часто воспринимается как техдолг: “давайте потом”. Но чтобы “потом” вообще наступило, нужно сначала: найти проблему → описать → оценить → приоритизировать → доказать, что фикс помог и ничего не сломал</li> </ul> <p>И вот тут обычно всё и застревает</p> <h3 id="o-chem-ya-budu-rasskazyvat-v-bloge">О чем я буду рассказывать в блоге</h3> <p>Мне платят за разработку сайтов уже больше 6 лет и продолжают это делать. Больше половины своего пути я работаю в крупной компании. Я пришел в эпоху реакт уже захватил мир, от поддержки Internet Explorer начали отказываться, продукт еще не парится о производительности, но разработчики уже начали задумываться</p> <p>Вы читаете этот текст в блоге, собранном с помощью 11ty. В это же время кто-то сидит ковыряет бету новой версии solidjs, кто-то смотрит что такое Speculation Rules и как бы его можно было применить в своих проектах. Короче, разработчики думают и <b>хотят</b> сделать лучше</p> <p>Вопрос только как</p> <h2 id="manifest">Манифест</h2> <p>Моя цель с frontendperf.ru простая:</p> <ul> <li>показать, что перформанс — это интересно и часто проще, чем кажется</li> <li>научить работать со “страшными” инструментами (да, включая Performance tab)</li> <li>объяснить, где тут деньги и почему бизнесу это реально надо</li> </ul> <p>В блоге будет:</p> <ul> <li>как мерить и почему это важно (RUM, Web Vitals)</li> <li>как читать Performance tab без боли</li> <li>кейсы “было/стало”</li> <li>чек-листы и приоритизация</li> <li>про перф в React/Solid/SSR/картинках/шрифтах</li> </ul> <p>Если вам это откликается и интересно, то подписывайтесь на <a href="https://t.me/frontendperf">мой Телеграм канал</a></p>