Избегаем водопадов запросов

Водопад — это последовательная задержка на данных, у которых нет последовательной зависимости. Признак — два await подряд, где второй аргумент не использует результат первого. Каждый await паркует функцию, пока его промис не разрешится, так что запросы идут нос-к-хвосту, и общее время становится суммой круговых рейсов вместо максимума.

// водопад: user и posts независимы, но идут последовательно
async function load(userId: string) {
  const user = await fetchUser(userId);    // 300ms
  const posts = await fetchPosts(userId);  // 300ms — стартует только после разрешения user
  return { user, posts };                  // итого ≈ 600ms
}

fetchPosts никогда не читает user. Нет причины ему ждать. Лечение — запустить оба до того, как ждать любой из них, чтобы круговые рейсы перекрылись.

Лечи независимые запросы, запуская их вместе, а потом ожидая группу — Promise.all. Сначала запусти промисы (пока не await), затем дождись их как набора. Теперь два круговых рейса перекрываются, и общее время схлопывается из суммы в максимум.

// параллельно: оба запроса в полёте до того, как любой из них ожидается
async function load(userId: string) {
  const userP = fetchUser(userId);    // запущен, не ожидается
  const postsP = fetchPosts(userId);  // запущен, не ожидается
  const [user, posts] = await Promise.all([userP, postsP]); // итого ≈ 300ms
  return { user, posts };
}

Структурный сдвиг мал, но точен: создавай промисы рано, ожидай их поздно. Если один отклоняется, Promise.all отклоняется сразу — используй Promise.allSettled, когда частичный результат всё равно должен отрендериться. Это один и тот же приём — что в загрузчике маршрута, что в серверном action, что в обычной async-функции.

В RSC водопад прячется в дереве компонентов: дочерний, который делает await, не может стартовать, пока родитель не отрендерился. Server Components могут быть async и await-ить данные напрямую, что чисто, — но если родитель ждёт, рендерится и только затем рендерит дочерний, который тоже ждёт, запрос дочернего стартует поздно. Подними независимые загрузки в общего предка и запусти их параллельно, либо рендери соседние async-компоненты, чтобы React мог обработать их одновременно.

// водопад: Profile ждёт, ЗАТЕМ рендерит Feed, который ждёт
async function Profile({ id }: { id: string }) {
  const user = await getUser(id);            // круговой рейс 1
  return <><Header user={user} /><Feed id={id} /></>; // загрузка Feed стартует только сейчас
}

// сплющено: запусти оба заранее, передай промисы вниз, дай Suspense стримить каждый
function Profile({ id }: { id: string }) {
  const userP = getUser(id);                 // оба в полёте немедленно
  const feedP = getFeed(id);
  return (
    <>
      <Suspense fallback={<HeaderSkeleton />}><Header userP={userP} /></Suspense>
      <Suspense fallback={<FeedSkeleton />}><Feed feedP={feedP} /></Suspense>
    </>
  );
}

Передача промиса вниз (и чтение его через use внутри каждого дочернего) даёт обоим запросам стартовать в один момент, пока каждая секция стримится независимо за своей границей Suspense.

Предзагружай вероятное следующее, чтобы круговой рейс уже завершился, когда пользователь его запросит. Если ты можешь предсказать следующий вид — строку, на которую пользователь наводит курсор, маршрут под курсором, вкладку, которую он откроет, — запусти его запрос рано, а не жди клика. С кэшем серверного состояния (TanStack Query, предзагрузка маршрута RSC) загруженные данные тёплые к моменту навигации, превращая видимый спиннер в мгновенный рендер.

// прогреваем кэш по наведению; клик затем читает из кэша, без водопада
function UserRow({ id }: { id: string }) {
  const qc = useQueryClient();
  return (
    <a
      href={`/users/${id}`}
      onMouseEnter={() => qc.prefetchQuery({ queryKey: ["user", id], queryFn: () => fetchUser(id) })}
    >
      View
    </a>
  );
}

Предзагрузка — это задержка, спрятанная заранее, а не сокращённая. Но она тратит трафик и работу сервера на догадку — поэтому предзагружай только то, что вероятно следующее (строку под курсором, соседний маршрут), а не всё на странице. Сверхпредзагрузка — это свой собственный баг производительности, разобранный ниже.