Які є підходи оптимізації продуктивності вебсторінки?

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

Що це і навіщо

• Оптимізація вебсторінки – процес зменшення часу, необхідного для завантаження і рендеру контенту. Це критично для 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).