Оптимізація зображень: WebP, AVIF, lazy loading — повний гайд

Зображення становлять 50–70% ваги середньої сторінки — про це свідчать дані HTTP Archive. Неоптимізовані картинки — головна причина повільного завантаження та поганих Core Web Vitals. Ми щорічно опрацьовуємо десятки проєктів із цією проблемою, і щоразу бачимо приріст LCP на 30–50% після впровадження стиснення та lazy loading.

Типовий кейс: інтернет-магазин з 10 000 товарів. До оптимізації середня вага сторінки — 3,5 МБ, LCP — 4,2 с. Після конвертації в WebP, налаштування srcset та відкладеного завантаження поза екраном вага впала до 1,2 МБ, LCP — 1,6 с. Конверсія зросла на 12%. Як цього досягли — розберемо нижче.

Чому варто оптимізувати зображення?

Google враховує LCP та CLS у ранжуванні. Кожен зайвий мегабайт знижує конверсію на 2–3%. Хороша оптимізація — найшвидший спосіб підвищити швидкість і пройти Core Web Vitals. Багаторічний досвід показує: грамотне налаштування зображень окупається за тиждень-два. Ми гарантуємо покращення показників LCP та CLS після наших робіт.

Що дають формати WebP та AVIF?

WebP стискає JPEG без втрат на 20–30%, з втратами — на 25–35%. AVIF стискає ще ефективніше: до 40–60% порівняно з JPEG. При цьому AVIF підтримує HDR та 10-бітну глибину кольору. Якщо у вас багато фотографій товарів — AVIF дасть відчутну економію. Для ілюстрацій з різкими переходами кольорів краще підходить WebP (AVIF може давати артефакти на контрастних межах).

Для сумісності використовуємо елемент <picture> з fallback:

<picture>
    <source type="image/avif"
            srcset="/images/product-400.avif 400w,
                    /images/product-800.avif 800w,
                    /images/product-1200.avif 1200w"
            sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 400px">
    <source type="image/webp"
            srcset="/images/product-400.webp 400w,
                    /images/product-800.webp 800w,
                    /images/product-1200.webp 1200w"
            sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 400px">
    <img src="/images/product-800.jpg"
         width="800" height="800"
         alt="Назва продукту"
         loading="lazy"
         decoding="async">
</picture>

Як правильно налаштувати lazy loading?

Нативний loading="lazy" підтримується у всіх сучасних браузерах. Детальніше про атрибут loading читайте на MDN. Для зображень поза першим екраном він підходить ідеально. Для LCP-елемента (зазвичай hero) обов'язково ставимо loading="eager" та fetchpriority="high".

<img src="photo.webp" loading="lazy" alt="Опис зображення">
<!-- LCP-зображення — НІКОЛИ не lazy -->
<img src="hero.webp" loading="eager" fetchpriority="high" alt="...">

Для фонових зображень використовуємо Intersection Observer з попереднім завантаженням. Важливо: не вішати lazy loading на зображення, які видно при завантаженні — це погіршить LCP. Також уникайте loading="lazy" для зображень з атрибутом fetchpriority="high" (вони конфліктують).

Як ми налаштовуємо конвертацію?

У типовому проєкті на Laravel використовуємо пакет spatie/laravel-medialibrary. Він генерує конверсії автоматично при завантаженні зображення. Ми задаємо формати, розміри та якість.

class Product extends Model
{
    use InteractsWithMedia;

    public function registerMediaConversions(?Media $media = null): void
    {
        $this->addMediaConversion('thumb')
            ->width(400)->height(400)
            ->format('webp')
            ->quality(80)
            ->performOnCollections('images');

        $this->addMediaConversion('medium')
            ->width(800)->height(800)
            ->format('webp')
            ->quality(82)
            ->performOnCollections('images');

        $this->addMediaConversion('avif-medium')
            ->width(800)->height(800)
            ->format('avif')
            ->quality(65)
            ->performOnCollections('images');
    }
}

Якщо не використовуєте Laravel — конвертуємо заздалегідь через CLI або на сервері. Nginx можна налаштувати на автоматичну віддачу WebP за заголовком Accept:

map $http_accept $webp_suffix {
    default "";
    "~*webp" ".webp";
}

location ~* \.(jpg|jpeg|png)$ {
    add_header Vary Accept;
    try_files $uri$webp_suffix $uri =404;
    expires 30d;
}

Чому AVIF кращий за WebP для деяких задач?

AVIF забезпечує на 15–25% краще стиснення при тій самій візуальній якості. Він підтримує HDR та 10-бітну глибину кольору, що критично для фототоварів. Однак WebP має ширшу підтримку (96% проти 88%), тому використовуємо обидва з fallback. Для контрастних ілюстрацій WebP переважніший через менші артефакти.

Типові помилки при оптимізації зображень

• Використання лише одного формату (наприклад, тільки WebP) — старі браузери не відобразять картинку.
• Відсутність атрибутів width/height — викликає CLS.
• Lazy loading на LCP-зображення — погіршує LCP.
• Стиснення з якістю нижче 60 для WebP та нижче 50 для AVIF — видимі артефакти.
• Неправильні розміри srcset (наприклад, занадто великі зображення для мобільних).

Що входить в роботу?

Ми пропонуємо комплексну оптимізацію зображень під ключ:

• Аудит: заміряємо вагу, розміри, формати всіх зображень.
• Налаштування конвертації: WebP/AVIF із заданою якістю.
• Responsive images: генерація srcset під різні роздільні здатності.
• Lazy loading та LQIP (blur placeholder).
• Деплой та інтеграція з CDN.
• Документація та навчання вашої команди.

Терміни: від 2 до 5 днів залежно від обсягу каталогу. Вартість розраховується індивідуально. Замовте консультацію — ми надішлемо план робіт і точну оцінку.

Який результат ви отримаєте?

• Зниження ваги сторінок на 50–70%.
• Покращення LCP на 30–50%.
• Проходження Core Web Vitals.
• Зростання конверсії за рахунок швидкості.

Ми гарантуємо покращення показників. Багаторічний досвід — понад 200 реалізованих проєктів. Зв'яжіться з нами для аудиту вашого сайту та отримайте перші рекомендації вже сьогодні.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.