Інтеграція Imgix для обробки зображень на льоту: прискорення сайту до ×5

Уявіть: сайт завантажується 5 секунд, LCP зашкалює за 4 секунди, а всі картинки — гігантські PNG по 5 МБ. Клієнти йдуть, пошуковики штрафують. Знайома ситуація? Найчастіше проблема в зображеннях: вони не оптимізовані, не адаптовані під екрани та роздаються з повільного сервера. Ми вирішуємо це за допомогою Imgix — проксі-CDN для зображень, який обробляє їх на льоту. Результат: LCP падає до 1.5 секунд, а розмір сторінки зменшується втричі.

Оригінали зберігаються у вашому S3-бакеті, а Imgix через URL-параметри трансформує їх та віддає через глобальну CDN, використовуючи кешування на периферії. Жодних зайвих копій, жодних ручних конвертацій.

Як Imgix обробляє зображення на льоту?

При запиті зображення Imgix отримує оригінал з S3, застосовує параметри з URL (ширина, формат, якість тощо) та кешує результат на CDN. Наступні запити обслуговуються з кешу — швидкість максимальна. Підтримуються всі сучасні формати: WebP, AVIF, а також автоматичний вибір (auto=format — docs.imgix.com). Згідно з документацією Imgix, сервіс скорочує вагу зображень до 60% без втрати якості.

Чому Imgix кращий за локальну обробку?

Локальна обробка (GD, ImageMagick, шини на сервері) навантажує CPU, вимагає місця для кешу та не масштабується під пікові навантаження. Imgix знімає це навантаження, пропонуючи:

Imgix у 5 разів швидший при пікових навантаженнях і не вимагає адміністрування серверів.

Як Imgix допомагає покращити Core Web Vitals?

LCP, CLS, INP — всі ці метрики залежать від зображень. Imgix вирішує кожну: LCP через preload та адаптивні розміри, CLS через явні width/height, INP через зниження навантаження на головний потік. Ми налаштовуємо кожен параметр під ваш контент. Наприклад, у проєкті інтернет-магазину одягу ми впровадили Imgix з signed URLs для захисту зображень товарів. Після налаштування preload для LCP-картинок та srcset для всіх інших LCP покращився з 3.2 до 1.1 секунди (на 66%), а загальна вага сторінки знизилася на 55%. Зв'яжіться з нами для аналогічного аудиту.

Які формати зображень найкраще підтримує Imgix?

Imgix підтримує WebP, AVIF, JPEG, PNG, GIF та SVG. Автоматичний вибір формату через параметр auto=format віддає браузеру найсучасніший формат, який він підтримує. Для браузерів без підтримки WebP/AVIF — JPEG. При цьому економія трафіку сягає 60% порівняно з оригіналом. Ви також можете примусово задати формат через fm=webp.

Налаштування джерела S3 та IAM

# У dashboard.imgix.com:
# Sources → Add Source → Amazon S3
# S3 Bucket Name: my-assets-bucket
# Access Key ID + Secret Access Key (IAM користувач з read-only на bucket)
# Subdomain: mysite.imgix.net

# IAM Policy для imgix:
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::my-assets-bucket",
      "arn:aws:s3:::my-assets-bucket/*"
    ]
  }]
}

Параметри трансформації

• Зміна розміру: ?w=800, ?w=800&h=600&fit=crop
• Формати та якість: ?auto=format,compress&q=75
• Розумна обрізка: ?fit=crop&crop=faces (розпізнавання облич)
• Колір та ефекти: ?sat=-100 (чорно-біле), ?blur=20
• Водяний знак: ?mark=URL&markw=20

TypeScript SDK та Signed URLs

// npm install @imgix/js-core
import ImgixClient from '@imgix/js-core';

const client = new ImgixClient({
  domain: 'mysite.imgix.net',
  secureURLToken: process.env.IMGIX_SECURE_TOKEN, // Для підпису URL
  useHTTPS: true,
});

// Генерація URL з підписом
const url = client.buildURL('products/shirt-red.jpg', {
  w: 600,
  h: 600,
  fit: 'crop',
  auto: 'format,compress',
  q: 80,
});

// srcset для responsive images
const srcSet = client.buildSrcSet('products/shirt-red.jpg', {
  auto: 'format,compress',
  fit: 'max',
}, {
  widths: [320, 480, 640, 800, 1080, 1200, 1600],
});

Next.js: кастомний loader

// lib/imgix-loader.ts
import ImgixClient from '@imgix/js-core';

const client = new ImgixClient({
  domain: process.env.NEXT_PUBLIC_IMGIX_DOMAIN!,
  secureURLToken: process.env.IMGIX_SECURE_TOKEN,
});

export default function imgixLoader({
  src,
  width,
  quality,
}: {
  src: string;
  width: number;
  quality?: number;
}): string {
  const path = src.startsWith('http') ? new URL(src).pathname : src;
  return client.buildURL(path, {
    w: width,
    auto: 'format,compress',
    q: quality ?? 75,
    fit: 'max',
  });
}

// next.config.ts
const nextConfig = {
  images: {
    loader: 'custom',
    loaderFile: './lib/imgix-loader.ts',
  },
};

import Image from 'next/image';

<Image
  src="/products/shirt-red.jpg"
  alt="Red shirt - imgix оптимізація"
  width={600}
  height={600}
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
  priority={isAboveFold}
/>

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

<link rel="preload" as="image" href="https://mysite.imgix.net/hero.jpg?w=1200&auto=format&q=80" imagesrcset="..." imagesizes="100vw"/>

Що входить у роботу з інтеграції Imgix?

• Аудит поточних зображень та їх впливу на Core Web Vitals
• Проєктування структури S3-бакета та налаштування IAM-політик
• Підключення Imgix: налаштування джерела, кастомного субдомену, SSL
• Інтеграція з вашим стеком: готовий код для Next.js, Vue, React або чистого HTML
• Signed URLs для захисту приватного контенту
• Оптимізація preload та srcset для критичних зображень
• Документація з використання та навчання команди
• Підтримка протягом місяця після запуску

Процес роботи та терміни

Ми проводимо аудит поточних зображень, проєктуємо структуру S3-бакета та підключаємо Imgix. Цим займається один інженер протягом 1–3 робочих днів. На виході ви отримуєте:

• Налаштований S3-бакет з IAM-політикою
• Робочий проксі-CDN з кастомним субдоменом
• Готовий код інтеграції з вашим стеком
• Signed URLs для приватного контенту
• Документацію з використання та підтримку протягом місяця

Етапи налаштування за 5 кроків

1. Створіть S3-бакет та IAM-користувача з read-only доступом.
2. Додайте джерело в Imgix dashboard.
3. Налаштуйте параметри трансформації під ваш контент.
4. Реалізуйте кастомний loader для вашого фреймворку.
5. Перевірте Core Web Vitals та оптимізуйте preload.

Типові проблеми та рішення

Пропозиція

Оцініть свій проєкт безкоштовно: ми проаналізуємо ваші зображення та покажемо, наскільки прискориться сайт. Досвід — понад 5 років, десятки успішних проєктів з Imgix. Гарантуємо працездатність інтеграції та відповідність метрикам продуктивності. Інтеграція під ключ за 1–3 дні. Напишіть нам для консультації — оцінимо проєкт безкоштовно.

Чому 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 пунктів.