Ось готовий урок, створений спеціально для тебе у стилі CS50. Вмикай уяву, ми починаємо!

🎓 Урок: Gzip та Brotli Compression

(Або як запхати слона в сірникову коробку і передати його через інтернет)

1. 🔥 Вступ: проблема та мотивація

Уявіть, що ви переїжджаєте. У вас є величезна купа одягу: футболки, джинси, светри. Ви можете просто скидати це все в коробки як попало. Це займе, скажімо, 10 коробок. А тепер уявіть, що кожну коробку треба відправити поштою, і за кожну ви платите $20. Дорого? Ще й як. А якщо пошта працює повільно, то чекати доведеться вічність.

А що, якби я вам сказав, що можна взяти ті самі речі, використати вакуумні пакети, висмоктати все повітря і вмістити все це... у 3 коробки?

Вміст той самий. Кількість речей та сама. Але об’єм — втричі менший. Доставка дешевша і втричі швидша.

У вебі відбувається те саме. Ваш сервер (склад) відправляє користувачу (вам) файли: HTML, CSS, JavaScript. Це текст. Багато тексту. Якщо ми відправляємо його «як є», ми марнуємо трафік користувача і змушуємо його дивитися на білий екран.

Питання до вас: Ви б хотіли чекати завантаження сайту 5 секунд чи 1.5 секунди, якщо результат на екрані буде абсолютно однаковим?

Відповідь очевидна. Ось чому нам потрібне стиснення (compression). Сьогодні ми розберемо два головних інструменти для цього: старого доброго Gzip та нового потужного Brotli.

2. 🧠 Теоретична база (без сухої академічності)

Давайте зазирнемо під капот. Як комп'ютер може зменшити текст, не втративши при цьому сенсу?

Як це працює? (Аналогія зі "Словником")

Уявіть, що ви читаєте книгу, де дуже часто повторюється фраза "Гаррі Поттер і в’язень Азкабану". Це довга фраза. А що, якби на початку книги ми написали: @ = "Гаррі Поттер і в’язень Азкабану"

І далі в тексті писали б просто @? Ми зекономили б купу сторінок!

Алгоритми стиснення (і Gzip, і Brotli) роблять саме це: 1. Шукають повтори в коді (а в HTML/CSS їх безліч: <div>, class=, function...). 2. Створюють "словник" цих повторів. 3. Замінюють довгі шматки на короткі посилання.

Головні герої:

👴 Gzip

Це стандарт індустрії вже понад 20 років. Він надійний, швидкий і працює на будь-якому пристрої, від старого Android-телефону до суперкомп'ютера. Він базується на алгоритмі DEFLATE (той самий, що в ZIP-архівах).

Суть: Добре стискає, дуже швидко розпаковується.

🧒 Brotli

Це новітня розробка від Google. Він розумніший. На відміну від Gzip, Brotli має вбудований статичний словник. Він заздалегідь знає, що в інтернеті часто зустрічаються слова <html>, <body>, script. Йому не треба вчити їх з нуля для кожного файлу.

Суть: Стискає на 15–20% краще, ніж Gzip, але працює трохи повільніше на етапі стиснення (тому ідеальний для файлів, які не змінюються щосекунди).
Важливо: Brotli працює тільки через HTTPS. Це вимога безпеки сучасних браузерів.

3. 🧪 Приклади (від простого до реального)

Приклад 1: "На пальцях"

Візьмемо рядок: AAAAAABBBBBB (12 символів)

Як це бачить алгоритм стиснення (спрощено): 6A6B (4 символи)

Ми стиснули дані в 3 рази! Браузер отримує 6A6B, розуміє правило і розгортає назад у AAAAAABBBBBB.

Приклад 2: Реальний JSON

Уявіть, що ваш API віддає список користувачів.

Без стиснення (Raw): 100 КБ

[
  {"id": 1, "name": "David", "role": "admin", "active": true},
  {"id": 2, "name": "Alice", "role": "user", "active": true},
  ... (і так 1000 разів)
]

Бачите, скільки разів повторюються слова "id", "name", "role"? Це ідеальна їжа для алгоритмів.

З Gzip: ~30 КБ (Економія 70%) З Brotli: ~26 КБ (Економія 74%)

Приклад 3: Як це виглядає в HTTP

Коли браузер звертається до сервера, він каже: "Гей, я розумію стиснення!" Це заголовок запиту (Request Header): Accept-Encoding: gzip, deflate, br

Сервер відповідає: "Ок, тримай стиснуту версію у Brotli". Заголовок відповіді (Response Header): Content-Encoding: br

👉 Запитання на уважність: Що станеться, якщо браузер НЕ надішле заголовок Accept-Encoding, а сервер спробує віддати стиснутий файл? (Пауза для роздумів) Відповідь: Браузер отримає "сміття" з ієрогліфів, яке не зможе прочитати. Тому сервер завжди перевіряє, що вміє клієнт.

4. 🛠 Практична частина

Час забруднити руки кодом! Виконайте ці завдання, щоб відчути різницю.

Завдання 1: Детектив у DevTools

Відкрийте будь-який популярний сайт (Google, Facebook, Rozetka).
Натисніть F12 -> вкладка Network.
Оновіть сторінку (F5).
Натисніть на перший-ліпший файл (бажано .js або .css).
Знайдіть у розділі Response Headers рядок Content-Encoding.
Що там написано? gzip? br? Чи, може, нічого?

Завдання 2: Node.js (Express) експеримент

Створіть простий сервер. Якщо у вас встановлено Node.js:

const express = require('express');
const compression = require('compression'); // npm install compression
const app = express();

// Спробуйте закоментувати цей рядок і подивитися на розмір відповіді!
app.use(compression());

app.get('/', (req, res) => {
  // Генеруємо дуже довгий рядок
  const heavyText = 'Привіт CS50! '.repeat(10000);
  res.send(heavyText);
});

app.listen(3000, () => console.log('Сервер працює на порту 3000'));

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

Завдання 3: Кейс "Пастка для новачка"

У вас є папка з картинками .jpg та .png. Ви налаштували сервер так, щоб він стискав все підряд Gzip-ом. * Питання: Чи зменшиться розмір картинок? * Підказка: JPEG — це вже стиснутий формат. * Спробуйте: "Зазіпуйте" файл картинки на комп'ютері. Чи змінився розмір? Чому це погана ідея для сервера? (Спойлер: ви просто витратите процесорний час сервера даремно).

5. 💡 Мислення як у розробника

Як думає Senior Developer, коли налаштовує стиснення?

"Текст стискаємо, медіа — ні". Досвідчений розробник знає: стискати треба HTML, CSS, JS, JSON, SVG. Не треба чіпати JPEG, PNG, MP4, WOFF2 (шрифти). Вони вже оптимізовані. Повторне стиснення лише навантажить CPU.
Trade-off: CPU vs Traffic. Стиснення вимагає роботи процесора.
- Динамічне стиснення (On-the-fly): Сервер стискає файл у момент запиту. Це навантажує процесор.
- Статичне стиснення (Build time): Розробник каже: "Я згенерую .js.br і .js.gz версії файлів під час білду (складання) проєкту". Серверу залишається просто віддати готовий файл. Це шлях професіонала.
Brotli > Gzip, але потрібен запасний план. Ми завжди надаємо перевагу Brotli (br), бо він ефективніший. Але ми залишаємо Gzip як fallback (запасний варіант) для дуже старих клієнтів.

6. 🧩 Підсумок

Ось що ми сьогодні розібрали: 1. Проблема: Текст у вебі "пухкий", передавати його довго і дорого. 2. Рішення: Gzip (класика) та Brotli (сучасний стандарт). 3. Механіка: Пошук повторів і заміна їх на короткі символи (словник). 4. Правило: Стискаємо текст, не чіпаємо картинки. Бажано робити це заздалегідь (pre-compression).

Тепер ви вмієте не просто писати код, а й доставляти його користувачу блискавично швидко. Ви дбаєте про трафік користувача, і повірте, він вам за це подумки дякує.

👀 Тизер наступного уроку: Добре, ми стиснули файл і він прилетів швидко. Але навіщо завантажувати його знову, якщо користувач перезавантажив сторінку? Наступного разу ми поговоримо про магію HTTP Caching. Як змусити браузер запам'ятати файл і не турбувати сервер зайвий раз.

А поки що — це був CS50. Щасти! 👋