10 промтов для оптимизации JavaScript-кода: как ускорить фронтенд и не сломать прод
Оптимизация фронтенда редко бывает про «переписать всё с нуля». Чаще это про поиск узкого места: тяжёлый бандл, лишние ре-рендеры, синхронный код в главном потоке, legacy-функция на 300 строк. И здесь AI-ассистент экономит часы — если дать ему правильный промт.
Плохой промт («оптимизируй мой код») возвращает общие советы. Хороший — задаёт контекст, ограничения и формат ответа: рантайм, метрику, которую надо улучшить, и требование не ломать поведение. Ниже — 10 рабочих промтов под реальные задачи фронтенд-разработчика. Каждый проверен на практике и учитывает главное правило: сначала измеряем, потом оптимизируем.
1. Поиск узких мест через анализ Event Loop
Задача: понять, что блокирует главный поток. Промт заставляет модель рассуждать о микро- и макрозадачах, а не гадать.
Ты — senior JavaScript-инженер. Проанализируй код ниже на предмет блокировки Event Loop.
Контекст: браузер Chrome, целевой INP < 200ms (метрика Core Web Vitals).
Для каждой проблемы укажи: (1) строку, (2) тип задачи (microtask/macrotask),
(3) почему это блокирует рендеринг, (4) конкретный фикс с кодом.
Не предлагай Web Workers, если задача решается разбиением на чанки.
[вставь код]
Пример: функция на Array.reduce по 50 000 элементов внутри обработчика scroll. Модель укажет на синхронный цикл, предложит requestIdleCallback или scheduler.yield() (реальная API из Chrome) для разбиения работы.
2. Рефакторинг legacy-функции без изменения поведения
Задача: разбить «функцию-монстр» на части, сохранив контракт.
Отрефактори эту функцию, сохранив публичный API и все side effects.
Ограничения: без новых зависимостей, ES2020, не менять имена экспортов.
Выведи: (1) список извлечённых функций с сигнатурами,
(2) итоговый код, (3) чек-лист для регресс-тестов.
[вставь код]
Пример: функция processOrder() на 200 строк с валидацией, расчётом скидки и записью в стор превращается в три чистые функции + оркестратор. Чек-лист подсказывает, какие кейсы покрыть тестами до мержа.
3. Аудит бандла и tree-shaking
Задача: уменьшить размер бандла Webpack/Vite.
Вот вывод `npx vite-bundle-visualizer` (или webpack-bundle-analyzer).
Найди: (1) самые тяжёлые модули, (2) что не tree-shake-ится и почему,
(3) замены на более лёгкие аналоги (с размером gzip),
(4) код для динамического import() тяжёлых частей.
Целевой бюджет: < 170KB gzip для initial chunk.
Пример: moment.js (~70KB) заменяется на date-fns с точечными импортами или Temporal-полифилл; lodash заменяется на lodash-es с именованными импортами. Проверяйте на bundlephobia.com перед заменой.
4. Оптимизация рендеринга React
Задача: убрать лишние ре-рендеры.
Проанализируй этот React-компонент (React 18).
Найди причины лишних ре-рендеров. Предложи фикс с useMemo/useCallback/memo
ТОЛЬКО там, где это оправдано — обоснуй каждый, объяснив стоимость мемоизации.
Укажи, как проверить результат в React DevTools Profiler.
[вставь компонент]
Пример: инлайн-объект в пропсах вызывает ре-рендер списка из 500 элементов. Модель предлагает вынести объект за пределы компонента — без useMemo, потому что он статичен.
5. Оптимизация запросов и кэширования
Задача: сократить число сетевых запросов и повторов.
Вот код работы с fetch. Предложи: (1) дедупликацию одинаковых запросов,
(2) стратегию кэша (stale-while-revalidate), (3) отмену через AbortController,
(4) обработку гонок (race conditions).
Не добавляй библиотеки — только нативный API.
[вставь код]
Пример: двойной запрос из-за StrictMode в dev решается AbortController; кэш поверх Cache API или простой Map с TTL.
6. Написание тестов на оптимизированный код
Задача: зафиксировать поведение до рефакторинга.
Напиши тесты на Vitest для функции ниже. Покрой: граничные случаи,
пустые входы, ошибки, асинхронность. Используй describe/it, без снапшотов.
Цель — тесты должны пройти и до, и после рефакторинга.
[вставь код]
Пример: тесты ловят, что parsePrice('') возвращает NaN, а не бросает ошибку — это важно сохранить при рефакторинге.
7. Code review с AI: чек-лист производительности
Задача: пройтись по PR глазами performance-инженера.
Сделай code review этого диффа с фокусом на производительность.
Формат: таблица
| Проблема | Severity | Строка | Фикс |.
Категории: утечки памяти, N+1 в UI, лишние аллокации, тяжёлые операции в рендере.
Игнорируй стилистику — только рантайм-влияние.
[вставь git diff]
Пример: ревью находит addEventListener без removeEventListener в useEffect — классическая утечка, которую не видно на code review вручную.
8. Профилирование памяти и утечек
Задача: найти, что держит объекты в heap.
Вот три heap snapshot из Chrome DevTools (до, после, повтор действия).
Опиши методологию поиска detached DOM и растущих массивов.
Дай шаги: как читать Retainers, что искать в Comparison view.
Приведи пример кода, который чаще всего вызывает такие утечки.
Пример: таймер без clearInterval в SPA-роутере держит ссылку на весь компонент — detached DOM растёт при каждой навигации.
9. Оптимизация изображений и загрузки ассетов
Задача: ускорить LCP.
Предложи стратегию загрузки изображений для этой страницы.
Учти: LCP-элемент, lazy-loading, `fetchpriority`, `srcset`,
современные форматы (AVIF/WebP) с fallback через <picture>.
Дай готовый HTML и поясни, как измерить через Lighthouse.
Пример: hero-изображение получает fetchpriority="high" и не lazy-грузится; остальные — loading="lazy" и decoding="async".
10. Промт для безопасного деплоя оптимизаций
Задача: не сломать прод.
Составь план выката этих оптимизаций. Включи:
(1) feature flag, (2) метрики для мониторинга (RUM Core Web Vitals),
(3) критерии отката, (4) A/B-план, (5) что проверить в первую очередь.
Пиши как runbook для дежурного инженера.
[описание изменений]
Пример: деплой через 10% трафика, мониторинг INP и error rate, автоматический откат при росте ошибок выше baseline.
Итог
Эти промты работают, потому что задают рамки: метрику, ограничения, формат вывода. AI не заменит профайлер Chrome DevTools или Lighthouse — он ускоряет интерпретацию их данных и предлагает код. Всегда проверяйте предложенные API в официальной документации (MDN, web.dev, react.dev) и измеряйте результат до и после. Начните с промта №1 — поиск узкого места даёт максимум пользы при минимуме риска.
Comments