Front-end

Повне пояснення

Що це і навіщо DOM (Document Object Model) — програмний інтерфейс, що описує структуру документа як дерево об’єктів. Він дозволяє JavaScript‑у читати, змінювати та реагувати на зміни у вмісті сторінки.

Ключові принципи/терміни

• Node – базовий елемент дерева (елемент, атрибут, текст тощо).
• Element – вузол, що відповідає тегу HTML.
• Attribute – властивість елемента (наприклад, id, class).
• Event – подія, що генерується DOM‑вузлом.

Як це працює

1. Браузер парсить HTML‑файл і створює дерево DOM.
2. Скрипт отримує доступ до вузлів через document.getElementById, querySelector тощо.
3. Зміни у вузлах автоматично оновлюють візуальне представлення.

Практика і реалізація (JS/TS)

const btn = document.querySelector('#btn') as HTMLButtonElement;
btn.addEventListener('click', () => {
  const div = document.createElement('div');
  div.textContent = 'Hello, DOM!';
  document.body.appendChild(div);
});

Тестування – можна використовувати Jest + jsdom:

test('adds div on click', () => {
  document.body.innerHTML = '<button id="btn">Add</button>';
  const btn = document.getElementById('btn') as HTMLButtonElement;
  // …підключити обробник і перевірити
});

Безпека – при вставці HTML слід уникати XSS, використовуючи textContent замість innerHTML або бібліотеки типу DOMPurify.

Оптимізація – мінімізуйте кількість змін у DOM, групуючи їх або використовуючи фрагменти (DocumentFragment).

Повне пояснення

Що це і навіщо

• async: завантажує скрипт асинхронно, не блокуючи парсинг HTML. Скрипт виконується одразу після завантаження, незалежно від того, чи завершено парсинг.
• defer: також завантажує скрипт асинхронно, але гарантує виконання лише після завершення парсингу всього документа. Скрипти з defer виконуються у тому порядку, в якому вони оголошені.

Ключові принципи/терміни

• парсинг DOM – процес побудови дерева елементів.
• завантаження (fetch) – отримання файлу скрипта.
• виконання – запуск коду в контексті сторінки.

Як це працює

1. Браузер читає HTML, натрапляючи на тег <script>.
2. Якщо атрибут async присутній, браузер відразу ініціює завантаження скрипта в окремому потоці, не зупиняючи парсинг.
3. Якщо атрибут defer присутній, браузер також завантажує скрипт паралельно, але ставить його у чергу виконання.
4. Після завершення парсингу DOM браузер виконує всі скрипти з defer у порядку їх появи.
5. Скрипт з async виконується, коли завантаження завершено, що може статися в будь-який момент.

Практика і реалізація

<script src="analytics.js" async></script>
<script src="app.js" defer></script>

• analytics.js не залежить від DOM, тому його можна виконати в будь‑який момент.
• app.js потребує, щоб DOM був готовий, тому використовується defer.

Тестування

• Для перевірки порядку виконання можна використати console.log у скриптах і спостерігати порядок в консолі.
• У Jest можна мокнути document.createElement і перевірити, що скрипти додаються з правильними атрибутами.

Особливості в контексті веб‑розробки

• async підходить для сторонніх бібліотек (наприклад, Google Analytics), де порядок виконання не критичний.
• defer ідеально для власних скриптів, що маніпулюють DOM або залежать один від одного.

Оптимізація

• Використання defer з усіма внутрішніми скриптами мінімізує блокування рендеру.
• async зменшує час до першого виконання, але може викликати race conditions.

Часті помилки

1. Використання async для скриптів, що модифікують DOM → помилки «document not ready».
2. Змішування async і defer у одному скрипті → непередбачуваний порядок.
3. Не врахування порядку defer → залежності між скриптами порушуються.
4. Додавання async до бібліотек, що очікують глобальних змінних → непередбачувані результати.
5. Використання defer у старих браузерах (IE < 10) → не підтримується.
6. Додавання async до скриптів, що мають внутрішні import → синтаксичні помилки.
7. Неочікуване виконання async скрипта перед завантаженням CSS → зміни стилів можуть бути не застосовані.
8. Підключення великого скрипта з async → блокування CPU, що впливає на інші ресурси.

Cheatsheet

• async: швидке завантаження, виконання коли готово, незалежно від DOM.
• defer: завантаження паралельно, виконання після парсингу DOM, у порядку оголошень.
• script без атрибутів: синхронне завантаження і виконання, блокує парсинг.

Follow‑up питання

1. Які сценарії краще підходять для async?
2. Як впливають async і defer на SEO та швидкість завантаження сторінки?
3. Чи можна комбінувати async і defer у одному скрипті, і що це означає?

Повне пояснення

Що це і навіщо

• innerHTML – властивість, що повертає або встановлює повний HTML‑вміст елемента. Використовується, коли потрібно динамічно вставити або отримати структуру DOM‑елементів.
• innerText – повертає лише видимий текст елемента, з урахуванням стилів (наприклад, display:none або visibility:hidden). Підходить для отримання чистого тексту без тегів.

Ключові принципи

• innerHTML розбирає рядок як HTML, створюючи нові вузли DOM.
• innerText не парсить HTML, а просто повертає текстовий вузол.
• Обидва властивості синхронні: при записі DOM оновлюється одразу.

Як це працює

1. Читання: браузер читає внутрішній вміст елемента.
   • innerHTML повертає рядок, що містить теги і атрибути.
   • innerText повертає текст, що відображається користувачу.
2. Запис: браузер замінює існуючий вміст.
   • innerHTML парсить новий рядок і створює/видаляє вузли.
   • innerText вставляє текст як простий текстовий вузол, не створюючи тегів.

Практика і реалізація (JS/TS)

const div = document.createElement('div');
div.innerHTML = '<p>Hello <strong>world</strong></p>';
console.log(div.innerText); // "Hello world"

const span = document.querySelector('#mySpan')!;
span.innerText = 'Привіт'; // вставляє лише текст

Тестування

• Jest: expect(element.innerHTML).toBe('<b>Bold</b>');
• Playwright: await page.locator('#id').innerText(); для перевірки видимого тексту.

Безпека

• Використання innerHTML з неперевіреним вмістом може викликати XSS. Завжди очищайте дані перед вставкою.

Оптимізація

• Якщо потрібен лише текст, використовуйте textContent замість innerText для кращої продуктивності.
• Для великих блоків HTML краще створювати DOM‑елементи через document.createElement і додавати їх у фрагмент, а потім вставляти один раз.

Часті помилки

1. Вставка скриптів через innerHTML → XSS.
2. Очікування, що innerText поверне HTML – помилкове розуміння.
3. Використання innerText у браузерах без підтримки – варто перевіряти textContent.
4. Неправильне очищення – не видаляє атрибути, що містять небезпечний код.
5. Використання innerHTML для великих блоків → перерисовка DOM.
6. Заміна innerText на innerHTML → втрати форматування.
7. Не враховує стилі видимості – innerText може повернути текст з display:none.
8. Проблеми з локалізацією – innerText не враховує dir атрибут.

Cheatsheet

• innerHTML: HTML‑рядок → DOM вузли.
• innerText: текст без тегів, враховує видимість.
• textContent: чистий текст без стилів, швидше за innerText.

Повне пояснення

Що це і навіщо Подія bubbling – механізм, що дозволяє одній події «піднятися» від конкретного елемента до його батьків, що спрощує обробку подій у великих DOM‑деревах.

Ключові принципи

• Подія спочатку виконується на елементі, де вона була ініційована (target).
• Потім переходить до батьківського елемента, і так далі, поки не досягне document або window.
• Якщо на будь‑якому рівні викликано event.stopPropagation(), подальше поширення припиняється.

Як це працює

1. Користувач взаємодіє з елементом (наприклад, клікає на кнопку).
2. Відбувається виклик click‑handler на цій кнопці.
3. Після завершення handler’у, браузер викликає click‑handler на батьківському елементі (наприклад, <div>), а потім на його батьку і так далі.

Практика та реалізація

// HTML
<div id="parent">
  <button id="child">Click me</button>
</div>

// JS
document.getElementById('child').addEventListener('click', e => {
  console.log('Child handler');
});

document.getElementById('parent').addEventListener('click', e => {
  console.log('Parent handler');
});

У результаті при кліку на кнопку виведуться обидва повідомлення.

Тестування

import { fireEvent } from '@testing-library/react';

test('bubbling works', () => {
  const parent = jest.fn();
  const child = jest.fn();

  document.body.innerHTML = `<div id="parent"><button id="child">Btn</button></div>`;
  document.getElementById('parent')!.addEventListener('click', parent);
  document.getElementById('child')!.addEventListener('click', child);

  fireEvent.click(document.getElementById('child')!);
  expect(child).toHaveBeenCalled();
  expect(parent).toHaveBeenCalled();
});

Оптимізація та edge cases

• Якщо потрібно обробити подію лише на конкретному елементі, використовуйте event.stopPropagation().
• Для великих списків елементів розгляньте delegation: один слухач на батьку.
• У випадках, коли потрібен лише capture‑фаза, використовуйте третій аргумент true або {capture: true}.

Часті помилки

1. Забудьте про stopPropagation() → непередбачувана обробка.
2. Використання addEventListener без перевірки на дублювання → подвійні виклики.
3. Не враховуєте, що event.target може бути дочірнім елементом.
4. Не розумієте різницю між bubbling і capturing.
5. Відсутність підтримки старих браузерів (IE <9) → attachEvent.
6. Перевантаження одного слухача на великому DOM → продуктивність.
7. Не очищуєте слухачі після unmount у React, що призводить до memory leaks.
8. Не враховуєте pointer-events: none → подія не досягає елемента.

Дизайн‑рішення

• Для реактивних фреймворків (React, Vue) використовуйте synthetic events або useEventListener з бібліотек.
• У Next.js 15 можна обробляти події на сервері через API‑роут, але bubbling відбувається лише в клієнтському коді.

Висновок Bubbling – це фундаментальний механізм DOM, що дозволяє централізовано обробляти події. Розуміння його роботи критично для ефективної розробки UI‑компонентів і оптимізації продуктивності.

Повне пояснення

Що це і навіщо

• stopPropagation() – метод Event, який припиняє подальший bubbling (спливання) події.
• Потрібно, коли дочірній елемент обробляє подію і не хоче, щоб її «поширювали» на батьківські елементи.

Ключові принципи

• bubbling – процес, коли після виконання обробника на елементі подія переходить до його батьків.
• stopPropagation() викликається в момент, коли подія ще не «поширилася».

Як це працює

1. Подія створюється і ініціалізується.
2. Відбувається фазування: capturing → target → bubbling.
3. Якщо в фазі bubbling викликати stopPropagation(), подія не переходить далі.

Практика і реалізація (JS/TS)

const btn = document.getElementById('btn')!;
btn.addEventListener('click', (e) => {
  e.stopPropagation();
  console.log('Button clicked, bubbling stopped');
});

Тестування (Jest + jsdom)

import { fireEvent } from '@testing-library/dom';
const parent = document.createElement('div');
const child = document.createElement('button');
parent.appendChild(child);
let parentCalled = false;
parent.addEventListener('click', () => { parentCalled = true; });
child.addEventListener('click', (e) => e.stopPropagation());
fireEvent.click(child);
expect(parentCalled).toBe(false);

Особливості в контексті React

• У React події – SyntheticEvent. Використовуємо e.stopPropagation() так само.
• Якщо потрібно повністю скасувати подію, також можна викликати e.preventDefault().

Оптимізація та edge cases

• stopPropagation() не скасовує default‑поведінку браузера.
• Якщо потрібен повний контроль, комбінуємо з preventDefault().
• У випадку декількох обробників на одному елементі, stopPropagation() вплине лише на подальші обробники.

Часті помилки

1. Викликати stopPropagation() після preventDefault() – не вплине на bubbling.
2. Забувати, що stopPropagation() працює лише в фазі bubbling (не в capturing).
3. Не використовувати stopPropagation() у глобальних обробниках, коли потрібна реакція на подію в інших частинах DOM.

Cheatsheet

• e.stopPropagation() – зупинити bubbling.
• e.preventDefault() – скасувати default‑поведінку.
• У React: event.stopPropagation() у функції обробника.

Повне пояснення

У браузерному середовищі кожна подія має два ключові механізми: "default action" (наприклад, переходи за посиланням, відправка форми) та "event propagation" (bubble‑ і capture‑фази). Метод event.preventDefault() запобігає виконанню стандартної дії, а event.stopPropagation() перериває подальший поширення в DOM‑дереві. Для повного блокування часто застосовують обидва:

element.addEventListener('click', (e) => {
  e.preventDefault();
  e.stopPropagation();
});

У React події – це SyntheticEvent, тому синтаксис той самий: e.preventDefault(); e.stopPropagation();. Якщо потрібен лише "stop" без «prevent», використовуйте тільки stopPropagation().

Повне пояснення

Що це і навіщо

• this в JavaScript — ключове слово, що посилається на об’єкт, у контексті якого виконується функція. У випадку event handler‑ів це об’єкт, що генерує подію.

Ключові принципи

• DOM‑події: this → елемент, що викликав подію (наприклад, <button>).
• React клас: this → інстанс компонента, якщо обробник не прив’язаний через bind або arrow function.
• React функціональний компонент: this не використовується; замість цього застосовують хуки.
• Arrow function: this захоплює контекст зовнішньої функції.
• bind: this явно встановлюється при створенні обробника.

Як це працює

1. При додаванні слухача (element.addEventListener('click', handler)) браузер зберігає посилання на handler і контекст елемента.
2. При спрацьовуванні події браузер викликає handler.call(element, event).
3. У класах React, якщо обробник не прив’язаний, this буде undefined у strict mode; тому потрібне bind або arrow function.

Практика і реалізація

// DOM‑подія
button.addEventListener('click', function(e) {
  console.log(this); // <button>
});

// React клас
class MyComponent extends React.Component {
  constructor(props) {
    super(props);
    this.handleClick = this.handleClick.bind(this);
  }
  handleClick() {
    console.log(this); // MyComponent instance
  }
}

Тестування

У Jest можна перевірити контекст:

const handler = jest.fn();
button.addEventListener('click', handler);
button.click();
expect(handler.mock.calls[0][0].target).toBe(button);

Безпека і приватність

Неправильне використання this у класах може призвести до помилок, що впливають на логіку UI. Завжди прив’язуйте обробники або використовуйте arrow functions.

Оптимізація

У React функціональних компонентах уникати this зменшує кількість об’єктів і підвищує читабельність коду.

Повне пояснення

Що це і навіщо

• LocalStorage: ключ‑значення сховище, що зберігається між сесіями браузера. Підходить для кешу, налаштувань користувача, токенів тощо.
• SessionStorage: сховище з тим самим інтерфейсом, але дані видаляються після закриття вкладки або браузера. Використовується для тимчасових даних, що не повинні залишатися після сесії.

Ключові принципи

• API: setItem(key, value), getItem(key), removeItem(key), clear(). Значення зберігаються як рядки.
• Синхронний доступ, тому не слід виконувати довгі обчислення в колбеках.
• Обмеження розміру: 5 МБ на домен (може бути 10 МБ у Chrome, 2–3 МБ у Safari). Якщо перевищити, QuotaExceededError.

Як це працює

• Дані зберігаються у IndexedDB‑подібному сховищі, доступному через window.
• При збереженні значення конвертується в рядок за допомогою String(value).
• При отриманні повертається той самий рядок, тому часто використовується JSON.stringify/JSON.parse.

Практика і реалізація

// Зберігання об’єкта
localStorage.setItem('user', JSON.stringify({id: 1, name: 'Ivan'}));

// Отримання
const user = JSON.parse(localStorage.getItem('user')!);

Тестування

• Jest: можна мокати localStorage за допомогою jest.spyOn(window, 'localStorage', 'get').mockReturnValue({ ... });.
• Vitest: vi.stubGlobal('localStorage', { getItem: vi.fn(), setItem: vi.fn() });.

Безпека

• Дані не шифруються; будь‑який користувач може переглянути їх через DevTools.
• Не зберігайте конфіденційні токени; використовуйте HttpOnly cookie.

Оптимізація

• Уникайте великих об’єктів; розділяйте дані на менші ключі.
• Перевіряйте localStorage.length перед записом, щоб уникнути помилок.

Часті помилки

1. QuotaExceededError – перевищено розмір.
2. JSON.parse(undefined) – спроба парсити null.
3. Синхронність – блокування UI при великому записі.
4. Крос‑домен – доступ лише до того домену, що його створив.
5. Відсутність підтримки – старі браузери (IE < 10) не мають.
6. Проблеми з кешуванням – зміни не відображаються миттєво.
7. Проблеми з видаленням – clear() очищує всі ключі, не лише ваші.
8. Проблеми з типами – getItem повертає string | null, треба перевіряти.

Чек‑лист діагностики

• Помилка при записі → перевірте розмір, очистіть localStorage.
• Невідповідність даних → переконайтеся, що парсинг/стрінгфікація коректна.
• Відсутність даних → перевірте, чи не очищується sessionStorage після закриття вкладки.

Альтернативи

• IndexedDB: більший розмір, асинхронний API.
• Cookies: менш простий, але підтримується сервером.
• Service Worker Cache API: для кешування ресурсів.

Повне пояснення

Що це і навіщо

• offsetHeight – фізична висота елемента, включаючи padding, border і scrollbar (не margin). Використовується, коли потрібна реальна розмірність елемента у вікні.
• getBoundingClientRect() повертає об’єкт з координатами елемента відносно viewport. Додаючи window.pageYOffset (scrollY), отримуємо координату відносно верхньої межі документа.

Ключові принципи

• offsetHeight – синхронний доступ, не потребує рендеру.
• getBoundingClientRect() – повертає дробові значення, тому для точності можна округлити.
• pageYOffset (або scrollY) – поточна вертикальна прокрутка.

Як це працює

1. Визначаємо елемент через document.querySelector або інший метод.
2. Отримуємо висоту: element.offsetHeight → число в пікселях.
3. Отримуємо позицію: element.getBoundingClientRect().top → відстань до верхньої межі viewport.
4. Коригуємо на прокрутку: + window.pageYOffset → абсолютна позиція відносно документа.

Практика і реалізація (JS/TS)

const el = document.querySelector('#myBlock') as HTMLElement;
if (el) {
  const height = el.offsetHeight; // 200
  const topFromDoc = el.getBoundingClientRect().top + window.pageYOffset; // 350
}

• У TypeScript тип HTMLElement гарантує доступ до властивостей.

Тестування

• Jest: можна мокати getBoundingClientRect і pageYOffset.

jest.spyOn(window, 'pageYOffset', 'get').mockReturnValue(100);
const mockRect = { top: 50, left: 0, width: 100, height: 200 } as DOMRect;
jest.spyOn(el, 'getBoundingClientRect').mockReturnValue(mockRect);
const top = el.getBoundingClientRect().top + window.pageYOffset; // 150

• Playwright: перевіряємо реальну позицію після прокрутки.

Оптимізація

• Якщо потрібна лише висота, використовуйте offsetHeight – мінімальна операція.
• Для позиції можна кешувати результат, якщо елемент не змінюється під час прокрутки.

Часті помилки

1. Використання clientHeight – не враховує border.
2. Забудьте про pageYOffset – отримаєте позицію відносно viewport, а не документа.
3. Не враховуєте scrollTop у старих браузерах.
4. Використання offsetTop – повертає позицію відносно батьківського елемента, а не документа.
5. Дробові значення – при порівнянні треба округлити.
6. Проблеми з display:none – висота буде 0.
7. Проблеми з transform – getBoundingClientRect() враховує трансформації.
8. Проблеми з position:fixed – позиція відносно viewport, тому треба враховувати прокрутку.

Дизайн‑рішення

• Для динамічних елементів, що змінюються в розмірі, використовуйте ResizeObserver.
• Для позиційних обчислень у реактивному UI – розгляньте useLayoutEffect в React.

Підсумок

Отримання висоти та позиції елемента відносно документа вимагає двох простих властивостей: offsetHeight і сумарної прокрутки (pageYOffset). Це фундаментальний інструмент для розрахунків layout‑у, анімацій і lazy‑loading.

Повне пояснення

Що це і навіщо Webpack — інструмент, що конвертує модулі (ES6+, TypeScript, CSS, зображення) у статичні ресурси, які браузер може виконати. Він потрібен для:

• управління залежностями між файлами;
• трансформації коду (Babel, TS);
• оптимізації розміру бандлів (tree shaking, minification).

Ключові принципи

• Entry – точка входу, з якої Webpack починає збірку.
• Output – місце, куди зберігаються готові бандли.
• Loaders – функції, що перетворюють файли перед їх включенням у граф.
• Plugins – розширення, що виконують додаткові дії (наприклад, HtmlWebpackPlugin генерує index.html).
• Mode – development або production, що визначає оптимізації.

Як це працює

1. Webpack читає entry і будує граф залежностей.
2. Для кожного файлу застосовуються відповідні loaders (наприклад, ts-loader для TypeScript).
3. Після трансформації файли об’єднуються у бандл.
4. Plugins виконують додаткові кроки (генерація HTML, копіювання статичних файлів).
5. Результат зберігається у output.

Практика і реалізація

// webpack.config.js
module.exports = {
  entry: './src/index.ts',
  output: { filename: 'bundle.js', path: __dirname + '/dist' },
  module: {
    rules: [
      { test: /\.ts$/, use: 'ts-loader', exclude: /node_modules/ }
    ]
  },
  resolve: { extensions: ['.ts', '.js'] },
  mode: 'production'
};

Тестування – Webpack сам по собі не тестує, але можна інтегрувати з Jest або Vitest через webpack-jest-transform.

Дизайн‑рішення – для великих проектів рекомендується розділити бандли за entry (наприклад, app.js, vendor.js) і використовувати SplitChunksPlugin.

Производительность – включення cache: { type: 'filesystem' } прискорює повторні збірки.

Безпека – у продакшн‑режимі Webpack автоматично мінімізує код, що зменшує поверхню атаки.

Особливості в контексті JS / TS Core – Webpack є стандартом для створення SPA, але в сучасних фреймворках (Next.js, Vite) часто замінюється більш швидкими альтернативами.

Оптимізація та типові помилки

• Не вказати mode: 'production' → великий бандл.
• Залишити exclude: /node_modules/ у loader‑ах → зайві трансформації.
• Неправильний resolve.extensions → помилки при імпорті без розширення.
• Відсутність output.clean: true → накопичення старих бандлів.

Чеклист діагностики

• Синтаксична помилка в config → Webpack видає чітке повідомлення.
• Missing loader → помилка «Module not found: Can't resolve».
• Бандл не підвантажується → перевірити output.publicPath.

Альтернативи – Vite, Rollup, Parcel. Вибір залежить від вимог до швидкості розробки та складності конфігурації.

Повне пояснення

Що це і навіщо – Dev‑збірка (development build) призначена для локальної розробки: вона зберігає повну інформацію про код, включаючи source maps, що дозволяє відстежувати помилки в оригінальних файлах. Prod‑збірка (production build) створюється для розгортання в продакшн‑середовищі, де важливі швидкість завантаження і безпека.

Ключові принципи/терміни –

• Source maps: карти, що зв’язують мінімізований код з оригінальним.
• Tree shaking: видалення невикористаних експортів під час bundling.
• Minification: стискання коду, видалення пробілів і коментарів.
• Cache‑busting: додавання хешу до імен файлів для контролю кешу.

Як це працює – інструмент bundler (наприклад, Vite/webpack) читає конфігурацію: у режимі dev включає hot‑reload, source maps і не мінімізує код; у prod застосовуються оптимізації: minify, tree‑shake, code splitting.

Практика і реалізація – у Vite:

vite build --mode production   # prod‑збірка
vite build --mode development  # dev‑збірка

У webpack:

module.exports = {
  mode: process.env.NODE_ENV, // "development" або "production"
};

Тестування – для prod‑збірки важливо перевірити, що bundle працює без помилок: Jest + jsdom можна використовувати для unit‑тестів, а Cypress – для end‑to‑end.

Безпека і приватність – у prod‑збірці слід вимкнути console.log, обмежити CORS, встановити CSP‑заголовки.

Оптимізація і масштабування – використання code splitting, lazy loading компонентів, CDN для статичних файлів.

Часті помилки – 1) Відсутність source maps у prod, що ускладнює дебаг; 2) Необхідність вказати правильний NODE_ENV; 3) Залишені console.log у продакшн‑bundle.

Cheatsheet –

• vite build --mode production → prod.
• vite build --mode development → dev.
• У webpack: mode: 'production' мінімізує, mode: 'development' додає source maps.
• Перевірка bundle‑size за допомогою webpack-bundle-analyzer.

Повне пояснення

У браузері кожна подія (наприклад, click, mouseover) ставиться у глобальну чергу event queue. 1️⃣ Що це і навіщо – черга дозволяє асинхронно обробляти взаємодії користувача без блокування UI. 2️⃣ Ключові принципи – FIFO (first‑in, first‑out) гарантує, що події обробляються у тому порядку, в якому вони були отримані. 3️⃣ Як це працює – коли користувач виконує дію, браузер створює об’єкт події і вставляє його в кінець черги. Потім event loop береться з початку черги, викликає відповідний handler і переходить до наступної. 4️⃣ Практика – у JavaScript це видно, коли додаємо кілька listeners на один елемент: вони виконуються послідовно. 5️⃣ Тестування – можна перевірити порядок за допомогою Jest + jsdom, логуючи console.log у кожному handler‑і. 6️⃣ Оптимізація – використання event delegation допомагає зменшити кількість listeners, але порядок обробки залишається FIFO. 7️⃣ Edge cases – якщо handler викликає event.stopImmediatePropagation(), наступні listeners не будуть виконані, але порядок обробки залишиться незмінним для тих, що ще не були викликані. 8️⃣ Часті помилки – неправильне розуміння, що обробка буде LIFO; це трапляється при використанні стеку для власних логічних структур, але не в DOM‑черзі. 9️⃣ Дизайн‑рішення – для критичних UI реакцій можна використовувати requestAnimationFrame або setTimeout(…, 0) для розподілу обробки між кадрами, але це не змінює FIFO‑принципу черги подій.

Повне пояснення

Що це і навіщо

• Event bubbling та capturing — два режими propagation у DOM, що визначають порядок обробки подій від цільового елемента до кореня і навпаки.

Ключові принципи

• Bubbling (підняття) – подія спочатку обробляється на елементі, де вона виникла, а потім «піднімається» через батьківські вузли.
• Capturing (захоплення) – подія «піймається» на шляху від кореня до цільового елемента.
• В обох випадках можна зупинити propagation за допомогою event.stopPropagation() або event.stopImmediatePropagation().

Як це працює

• При виклику addEventListener(type, handler, {capture: true}) обробник підписується на фазу захоплення.
• Якщо флаг {capture: false} (або не вказано), обробник підписується на фазу bubbling.
• Фаза target (ціль) виконується між захопленням і підняттям.

Практика та реалізація

// Capturing
document.addEventListener('click', handler, {capture: true});
// Bubbling (default)
document.addEventListener('click', handler);

Тестування

• У Jest можна перевірити порядок виклику обробників, використовуючи jest.fn() і симуляцію подій через dispatchEvent.

Особливості в контексті React

• У React події обгортаються у SyntheticEvent, який підтримує bubbling. Capturing можна реалізувати через onClickCapture.

Оптимізація та edge cases

• Надмірне використання bubbling може призвести до непередбачуваних побічних ефектів, особливо при глибокій вкладеності.
• Для критичних подій (наприклад, клавіші Escape) часто використовують capturing, щоб перехопити їх на найвищому рівні.

Часті помилки

1. Не розуміння, що addEventListener за замовчуванням працює в bubbling.
2. Застосування stopPropagation у всіх обробниках, що блокує інші слушники.
3. Використання event.target замість this у класових компонентах.
4. Забудова про фазу target, що може вплинути на логіку.
5. Перевантаження кореневого елемента (наприклад, document) обробниками.
6. Неочікуване перехоплення подій у фреймах (iframe).
7. Відсутність preventDefault при необхідності.
8. Використання capture: true у всіх обробниках, що знижує продуктивність.

Cheatsheet

• capture: true → capturing, false або не вказано → bubbling.
• event.stopPropagation() → зупинити подальший propagation.
• event.stopImmediatePropagation() → зупинити інші обробники на тому ж елементі.
• event.target → елемент, де подія виникла; this у синтетичних обробниках React → елемент, на якому підписано слухач.

Повне пояснення

Що це і навіщо

• stopPropagation() – зупиняє bubbling (розповсюдження) події, але інші обробники на тому ж елементі продовжують виконуватись.
• stopImmediatePropagation() – зупиняє bubbling і також перериває виконання всіх наступних обробників на тому ж елементі.

Ключові принципи

• Події в DOM мають три фази: capturing, target і bubbling. Методи працюють лише у фазі target та bubbling.
• stopPropagation() змінює прапорець event.cancelBubble (для старих браузерів) і встановлює event.propagationStopped = true.
• stopImmediatePropagation() додає ще прапорець event.immediatePropagationStopped = true, що блокує виконання подальших listeners.

Як це працює

1. При виклику stopPropagation() браузер продовжує виконувати поточний listener, а далі не передає event‑у в батьківські елементи.
2. При виклику stopImmediatePropagation() браузер не лише зупиняє розповсюдження, а й відразу припиняє виконання всіх наступних listeners на тому ж елементі.

Практика і реалізація (JS/TS)

element.addEventListener('click', (e) => {
  e.stopPropagation(); // зупиняє bubbling
});

element.addEventListener('click', (e) => {
  e.stopImmediatePropagation(); // зупиняє bubbling і наступні listeners
});

Тестування (Jest + jsdom)

import { fireEvent } from '@testing-library/dom';

test('stopPropagation blocks bubbling', () => {
  const parent = document.createElement('div');
  const child = document.createElement('button');
  parent.appendChild(child);

  const spyParent = jest.fn();
  const spyChild = jest.fn((e) => e.stopPropagation());

  parent.addEventListener('click', spyParent);
  child.addEventListener('click', spyChild);

  fireEvent.click(child);
  expect(spyParent).not.toHaveBeenCalled();
});

Особливості в контексті React

• У React synthetic events обгортають native event, але методи stopPropagation і stopImmediatePropagation працюють так само.
• Якщо потрібно зупинити подальші handlers у React, використовуйте e.nativeEvent.stopImmediatePropagation().

Оптимізація та edge‑cases

• Використання stopImmediatePropagation може вплинути на продуктивність, якщо у елементі багато listeners.
• У багатопоточних сценаріях (Web Workers) ці методи не застосовуються.

Часті помилки

1. Заміна stopPropagation на preventDefault – це інша функція, яка лише зупиняє дефолтну поведінку.
2. Виклик stopPropagation у listener, який вже був зупинений попереднім listener‑ом.
3. Не врахування, що stopImmediatePropagation не зупиняє bubbling у фазі capturing.

Cheatsheet

• stopPropagation() – зупиняє bubbling, залишає інші listeners.
• stopImmediatePropagation() – зупиняє bubbling + наступні listeners на тому ж елементі.
• Для React: e.nativeEvent.stopImmediatePropagation() для повної блокади.

Повне пояснення

Що це і навіщо

• Оптимізація вебсторінки – процес зменшення часу, необхідного для завантаження і рендеру контенту. Це критично для UX, SEO та конверсій.

Ключові принципи

• Мінімізація HTTP‑запитів: об’єднуємо файли, використовуємо спрайти.
• Мінімізація розміру payload: gzip/ Brotli, tree‑shaking, dead code elimination.
• Кешування: Cache‑контроль, ETag, Service Worker.
• Lazy‑loading: завантаження компонентів/зображень лише при потребі.
• CDN: географічно розподілені вузли, швидкий доступ.
• Профілювання: Lighthouse, Chrome DevTools, WebPageTest.

Як це працює

1. Bundling: Webpack/ Vite збирають JS/CSS, видаляючи непотрібний код.
2. Compression: Сервер відповідає gzip/Brotli, браузер розпаковує.
3. Caching: При першому запиті сервер встановлює заголовки, а Service Worker обробляє наступні.
4. Lazy‑loading: React.lazy + Suspense або IntersectionObserver для зображень.

Практика і реалізація (JS/TS)

// Lazy‑load компоненту
const Heavy = React.lazy(() => import('./Heavy'));
function App() {
  return <React.Suspense fallback={<Spinner/>}><Heavy/></React.Suspense>;
}

// IntersectionObserver для зображень
const img = document.querySelector('img[data-src]');
new IntersectionObserver((entries, obs) => {
  entries.forEach(e => { if (e.isIntersecting) e.target.src = e.target.dataset.src; });
}).observe(img!);

Тестування

• Unit: перевірка, що компонент рендериться лише після lazy‑load.
• Integration: Jest + @testing-library/react, mock IntersectionObserver.
• E2E: Playwright – вимірювання First Contentful Paint (FCP) і Time to Interactive (TTI).

Безпека та приватність

• CSP: обмеження джерел, щоб уникнути XSS.
• HTTPS: забезпечуєши шифрування і підтримку HTTP/2.

Оптимізація, типові помилки та edge cases

• Необхідність preload критичних ресурсів (font, CSS).
• Перевантаження bundle‑у через неефективний tree‑shaking.
• Застарілий Service Worker, що блокує оновлення.

Чекліст для діагностики

1. Lighthouse score < 80 → перевірити ресурси.
2. Більше 4 HTTP‑запитів → об’єднати.
3. Розмір JS > 200 KB → tree‑shake, split chunks.
4. Немає cache‑headers → налаштувати.

Альтернативи

• Server‑side rendering (SSR) vs Static Site Generation (SSG) – вибір залежить від динамічності контенту.
• React Server Components – зменшують клієнтський JS.

Часті помилки (8)

1. Використання require() замість import → збільшує bundle.
2. Необхідність у eval() → XSS і збільшує розмір.
3. Відсутність async у <script> → блокує рендер.
4. Неправильний Cache-Control → кеш не працює.
5. Перевантаження CDN‑запитів через неправильну конфігурацію.
6. Необхідність у prefetch замість preload → не критично.
7. Відсутність fallback для lazy‑loaded компонентів → 404.
8. Неправильне використання IntersectionObserver у старих браузерах → fallback.

Cheatsheet

• gzip/Brotli → 70‑80 % зменшення.
• preload для font, CSS → 0.5 s FCP.
• lazy‑load з IntersectionObserver → 30 % JS.
• CDN + Cache‑control → 2× швидше.

Follow‑up питання

1. Як вимірювати ефективність оптимізації? – Lighthouse, WebPageTest.
2. Що робити, якщо bundle все ще великий після tree‑shaking? – розділити на чанки, використати dynamic imports.
3. Як забезпечити безпеку при використанні CDN? – HSTS, CSP, Subresource Integrity (SRI).

Повне пояснення

Що це і навіщо

Same-origin policy (SOP) — ключовий захист веб‑програми, що запобігає виконанню скриптів з одного домену доступ до даних, що належать іншому. Це запобігає XSS‑атак і витоку конфіденційної інформації.

Ключові принципи

• Origin — комбінація протоколу, домену і порту. Якщо вони збігаються, доступ дозволений.
• Політика — «запретити» доступ, якщо origin не збігається.

Як це працює

При виконанні DOM‑операцій, HTTP‑запитів або доступу до сховищ браузер перевіряє origin ресурсу. Якщо він не співпадає з origin сторінки, браузер генерує помилку і блокує операцію.

Практика та реалізація

• DOM: document.cookie, localStorage.getItem() – доступ обмежений до того origin, що відкрив сторінку.
• XHR / fetch: fetch('https://api.example.com') з іншого origin блокується, якщо не налаштовано CORS.
• WebSocket: new WebSocket('wss://socket.example.com') – перевірка origin на сервері.
• IndexedDB: indexedDB.open('db') створює базу, доступну лише з того origin.

Тестування

// Jest + jsdom
import { JSDOM } from 'jsdom';
const dom = new JSDOM(`<!DOCTYPE html><p>Hello</p>`, { url: 'https://a.com' });
expect(() => dom.window.localStorage.setItem('x', '1')).not.toThrow();

Безпека

SOP працює в парі з CORS, який дозволяє явно розширити доступ. Без налаштування CORS будь-який cross‑origin запит буде заблокований.

Підсумок

Same-origin policy — це фундаментальний захист, що поширюється на більшість браузерних API: DOM, XHR/fetch, WebSocket, IndexedDB, localStorage, sessionStorage і інші. Він гарантує, що скрипти не можуть читати чи писати дані з інших origin без явного дозволу.

Повне пояснення

Що це і навіщо

• LocalStorage / SessionStorage – простий key/value store, доступний через window.localStorage/sessionStorage. Працює синхронно, обмежений 5 МБ на домен.
• Cookies – також key/value, але надсилаються серверу з кожним HTTP‑запитом; обмеження 4 КБ, підтримка атрибутів HttpOnly, Secure.
• IndexedDB – асинхронний NoSQL‑store, підтримує транзакції, індекси, обробку великих даних (до сотень мегабайт).
• WebSQL – застарілий, не підтримується новими браузерами.

Ключові принципи/терміни

• Scope: LocalStorage – глобальний для домену, SessionStorage – за вкладкою, Cookies – за доменом/піддоменом.
• Lifetime: LocalStorage постійний, SessionStorage – до закриття вкладки, Cookies мають expires/max-age.
• API: синхронний (setItem, getItem) vs асинхронний (open, transaction).

Як це працює

• При записі в LocalStorage/SessionStorage браузер зберігає рядок у локальну базу даних (IndexedDB‑подібна). При читанні виконується синхронний доступ.
• Cookies формуються у заголовку Set-Cookie і зберігаються в кеші браузера; при кожному запиті додаються у заголовок Cookie.
• IndexedDB відкриває базу через indexedDB.open(), створює об’єктні сховища (objectStore) і виконує транзакції.

Практика та реалізація

// LocalStorage
localStorage.setItem('token', 'abc123');
const token = localStorage.getItem('token');

// SessionStorage
sessionStorage.setItem('temp', 'data');

// Cookies (js-cookie)
Cookies.set('user', 'john', { expires: 7, secure: true });

// IndexedDB (idb)
import { openDB } from 'idb';
const db = await openDB('my-db', 1, {
  upgrade(db) { db.createObjectStore('items'); }
});
await db.put('items', { id: 1, name: 'foo' }, 1);

Тестування

• Для LocalStorage/SessionStorage: jest-localstorage-mock.
• Для Cookies: js-cookie mock або @testing-library/react-hooks з renderHook.
• Для IndexedDB: fake-indexeddb або idb-mock.

Безпека та приватність

• Cookies з HttpOnly недоступні через JS, захищають від XSS.
• LocalStorage/SessionStorage доступний скриптам; слід шифрувати чутливі дані.
• IndexedDB не надсилається серверу, але доступний через скрипти; слід обмежувати права.

Переваги/Недоліки

• LocalStorage: простий, швидкий, але обмежений розмір і синхронний.
• SessionStorage: підходить для тимчасових даних, не зберігається після закриття вкладки.
• Cookies: потрібні для аутентифікації, але збільшують розмір запиту.
• IndexedDB: підходить для великих даних, складні запити, але API громіздкий.

Часті помилки

1. Перевищення розміру LocalStorage → QuotaExceededError.
2. Зберігання паролів у LocalStorage → XSS‑ризик.
3. Неочікуване видалення SessionStorage при закритті вкладки.
4. Cookies без Secure піддаються перехопленню.
5. IndexedDB транзакції без await → непередбачувані результати.
6. Використання WebSQL у нових проектах → непідтримка.
7. Неочікуване оновлення Cookies через SameSite=Lax → CSRF.
8. Зберігання великих об’єктів у LocalStorage → блокування UI.

Cheatsheet

• localStorage.setItem(key, value) – синхронно.
• sessionStorage.getItem(key) – синхронно, видаляється при закритті вкладки.
• Cookies.set(name, value, { expires: days }) – HTTP‑запит.
• indexedDB.open(name, version) + транзакції – асинхронно.

Follow‑up питання

• Які обмеження розміру для Cookies і як їх уникнути?
• Як забезпечити безпечне зберігання токенів у браузері?

Повне пояснення

Що це і навіщо

Web worker – це окремий виконуваний контекст, який дозволяє виконувати довгі обчислення або асинхронні операції без блокування UI‑потоку. Це корисно для розрахунків, парсингу великих файлів, роботи з WebSocket тощо.

Ключові принципи

• Isolated context – worker не має доступу до window, DOM, глобальних змінних.
• Message passing – обмін даними відбувається через postMessage/onmessage.
• Structured clone algorithm – копіює об’єкти, підтримує ArrayBuffer, Blob, File, ImageBitmap тощо.
• Transferable objects – можна передати власність на ArrayBuffer або MessagePort, що зменшує копіювання.

Як це працює

1. Головний потік створює worker: const w = new Worker('worker.js');.
2. Для надсилання даних викликається w.postMessage(data);.
3. У worker‑і обробляємо: self.onmessage = e => { /* ... */ };.
4. Для відповіді: self.postMessage(result);.
5. У головному потоці обробляємо: w.onmessage = e => { /* ... */ };.

Практика і реалізація

// main.js
const worker = new Worker('worker.js');
worker.postMessage({cmd: 'sum', nums: [1,2,3]});
worker.onmessage = e => console.log('Result:', e.data);

// worker.js
self.onmessage = e => {
  const {cmd, nums} = e.data;
  if (cmd === 'sum') {
    const res = nums.reduce((a,b)=>a+b,0);
    self.postMessage(res);
  }
};

Комунікація між worker’ами

• MessageChannel: створюємо канал і передаємо один порт одному worker’у, інший – іншому.
• postMessage з посиланням на worker: workerA.postMessage({cmd:'msg', port:portB});.

// main.js
const w1 = new Worker('w1.js');
const w2 = new Worker('w2.js');
const channel = new MessageChannel();
w1.postMessage({port: channel.port1}, [channel.port1]);
w2.postMessage({port: channel.port2}, [channel.port2]);

Тестування

• Jest: мокати Worker і перевіряти виклики postMessage.
• Vitest: використовувати workerize-loader для реального воркера.

Безпека

• Воркери не мають доступу до document, тому XSS‑ризики зменшуються.
• Переконайтеся, що передані дані не містять небажаних скриптів.

Переваги та обмеження

• Перевага: паралельна обробка, не блокує UI.
• Обмеження: немає доступу до DOM, обмежений розмір пам’яті, копіювання великих об’єктів може бути дорогим.

Чеклист діагностики

1. Worker не створюється – перевірте шлях до файлу.
2. onmessage не виконується – переконайтеся, що self використовується у worker‑і.
3. Дані не приходять – перевірте, що об’єкт підтримується алгоритмом clone.
4. Перевищення пам’яті – використовуйте transferable objects (ArrayBuffer).

Повне пояснення

Що це і навіщо

• Transferable‑об’єкти (наприклад, ArrayBuffer, MessagePort) дозволяють передавати дані між воркерами або процесами без копіювання.
• Це критично важливо для продуктивності, коли обробляються великі масиви або медіа‑дані.

Ключові принципи

• Після передачі об’єкт стає «заблокованим» у вихідному контексті – його можна лише читати, але не змінювати.
• Переноситься власність пам’яті; інший контекст отримує новий посилання на ту саму область.

Як це працює

• Відправник викликає postMessage(message, [transfer]), де transfer – масив об’єктів.
• Відправник і отримувач отримують посилання на одну й ту ж пам’ять; копіювання не відбувається.

Практика і реалізація

// main.js
const worker = new Worker('worker.js');
const buffer = new ArrayBuffer(1024);
worker.postMessage({buffer}, [buffer]); // передаємо без копіювання

// worker.js
onmessage = e => {
  const {buffer} = e.data;
  // buffer вже недоступний у main.js
};

Тестування

• У Jest можна перевірити, що об’єкт став недоступним після передачі, використовуючи expect(() => buffer.byteLength).toThrow().

Безпека

• Перенесені об’єкти не можуть бути змінені у вихідному контексті, що зменшує ризик непередбачуваних побічних ефектів.

Переваги

• Зменшення використання пам’яті.
• Підвищена швидкість передачі великих даних.

Обмеження

• Підтримуються лише об’єкти, що реалізують інтерфейс Transferable (ArrayBuffer, MessagePort тощо).
• Після передачі об’єкт не можна використовувати у вихідному контексті.

Часті помилки

• Переведення не‑Transferable об’єктів (наприклад, Uint8Array) викликає помилку.
• Забудова передачі в масиві transfer призводить до копіювання.

Висновок Transferable‑об’єкти – це механізм, що дозволяє ефективно обмінюватися великими даними між контекстами без копіювання, що критично важливо для продуктивності веб‑програми.

Повне пояснення

Що це і навіщо

Ресурсомісткі операції (наприклад, великі масиви, складні обчислення або тяжкі запити) блокують головний потік JavaScript, що призводить до затримок у рендерингу. Оптимізація дозволяє розподілити навантаження, зберегти плавність UI і покращити UX.

Ключові принципи

• Асинхронність: розбивка задач на проміси або async/await.
• Паралелізм: Web Workers, Promise.all.
• Синхронізація з рендером: requestAnimationFrame, setTimeout(0).
• Профілювання: Chrome DevTools Performance, Lighthouse.

Як це працює

1. Web Workers виконують обчислення у окремому потоці, не блокуючи UI.
2. Promise.all дозволяє одночасно виконувати кілька асинхронних запитів.
3. requestAnimationFrame гарантує, що оновлення DOM відбудеться перед наступним кадром.
4. Debounce/Throttle обмежують частоту викликів функцій, що часто спрацьовують (наприклад, scroll, resize).

Практика і реалізація

// Web Worker приклад
const worker = new Worker('worker.js');
worker.postMessage({ data: largeArray });
worker.onmessage = e => console.log('Result', e.data);

// Debounce
const debounced = debounce(() => fetchData(), 300);
window.addEventListener('resize', debounced);

Тестування

• Unit: перевірка функцій, що повертають проміси.
• Integration: Jest + jsdom для перевірки реакції UI на асинхронні оновлення.
• E2E: Playwright для симуляції навантаження і вимірювання FPS.

Дизайн‑рішення

• Lazy loading компонентів (React.lazy + Suspense).
• Code splitting через dynamic import.

Безпека і приватність

Web Workers із власним контекстом не мають доступу до DOM, що зменшує ризик XSS.

Оптимізація і типові помилки

• Не використовувати setTimeout(0) замість requestAnimationFrame для рендеру.
• Не створювати нові функції в циклі без мемоізації.
• Перевіряти, чи не виконується worker занадто часто (наприклад, при кожному scroll).

Альтернативи

• WebAssembly для надзвичайно тяжких обчислень.
• Service Workers для кешування великих ресурсів.

Часті помилки (8)

1. Блокування головного потоку великими синхронними обчисленнями.
2. Перевантаження Web Workers непотрібними задачами.
3. Відсутність fallback для браузерів без підтримки Workers.
4. Необмежене використання Promise.all, що призводить до великої кількості одночасних запитів.
5. Відсутність debouncing у подіях, що спрацьовують часто.
6. Не використання requestAnimationFrame для оновлення UI.
7. Перевантаження DOM через часті маніпуляції.
8. Необережне кешування результатів, що швидко змінюються.

Cheatsheet

• Web Worker: new Worker('file.js')
• Debounce: _.debounce(fn, ms)
• Throttle: _.throttle(fn, ms)
• Lazy load: const Comp = React.lazy(() => import('./Comp'))

Follow‑up питання

• Як вимірювати вплив Web Worker на продуктивність?
• Які критерії вибору між debounce і throttle?

Повне пояснення

ResizeObserver виконує callback у момент, коли розміри елемента змінюються в DOM‑tree. Це відбувається після того, як браузер завершив розрахунок стилів і layout‑у, але до фазі paint. Тому колбек отримує новий розмір ще до того, як елемент буде відображений. Це корисно для підготовки UI (наприклад, оновлення внутрішніх розмірів або позицій) до того, як користувач побачить зміни. Якщо потрібна реакція після paint, треба використовувати requestAnimationFrame або setTimeout(…,0) після колбеку ResizeObserver.

Повне пояснення

Що це і навіщо

Virtual DOM (VDOM) — внутрішнє представлення структури елементів інтерфейсу у вигляді об’єктної моделі, що існує в пам’яті. Його головна мета — мінімізувати прямий доступ до реального DOM, який є дорогим у плані продуктивності.

Ключові принципи

• Абстракція: VDOM відокремлює логіку рендерингу від реального DOM.
• Diff‑алгоритм: порівнює старий і новий VDOM, знаходить мінімальний набір змін.
• Batch‑updates: зміни застосовуються в пакетах, що зменшує кількість перерисувань.

Як це працює

1. Render: компонент повертає JSX/React‑елементи, які трансформуються у VDOM-об’єкти.
2. Diff: React (або інша бібліотека) порівнює новий VDOM з попереднім.
3. Patch: обчислені різниці застосовуються до реального DOM.

Практика і реалізація

function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}

У цьому прикладі при кожному кліку React створює новий VDOM, diff‑ує його і оновлює лише текст у кнопці.

Тестування

Для перевірки, що VDOM працює коректно, можна використовувати react-test-renderer:

import renderer from 'react-test-renderer';
const tree = renderer.create(<Counter />).toJSON();
expect(tree.children[0]).toBe('0');

Дизайн‑рішення

• Key у списках: допомагає diff‑алгоритму правильно ідентифікувати елементи.
• PureComponent / React.memo: запобігає зайвим перерендерингам.

Оптимізація

• Batching: React групує оновлення у один рендер.
• Avoid deep state mutations: мутування об’єктів у стані призводить до повного перерендерингу.

Безпека

VDOM сам по собі не впливає на безпеку, але правильне управління станом і props допомагає уникнути XSS‑уразливостей.

Альтернативи

• Svelte: компілює код у прямий DOM‑маніпуляції без VDOM.
• Vue 3: використовує реактивну систему, але також має VDOM‑подібний підхід.

Часті помилки

1. Мутування стану → викликає непередбачувані оновлення.
2. Відсутність key у списках → погана продуктивність і неправильні анімації.
3. Використання forceUpdate → обходить оптимізації.
4. Надмірне використання useEffect → створює зайві рендери.
5. Відсутність memoization → повторювані обчислення.
6. Неправильне використання ref → може порушити синхронність.
7. Використання dangerouslySetInnerHTML → ризик XSS.
8. Неправильна обробка асинхронних даних → оновлення після unmount.

Cheatsheet

• VDOM – пам’яттєва модель DOM.
• Diff – пошук мінімальних змін.
• Patch – застосування змін до реального DOM.
• Key – унікальний ідентифікатор елементу в списку.
• React.memo – запобігає зайвим перерендерингам.

Follow‑up питання

1. Як працює алгоритм diff у React?
2. Чому важливі ключі в списках?
3. Які альтернативи VDOM існують у сучасних фреймворках?

Повне пояснення

Що це і навіщо

Same-Origin Policy (SOP) обмежує доступ скриптів до ресурсів, що мають різний origin (scheme + host + port). Це запобігає XSS‑атак і несанкціонованому доступу.

Ключові принципи

• Origin – унікальний ідентифікатор ресурсу.
• Same-origin – однаковий origin → повний доступ до DOM, localStorage тощо.
• Cross-origin – різні origins → обмежений доступ, потрібен спеціальний механізм.

Як це працює

1. При завантаженні сторінки браузер визначає origin.
2. Якщо скрипт намагається звернутися до ресурсу з іншого origin, SOP блокує доступ.
3. Для дозволеного спілкування між вкладками використовуються API:
   • postMessage – надсилає повідомлення між окремими вікнами/вкладками.
   • BroadcastChannel – простий спосіб розповсюдження повідомлень між усіма вкладками того ж origin.

Практика і реалізація

// Вкладка A
const channel = new BroadcastChannel('chat');
channel.postMessage({ text: 'Привіт' });

// Вкладка B
const channel = new BroadcastChannel('chat');
channel.onmessage = e => console.log(e.data.text);

Тестування

Для unit‑тестів можна мокати BroadcastChannel або використовувати бібліотеку jsdom з підтримкою postMessage. При інтеграційному тестуванні Playwright дозволяє відкривати кілька вкладок і перевіряти обмін.

Безпека

• Перевіряйте event.origin у onmessage‑обробнику.
• Не довіряйте даним без валідації.

Альтернативи

• localStorage events – старий спосіб, але працює лише між вкладками одного origin.
• Service Workers – можуть пересилати повідомлення через postMessage між вкладками і воркерами.

Часті помилки

1. Забудьте перевірити event.origin → XSS.
2. Використання BroadcastChannel без перевірки підтримки браузера → помилка.
3. Неправильний ключ каналу → повідомлення не доходять.
4. Надмірне використання postMessage → продуктивність.
5. Неочікувані типи даних → помилки парсингу.
6. Відсутність close() → витік пам’яті.
7. Перевищення розміру повідомлення (≈64 KB) → обірвані дані.
8. Необхідність CORS‑заголовків при fetch між origin → блокування.

Cheatsheet

• postMessage: window.postMessage(message, targetOrigin).
• BroadcastChannel: new BroadcastChannel(name) → channel.postMessage(msg), channel.onmessage.
• Перевірка origin: if (event.origin !== expectedOrigin) return;.

Повне пояснення

Що це і навіщо

Content Security Policy (CSP) — політика безпеки, що дозволяє веб‑розробникам вказувати, які джерела контенту (скрипти, стилі, зображення тощо) дозволено завантажувати. Це запобігає виконанню небажаних скриптів, що зменшує ризик XSS‑атак.

Ключові принципи

• Джерела (sources) визначаються через директиви: default-src, script-src, style-src тощо.
• Синтаксис: значення можуть бути 'self', URL, https:, data: тощо.
• Заголовок або <meta http-equiv="Content-Security-Policy">.

Як це працює

Браузер читає заголовок CSP, порівнює кожен запит на ресурс із дозволеними джерелами. Якщо правило не відповідає, браузер блокує запит і генерує повідомлення в консолі.

Практика та реалізація

# У Node.js (Express)
app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', "default-src 'self'; script-src 'self' https://cdn.jsdelivr.net");
  next();
});

Тестування

• Unit: перевірка, що заголовок встановлено у відповіді.
• Integration: використати supertest для GET‑запиту і перевірити заголовок.
• E2E: у Playwright можна page.waitForEvent('response') і перевірити CSP.

Безпека та приватність

CSP допомагає уникнути XSS, але не замінює інші заходи (наприклад, sanitization). Важливо комбінувати CSP з X-Content-Type-Options: nosniff і правильним налаштуванням CORS.

Оптимізація

• Використовуйте nonce або hash для динамічних скриптів.
• Уникайте 'unsafe-inline' і 'unsafe-eval', якщо це можливо.

Часті помилки

1. Відсутність default-src → браузер дозволяє всі ресурси.
2. Неправильний синтаксис → CSP не застосовується.
3. Використання 'unsafe-inline' → XSS‑вразливість.
4. Невірний nonce → скрипти не виконуються.
5. Забагато директив → збільшує складність.
6. Невірний script-src → блокує потрібні CDN‑скрипти.
7. Відсутність report-uri → немає звітів про порушення.
8. Невірний frame-ancestors → дозволяє фрейми з небажаних джерел.

Cheatsheet

• default-src 'self' – дозволити лише власні ресурси.
• script-src 'self' https://cdn.example.com – дозволити скрипти з власного домену і CDN.
• style-src 'self' https://fonts.googleapis.com – дозволити стилі з Google Fonts.
• img-src * data: – дозволити будь-які зображення і data URI.
• report-uri /csp-report – надсилати порушення на сервер.

Повне пояснення

Що це і навіщо

Кешування статичних файлів (скриптів, стилів) зменшує час завантаження сторінки, але у разі оновлення коду браузер може продовжувати використовувати стару версію. Щоб уникнути цього, треба забезпечити зміну URL‑адреси при кожному релізі.

Ключові принципи

• Cache busting – додавання унікального параметра (hash, timestamp) до URL.
• Cache‑control headers – max-age, no-cache, must-revalidate.
• Service‑worker – контроль кешу на стороні клієнта.

Як це працює

1. При збірці проекту інструмент (Webpack, Vite, Next.js) генерує файл з хешем у назві.
2. HTML посилається на цей файл: <script src="/static/js/app.abc123.js"></script>.
3. Коли код змінюється, генерується новий hash (app.def456.js). Браузер бачить інший URL і завантажує новий файл.

Практика та реалізація

• Webpack: output.filename = '[name].[contenthash].js'.
• Vite: автоматично додає [hash] у назву файлів.
• Next.js: next.config.js → output: 'standalone', кешування за замовчуванням.

Тестування

import { render } from '@testing-library/react';
const { container } = render(<App />);
expect(container.querySelector('script[src*=".js"]')).toHaveAttribute('src', /\.abc123\.js$/);

Безпека та приватність

Уникайте Cache-Control: no-store для всіх ресурсів, бо це знижує продуктивність. Використовуйте immutable для файлів, що не змінюються.

Оптимізація

• Preload: <link rel="preload" href="/static/js/app.abc123.js" as="script">.
• HTTP/2 push: сервер може надсилати ресурси разом із HTML.

Часті помилки

1. Залишаєте статичні файли без хешу → браузер кешує.
2. Неправильний Cache-Control → ресурси не оновлюються.
3. Service‑worker кешує старі файли → потрібно правильно обробляти activate.

Cheatsheet

• Hash: [contenthash] → змінюється при змінах.
• Headers: Cache-Control: public, max-age=31536000, immutable для статичних.
• No-cache: Cache-Control: no-cache, must-revalidate для динамічних.

Follow‑up питання

• Як працює service-worker у контексті кешування?
• Які переваги має HTTP/2 push над preload?

Повне пояснення

Що це і навіщо

• requestAnimationFrame (RAF) – функція, що реєструє колбек для виконання перед наступним кадром рендеру. Використовується переважно в анімаціях, іграх та інтерактивних UI.

Ключові принципи

• RAF синхронізується з частотою дисплея (часто 60 Hz), тому колбек виконується приблизно кожні 16.7 мс.
• Якщо вкладка неактивна, браузер приостанавливає виклики RAF, що зменшує навантаження.
• Callback отримує DOMHighResTimeStamp, що дозволяє обчислювати точний час між кадрами.

Як це працює

1. Користувач викликає requestAnimationFrame(callback).
2. Браузер планує виконання callback перед наступним перерисовуванням.
3. Після виклику колбеку, якщо він сам реєструє новий RAF, цикл продовжується.

Практика і реалізація

function animate(time){
  // обчислення позиції, зміна стилів…
  requestAnimationFrame(animate);
}
requestAnimationFrame(animate);

Тестування

• Для unit‑тестів можна замокати requestAnimationFrame через Jest: global.requestAnimationFrame = jest.fn(cb => setTimeout(() => cb(performance.now()), 0));.

Оптимізація

• Не викликайте RAF у вкладках, що не видимі (браузер сам це робить).
• Уникайте тяжких обчислень у колбеку; розділяйте логіку на менші частини.

Часті помилки

• Використання setInterval замість RAF → не синхронізовано, мерехтіння.
• Забудьте про cancelAnimationFrame → витік пам’яті при переходах між компонентами.
• Виклик RAF у циклі без requestAnimationFrame → блокування UI.

Повне пояснення

Що це і навіщо: Мікросервісна архітектура Front‑end App розбиває великий монолітний застосунок на дрібні, автономні частини. Це дозволяє розробникам працювати над окремими фічами без впливу на інші, швидко масштабувати частини за потребою та зменшити час розгортання.

Ключові принципи: незалежність, самодостатність, власний життєвий цикл, окремі репозиторії/пакети, спілкування через HTTP/REST, GraphQL або event‑bus (наприклад, Pub/Sub).

Як це працює: Кожен мікросервіс розгортається у власному контейнері (Docker) або як окремий Next.js / React‑приложення. UI збирається з компонентів, що запитують дані через API‑gateway або безпосередньо.

Практика і реалізація: У Next.js 14/15 можна створити окремі app‑папки для різних мікросервісів, використовуючи app/api для API‑роутів. У React можна розділити код на пакети через Lerna або Turborepo.

Тестування: Unit‑тести для окремих компонентів (Jest, Vitest), інтеграційні тести між мікросервісами (Supertest, Playwright), end‑to‑end тестування через Cypress.

Безпека: Аутентифікація та авторизація через shared auth‑service, CORS‑політика, rate limiting.

Оптимізація: Lazy loading компонентів, code‑splitting, CDN для статичних ресурсів.

Переваги: швидке розгортання, масштабування, ізоляція помилок.

Недоліки: складність оркестрації, збільшення мережевого трафіку, потреба в CI/CD pipeline для кожного мікросервісу.

Повне пояснення

Що це і навіщо Shadow DOM (інкапсуляція) забезпечує ізоляцію стилів і структури компоненту, що запобігає колізіям CSS та JavaScript між різними частинами сторінки. Це ключовий механізм Web Components.

Ключові принципи

• Ізоляція: стилі, скрипти й DOM елементи в Shadow Root не впливають на глобальний документ.
• Mode: open (доступний через JavaScript) або closed (невидимий).
• Slot: механізм для вставки контенту з зовнішнього DOM.

Як це працює

1. Створюється елемент‑хост.
2. Викликаємо attachShadow({mode}) → отримуємо ShadowRoot.
3. Додаємо внутрішні елементи, стилі й скрипти до ShadowRoot.
4. При потребі вставляємо контент у <slot>.

Практика і реалізація

class MyCard extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({mode:'open'});
    shadow.innerHTML = `<style>p{color:red;}</style><slot></slot>`;
  }
}
customElements.define('my-card', MyCard);

<my-card>Текст у слоті</my-card>

Тестування

• Unit: перевірити, що shadowRoot існує і містить очікувані елементи.
• Integration: використати Jest + @testing-library/dom для рендеру компоненту.

Безпека Shadow DOM не обмежує доступ до скриптів, тому слід уникати небезпечного коду всередині компоненту.

Особливості в контексті JS/TS Core

• Підтримується у всіх сучасних браузерах.
• Важливий для створення Web Components, що інтегруються з React/Angular через @webcomponents/custom-elements.

Оптимізація

• Ізоляція зменшує кількість перерисовок, оскільки стилі не застосовуються глобально.
• Використання adoptedStyleSheets (CSS OM) підвищує продуктивність.

Часті помилки

1. Забудьте про mode: 'open' → неможливо отримати доступ до ShadowRoot.
2. Неправильне використання <slot> → контент не вставляється.
3. Перевантаження ShadowRoot великою кількістю стилів → зниження продуктивності.
4. Спроба змінити внутрішні елементи через глобальний CSS → не працює.
5. Вставка скриптів у ShadowRoot без defer → може блокувати рендер.
6. Використання closed mode, коли потрібний доступ з тестів.
7. Неправильне визначення customElements.define → помилка при повторному реєстрації.
8. Забудьте про кросбраузерну підтримку – IE не підтримує Shadow DOM.

Cheatsheet

• attachShadow({mode}) – створює ShadowRoot.
• <slot> – вставка контенту.
• shadowRoot.querySelector – доступ до внутрішніх елементів.

Follow‑up питання

• Як працює adoptedStyleSheets?
• Чи можна використовувати Shadow DOM у React‑компонентах?

Повне пояснення

nextElementSibling – це властивість елемента, що повертає наступний сусід‑елемент у DOM‑дереві. Вона пропускає вузли типу Text, Comment тощо і повертає лише елементи (NodeType 1). Якщо наступний вузол не є елементом, значення буде null.

nextSibling – це властивість, що повертає будь‑який наступний вузол (Text, Comment, Element тощо). Якщо після елемента йде текстовий вузол або коментар, nextSibling поверне його.

Коли використовувати?

• Якщо потрібен лише елемент‑сусід, використовуйте nextElementSibling.
• Якщо треба обробляти всі вузли (наприклад, видаляти пробіли чи коментарі), використовуйте nextSibling.

Приклад коду

const div = document.querySelector('#first');
console.log(div.nextElementSibling); // <p>…</p>
console.log(div.nextSibling);        // #text (пробіл)

Переваги/Недоліки

• nextElementSibling простіший у використанні, коли потрібен лише елемент.
• nextSibling дає повний контроль над усіма вузлами, але потребує додаткової перевірки типу.

Тестування У Jest можна перевірити:

expect(div.nextElementSibling.tagName).toBe('P');

або

expect(div.nextSibling.nodeType).toBe(Node.TEXT_NODE);

Повне пояснення

Що це і навіщо

• Метрики – це вимірювані дані, що відображають стан веб‑сайту.
• Вони використовуються для моніторингу продуктивності, аналізу поведінки користувачів і прийняття рішень щодо оптимізації.

Ключові принципи/терміни

• Load time / LCP (Largest Contentful Paint) – час, коли головний контент стає видимим.
• First Contentful Paint (FCP) – перший момент, коли браузер рендерить щось.
• Time to Interactive (TTI) – коли сторінка стає повністю взаємодійною.
• Bounce rate – відсоток користувачів, що покидають сайт після однієї сторінки.
• Conversion rate – відсоток користувачів, що виконали цільову дію (покупка, підписка тощо).
• Page Views / Sessions – кількість переглядів і сесій.

Як це працює

• Метрики збираються за допомогою інструментів (Google Analytics, Web Vitals API, Lighthouse) або власних скриптів.
• Дані зберігаються у базах (BigQuery, ClickHouse) і аналізуються через дашборди.

Практика та реалізація

• Для збору Web Vitals можна вставити скрипт:

<script>
  import { getCLS, getFID, getLCP } from 'web-vitals';
  getCLS(console.log);
  getFID(console.log);
  getLCP(console.log);
</script>

• У Google Analytics можна налаштувати події для відстеження конверсій.

Тестування

• Використовують Lighthouse (CLI або Chrome DevTools) для автоматизованого тесту швидкості.
• В Jest можна перевірити, що API повертає очікувані метрики:

import { getMetrics } from './metrics';
it('returns load time', () => {
  expect(getMetrics().loadTime).toBeGreaterThan(0);
});

Безпека та приватність

• Метрики не повинні містити персональних даних; використовують анонімізацію IP.
• Дотримання GDPR: користувачі мають можливість відмовитися від збору.

Оптимізація

• Зменшення LCP: оптимізувати зображення, використовувати lazy‑loading.
• Зменшити FID: мінімізувати JavaScript, розділити код.
• Підвищення конверсії: A/B‑тестування UI, поліпшення CTA.

Часті помилки

1. Не вимірювати LCP → не розуміємо, коли користувач бачить контент.
2. Відсутність TTI → сторінка здається «замороженою».
3. Не відстежувати bounce rate → не знаємо, чому користувачі йдуть.
4. Перевантаження даних → великі запити до API збільшують load time.
5. Не анонімізувати IP → порушення GDPR.
6. Відсутність метрик у мобільних пристроях → не розуміємо UX на смартфонах.
7. Не використовувати кешування → збільшує серверний час.
8. Неправильна конфігурація CDN → збільшує RTT.

Cheatsheet

• LCP < 2.5s – хороша.
• FID < 100ms – швидка реакція.
• TTI < 5s – повноцінна взаємодія.
• Bounce rate < 40% – хороша залученість.
• Conversion rate > 2% – ефективна маркетингова кампанія.

Повне пояснення

Що це і навіщо

• mouseleave та mouseout — події миші, що реагують на переміщення курсору.
• mouseleave використовується, коли потрібна реакція лише при виході з конкретного елемента, незалежно від дочірніх.
• mouseout потрібна, коли треба знати про переходи між вкладеними елементами.

Ключові принципи/терміни

• Event bubbling – обидві події підвисають, але mouseleave не спрацьовує при переході між дочірніми.
• Target – елемент, на якому спрацьовує подія; у mouseout це може бути дочірній.

Як це працює

• При переміщенні курсору з елемента на інший, браузер генерує mouseout і, якщо вихід не в дочірній елемент, також mouseleave.
• Якщо курсор переходить між дочірніми вузлами, генерується mouseout, але не mouseleave.

Практика і реалізація

<div onmouseleave={handleLeave} onmouseout={handleOut}>Content</div>

Тестування

• У Jest можна симулювати mouseout і перевірити, що відповідний колбек викликаний.

Особливості в контексті frontend

• У React використовується onMouseLeave/onMouseOut. Важливо розуміти різницю, щоб уникнути зайвих перерендерів.

Оптимізація та типові помилки

• Часто плутають mouseleave з mouseout, що призводить до зайвих обробників.
• Переконайтеся, що не додаєте mouseleave до елементів без дочірніх, якщо потрібна реакція лише на вихід з них.

Диагностика

• Якщо mouseleave не спрацьовує, перевірте, чи немає дочірніх елементів, які захоплюють подію.
• Для mouseout використовуйте event.relatedTarget, щоб визначити, куди переміщено курсор.

Повне пояснення

Що це і навіщо Web Accessibility (WCAG) визначає правила, що дозволяють користувачам з вадами сприйняття, руху чи інтелектуальними обмеженнями ефективно взаємодіяти з веб‑ресурсами. Це не лише етична вимога, а й юридична відповідність у багатьох країнах.

Ключові принципи/терміни

• Perceivable – інформація має бути представлена так, щоб її можна було сприймати (текстові альтернативи для зображень, контрастність).
• Operable – інтерфейс повинен бути керованим клавіатурою, м’яким скролом.
• Understandable – контент і навігація мають бути логічними, простими.
• Robust – сайт повинен працювати з різними браузерами і допоміжними технологіями (screen readers).

Як це працює

1. Використовують семантичні елементи (<header>, <nav>, <main>).
2. Додають ARIA‑атрибути (role, aria-label) для уточнення контексту.
3. Перевіряють контрастність кольорів (WCAG AA/AAA).
4. Забезпечують клавіатурну навігацію (focus‑стилі, tabindex).

Практика і реалізація

<button aria-label="Закрити">✕</button>

// React: focus‑trap для модальних вікон
import { FocusTrap } from 'focus-trap-react';

Тестування

• Unit: axe-core в Jest.

import { toHaveNoViolations } from 'jest-axe';
expect(container).toHaveNoViolations();

• Integration: Lighthouse CI.
• E2E: Playwright з page.keyboard.press('Tab') для перевірки клавіатурної навігації.

Безпека і приватність

• Переконатися, що ARIA‑атрибути не розкривають конфіденційних даних.
• Використовувати aria-live лише для динамічної інформації, що не містить особистих даних.

Оптимізація і типові помилки

• Перевірка контрастності за допомогою color-thief або онлайн‑інструментів.
• Уникати tabindex="-1" без потреби, бо це порушує логіку клавіатурної навігації.

Диагностика

• Симптом: користувач не може перейти до кнопки. Причина: відсутній tabindex або display:none. Дія: додати tabindex="0" і перевірити видимість.

Альтернативи/порівняння

• WCAG vs. Section 508: обидва стандарти, але WCAG більш універсальний.

Часті помилки

1. Відсутність alt‑тексту.
2. Низький контраст кольорів.
3. Кнопки без focus‑стилю.
4. Неправильне використання role="button" на <div>.
5. Перевантаження ARIA‑атрибутів.
6. Необхідність у aria-hidden="true" для елементів, що не потрібні.
7. Застарілі tabindex значення.
8. Відсутність aria-label для іконок.

Повне пояснення

Що це і навіщо

• Drag & Drop + FileReader дозволяють користувачеві швидко завантажувати локальні файли без форм.

Ключові принципи

• dragover/drop‑події, event.preventDefault() для дозволу drop.
• FileReader.readAsText() повертає Promise‑подібний результат через onload.

Як це працює

1. Навешуємо dragover на контейнер: e.preventDefault().
2. Навешуємо drop: отримуємо event.dataTransfer.files[0].
3. Перевіряємо MIME‑тип або розширення (file.name.endsWith('.txt')).
4. Створюємо const reader = new FileReader();.
5. У reader.onload отримуємо reader.result – текст, і вставляємо у елемент.

Практика (JS/TS)

const dropZone = document.getElementById('drop') as HTMLElement;
dropZone.addEventListener('dragover', e => e.preventDefault());

dropZone.addEventListener('drop', async e => {
  e.preventDefault();
  const file = e.dataTransfer?.files[0];
  if (!file || !file.name.endsWith('.txt')) return;
  const reader = new FileReader();
  reader.onload = () => {
    document.getElementById('output')!.textContent = reader.result as string;
  };
  reader.readAsText(file);
});

Тестування – можна мокати FileReader у Jest, перевіряючи, що readAsText викликається з правильним файлом.

Безпека – обмежуємо типи файлів, не виконуючи код з файлу.

Оптимізація – для великих файлів можна використовувати readAsText з slice, але для звичайних .txt‑файлів це не критично.

Повне пояснення

Що це і навіщо

Пробільні символи в HTML (пробіли,

‑) не впливають на кінцевий розмір DOM‑дерева, тому їх видалення не зменшує час рендеру.

Ключові принципи

• Tokenization – парсер перетворює вхідний потік у токени, пробіли між тегами і текстом не створюють нових вузлів.
• Layout – розмір елементів визначається CSS‑правилами, а не кількістю пробілів у HTML.

Як це працює

1. HTML‑парсер читає файл, ігнорує зайві пробіли між тегами.
2. DOM‑дерево формується лише з елементів, атрибутів і текстових вузлів.
3. Render‑tree створюється з DOM‑дерева і CSS‑правил.

Практика і реалізація

Використання інструментів, як‑то HTMLMinifier або Prettier, допомагає видаляти зайві пробіли, але це не впливає на швидкість рендеру.

Тестування

Порівняння часу завантаження з curl -w %{time_total} або в DevTools → Performance.

Оптимізація продуктивності

• Мінімізація CSS/JS – зменшує кількість HTTP‑запитів.
• Lazy‑loading – відкладене завантаження зображень і скриптів.
• Critical CSS – вбудовування критичних стилів у <head>.

Accessibility

Немає прямого впливу, але чистий HTML полегшує читання скриптами.

Безпека та валідація

Пробіли не створюють XSS‑вразливостей, але правильна валідація HTML важлива.

Типові помилки й edge cases

• Перевантаження DOM через зайві <div>‑контейнери.
• Неправильне використання   замість пробілу, що створює зайві вузли.

Cheatsheet + follow‑up питання

• Чи впливає видалення пробілів на SEO? – Ні, лише на читабельність.
• Які інструменти можна використовувати для мінімізації HTML? – html-minifier-terser, gulp-htmlmin.