Рефакторинг и производительность вайбкодинг-проекта

Рефакторинг — изменение внутреннего устройства кода без изменения того, как продукт выглядит и работает снаружи. Пользователь получает тот же результат, а внутри структура становится понятнее и управляемее. Тебе не нужно уметь делать это руками. Полезно другое: узнавать момент, когда пора попросить об этом агента. Первый сигнал уже был в теме «Чтение и отладка кода агента»: огромный файл на сотни строк. Вот ещё несколько:

• Одно и то же приходится объяснять заново. Правка карточки товара требует править три разных места в коде, потому что похожий компонент скопировали, а не переиспользовали. Это верный признак, что пора вынести общую часть в одно место.
• Простые правки стали занимать больше времени. Раньше мелкое изменение решалось одним промптом. Теперь агент каждый раз задевает что-то соседнее, и приходится откатывать (тема «Чтение и отладка кода агента»). Часто это не вина агента, а симптом того, что структура вокруг стала слишком запутанной.
• Один и тот же визуальный паттерн выглядит слегка по-разному в разных местах. Одна и та же карточка или кнопка в разных частях продукта отличается на пиксель. Скорее всего, это не один переиспользуемый компонент, а несколько похожих копий, которые незаметно разошлись.

Делай рефакторинг теми же небольшими, проверяемыми шагами, что и любую правку (тема «Вайбкодинг: сайты», раздел «Когда результат не тот»). Один рефакторинг-проход за раз. Скриншот интерфейса до и после, чтобы убедиться: визуально ничего не изменилось, хотя внутри поменялось многое.

Пройдись по этому проекту и найди повторяющуюся логику или похожие компоненты, которые стоит вынести в переиспользуемые. Не меняй ничего в том, как выглядит и работает приложение — только внутреннюю структуру

Этот файл вырос слишком большим — разбей его на несколько логических файлов поменьше, сохранив поведение точно таким же. Покажи список того, что куда переехало

«Работает у меня быстро» — это ещё не метрика. У дизайнера обычно мощный компьютер и хороший интернет, а у части реальных пользователей нет. Прежде чем что-то оптимизировать, один раз измерь, что вообще происходит:

• Lighthouse — бесплатный инструмент аудита, встроенный в DevTools браузера Chrome (тема «Чтение и отладка кода агента»). Открываешь вкладку Lighthouse, запускаешь анализ и получаешь числовую оценку страницы вместе со списком конкретных находок: что именно её замедляет.
• Core Web Vitals — три конкретные метрики, которыми Google измеряет ощущение скорости у реальных пользователей. Первая — скорость появления главного контента на экране (LCP). Вторая — отзывчивость страницы на действия пользователя, клики, тапы и ввод, на протяжении всего визита (INP; в 2024 году эта метрика заменила прежний «отклик на первое взаимодействие», FID). INP в отчёте Lighthouse нет — она считается по реальным пользователям (PageSpeed Insights), в Lighthouse вместо неё TBT. Третья — насколько сильно элементы страницы «прыгают» во время загрузки (CLS). Запоминать точные названия не обязательно. Достаточно знать, что за обтекаемой фразой «страница ощущается медленной» стоят измеримые числа, а не только субъективное впечатление.
• Вкладка Network (тема «Чтение и отладка кода агента») показывает, сколько всего запросов уходит при загрузке страницы и сколько весит каждый из них. Она выручает, когда непонятно, тормозит ли сама страница или один конкретный тяжёлый файл на ней.

Практическая привычка: замерять до и после, а не полагаться на ощущение. Прогони Lighthouse перед тем, как просить агента что-то поменять, и сохрани результат. После изменения прогони его же ещё раз и сравни числа. Общая оценка заметно гуляет даже без правок, а dev-сервер даёт другие числа, чем production-сборка. Поэтому мерь одну и ту же production-сборку с одним пресетом, делай по три прогона и сравнивай медиану конкретной метрики, например LCP, а не общий балл. Это тот же принцип «зафиксировать и сравнить», что и в теме «Вайбкодинг: арт и инструменты» для генеративной графики, только применённый к скорости, а не к визуальным параметрам.

Собери production-версию проекта и запусти её локально. Затем прогони npx lighthouse <адрес страницы> три раза с одним пресетом и покажи медиану LCP, CLS и общей оценки плюс три самые критичные проблемы. Если Chrome не найден или команда не запускается — скажи мне, цифры не придумывай

Оговорка: не у каждого агента есть доступ к браузеру. Терминальный агент может запустить Lighthouse из командной строки или через подключённый браузерный MCP-сервер (например, Chrome DevTools MCP). Веб-агент вроде v0 этого, скорее всего, не умеет. Если агент отвечает, что не может запустить аудит, прогони Lighthouse сам во вкладке DevTools и вставь агенту текст отчёта. Исправлять находки он сможет и так.

Оптимизация — тоже точечная правка, а не одна большая переделка. Проси агента исправлять находки Lighthouse по одной, начиная с самых критичных. Не пытайся исправить всё разом одним промптом.

Почти всегда начинай с картинок: это самая тяжёлая часть страницы и самая простая правка. Для масштаба: одна обложка шириной 1600 пикселей весит около 1,3 МБ в PNG, 110 КБ в JPEG и 50 КБ в WebP. AVIF ужимает её ещё до 40 КБ. На глаз все версии одинаковые, а разница в весе — в 25 раз. PNG оставляй для иконок, логотипов и картинок с прозрачностью, а фото и обложки переводи в WebP.

• «Изображения на этой странице заметно тяжёлые — сожми их и переведи в современный формат (WebP или AVIF) без заметной потери качества»
• «Прогони аудит на неиспользуемый код и зависимости, которые раздувают размер итогового бандла, и предложи, что можно безопасно убрать»
• «На этой странице много контента ниже первого экрана — можно ли загружать его лениво (lazy loading), чтобы не тормозить начальную загрузку»
• «Замерь Lighthouse-оценку этой страницы до и после того, как добавишь новый блок с картой — покажи, ухудшилось ли что-то, и если да, что именно»

Найди в этом проекте два похожих, но не идентичных компонента карточки и предложи, как свести их к одному переиспользуемому, не меняя внешний вид ни одной из карточек

Прогони рефакторинг вот этого конкретного компонента (вставить путь) для читаемости: переименуй неясные переменные, убери мёртвый код — но не трогай логику

Объясни простыми словами разницу между Core Web Vitals и просто "сайт открывается быстро" — как будто я никогда не занимался оптимизацией

У этой страницы низкая оценка Lighthouse по картинкам — покажи список самых тяжёлых файлов и предложи, что сжать в первую очередь