Что такое оптимизация

На интервью хороший ответ не должен звучать как список библиотек и хуков. Оптимизация это улучшение измеримого свойства приложения. Например, первый экран открылся быстрее, ввод блокируется реже, лишних запросов стало меньше, JavaScript скачивается легче, интерфейс стабильнее работает на слабом телефоне.

Сразу добавьте важное ограничение. Оптимизация без измерений часто превращается в угадывание. Можно долго мемоизировать компоненты, хотя пользователь ждет из-за большого изображения, тяжелого шрифта, медленного API или стороннего скрипта.

Короткая формулировка для ответа:

Для меня оптимизация это не просто сделать быстрее. Это найти узкое место в конкретном сценарии, изменить его и подтвердить результат метриками. Во фронтенде это может быть загрузка, рендеринг, сеть, кеширование, изображения или работа main thread.

Сильный ответ показывает порядок действий. Вы не просто знаете lazy loading, debounce и useMemo. Вы понимаете, когда каждый прием уместен и какую проблему он решает.

Такой порядок защищает от типичной ошибки. Если вы сразу говорите "я применяю React.memo", интервьюер легко спросит: "А как вы поняли, что проблема была в рендерах?" Если вы сначала говорите про замеры, ответ выглядит надежнее.

Для загрузки часто смотрят размер бандла, критический CSS, изображения, шрифты, кеширование статических ресурсов и серверный ответ. Практический пример: тяжелый редактор, график или админский модуль не нужны на первом экране. Их можно вынести в отдельный чанк и загрузить позже.

import { lazy, Suspense } from "react";

const ChartPanel = lazy(() => import("./ChartPanel"));

export function Dashboard() {
  return (
    <Suspense
      fallback={
        <div role="status" aria-live="polite">
          Загружаем график...
        </div>
      }
    >
      <ChartPanel />
    </Suspense>
  );
}

Это может уменьшить начальный JavaScript. Но есть trade-off: если график нужен сразу после первого клика, пользователь может ждать уже внутри интерфейса. Тогда стоит подумать о prefetch, skeleton и приоритете загрузки. Для доступности у fallback должно быть понятное состояние загрузки. Иначе пользователь скринридера может не понять, почему часть интерфейса пропала.

Для рендеринга не стоит начинать с мемоизации всего подряд. Сначала проверьте, что компонент действительно часто и дорого рендерится. Потом разберите, почему меняются пропсы, нет ли лишнего состояния выше по дереву и можно ли проще разделить компонент.

Плохой подход:

const ProductCard = React.memo(function ProductCard({ product, onClick }) {
  return <button onClick={() => onClick(product.id)}>{product.title}</button>;
});

Сам по себе React.memo может не помочь, если родитель на каждый рендер создает новый объект product или новую функцию onClick. Без профилирования вы только усложните код. Сначала найдите источник лишних обновлений, а мемоизацию применяйте точечно.

Для сетевых запросов оптимизация часто связана не только со скоростью, но и с корректностью UI. Например, поиск не должен отправлять запрос на каждый символ и не должен показывать старый результат поверх нового.

useEffect(() => {
  if (!query) {
    setResults([]);
    setStatus("idle");
    return;
  }

  const controller = new AbortController();
  setStatus("loading");

  const timerId = window.setTimeout(async () => {
    try {
      const response = await fetch(`/api/search?q=${encodeURIComponent(query)}`, {
        signal: controller.signal,
      });

      if (!response.ok) {
        throw new Error("Search request failed");
      }

      const data = await response.json();
      setResults(data);
      setStatus("success");
    } catch (error) {
      if (error instanceof DOMException && error.name === "AbortError") return;
      setStatus("error");
    }
  }, 300);

  return () => {
    window.clearTimeout(timerId);
    controller.abort();
  };
}, [query]);

Здесь debounce снижает количество запросов, а AbortController помогает не обрабатывать устаревший запрос. Проверка response.ok и отдельные состояния loading, error и empty state защищают UX после сбоя. Без cleanup можно получить race condition, лишнюю нагрузку на API, обновление размонтированного компонента и неверные данные в интерфейсе.

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

Например, на странице каталога мы увидели, что первый экран медленно появляется на мобильных устройствах. В Performance panel и по RUM-данным было видно, что мешают большой JS-чанк и тяжелое изображение. Мы вынесли часть фильтров в lazy loading, оптимизировали изображение для LCP и проверили метрики после релиза. В итоге сценарий стал быстрее, а код остался понятным.

Даже без точных цифр можно сказать честно: "Я бы сравнил LCP, INP, размер бандла и количество запросов до и после". Это лучше, чем обещать абстрактное ускорение.

На вопрос "что такое оптимизация" отвечайте в три шага. Сначала дайте определение через измеримое улучшение. Затем назовите основные направления во фронтенде: загрузка, рендеринг, сеть, кеш, изображения, main thread. В конце обязательно скажите про проверку результата и цену решения.

Хорошая финальная мысль:

Я стараюсь оптимизировать не ради самого приема, а ради пользовательского сценария. Если изменение не улучшило метрику или UX, а только усложнило код, это плохая оптимизация.