HTTP/1.1 дозволяє на одному з'єднанні лише один запит за раз. Браузер відкриває близько 6 з'єднань на домен, і решта запитів чекає в черзі. Звідси старі прийоми оптимізації:
- об'єднувати запити - «товсті» ендпойнти, що повертають усе для екрана одразу;
- «шардинг» доменів -
api1.,api2., щоб обійти ліміт з'єднань; - склеювання ресурсів, спрайти.
HTTP/2 мультиплексує: багато запитів паралельно в одному з'єднанні, плюс стиснення заголовків (HPACK). HTTP/3 робить те саме поверх QUIC (UDP): втрата пакета в одному потоці не блокує інші, швидше встановлення з'єднання, краще поводження при зміні мережі (Wi-Fi → мобільна).
Що це змінює для API:
- дрібні запити стали дешевшими. Кілька паралельних
GETдо різних ресурсів більше не впираються в ліміт з'єднань. Агрегувальні «все-в-одному» ендпойнти менш потрібні, а дрібні ресурси краще кешуються окремо; - шардинг доменів шкідливий: кожен домен - окреме з'єднання з TLS-рукостисканням, і мультиплексування втрачається;
- заголовки дешеві - стиснення HPACK/QPACK зменшує вартість повторюваних заголовків (
Authorization, cookies); - довгі з'єднання для стримінгу (SSE) не займають ліміт браузера: на HTTP/1.1 кілька вкладок з SSE вичерпують 6 з'єднань, на HTTP/2 - ні.
Чого HTTP/2 не скасовує:
- затримка (latency) кожного запиту лишається: послідовні залежні запити («водоспад» - спершу користувач, потім його замовлення, потім товари) все одно повільні. Від водоспаду захищає проєктування (
include, вкладені ресурси), а не протокол; - вартість на сервері: паралельні запити - це паралельна робота PHP-воркерів і бази;
- Server Push з HTTP/2 практично мертвий - браузери прибрали його підтримку; замість нього -
103 Early Hintsіpreload.
Де вмикається: HTTP/2 і HTTP/3 налаштовуються на вебсервері чи CDN (Nginx, Caddy, Cloudflare), а не в Laravel. Для API за CDN клієнт спілкується з CDN по HTTP/3, а CDN з сервером - по HTTP/1.1 чи 2, і переваги для клієнта все одно є.
Перевірка: колонка Protocol у DevTools (h2, h3) чи curl --http2 -I.
