Архітектура веб-продуктивності: системний аналіз 12 інженерних принципів (видання 2026)

Веб-продуктивність у 2026 році - це вже не дисципліна мікро-оптимізацій, а сума архітектурних рішень на дванадцяти шарах стеку. У цій статті я розбираю кожен шар через протокольну механіку, конвеєри рендерингу браузерів та реальні дані HTTP Archive 2025 Web Almanac і Chrome User Experience Report (CrUX). По кожному стовпу: яке фізичне або обчислювальне обмеження створює вузьке місце, який інженерний примітив його усуває, і як це вимірювано впливає на Core Web Vitals - LCP, INP та CLS.

Сайт, коректний на всіх дванадцяти стовпах, не просто «відчувається швидшим» - він вимірювано входить у верхні 10% вебу. Deloitte Digital у дослідженні *Milliseconds Make Millions* (2020) показали: покращення швидкості мобільного сайту на 0,1 секунди збільшує роздрібну конверсію на 8,4% та середній чек на 9,2%. І зворотне теж правда: слабкість навіть на одному фундаментальному стовпі - зазвичай це стовп 1 (транспорт) або стовп 10 (діагностика) - обрушить загальний результат незалежно від зусиль на решті.

Стовп 1 - Фізика мережі: транспортні протоколи та компресія

Будь-яка розмова про продуктивність починається на фізичному рівні, бо затримка обмежена швидкістю світла. Round-trip Нью-Йорк - Франкфурт по оптоволокну - близько 80мс. Це жорстка фізична підлога, яку жодна клієнтська оптимізація не знизить. Інженерія може контролювати кількість round-trip, потрібних для доставки сторінки - саме тому вибір транспортного протоколу важливіший за майже будь-яке інше рішення.

HTTP/1.1 вимагає до шести послідовних TCP-з'єднань на origin, кожне зі своїм TLS-handshake (~2 RTT) і TCP slow-start. На нестабільному 4G, де втрати пакетів у польових даних складають 2–4%, архітектура провалюється у Head-of-Line blocking: один втрачений TCP-сегмент стопорить усі наступні потоки. HTTP/2 мультиплексує потоки по одному з'єднанню, але HoL-блокування залишилось на рівні TCP через його гарантію in-order доставки байтів. HTTP/3 (RFC 9114, червень 2022) перебудовує HTTP поверх QUIC (RFC 9000) - UDP-транспорту, де кожен потік незалежно надійний. Втрата пакета в потоці A більше не блокує потік B. За публічними даними Cloudflare, HTTP/3 знижує 99-й перцентиль часу завантаження сторінки на проблемних мобільних мережах на 18–34% порівняно з HTTP/2.

Над транспортом - компресія. Brotli (RFC 7932) розроблений Google спеціально для вебу: його статичний словник попередньо навчений на корпусі типових HTML/CSS/JS токенів, що дає 15–25% переваги за розміром над gzip на текстових асетах. Плата асиметрична: Brotli-11 стискає приблизно у 60 разів повільніше за gzip-6, тому застосовувати його можна лише на етапі білду, не на льоту. Коректна архітектура: перед-компресія на CI/CD (варіанти .br і .gz обидва кладуться на CDN origin), вибір через Accept-Encoding, fallback на gzip лише для клієнтів без підтримки Brotli (у 2026 таких практично немає).

• Архітектурне правило: HTTP/3 на порту 443 з Alt-Svc. Відкат на HTTP/2 для клієнтів без QUIC. Продакшн-бандл не повинен віддаватися по HTTP/1.1, крім юридично обмежених випадків.
• Правило компресії: Brotli-11 на всі текстові асети (HTML, CSS, JS, JSON, SVG, шрифти) на білді. Не стискайте повторно вже стиснені бінарні формати (AVIF, WebP, MP4, woff2) - це чисті втрати.
• Вимірювання: перевіряйте версію протоколу в DevTools → Network → колонка Protocol. http/1.1 у проді - це не edge case, а помилка конфігурації CDN.

Стовп 2 - Конвеєр зображень: інженерія форматів і проблема LCP

Зображення - найважчий клас ресурсів у сучасному вебі. За даними HTTP Archive 2025 Web Almanac, медіанна вага зображень на мобільній сторінці - 1012 КБ, близько 48% від усього трафіку. Оптимізація зображень - це не деталь, а домінуючий важіль впливу на LCP для ~85% сторінок, де елементом Largest Contentful Paint є зображення.

Вибір формату - це компроміс між ступенем стиснення та точністю, який визначається нижнім відео-кодеком. JPEG (1992, DCT) - це підлога. WebP (2010, VP8) дає 25–35% виграшу при тій самій сприйманій якості. AVIF (2019, intra-кадри AV1) зменшує файл ще на 20–50% порівняно з WebP і - що критично - підтримує 10- і 12-бітну глибину кольору та простір BT.2020 для HDR. На типовій продуктовій фотографії 2048×2048 sRGB: JPEG Q80 = 420 КБ, WebP Q80 = 280 КБ, AVIF Q55 = 145 КБ - усі при SSIM вище 0,98.

Елемент <picture> із source за типом - правильний механізм доставки: браузер сам обирає найкращий підтримуваний формат без JS-round-trip. Крім формату, *роздільна здатність* має відповідати відрендереному розміру. Hero-зображення 2000×1500, віддане на 390-піксельний мобільний viewport, марнує ~90% байтів. Це задача srcset + sizes: sizes декларує відрендерену ширину як CSS-вираз; браузер множить на devicePixelRatio і обирає найближчий дескриптор з srcset. Неправильний sizes - часта причина поганого LCP на зовні добре оптимізованих сайтах.

І нарешті, LCP-зображення потребує явної пріоритизації. Атрибут fetchpriority="high" (Priority Hints, Chrome 101+) піднімає ресурс вище дефолтного medium, сигналізуючи preload scanner відправити його до усіх lazy-завантажень. loading="lazy" на не-LCP зображеннях, навпаки, відкладає запит до перетину з viewport. Асиметрія навмисна: одне зображення - гіперпріоритет, усе решта - відкладення.

• Декодування: decoding="async" виводить декод у compositor worker. На hero-зображеннях (>500 КБ декодованого RGBA) це знімає 20–80мс стол головного потоку, що інакше б'є по INP під час скролу.
• Явні розміри: кожен <img> вимагає атрибутів width і height (або CSS aspect-ratio). Без них браузер не може порахувати layout до приходу байтів - пряма причина CLS.
• CDN-трансформація: матриця форматів і розмірів генерується на edge (Cloudflare Images, Vercel Image Optimization, imgix), не коммітиться в git. Типова матриця - 5 ширин × 3 формати = 15 варіантів на оригінал.

Стовп 3 - Типографіка: метрики шрифтів і компроміс FOUT/FOIT

Веб-шрифти оманливо дорогі, бо блокують рендер за замовчуванням. Поки файл шрифта не завантажено, не декодовано і не зіставлено з правилом @font-face, браузер стоїть перед вибором: рендерити невидимий текст (FOIT) або фолбек, який зсуне верстку при приході справжнього шрифта (FOUT). Хибний вибір тут - пряма причина CLS.

Варіативні шрифти (OpenType 1.8, 2016) вирішують половину задачі. Замість восьми woff2 на ваги 100–900 один файл несе неперервну вісь ваги і інтерполює на льоту. Властивість font-variation-settings відкриває доступ до осей. Продакшн Inter variable важить ~120 КБ woff2 - менше, ніж два статичні ваги. Економія мережі складається із subsetting: вирізання невикористовуваних гліфів (кирилиця в англійській збірці, CJK у латинській) зазвичай зменшує файл удвічі.

Стратегію рендерингу задає font-display. Значення не взаємозамінні. swap показує фолбек одразу й підміняє його при завантаженні веб-шрифта - приймає FOUT, відкидає FOIT. optional дає браузеру 100мс бюджету: якщо шрифт не прийшов, він пропускається для цього завантаження - правильний вибір для декоративних шрифтів. Дескриптори size-adjust, ascent-override, descent-override дозволяють підігнати метрики фолбека під веб-шрифт піксель у піксель, зводячи CLS від swap до нуля.

• Preload LCP-шрифта: <link rel="preload" as="font" type="font/woff2" crossorigin>. Пропуск crossorigin тихо інвалідує preload, бо шрифти завжди CORS-запитуються.
• Self-hosting: Google Fonts через fonts.googleapis.com додає DNS-резолв, TCP/TLS handshake та непередбачувану межу кешу. Self-hosting на основному origin швидший у будь-якому вимірі.
• Збіг метрик фолбека: використовуйте screenspan.net/fallback для генерації значень size-adjust, ascent-override, line-gap-override, що обнуляють зсув від swap.

Стовп 4 - Архітектура JavaScript: модель вартості гідратації

JavaScript - найдорожчі байти у вебі. 100 КБ зображення - це мережа і декодер; 100 КБ JavaScript - це мережа, парсер, компілятор, кеш байткоду, головний потік (для виконання) і V8-heap (для утриманих об'єктів). Аналіз Едді Османі *The Cost of JavaScript* (2022, актуалізовано 2025) показує, що mid-range Android (Moto G Power) обробляє JS приблизно в 4 рази повільніше за high-end десктоп. Саме тому JS-важкі сайти чудово працюють у розробці і провалюються в продакшені: залізо розробника не репрезентативне для поля.

React Server Components (RSC), стабілізовані в React 19 і дефолтні в Next.js 15+ - найзначніший архітектурний зсув з часів хуків. RSC виконується лише на сервері, емітить серіалізований UI-output (не HTML, не VDOM - спеціалізований wire-формат) і не додає *жодного байта* в клієнтський бандл. Операційне правило: кожен компонент без state, ефектів, браузерних API та обробників подій має бути RSC за замовчуванням. Клієнтські компоненти (межа 'use client') - явний виняток, а не норма.

Окрім RSC, Islands-архітектура (Джейсон Міллер, 2020) формалізує часткову гідратацію. Кожен інтерактивний віджет - незалежно гідрований острів; статичний HTML між островами не несе JavaScript. Astro - канонічна реалізація; Qwik йде далі з Resumability - серіалізує стан виконання фреймворку у HTML і відкладає гідратацію до першої інтеракції. За продакшн-бенчмарками команди Qwik: 50 КБ Qwik-застосунок віддає ~1 КБ початкового JS проти ~45 КБ еквівалентної React SPA.

• Ціль білду: es2024. Кожен поліфіл в основному бандлі - податок на сучасні браузери, які у 2026 покривають >96% трафіку.
• Dynamic import по інтеракції: const Modal = dynamic(() => import('./Modal')) відкладає модуль до рендеру. Для по-справжньому важких віджетів (3D-сцени, rich-text редактори, плеєри) гейтьте імпорт за обробник події, а не за mount компонента.
• Аналіз бандла обов'язковий: @next/bundle-analyzer або rollup-plugin-visualizer мають крутитися у CI. Непояснені +20 КБ у main chunk - це регресія, що вимагає ревʼю до merge.

Стовп 5 - Critical Rendering Path: CSSOM, layout та containment

Рендеринг-пайплайн браузера має шість стадій: Parse HTML → DOM → Parse CSS → CSSOM → Render Tree → Layout → Paint → Composite. CSS блокує рендер за замовчуванням, бо без CSSOM браузер не може побудувати render tree. Саме тому <link rel="stylesheet"> у <head> напряму гейтить First Contentful Paint.

Коректна архітектура інлайнить *критичний* CSS - правила, потрібні для рендеру above-the-fold - прямо в <head>, решту відкладає. Next.js робить це автоматично через CSS-in-JS інтеграцію; для статичних сайтів - Critters або Beasties (активний форк на 2025). Результат: FCP розблокований одразу по приходу HTML, повний стиль-шит завантажується асинхронно.

CSS Containment (W3C CSS Containment Module Level 2) дає рушію явний дозвіл локалізувати перерахунок стилів, layout і paint. contain: layout paint style на межі компонента обіцяє браузеру, що зміни всередині не торкнуться зовнішнього дерева - рушій пропускає перерахунок решти render tree. Споріднена властивість content-visibility: auto йде далі: піддерево взагалі не layout'иться, поки не наближається до viewport. За прикладами зі специфікації Containment, content-visibility: auto на архіві з 10 000 статей зрізає початкову роботу рендеру на >90%.

• Contain-intrinsic-size: завжди пара до content-visibility: auto, інакше CLS буде катастрофічним при появі елементів у viewport.
• Уникайте layout thrashing: читання layout-залежної властивості (offsetWidth, getBoundingClientRect) після запису в DOM форсує синхронний layout. Класика: спочатку всі читання, потім усі записи в межах кадру.
• Лише CSS-анімації: анімуйте тільки transform і opacity. Анімація top/left/width/height тригерить layout щокадру - на 60Hz це 16,67мс бюджету лише на композицію.

Стовп 6 - Управління сторонніми скриптами: Facade і Partytown

Сторонні скрипти - тихий убивця CWV. HTTP Archive 2025 Web Almanac: медіанна мобільна сторінка вантажить 22 third-party запити на 520 КБ сумарно, топ - Google Tag Manager (~80 КБ min), Intercom/Zendesk (~350 КБ), вбудовані плеєри (~600 КБ). Кожен із них виконується на головному потоці й напряму вносить внесок у Total Blocking Time і INP.

Facade Pattern формалізує інженерну відповідь. Замість їгерного завантаження віджета рендериться статична заглушка (PNG чат-бульбашки, прев'ю відео), візуально невідрізнима від справжнього віджета. Лише при інтеракції - клік або програмний сигнал наміру (mouseenter з dwell) - вантажиться реальний third-party payload. Пакет @next/third-parties постачає facade для YouTube, Google Maps, GTM, Intercom та Zendesk з коробки.

Partytown (Builder.io, 2022) розвʼязує задачу інакше: переселяє скрипти у виділений Web Worker, синхронно проксуючи доступ до DOM через SharedArrayBuffer і service worker. Воркер крутиться у фоновому потоці, і 200мс callback аналітики більше не витісняє кадр анімації на main thread. Компроміс - сумісність: скрипти, що покладаються на синхронний document.write чи браузер-специфічні глобали, можуть ламатися. Partytown - правильна відповідь для GA, HubSpot, Hotjar і Meta Pixel; для решти - facade.

Стовп 7 - HTTP-кешування: stale-while-revalidate і контракт свіжості

HTTP-кеш - найнедовикористовуваніший важіль продуктивності в індустрії. Ментальна модель більшості розробників - «виставляй Cache-Control і сподівайся» - пропускає контракт, що його задає заголовок. Дві директиви, що роблять важку роботу у 2026, - immutable і stale-while-revalidate.

Для хешованих статичних асетів (/static/chunk-8a7b3f.js) правильний заголовок - Cache-Control: public, max-age=31536000, immutable. Директива immutable (RFC 8246) явно каже браузеру, що ресурс за цим URL не зміниться ніколи - це вимикає ревалідацію навіть при ручному reload. Хешоване ім'я - ключ кешу; зміна контенту дає новий хеш і, отже, новий URL. Разом з довгим edge-кешем це повністю прибирає надлишкову мережеву роботу.

Для нехешованих ресурсів - HTML-сторінок, API-відповідей, навігаційних документів - коректний інструмент це stale-while-revalidate (RFC 5861). Cache-Control: public, max-age=60, stale-while-revalidate=86400 означає: віддавати з кешу 60 секунд; після цього - віддавати *застарілу* копію миттєво і асинхронно ревалідувати в origin. Користувач бачить кеш-швидку відповідь щоразу, кеш сам відновлюється на горизонті 24 годин. Next.js вбудовує це в ISR: edge віддає stale, origin перерендерює, наступний запит отримує свіже.

Стовп 8 - Resource Hints: 103 Early Hints і preload scanner

Коли користувач навігує на сторінку, сервер має спершу згенерувати HTML-відповідь, перш ніж браузер побачить теги <link rel="preload">. На динамічній сторінці з 300мс серверного думання це 300мс мережевого простою. HTTP-статус 1xx Early Hints (RFC 8297) і конкретно 103 дозволяють серверу віддати preload-заголовки *до* фінального 200 - накладаючи серверну роботу на мережеву доставку критичних ресурсів.

Підтримка сильна: Chromium 103+, Vercel, Cloudflare, Fastly. Next.js емітить 103 автоматично для шрифтів і CSS. Вимірюваний ефект за даними Shopify 2022: 20–30% зниження LCP на холодних навігаціях, де домінує серверне думання.

<link rel="preconnect"> для критичних third-party origins прогріває DNS, TCP та TLS до того, як браузер попросить ресурс. Застосовуйте максимум до 4–6 origin (handshake сам по собі дорогий); для менш критичних - лише rel="dns-prefetch".

Стовп 9 - Edge Computing: топологія рендерингу і cold starts

Місце рендерингу - архітектурне рішення. Client-side виштовхує обчислення на пристрій - дешево серверу, дорого батареї та LCP. Origin SSR централізує обчислення - дешево клієнту, дорого за затримкою, якщо origin у us-east-1, а користувач у Сінгапурі. Edge SSR (Vercel Edge Functions, Cloudflare Workers, Deno Deploy) рендерить у точці присутності у ~50мс від користувача - отримуючи і маленький бандл SSR-виводу, і низьку затримку близького origin.

Архітектурна пастка - cold start. Традиційна Node.js Lambda стартує 300–800мс; V8 isolates (runtime Cloudflare Workers) - <5мс, бо ізоляти шарять один V8-процес і піднімають лише новий контекст виконання. У 2026 Vercel Fluid Compute переводикористовує інстанси функції між конкурентними запитами, амортизуючи cold-start по всьому життєвому циклу функції. Практичне правило: логіка на кожен запит (auth, A/B-прапорці, гео-роутинг) - в isolate-runtime; довгі або важкі за пам'яттю задачі (image processing, ML-інференс) - Node.js Fluid Compute з 300с таймаутом.

Стовп 10 - Core Web Vitals: формальні визначення і діагностика

Core Web Vitals - не естетичні цілі, а формально специфіковані метрики з протокольною семантикою спостереження від W3C Web Performance Working Group. Усі три репортуються на 75-му перцентилі польового трафіку - тобто ви проходите, лише якщо три чверті користувачів бачать добрий досвід, не медіана.

LCP (Largest Contentful Paint) - час рендеру найбільшого зображення чи текстового блоку у viewport, відносно navigation start. Поріг: <2,5с добре, >4,0с погано. Елемент ідентифікується через PerformanceObserver з entryType largest-contentful-paint. LCP розкладається на чотири підкомпоненти: TTFB, resource load delay, resource load duration, element render delay. Оптимізація має цілитися у домінуючий підкомпонент - preload зображення, не обмеженого шириною каналу, це пуста витрата.

INP (Interaction to Next Paint) замінив First Input Delay 12 березня 2024. На відміну від FID, що вимірював лише затримку на першій взаємодії, INP спостерігає кожну кваліфікаційну інтеракцію за сесію і репортує приблизно 98-й перцентиль. Поріг: <200мс добре, >500мс погано. Кожна інтеракція розкладається на input delay (час у черзі обробника), processing duration (обробник і робота рендеру), presentation delay (від композитора до екрана). Детальний розбір INP - у статті Оптимізація INP у Next.js 16.

CLS (Cumulative Layout Shift) - безрозмірний добуток impact fraction (частка viewport, зачеплена зсувом) і distance fraction (наскільки далеко зсунулись елементи). Поріг: <0,1 добре, >0,25 погано. Вікно вимірювання - «session windows» (до 5с між зсувами, ліміт 5с сумарно), не весь життєвий цикл сторінки - критичний нюанс, що запобігає безконечному накопиченню в довгоживучій SPA. Причини: пізні шрифти без size-adjust, зображення без width/height, реклама/embed без резерву, клієнтський інжект контенту над згином.

Стовп 11 - Відео і медіа: інженерія кодеків та адаптивний стримінг

Автоплей фонового відео - оманливо дорога фіча. 10-секундний 1080p H.264 loop важить ~3 МБ; той самий loop в AV1 (ffmpeg -c:v libaom-av1 -crf 30 -b:v 0) - ~900 КБ, у 3,3 раза менше при тій самій візуальній якості. AV1 - правильний baseline у 2026; апаратний декод на Android та iPhone 15+ робить питання софт-декоду неактуальним.

GIF - антипатерн при будь-якому розмірі вище ~50 КБ: формат 1987 року з палітровою індексацією і без міжкадрового стиснення. 3 МБ GIF тривіально стає 200 КБ muted-looping MP4. Патерн <video autoplay muted loop playsinline> зберігає «просто грає» від GIF при у 10–20 разів кращому стисненні. Атрибут playsinline критичний для iOS: без нього відео відкривається fullscreen по тапу.

Для довгого відео (hero loops >30с, демо, відгуки) обов'язковий HLS або DASH адаптивний стримінг. HLS ріже відео на чанки по 2–6с на кількох сходах бітрейту; плеєр обирає сходинку за виміряним throughput і апгрейдить/даунгрейдить по ходу. Мобільний 4G тягне 480p, десктоп на оптиці апгрейдиться до 1080p у процесі. Без адаптивного стримінгу мобільний користувач платить повну ціну 1080p, а браузер тротлить з'єднання.

Стовп 12 - Real User Monitoring: реальність польових даних

Лабораторні інструменти - Lighthouse, PageSpeed Insights, WebPageTest - показують те, що синтетичний пристрій на синтетичному з'єднанні виміряв. Це діагностичні інструменти, не ранжувальні. Сигнал Google і датасет HTTP Archive побудовані на польових даних: Chrome User Experience Report (CrUX) агрегує анонімізовані заміри від opted-in Chrome-користувачів на 75-му перцентилі за 28-денне вікно.

Архітектурний наслідок: важливий 75-й перцентиль *ваших справжніх користувачів*, не 50-й перцентиль Lighthouse на вашому MacBook M3. Lighthouse і поле розходяться у 3–5 разів для застосунків з важкими клієнтськими обчисленнями, повільними third-party або довгими анімаціями. Єдиний спосіб закрити розрив - інструментувати продакшн клієнтським web-vitals (Google, MIT), форвардити кожне вимірювання у RUM-бекенд (Vercel Speed Insights, DataDog RUM, SpeedCurve, Cloudflare Web Analytics) і сегментувати розподіл за шаблоном сторінки, класом пристрою, гео та типом зʼєднання.

Бібліотека web-vitals - ~2 КБ gzipped, використовує PerformanceObserver для звіту по LCP, INP, CLS, FCP, TTFB без семплювання. Форвардьте асинхронно через navigator.sendBeacon, щоб саме вимірювання не потрапило у INP. Щойно пайплайн живий - задайте бюджет на шаблон сторінки (LCP_p75 <= 2000ms, INP_p75 <= 150ms, CLS_p75 <= 0.05) і ставтеся до його порушення як до регресії, що блокує білд.

Кейс: архітектура Three.js hero на цьому портфоліо

Це портфоліо несе real-time Three.js background - архітектурно це найдорожчий клас віджетів у вебі: WebGL-контекст, сцен-граф, 60Hz render loop і зазвичай 400–800 КБ стисненого бандла. Синхронне завантаження як hero знищило б LCP. Реалізація використовує три накладені техніки.

• Poster-first рендер: hero-кадр - попередньо відрендерений 1200×800 AVIF-постер, саме він LCP-елемент. Three.js-runtime ніколи не на критичному шляху.
• Ініціалізація за наміром: імпорти Three.js і сцен-граф завантажуються за requestIdleCallback і першим сигналом наміру (скрол, hover, 2-секундний таймер - що раніше). INP у вікні першого paint збережено.
• Контейнмент і відкладення нижніх блоків: контактна форма, карусель цін, слайдер відгуків - через next/dynamic({ ssr: false }) із suspense-заглушками, що резервують CLS-безпечні розміри.

Якщо у вашому інтернет-магазині чи маркетинг-сайті є схоже структурне обмеження - важкий hero-віджет, повільний TTFB, уперта регресія INP - почніть з послуги performance-архітектури, подивіться кейси або обговоріть задачу напряму.

Висновок

Веб-продуктивність у 2026 - це не оптимізація після запуску. Це результат дванадцяти архітектурних рішень: протокол, конвеєр зображень, доставка шрифтів, гідратація, rendering path, third-party скрипти, кешування, resource hints, edge-топологія, діагностика vitals, медіа-кодеки та RUM. Пропустив один стовп - отримай 30–60% регресії саме на тій метриці, яку цей стовп тримає, а не скромні 5%. Впровади всі дванадцять правильно - і сайт опиниться у верхньому дециле вебу. Це напряму конвертується у залученість, утримання користувачів і виручку.

Джерела

• HTTP Archive 2025 Web Almanac, State of the Web Report: https://almanac.httparchive.org
• W3C Web Performance Working Group, специфікації Core Web Vitals: https://www.w3.org/webperf/
• Chrome User Experience Report (CrUX): https://developer.chrome.com/docs/crux
• RFC 9114 - HTTP/3 (IETF, 2022)
• RFC 9000 - QUIC Transport Protocol (IETF, 2021)
• RFC 8246 - HTTP Immutable Responses (IETF, 2017)
• RFC 5861 - stale-while-revalidate / stale-if-error (IETF, 2010)
• RFC 8297 - HTTP 103 Early Hints (IETF, 2017)
• Deloitte Digital, *Milliseconds Make Millions* (2020) - бенчмарк впливу на конверсію
• Osmani, A. *The Cost of JavaScript*, Google Chrome DevRel (2022, оновлено 2025)
• Google Search Central, анонс Page Experience та INP (травень 2023): https://developers.google.com/search/blog/2023/05/introducing-inp
• W3C CSS Containment Module Level 2, Editor's Draft
• web-vitals JavaScript library, Google / MIT: https://github.com/GoogleChrome/web-vitals