Использовал ли Lazy Loading

Lazy Loading означает, что ресурс загружается не на старте страницы, а тогда, когда он становится нужен. Во frontend это чаще всего изображения ниже первого экрана, iframe, отдельные маршруты, модальные окна, графики, редакторы и другие тяжелые части интерфейса.

На интервью не останавливайтесь на одном определении. Скажите, какой ресурс вы откладывали, почему он не нужен сразу, какой fallback видел пользователь и как вы проверяли результат. Если production-опыта не было, не выдумывайте. Спокойно объясните, где вы применили бы подход и какие риски учли бы.

Если у вас был похожий опыт, можно ответить так:

Да, использовал. Например, откладывал загрузку тяжелых частей интерфейса, которые не нужны на первом экране: отдельные маршруты, модальные окна и изображения ниже fold. В React это делал через динамический import, React.lazy и Suspense, а для изображений использовал native loading='lazy' или Intersection Observer, если нужна была более точная логика. При этом я не делал lazy для LCP-изображения и критичного контента, добавлял fallback и проверял эффект по размеру бандла и Web Vitals.

Замените пример на свой. Если вы работали только с изображениями, не говорите, что глубоко внедряли code splitting. Лучше сузить ответ, чем получить уточнение, на которое нечего сказать.

Хорошее правило простое: лениво грузите то, что пользователь может не увидеть или открыть не сразу. Не откладывайте то, без чего страница выглядит пустой, ломается основной сценарий или ухудшается LCP.

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

<img
  src="/gallery/item-42.webp"
  alt="Пример карточки товара"
  width="640"
  height="480"
  loading="lazy"
/>

Здесь loading='lazy' откладывает загрузку, а width и height помогают браузеру заранее зарезервировать место. Без размеров можно получить CLS и плохое ощущение при скролле.

Если вместо нативного атрибута вы используете IntersectionObserver, не забудьте cleanup в useEffect. Без unobserve или disconnect observer может держать ссылку на элемент и вызывать лишние callback после размонтирования. Для UX часто полезен rootMargin, чтобы начать загрузку до того, как пользователь увидит пустой блок.

В React типичный пример выглядит так: тяжелый компонент выносится в отдельный chunk и загружается только при рендере.

import { Suspense, lazy } from 'react';
import { ErrorBoundary } from './ErrorBoundary';

const AnalyticsPanel = lazy(() => import('./AnalyticsPanel'));

function ChunkErrorFallback() {
  return (
    <div role="alert">
      <p>Не удалось загрузить отчет.</p>
      <button type="button" onClick={() => window.location.reload()}>
        Обновить страницу
      </button>
    </div>
  );
}

export function Dashboard() {
  return (
    <ErrorBoundary fallback={<ChunkErrorFallback />}>
      <Suspense fallback={<div className="panel-skeleton">Загружаем отчет...</div>}>
        <AnalyticsPanel />
      </Suspense>
    </ErrorBoundary>
  );
}

Suspense нужен для ожидания загрузки. ErrorBoundary нужен на случай, если chunk не загрузился. Это может случиться из-за сети, CDN, блокировщика или ситуации, когда пользователь открыл старый HTML после нового деплоя. В fallback лучше дать текст ошибки и доступную кнопку восстановления. Если ваш Error Boundary умеет сбрасывать состояние, используйте reset вместо полного обновления страницы.

Сильный ответ показывает не только API, но и порядок внедрения. Сначала найдите узкое место: большой initial bundle, тяжелую библиотеку графиков, редактор, карту, галерею или редко открываемый экран. Затем вынесите это в отдельную загрузку, добавьте fallback и проверьте, не стало ли хуже в основном сценарии.

Важно не путать уменьшение initial bundle с улучшением всего UX. Если пользователь все равно сразу нажимает кнопку и ждет загрузку chunk, задержка просто переехала на более заметный момент. Поэтому стоит проверять не только Lighthouse, но и реальный пользовательский путь.

Lazy Loading может навредить SEO и доступности, если спрятать важный контент за клиентской логикой. Основной текст, заголовки, важные ссылки и контент, по которому страница должна ранжироваться, лучше отдавать сразу или через SSR, если это часть вашего стека.

Для изображений не забывайте про alt, размеры и правильный формат. Для fallback-состояний избегайте бесконечного спиннера без текста. Пользователь должен понимать, что происходит, особенно если сеть медленная.

На интервью хорошо звучит такая мысль: я не добавляю Lazy Loading просто потому, что это модно. Я смотрю, уменьшился ли initial JavaScript, улучшился ли первый экран, не вырос ли CLS, не появились ли задержки при переходах и не стало ли больше ошибок загрузки chunks.

Подходящие инструменты: bundle analyzer для размера chunks, Lighthouse как быстрый локальный сигнал, Web Vitals для LCP, CLS и INP, а также реальные метрики из продакшена. Если метрик нет, хотя бы скажите, какие именно вы бы сравнили до и после.