Рекомендации по производительности
Принцип
«Premature optimization is the root of all evil» — но знание базовых правил — не premature optimization.
Бюджеты производительности
Backend (API)
| Метрика | Целевое значение |
|---|---|
| P50 Latency | < 100ms |
| P95 Latency | < 500ms |
| P99 Latency | < 1s |
| Error Rate | < 0.1% |
| Throughput | Определяется SLO сервиса |
Mobile (iOS / Android)
| Метрика | Целевое значение |
|---|---|
| Cold Start | < 2s |
| Frame Rate | 60 fps (без дропов) |
| Memory Usage | < 150MB (idle) |
| App Size | < 50MB (download) |
| Battery Impact | Минимальный background drain |
Web (Frontend)
| Метрика | Целевое значение |
|---|---|
| LCP | < 2.5s |
| FID / INP | < 200ms |
| CLS | < 0.1 |
| Bundle Size | < 200KB (gzipped) |
| TTI | < 3.5s |
Рекомендации по платформам
Go (Backend)
- Используй пулы объектов (
sync.Pool) для частых аллокаций - Профилируй через
pprofперед оптимизацией - Избегай N+1 запросов к БД — используй batch/preload
- Используй кэширование с разумным TTL
- Контролируй количество горутин
Database
- Индексы на все поля в WHERE / JOIN / ORDER BY
- EXPLAIN ANALYZE для тяжёлых запросов
- Connection pooling (pgbouncer для PostgreSQL)
- Read replicas для read-heavy нагрузки
Общие правила
- Измеряй, потом оптимизируй — без метрик нет оптимизации
- Кэшируй на правильном уровне — CDN > reverse proxy > app > DB
- Pagination обязательна — никогда не возвращай все записи
- Асинхронные задачи — тяжёлые операции в фоновые очереди
- Компрессия — gzip/brotli для HTTP-ответов
Ревью производительности
Перед мержем изменений, затрагивающих hot paths:
- [ ] Запущены бенчмарки (до/после)
- [ ] Проверен EXPLAIN ANALYZE для новых запросов
- [ ] Оценена нагрузка на кэш
- [ ] Нет очевидных N+1 проблем