Компьютерные сети
HTTP Performance
Каждые 100ms задержки загрузки = 1% потерь конверсии (Amazon data). HTTP performance напрямую влияет на бизнес-метрики. Compression, caching, preload - базовые техники для любого web developer.
- **Google Search**: каждая millisecond matters для UX и SEO ranking
- **Shopify**: Core Web Vitals улучшение дало +7% conversion rate
- **Netflix**: custom image format, adaptive bitrate, edge caching
Предварительные знания
Response Compression
**Compression** уменьшает размер HTTP ответов в 3-10 раз. Текстовые данные (HTML, CSS, JS, JSON) сжимаются отлично. Бинарные (images, video) - уже сжаты, дополнительная компрессия бесполезна.
**Brotli** (br) даёт на 10-20% лучшее сжатие чем gzip, но медленнее сжимает. Решение: pre-compress статику при build (br level 11), dynamic content через gzip (быстрее).
Не сжимайте: images (JPEG/PNG/WebP уже сжаты), video, fonts (WOFF2 уже сжат), encrypted data. Двойное сжатие может даже увеличить размер.
Почему Brotli часто используют только для статических файлов?
Caching Headers
**HTTP Caching** - ключ к производительности. Правильные заголовки позволяют браузеру/CDN кешировать ресурсы и не делать повторные запросы. Cache-Control - главный заголовок.
**ETag** vs **Last-Modified**: ETag точнее (хеш контента), Last-Modified проще (timestamp). ETag позволяет обнаружить изменения при одинаковом времени.
**304 Not Modified**: когда cache expired, браузер делает conditional request (If-None-Match: ETag). Если контент не изменился, сервер возвращает 304 без body - экономия bandwidth.
Зачем использовать immutable для bundle.js с хешем в имени?
Cache Strategies
Выбор cache стратегии зависит от типа контента: статика с версионированием, динамические API, персонализированные данные требуют разных подходов.
**stale-while-revalidate** - game changer для UX. Пользователь видит данные мгновенно (из кеша), пока в фоне идёт refresh. SWR pattern популярен в React (useSWR hook).
Почему для index.html используют no-cache вместо max-age?
Resource Hints
**Resource Hints** подсказывают браузеру что загружать заранее. Это сокращает waterfall: DNS lookup, TCP/TLS handshake, fetch начинаются раньше, чем браузер 'увидит' ресурс в HTML/CSS.
**HTTP 103 Early Hints** - сервер отправляет preload hints ДО основного response. Пока сервер готовит HTML, браузер уже загружает critical CSS/fonts.
Разница между preload и prefetch?
Critical Rendering Path
**Critical Rendering Path** - цепочка от получения HTML до первой отрисовки. Оптимизация CRP критична для Core Web Vitals (LCP, FID, CLS). Главные враги: render-blocking CSS/JS.
**CSS blocks rendering** потому что браузер не может рисовать без CSSOM. **JS blocks parsing** потому что может модифицировать DOM. defer/async решают это.
Современные frameworks (Next.js, Nuxt) автоматизируют: code splitting, automatic preload, image optimization. Но понимание основ помогает диагностировать проблемы.
HTTP/2 решает все проблемы производительности
HTTP/2 устраняет connection bottleneck, но не решает: render-blocking CSS/JS, большой размер ресурсов, отсутствие кеширования. Compression, caching, critical path оптимизация важны независимо от протокола
HTTP/2 мультиплексирует запросы, но не делает файлы меньше и не убирает blocking. Code splitting, lazy loading, resource hints - всё ещё необходимо.
Почему CSS считается render-blocking, а JS с defer нет?
Итоги
- **Compression**: Brotli для статики (pre-compress), gzip для динамики
- **Cache-Control**: immutable для versioned assets, no-cache для HTML
- **stale-while-revalidate**: мгновенный UX + background refresh
- **Resource Hints**: preconnect для third-party, preload для critical path
Связанные темы
HTTP Performance связана с frontend и infrastructure:
- HTTP/2 и HTTP/3 — Протоколы как foundation для performance
- CDN — Edge caching для static assets
- Latency Numbers — Понимание где теряется время
Вопросы для размышления
- Как измерять реальный impact performance оптимизаций?
- Trade-off между cache hit rate и freshness?
- Когда Service Worker лучше HTTP caching?