---
title: "Производительность"
description: "Паттерны производительности, специфичные для Ring Platform — React 19 cache(), имитация Firebase во время сборки, оптимизация запросов DatabaseService, серверные компоненты и Firebase Admin SDK."
locale: "ru"
---
# Оптимизация производительности

Стратегии профилирования и оптимизации, специфичные для Ring Platform. Этот документ охватывает реальные паттерны кодовой базы. По ожиданиям производительности для пользователей см. [Производительность](/docs/en/features/performance.md). По усилению производительности в продакшене см. [Производительность развертывания](/docs/en/deployment/performance.md). По общим конвенциям разработки см. [Лучшие практики](/docs/en/development/best-practices.md).

> **Warning**
> Ring Platform **не** использует Firestore на стороне клиента. Firebase используется исключительно через Admin SDK в `lib/firebase-admin.server.ts`. Единственный клиентский код Firebase — это `public/firebase-messaging-sw.js` для push-уведомлений FCM.

### For founders

## Что влияет на время загрузки

Ring Platform загружается быстро, поскольку большинство страниц — это **серверные компоненты React**, рендерящиеся на сервере. Ключевые факторы, влияющие на производительность:

- **Кэширование серверных данных** — повторные чтения Firestore во время одного запроса дедуплицируются с помощью `cache()` из React 19.
- **Оптимизации во время сборки** — Firebase Admin имитируется во время статической генерации, сокращая время сборки примерно на 31%.
- **Минимальный клиентский JavaScript** — только страницы с интерактивностью (формы, карты, оформление заказа) используют клиентские компоненты.
- **Ресурсы через CDN** — статические страницы предварительно собираются и обслуживаются из кэша на периферии сети.

## Доступные оптимизации производительности

| Оптимизация | Преимущество |
|---|---|
| React 19 cache() | Дедупликация чтений Firestore на один запрос |
| Имитация Firebase во время сборки | ~31% более быстрые сборки, предотвращает 22+ лишних инициализаций |
| Уровень запросов DatabaseService | Унифицированный PostgreSQL + Firestore с кэшированием |
| Серверные компоненты по умолчанию | Без клиентского JS для большинства страниц |
| WayForPay только на сервере | Никакая логика платежей не попадает на клиент |
| FCM Service Worker | Push-уведомления обрабатываются вне главного потока |

### For developers

## React 19 cache() для дедупликации данных

Модуль `firebase-service-manager.ts` оборачивает каждое чтение Firestore Admin SDK с помощью `cache()` из React 19. Это предотвращает дублирование запросов в пределах одного прохода рендеринга серверного компонента.

```typescript
import { getCachedDocument, getCachedCollection } from '@/lib/services/firebase-service-manager'

// Несколько вызовов одного документа во время SSG сводятся к одному чтению Firestore
const entity = await getCachedDocument('entities', 'abc123')
const sameEntity = await getCachedDocument('entities', 'abc123') // cache hit

// Запросы коллекций также кэшируются на один запрос
const activeEntities = await getCachedCollection('entities', {
  where: { field: 'status', operator: '==', value: 'active' },
  orderBy: { field: 'createdAt', direction: 'desc' },
  limit: 20
})
```

Функция `cache()` импортируется из React 19 — это не собственная реализация. Все функции кэшированного чтения находятся в `lib/services/firebase-service-manager.ts` и работают с `firebase-admin/firestore`.

> **Tip**
> Область кэша — только текущий проход рендеринга серверного компонента. После отправки ответа кэш удаляется. Для долговременного кэширования используйте `revalidate` на fetch или выделенный слой кэширования.

## Имитация Firebase во время сборки

Во время `next build` устанавливается `NEXT_PHASE=phase-production-build`. Модуль в `lib/firebase/build-mock.server.ts` обнаруживает это и возвращает имитированные экземпляры Firestore, Auth и RTDB. Это предотвращает примерно 22 инициализации Firebase Admin, которые иначе выполнялись бы во время статической генерации.

```typescript
import { isBuildTime, getMockFirebaseServices } from '@/lib/firebase/build-mock.server'

if (isBuildTime()) {
  const { mockDb, mockAuth } = getMockFirebaseServices()
  // mockDb.collection('test').get() возвращает пустые результаты
  // Учетные данные Firebase не нужны во время сборки
}
```

Слой имитации реализует полный интерфейс запросов Firestore с цепочечными методами `where()`, `orderBy()`, `limit()` и пагинацией — все возвращают пустые наборы результатов. Методы Auth возвращают безопасные объекты пользователей по умолчанию. Это активно в `lib/firebase/build-mock.server.ts:36`.

## Оптимизация запросов DatabaseService

Уровень абстракции базы данных в `lib/database/DatabaseService.ts` предоставляет унифицированный API запросов для PostgreSQL и Firestore со встроенным кэшированием сущностей на 30 секунд.

```typescript
import { getDatabaseService } from '@/lib/database/DatabaseService'

const db = getDatabaseService()
const result = await db.query({
  collection: 'entities',
  filters: { status: 'active' },
  orderBy: { field: 'createdAt', direction: 'desc' },
  pagination: { limit: 20 }
})

if (!result.success) {
  throw result.error || new Error('Query failed')
}
```

Сервис включает класс `EntityCache` с инвалидацией на основе TTL. Для согласованности чтения после записи операции записи инвалидируют соответствующие ключи.

> **Warning**
> Не вызывайте `db.users.findById()` или подобные паттерны. API DatabaseService использует `db.query({ collection, filters })` с одним объектом параметров. См. `lib/database/DatabaseService.ts:74` для полного интерфейса.

## Серверные компоненты по умолчанию

Все страницы в `app/` являются серверными компонентами, если они не содержат директиву `'use client'`. Это устраняет клиентский JavaScript для большинства маршрутов. Клиентские компоненты используются только для:

- Интерактивных форм (оформление заказа, онбординг продавцов)
- Отображения карт (Ringdom Maps)
- Интерфейсов кошельков и платежей
- Панелей администрирования

Ищите `'use client'` в `app/`, чтобы увидеть полный перечень клиентских компонентов.

## Обработка фоновых сообщений FCM

Firebase Cloud Messaging полностью обрабатывается в Service Worker в `public/firebase-messaging-sw.js`. Push-события обрабатываются без пробуждения главного потока JavaScript. Клиент только регистрирует Service Worker и передает FCM-токен на сервер.

## WayForPay только на сервере

Платежные запросы выполняются исключительно на стороне сервера. Никакие учетные данные продавца WayForPay, HMAC-ключи или логика платежей не попадают в браузер. Клиент отправляет ссылку на заказ; сервер формирует и верифицирует все платежные данные. См. [Интеграция WayForPay](/docs/en/features/wayforpay-integration.md).

## Стратегии рендеринга Next.js 16

Используйте экспорт `force-dynamic`, `force-static` или `revalidate` для каждой страницы, чтобы контролировать рендеринг:

```typescript
// Статическая страница, ревалидируется каждые 60 секунд
export const revalidate = 60

// Полностью динамическая — без кэширования
export const dynamic = 'force-dynamic'
```

Статическая генерация является режимом по умолчанию. Явно помечайте страницы как `force-dynamic`, если они отображают данные конкретного пользователя.

## Показатели производительности

- First Contentful Paint: < 1.5 с
- Largest Contentful Paint: < 2.5 с
- First Input Delay: < 100 мс
- Cumulative Layout Shift: < 0.1
- Сокращение времени сборки благодаря имитации Firebase: ~31%

## Мониторинг

Web Vitals собираются в продакшене. Настройте отслеживание аналитики в среде развертывания. Для анализа во время сборки выполните:

```bash
npm run build
npm run analyze
```

Модуль `firebase-service-manager.ts` также предоставляет внутренние метрики кэша:

```typescript
import { getCacheMetrics } from '@/lib/services/firebase-service-manager'

const metrics = getCacheMetrics()
console.log(`Hit rate: ${metrics.hitRate.toFixed(1)}%`)
```

---

> **Info**
> По ожиданиям производительности для пользователей см. [Производительность (пользователь)](/docs/en/features/performance.md). По мониторингу продакшена и настройке инфраструктуры см. [Производительность развертывания](/docs/en/deployment/performance.md). По общим конвенциям разработки см. [Лучшие практики](/docs/en/development/best-practices.md).