Чому HTML5-ігри швидше завантажуються

Вступ: швидкість = конверсія

Для ігор в браузері «швидше завантажується» означає: менше байтів, менше запитів, менше очікування першого кадру. HTML5-стек (HTML/CSS/JS/WebGL/WASM) дає сучасну доставку і кешування «з коробки», а значить - короткий TTFB, низький LCP і швидкий Time-to-First-Interaction (TTFI).

1) Мережа і транспорт: чому веб швидше за замовчуванням

HTTP/2 и HTTP/3 (QUIC)

Мультиплексування: десятки асетів (спрайти, чанки коду) йдуть одним з'єднанням - немає «штормів» TCP.

0-RTT и TLS 1. 3: швидке рукостискання, коротше шлях до першого байта.

Пріоритизація потоків: критичні асети (ініціалізація рушія, головний атлас) отримують більший пріоритет.

CDN і кеш на краю

POP-вузли ближче до гравця, кешують незмінні асети (хеш-імена).

'stale-while-revalidate'дозволяє показувати стару версію і паралельно підтягувати нову.

Заголовки (рецепт):


Cache-Control: public, max-age=31536000, immutable
Content-Encoding: br//для JS/CSS (Brotli)
Cross-Origin-Resource-Policy: cross-origin
Timing-Allow-Origin:

2) Бандлінг і код-спліт: доставляємо «рівно стільки, скільки потрібно»

ES-модулі та динамічний імпорт

Ділимо код на level packs: «лобі», «туторіал», «рівні 1-3», «магазин».

Перший екран отримує тільки ініціалізаційний чанк (50-150 КБ gz/br). Решта - на вимогу.

Tree-shaking і мініфікація

Видаляємо невикористовувані API рушія/бібліотек.

Terser/LightningCSS + module sideEffects = false для агресивної вирубки мертвого коду.

Приклад динамічного завантаження:

js
//Завантажуємо бойовий рендерер тільки при старті бою const {BattleRenderer} = await import ('./chunks/battleRenderer. js');
new BattleRenderer(). mount(canvas);

3) Асети: основна економія байтів

Зображення

WebP/AVIF для UI/ілюстрацій: мінус 25-50% до розміру проти PNG/JPEG.

Спрайт-листи і атласи зменшують кількість запитів і накладні витрати.

Device/Client Hints: `Accept-CH: DPR, Width, Viewport-Width'→ сервер/edge віддає потрібний розмір.

3D/Текстури

Basis/UASTC (KTX2): універсальне стиснення GPU-текстур (ETC1S/ASTC/BC) - вантажимо один файл, розпаковуємо у форматі відеокарти.

Міп-рівні завантажуються прогресивно: спочатку низька якість → потім апсемпл.

Аудіо

Opus замість MP3/AAC - краще при низьких бітрейтах; стрімінг доріжок на вимогу (музика зони - після входу в зону).

Відео/кат-сцени

WebCodecs/MediaSource і LL-HLS для коротких роликів; постер і перший сегмент - передзавантаження, решта - ліниво.

4) Ініціалізація рушія: спершу «скелет», потім «м'ясо»

Lazy scene graph

Завантажуємо тільки критичні вузли сцени (UI, камера, фон). Моделі/шейдери - по першій необхідності.

Фонові asset jobs: завантажувач тримає чергу з пріоритетами.

Service Worker (SW) як «теплий кеш»

Інсталюється на першому візиті і кешує ядро клієнта, маніфест атласів, шейдери.

При повторному вході - оффлайн-готовність і TTFI ~ миттєво.

Приклад стратегії SW (спрощено):

js self. addEventListener('fetch', e => {
e. respondWith(caches. open('game-v12'). then(async c => {
const cached = await c. match(e. request);
const fresh = fetch(e. request). then(r => { c. put(e. request, r. clone()); return r; });
return cached          fresh;
}));
});

5) WebGL и WASM: «нативна» швидкість в браузері

WebGL/WebGPU: шейдери і рендер - на GPU; CPU залишається на логіку.

WebAssembly (WASM): важкі частини рушія (фізика, шлях, розпакування текстур) працюють майже як нативні бібліотеки.

Потоки (Web Workers): декод текстур/аудіо, парсинг рівнів, підготовка мішей - без блокувань основного потоку.

Оптимізація першого кадру (FTF - First Time to Frame):

Заради FTF жертвуємо «красою»: вантажимо low-poly/low-res, до-стрімимо high-res пізніше.

6) Пріоритизація завантаження: даємо важливому пройти першим

HTML-підказки:

html
<link rel="preconnect" href="https://cdn. example. com">
<link rel="preload" as="script" href="/app. a1b2c3. js" crossorigin>
<link rel="preload" as="image" href="/atlases/ui@1x. avif" imagesrcset="/ui@2x. avif 2x">

Fetch-пріоритети і'fetchpriority '

' fetchpriority =» high»'- ініціалізаційний JS і атласи UI.

Інші асети - «low», щоб не заважати критичному шляху.

7) Метрики і SLO «швидкої» HTML5-гри

Цільові орієнтири:

TTFB <200-300 мс (з CDN).
LCP (лобі) <1. 8–2. 5 з на мобільному.
Time-to-First-Interaction (TTFI) < 2–3 с.
First Frame In-Game <1-2 с після старту сцени.
Total Download (перший запуск): ≤ 1-3 МБ на лобі, ≤ 5-10 МБ до першого бою/рівня.
Повторний запуск: ~ 0-200 КБ завдяки SW-кешу.

Спостережуваність: RUM-події по мережах/гео/пристроях, Web Vitals, прогрес завантажувача, відмови по тайм-аутах.

8) Пайплайн збірки: як отримати «тонкий перший байт»

1. Аналіз бандла (source-map-explorer, webpack-bundle-analyzer).

2. Код-спліт за сценами/фічами, видалення «товстих» поліфілів (таргетуємо сучасні браузери).

3. Мініфікація: Terser/ESBuild + CSS Minify, видалення dev-логіки.

4. Зображення: 'sharp/squoosh'→ AVIF/WebP, генерація'srcset'.

5. Текстури: конверт в KTX2 (Basis/UASTC), створення міпів.

6. Аудіо: Opus VBR 48-96 kbps, кліпи - укорочені прев'ю.

7. Маніфест асетів (артефакт) + hash-імена +'immutable'.

8. PWA/SW: предкеш ядра, runtime-кеш атласів з'stale-while-revalidate'.

9. CDN: Preload-хінти,'Surrogate-Control', Soft-Purge за тегами.

9) Продуктивність рантайму: щоб гра «літала» після завантаження

Main-thread budget: тримайте JS-таски <50 мс; важке - в Workers.

Батч-рендер: групуйте draw-calls, використовуйте інстансинг.

GC-тиск: орендуйте масиви/буфери, уникайте «сміття» в ігрових тиках.

Адаптивний FPS: знижуйте якість пост-ефектів при падінні FPS, не чіпаючи геймплей.

10) Анти-патерни (що робить гру повільною)

Один монолітний бандл 5-15 МБ «на старт».

PNG-текстури без компресії GPU, відсутність KTX2/Basis.

«rng% N» у завантажувачі асетів (детермінованість важливіша - але це ще й про PF).

Запити без кеш-заголовків або без хеш-імен → кожен візит «холодний».

Поліфіли для всього світу (IE, старі Safari) - тягнемо мегабайти даремно.

Відсутність SW/передзавантажень - повторні візити такі ж важкі, як перший.

«Важкі» шрифти (кілька накреслень без'unicode-range'і'font-display: swap`).

11) Чек-лист швидкої HTML5-гри

Мережа та CDN

HTTP/3 включено;'preconnect'до CDN/провайдерів.
`Cache-Control: immutable` + hash-имена; `stale-while-revalidate`.

Код і бандли

Код-спліт по сценах; ES-модулі; tree-shaking.
Ініціалізаційний JS ≤ 150 КБ br; карти коду окремо.

Асети

WebP/AVIF для UI; KTX2 Basis/UASTC для текстур.
Атласи і міпи; аудіо Opus; ледачі відео/ролики.

PWA/кеш

Service Worker: предкеш ядра, runtime-кеш атласів.
Повторний візит вантажиться «з теплого» кеша.

Пріоритети

'preload'критичних чанків/атласів;'fetchpriority'для важливого.
Низький пріоритет на другорядні сцени.

Метрики

TTFB/LCP/TTFI/FTF/Download-budget на дашборді.
Алерти по зростанню ваги, падіння hit-ratio CDN.

12) Міні-рецепти заголовків

Статика (JS/CSS/атласи):


Cache-Control: public, max-age=31536000, immutable
Content-Encoding: br

JSON-маніфести сцен (часто змінюються):


Cache-Control: public, max-age=60, stale-while-revalidate=120
Surrogate-Control: max-age=60, stale-if-error=600

Шрифти:


Cache-Control: public, max-age=31536000, immutable
Cross-Origin-Resource-Policy: cross-origin

HTML5-ігри завантажуються швидше, тому що веб-платформа поєднує ефективний транспорт (HTTP/2-3, TLS 1. 3), розумну доставку (CDN, кеш, передзавантаження), легкі асети (WebP/AVIF, KTX2, Opus) та інкрементальну ініціалізацію (код-спліт, ліниві сцени, SW-кеш). Додайте WebGL/WASM і сувору дисципліну метрик - і перший кадр з'являється за секунди, а повторний вхід стає майже миттєвим.