Перейти к основному содержимому

Next.js

Экспресс-шпаргалка 20/20​

  1. App Router использует nested layouts, server components и file-based conventions нового поколения по сравнению с Pages Router.
  2. Server Components рендерятся на сервере и уменьшают JS в браузере; Client Components нужны для интерактивности и browser API.
  3. SSR - динамика/персонализация, SSG - статический контент, ISR - периодическое обновление pre-rendered страниц.
  4. Кэш в Next управляется на уровне fetch/route/page и контролируется revalidate/tag/path invalidation.
  5. Route Handlers - это серверные HTTP endpoints внутри app router, удобны для BFF сценариев.
  6. Hydration mismatch происходит, когда серверный HTML не совпадает с клиентским рендером.
  7. loading/error states реализуются через loading.js, error.js и Suspense boundaries.
  8. Dynamic rendering нужен при request-time данных, static - когда данные стабильны и важна скорость/SEO.
  9. generateMetadata формирует SEO-метаданные на сервере и должен учитывать data freshness.
  10. Оптимизация media: next/image, next/font, контроль размеров и preload критических ассетов.
  11. Границы server/client нужно держать явными через use client и не импортировать server-only код в клиент.
  12. Server Actions - серверные мутации рядом с UI, но требуют проверки прав и безопасной обработки ошибок.
  13. Авторизацию в Next обычно строят через middleware + server-side проверки + secure cookies.
  14. TTFB/LCP улучшают через кэш, streaming, уменьшение blocking fetch и оптимизацию critical path.
  15. BFF в Next подходит для умеренной сложности; при росте домена лучше выделенный backend.
  16. Edge/runtime дает меньшую latency ближе к пользователю, но имеет ограничения по API окружения.
  17. Глобальный state без boundaries усложняет hydration и увеличивает стоимость ререндеров.
  18. Инвалидация кэша после мутаций делается через revalidatePath/revalidateTag и явные правила freshness.
  19. i18n в Next проектируют через локализованные маршруты, словари и корректные SEO alternate links.
  20. Частые anti-patterns: смешивание server/client, отсутствие cache strategy и переизбыток client components.

1. Что изменилось в App Router по сравнению с Pages Router?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

App Router использует nested layouts, server components и file-based conventions нового поколения по сравнению с Pages Router.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Проверяю целевой сценарий под slow network/CPU throttling и подтверждаю улучшение цифрами, а не ощущением.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Что изменилось в App Router по сравнению с Pages Router?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните поведение на быстром и медленном устройстве/сети.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  2. Как будете валидировать эффект на медленных устройствах?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы SSR/CSR/SSG/ISR (если применимо).
  2. Профилирование рендера до/после изменения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

2. Разница между Server Components и Client Components?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

Server Components рендерятся на сервере и уменьшают JS в браузере; Client Components нужны для интерактивности и browser API.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Разница между Server Components и Client Components?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не проверяют сценарий на медленных устройствах и сетях.
  2. Переусложняют мемоизацию там, где нет измеримой проблемы.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  2. Как будете валидировать эффект на медленных устройствах?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Профилирование рендера до/после изменения.
  2. Критический путь рендера и метрики LCP/INP/CLS.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

3. Как выбирать между SSR, SSG и ISR в Next.js?​

Теги: nextjs, react, rendering Сложность: Middle/Senior

Короткий ответ​

SSR - динамика/персонализация, SSG - статический контент, ISR - периодическое обновление pre-rendered страниц.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример​

export const revalidate = 60;
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { next: { revalidate: 60 } });
  return <pre>{JSON.stringify(await res.json(), null, 2)}</pre>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как выбирать между SSR, SSG и ISR в Next.js?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  2. Переусложняют мемоизацию там, где нет измеримой проблемы.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как будете валидировать эффект на медленных устройствах?
  2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критический путь рендера и метрики LCP/INP/CLS.
  2. Границы SSR/CSR/SSG/ISR (если применимо).
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

4. Как устроен кэш данных в Next.js и revalidation?​

Теги: nextjs, react, cache Сложность: Middle/Senior

Короткий ответ​

Кэш в Next управляется на уровне fetch/route/page и контролируется revalidate/tag/path invalidation.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Без стратегии инвалидации кэш становится источником stale-данных и трудноуловимых багов.
  3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как устроен кэш данных в Next.js и revalidation?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните поведение на быстром и медленном устройстве/сети.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  2. Переусложняют мемоизацию там, где нет измеримой проблемы.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы SSR/CSR/SSG/ISR (если применимо).
  2. Профилирование рендера до/после изменения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

5. Что такое Route Handlers и когда их использовать?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

Route Handlers - это серверные HTTP endpoints внутри app router, удобны для BFF сценариев.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример​

// app/api/users/route.ts
export async function GET() {
  return Response.json({ users: [] });
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Что такое Route Handlers и когда их использовать?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Не проверяют сценарий на медленных устройствах и сетях.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как будете валидировать эффект на медленных устройствах?
  2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Профилирование рендера до/после изменения.
  2. Критический путь рендера и метрики LCP/INP/CLS.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

6. Как избежать hydration mismatch в Next.js?​

Теги: nextjs, react, rendering Сложность: Middle/Senior

Короткий ответ​

Hydration mismatch происходит, когда серверный HTML не совпадает с клиентским рендером.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Недетерминированный initial render вызывает mismatch и деградацию UX.
  3. Как проверяете решение: Проверяю целевой сценарий под slow network/CPU throttling и подтверждаю улучшение цифрами, а не ощущением.

Мини-пример​

'use client';
import { useEffect, useState } from 'react';
export default function Clock() {
  const [now, setNow] = useState('');
  useEffect(() => setNow(new Date().toISOString()), []);
  return <span>{now}</span>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как избежать hydration mismatch в Next.js?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Не проверяют сценарий на медленных устройствах и сетях.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы SSR/CSR/SSG/ISR (если применимо).
  2. Профилирование рендера до/после изменения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

7. Как организовать loading/error states в App Router?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

loading/error states реализуются через loading.js, error.js и Suspense boundaries.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как организовать loading/error states в App Router?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не проверяют сценарий на медленных устройствах и сетях.
  2. Переусложняют мемоизацию там, где нет измеримой проблемы.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как будете валидировать эффект на медленных устройствах?
  2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Профилирование рендера до/после изменения.
  2. Границы SSR/CSR/SSG/ISR (если применимо).
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

8. Когда нужен dynamic rendering, а когда static?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

Dynamic rendering нужен при request-time данных, static - когда данные стабильны и важна скорость/SEO.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Когда нужен dynamic rendering, а когда static?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  2. Как будете валидировать эффект на медленных устройствах?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Профилирование рендера до/после изменения.
  2. Критический путь рендера и метрики LCP/INP/CLS.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

9. Как работает generateMetadata и зачем он важен?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

generateMetadata формирует SEO-метаданные на сервере и должен учитывать data freshness.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как работает generateMetadata и зачем он важен?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не проверяют сценарий на медленных устройствах и сетях.
  2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как будете валидировать эффект на медленных устройствах?
  2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критический путь рендера и метрики LCP/INP/CLS.
  2. Границы SSR/CSR/SSG/ISR (если применимо).
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

10. Как в Next.js оптимизировать изображения и шрифты?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

Оптимизация media: next/image, next/font, контроль размеров и preload критических ассетов.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как в Next.js оптимизировать изображения и шрифты?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Не проверяют сценарий на медленных устройствах и сетях.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  2. Как будете валидировать эффект на медленных устройствах?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критический путь рендера и метрики LCP/INP/CLS.
  2. Профилирование рендера до/после изменения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

11. Как разделять server/client логику без дублирования?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

Границы server/client нужно держать явными через use client и не импортировать server-only код в клиент.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как разделять server/client логику без дублирования?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  2. Не проверяют сценарий на медленных устройствах и сетях.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы SSR/CSR/SSG/ISR (если применимо).
  2. Профилирование рендера до/после изменения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

12. Что такое Server Actions и где их границы?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

Server Actions - серверные мутации рядом с UI, но требуют проверки прав и безопасной обработки ошибок.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Что такое Server Actions и где их границы?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  2. Переусложняют мемоизацию там, где нет измеримой проблемы.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как будете валидировать эффект на медленных устройствах?
  2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Профилирование рендера до/после изменения.
  2. Границы SSR/CSR/SSG/ISR (если применимо).
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

13. Как проектировать авторизацию в Next.js приложении?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

Авторизацию в Next обычно строят через middleware + server-side проверки + secure cookies.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как проектировать авторизацию в Next.js приложении?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы SSR/CSR/SSG/ISR (если применимо).
  2. Профилирование рендера до/после изменения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

14. Как оптимизировать TTFB и LCP в Next-проекте?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

TTFB/LCP улучшают через кэш, streaming, уменьшение blocking fetch и оптимизацию critical path.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как оптимизировать TTFB и LCP в Next-проекте?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не проверяют сценарий на медленных устройствах и сетях.
  2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Профилирование рендера до/после изменения.
  2. Границы SSR/CSR/SSG/ISR (если применимо).
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

15. Как организовать API слой в Next: BFF или внешний backend?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

BFF в Next подходит для умеренной сложности; при росте домена лучше выделенный backend.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Проверяю целевой сценарий под slow network/CPU throttling и подтверждаю улучшение цифрами, а не ощущением.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как организовать API слой в Next: BFF или внешний backend?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы SSR/CSR/SSG/ISR (если применимо).
  2. Критический путь рендера и метрики LCP/INP/CLS.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

16. Как деплоить Next.js на edge/runtime и что учитывать?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

Edge/runtime дает меньшую latency ближе к пользователю, но имеет ограничения по API окружения.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Проверяю целевой сценарий под slow network/CPU throttling и подтверждаю улучшение цифрами, а не ощущением.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как деплоить Next.js на edge/runtime и что учитывать?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Сравните поведение на быстром и медленном устройстве/сети.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как будете валидировать эффект на медленных устройствах?
  2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критический путь рендера и метрики LCP/INP/CLS.
  2. Профилирование рендера до/после изменения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

17. Какие риски у глобального state в Next-приложении?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

Глобальный state без boundaries усложняет hydration и увеличивает стоимость ререндеров.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Проверяю целевой сценарий под slow network/CPU throttling и подтверждаю улучшение цифрами, а не ощущением.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Какие риски у глобального state в Next-приложении?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Не проверяют сценарий на медленных устройствах и сетях.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  2. Как будете валидировать эффект на медленных устройствах?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критический путь рендера и метрики LCP/INP/CLS.
  2. Профилирование рендера до/после изменения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

18. Как строить кэш-инвалидацию после мутаций данных?​

Теги: nextjs, react, cache Сложность: Middle/Senior

Короткий ответ​

Инвалидация кэша после мутаций делается через revalidatePath/revalidateTag и явные правила freshness.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Без стратегии инвалидации кэш становится источником stale-данных и трудноуловимых багов.
  3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример​

export class CreateUserDto {
  @IsEmail()
  email!: string;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как строить кэш-инвалидацию после мутаций данных?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
  2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Границы SSR/CSR/SSG/ISR (если применимо).
  2. Критический путь рендера и метрики LCP/INP/CLS.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

19. Как строить мультиязычность и роутинг i18n в Next?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

i18n в Next проектируют через локализованные маршруты, словари и корректные SEO alternate links.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как строить мультиязычность и роутинг i18n в Next?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Не проверяют сценарий на медленных устройствах и сетях.
  2. Переусложняют мемоизацию там, где нет измеримой проблемы.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как будете валидировать эффект на медленных устройствах?
  2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критический путь рендера и метрики LCP/INP/CLS.
  2. Границы SSR/CSR/SSG/ISR (если применимо).
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js

20. Какие anti-patterns чаще всего встречаются в Next-коде?​

Теги: nextjs, react Сложность: Middle/Senior

Короткий ответ​

Частые anti-patterns: смешивание server/client, отсутствие cache strategy и переизбыток client components.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для продуктовых web-приложений с SEO, персонализацией и требованиями к скорости рендера.
  2. Главный риск: Неверная стратегия рендера и кэша в Next.js быстро приводит к росту TTFB/LCP и нестабильному UX.
  3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример​

export const dynamic = 'force-dynamic';
export default async function Page() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();
  return <main>{data.length}</main>;
}

Куда дальше​

  1. Вернитесь в модуль: Next.js.
  2. Сверьтесь с картой темы: Next.js.
  3. Продолжайте по маршруту: Middle трек.
  4. Закрепите один ответ на практике в Песочнице.

Углубление (2-3 минуты)​

  1. Свяжите тему "Какие anti-patterns чаще всего встречаются в Next-коде?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Переусложняют мемоизацию там, где нет измеримой проблемы.
  2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
  2. Как будете валидировать эффект на медленных устройствах?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Критический путь рендера и метрики LCP/INP/CLS.
  2. Профилирование рендера до/после изменения.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Next.js
  2. Обучение: Рендеринг веб-страницы
  3. Карта подготовки: Next.js