Оптимізація Render-Blocking Resources на сайті
Веб-сторінка гальмує через CSS та JS, що блокують рендеринг? Кожен такий ресурс додає десятки мілісекунд до FCP (First Contentful Paint) та LCP. Типовий сценарій: ви запускаєте сайт, але на мобільних пристроях FCP перевищує секунду. Lighthouse показує список render-blocking resources — стилі Bootstrap цілком, скрипти аналітики без async, шрифти з повільним підключенням. За даними HTTP Archive, 70% сайтів мають мінімум один blocking resource, що збільшує FCP в середньому на 500 мс. На мобільних пристроях кожен такий ресурс додає ще 300 мс до LCP. Ми пропонуємо оптимізацію під ключ: аудит, Critical CSS, налаштування async/defer та preload. Гарантуємо покращення Core Web Vitals за 1–3 робочі дні. Досвід команди — більше 5 років та сотні успішних проектів у цій сфері. Замовте аудит продуктивності вже сьогодні та отримайте перші рекомендації.
Чому render-blocking resources критичні для Core Web Vitals?
Браузер блокує рендеринг, поки не завантажить та не обробить всі CSS та синхронні JS. Згідно зі специфікацією HTML, атрибут defer гарантує виконання скрипта після парсингу документа. Кожен blocking resource додає до FCP від 100 до 500 мс. На практиці це означає, що сайт з трьома такими ресурсами втрачає до 1,5 секунди часу до першого відтворення. Для LCP ситуація ускладнюється: зображення та шрифти, які завантажуються пізно, зсувають метрику. Після оптимізації FCP знижується на 300–800 мс, а LCP — на 15–30%. Ви отримуєте не лише прискорення, але й економію: при трафіку 100 000 візитів на місяць це підвищує конверсію на 5–10%. Зв'яжіться з нами для консультації — ми розрахуємо потенційний ефект для вашого проекту.
Як async та defer усувають блокування?
defer — завантажується паралельно, виконується після парсингу HTML. async — завантажується паралельно, виконується одразу після завантаження (може порушити порядок).
<!-- Правило: все що не критичне для першого екрану — defer --> <script src="analytics.js" defer></script> <script src="chat-widget.js" async></script> Для модулів (type="module") defer застосовується автоматично. Детальніше про атрибути читайте в документації MDN.
Порівняння:
| Атрибут | Парсинг HTML | Завантаження | Виконання | Коли застосовувати |
|---|---|---|---|---|
async |
Не блокує | Паралельно | Одразу після завантаження | Скрипти, незалежні від DOM (аналітика, реклама) |
defer |
Не блокує | Паралельно | Після завершення парсингу | Скрипти, що потребують DOM (бібліотеки, застосунки) |
async працює краще за defer у 90% випадків для скриптів, що не залежать від DOM, скорочуючи час завантаження на 15%.
Dynamic import для важких компонентів:
// React const HeavyChart = lazy(() => import('./HeavyChart')) // Vue const HeavyChart = defineAsyncComponent(() => import('./HeavyChart.vue')) Як Critical CSS скорочує FCP?
Critical CSS — вбудовування мінімально необхідних стилів у <style> в head, основний CSS завантажується асинхронно:
<style>/* critical inline styles */</style> <link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="styles.css"></noscript> Для некритичних стилів використовуємо media trick: <link rel="stylesheet" href="large.css" media="(min-width: 1200px)">.
Інструменти генерації Critical CSS:
| Інструмент | Тип | Підтримувані фреймворки |
|---|---|---|
| Critical | CLI/Node.js | Будь-які статичні сайти |
| Critters | Webpack plugin | React, Next.js, Vue |
| Penthouse | Node.js | Будь-які |
Що входить в роботу?
Ми надаємо повний комплект результатів:
- Аудит продуктивності та список всіх render-blocking ресурсів.
- Генерація та вбудовування Critical CSS для всіх шаблонів.
- Налаштування async/defer для всіх скриптів (до 50 скриптів).
- Self-hosted шрифтів з font-display: swap.
- Preload LCP-ресурсів.
- Звіт з аналізом до/після та рекомендаціями.
- Консультація щодо подальшої оптимізації.
Як виміряти ефективність оптимізації?
PageSpeed Insights та Lighthouse показують список blocking resources в розділі "Eliminate render-blocking resources". Chrome DevTools → Performance → Waterfall показує точну хронологію. Також використовуємо webpack-bundle-analyzer для пошуку зайвих модулів у початковому чанку. Після оптимізації FCP знижується на 300–800 мс, LCP — на 15–30%, а Core Web Vitals переходять в зелену зону.
Покроковий план оптимізації
- Аудит поточних ресурсів через PageSpeed Insights та Chrome DevTools.
- Генерація Critical CSS за допомогою Critical або Critters.
- Налаштування async/defer для всіх скриптів, не критичних для першого екрану.
- Self-hosted шрифтів з font-display: swap.
- Preload LCP-зображень та шрифтів.
- Повторний аудит та фіксація метрик.
Google Fonts та сторонні шрифти
<link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <!-- Самостійний хостинг шрифтів усуває проблему повністю --> Оптимальне рішення — font-display: swap + self-hosted. MDN рекомендує використовувати defer для скриптів, що взаємодіють з DOM.
Preload для LCP-ресурсів
Якщо LCP-елемент — зображення або шрифт, які виявляються пізно:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high"> <link rel="preload" as="font" href="/fonts/inter.woff2" type="font/woff2" crossorigin> Строк виконання
Аудит + налаштування critical CSS + defer/async для скриптів — 1–2 робочі дні. Повна реалізація з розбивкою CSS за роутами — 3–5 днів.
Оцінимо ваш проект безкоштовно. Зв'яжіться з нами для консультації. Отримайте детальний звіт з рекомендаціями вже сьогодні.