Расскажите о случае, когда вы улучшали performance, accessibility, testing или maintainability в проекте на Next.js.

Улучшение качества проекта на Next.js

Расскажу о конкретном случае улучшения производительности и maintainability в production-приложении на Next.js 14, где было несколько узких мест: медленная загрузка страниц, недостаточное покрытие тестами и сложность поддержки кода.

Performance: переход на Server Components и потоковый рендеринг

Исходно страница каталога товаров была полностью клиентской — данные загружались через useEffect + fetch, что давало TTFB ~2.5 секунды и мерцание при первой загрузке. Переписал страницу на Server Component с Suspense-стримингом:

// Было: клиентский компонент с useEffect
'use client';
const [products, setProducts] = useState([]);
useEffect(() => {
  fetch('/api/products').then(r => r.json()).then(setProducts);
}, []);

// Стало: серверный компонент + Suspense
// app/catalog/page.tsx
import { Suspense } from 'react';
import { ProductList } from './ProductList';
import { Filters } from './Filters';

export default function CatalogPage() {
  return (
    <div className="catalog">
      <Suspense fallback={<FiltersSkeleton />}>
        <Filters />
      </Suspense>
      <Suspense fallback={<ProductListSkeleton />}>
        <ProductList />
      </Suspense>
    </div>
  );
}

// app/catalog/ProductList.tsx
async function ProductList() {
  const products = await db.product.findMany({ take: 20 });
  return <ul>{products.map(p => <ProductCard key={p.id} product={p} />)}</ul>;
}

Результат: TTFB упал до 400 мс, LCP улучшился на 60%. Пользователь видит скелетоны мгновенно, данные приходят по мере готовности.

Accessibility: аудит с axe-core

Добавил @axe-core/react в dev-режим и интегрировал jest-axe в тесты компонентов. Нашёл 12 нарушений: отсутствующие aria-label у иконок, недостаточный контраст кнопок, форма без <label>. Исправил все P0/P1-нарушения, добавил Storybook-тесты с a11y аддоном для регрессионного контроля.

Testing: интеграция MSW и Testing Library

Добавил msw (Mock Service Worker) для изоляции API-запросов в тестах и переписал критические тесты с Enzyme на Testing Library:

// tests/catalog.test.tsx
import { render, screen, waitFor } from '@testing-library/react';
import { server } from '../mocks/server';
import { http, HttpResponse } from 'msw';
import CatalogPage from '../app/catalog/page';

test('отображает список товаров', async () => {
  server.use(
    http.get('/api/products', () =>
      HttpResponse.json([{ id: '1', name: 'iPhone 15' }])
    )
  );

  render(<CatalogPage />);

  await waitFor(() => {
    expect(screen.getByText('iPhone 15')).toBeInTheDocument();
  });
});

Maintainability: barrel exports и строгий TypeScript

Ввёл barrel-файлы для компонентов, включил "strict": true в tsconfig.json и добавил ESLint-правило @typescript-eslint/no-explicit-any. Это позволило IDE лучше находить использования и упростило рефакторинг.

Подводные камни

• Suspense и async Server Components в тестах — jest не умеет рендерить async Server Components напрямую; для unit-тестов выносите логику в отдельные функции, а компоненты тестируйте через E2E (Playwright).
• axe-core не заменяет ручной аудит — автоматика находит ~30% нарушений WCAG; навигация с клавиатуры и скринридерами проверяется только вручную.
• Barrel-файлы ломают tree-shaking — при неправильной настройке sideEffects в package.json barrel export тянет весь модуль в бандл; проверяйте через next build --debug.
• MSW 2.x несовместим с MSW 1.x — API полностью переписан; при обновлении обязательно перечитайте гайд по миграции, иначе хендлеры молча не регистрируются.
• Streaming и метатеги — при использовании Suspense на уровне страницы метатеги из generateMetadata отправляются до потока, но тайтл страницы должен быть известен заранее — нельзя делать generateMetadata зависимым от стриминг-данных.
• Перенос логики на сервер увеличивает нагрузку на БД — N+1 запросы, которые раньше были на клиенте (и незаметны), теперь бьют по БД на каждый SSR; обязательно профилируйте с prisma.$on('query', ...) или pg_stat_statements.

• Выдумывать опыт или говорить слишком общими фразами
• Не объяснять свою личную роль в работе с Next.js
• Не показывать результат, метрики или извлечённые уроки

• Может подготовить честный пример использования Next.js
• Показывает свою роль, решения и результат
• Умеет рефлексировать над trade-offs и уроками