Производительность — зачем оптимизировать
Производительность веб-приложений напрямую влияет на бизнес-метрики: конверсию, удержание пользователей, SEO-ранжирование и затраты на инфраструктуру. Медленные сайты теряют пользователей и деньги — это доказано исследованиями крупнейших компаний.
Зачем нужно
Задержка имеет измеримую цену: Amazon: +100ms → -1% продаж; Google: +500ms → -20% трафика; Walmart: -1s загрузки → +2% конверсии. С 2021 года Google использует Core Web Vitals как фактор ранжирования. Каждые 100ms на медленных устройствах ощущаются пользователем.
Где используется
- E-commerce: прямая связь скорости и конверсии/выручки
- SaaS: производительность = удержание пользователей
- Медиа: скорость = просмотры страниц, время на сайте
- Мобильные рынки: 3G сети, бюджетные устройства — особенно критично
Основной контент
Влияние производительности на бизнес
Исследованные данные:
Pinterest: -40% TTI → +15% SEO трафик, +15% конверсия
BBC: каждые 1s загрузки → -10% пользователей
Mobify: -100ms TTI → +1.11% конверсия (мобайл)
AutoAnything: -50% время загрузки → +12-13% продаж
Google Search (с 2021):
Core Web Vitals — официальный фактор ранжирования
"Good" статус для всех трёх метрик = конкурентное преимущество
Пользователи vs Производительность
Исследования UX:
< 100ms — мгновенно (пользователь не замечает задержки)
100-300ms — быстро (ощущается плавным)
300-1000ms — машина работает
1-5s — пользователь теряет фокус (bounce rate растёт)
> 5s — пользователь уходит
Мобильные устройства:
50% трафика — мобайл
Медианный телефон в 4x медленнее iPhone 13
4G LTE = 14Mbps, но 3G = 1.6Mbps всё ещё распространён
Когда оптимизировать — правило Кнута
"Преждевременная оптимизация — корень всех зол" — Donald Knuth
Правильный процесс:
1. Measure → Измерь метрики (Lighthouse, RUM, WebPageTest)
2. Analyse → Найди узкое место (waterfall, flamegraph, coverage)
3. Optimize → Исправь конкретную проблему
4. Verify → Измерь результат (A/B тест или before/after)
5. Monitor → Продолжай мониторинг в production
НЕ оптимизируй наугад без данных!
Быстрая проверка производительности
# 1. Lighthouse из командной строки
npx lighthouse https://example.com --view
# 2. PageSpeed Insights API
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?\
url=https://example.com&key=$API_KEY" | jq '.lighthouseResult.categories'
# 3. web-vitals в браузере (console)
import('https://unpkg.com/web-vitals@3').then(({onLCP,onINP,onCLS}) => {
onLCP(console.log);
onINP(console.log);
onCLS(console.log);
});
Уровни оптимизации
Сеть: Сжатие, CDN, кеширование, HTTP/2, preload
Ресурсы: Минификация, tree shaking, code splitting, изображения
Рендер: Critical CSS, defer JS, font-display, lazy loading
Runtime: Виртуализация, мемоизация, Web Workers
Сервер: TTFB, SSR, Edge Computing, ISR
Частые ошибки
- Оптимизация без измерения — "оптимизируем то, что кажется медленным"
- Фокус только на Lighthouse Score, игнорируя RUM — lab ≠ field данные
- Преждевременная оптимизация — тратить время на микро-оптимизации вместо крупных проблем
- Оптимизация только для desktop — 50% трафика с mobile, намного медленнее
Связанные темы
- _MOC Производительность
- Core Web Vitals -- LCP, FID, CLS
- Метрики -- FCP, TTFB, TTI, TBT
- Real User Monitoring (RUM)
- Performance Budget