Кастомні плагіни Eleventy: розробка, тестування та оптимізація

Розробка кастомного плагіна Eleventy

Одного разу клієнт витратив два тижні на ручну оптимізацію зображень при збірці — ми написали плагін за день, який автоматично генерує WebP та AVIF. Після цього проєкту ми формалізували процес і тепер пропонуємо розробку плагінів під ключ. Стандартний Eleventy дає багато, але не все: кастомна обробка зображень, інтеграція з headless CMS, мультимовність — без плагіна це перетворюється на копіпасту та крихкі хелпери. Плагін же дає перевикористовувану, тестовану логіку, що скорочує час розробки та підтримки. Завдяки модульності такий підхід легко масштабувати: написаний одного разу плагін можна використовувати в десятках проєктів, економлячи сотні годин.

Які проблеми вирішуємо

• Кастомна обробка зображень зі стисненням, множиною форматів і розмірів — економія до 40% об'єму збірки. В одному проєкті ми знизили підсумковий розмір сайту з 150 МБ до 90 МБ лише за рахунок плагіна зображень. Це призвело до економії на хостингу до 30%.
• Інтеграція з зовнішніми API з кешуванням та обробкою помилок — підвантаження товарів з headless CMS. Плагін обробляє таймаути та повтори, гарантуючи стабільну збірку.
• Складні трансформації HTML — видалення невикористовуваних стилів, додавання critical CSS, вставка метаданих. Це знижує час завантаження сторінки на 20% за даними Lighthouse.
• Мультимовність з динамічними маршрутами та локаллю в URL — плагін генерує сторінки для кожної мови, підтягуючи переклади з JSON.

Без плагіна ці завдання вирішуються разовими скриптами, які складно підтримувати та тестувати. Плагін же інкапсулює всю логіку і може бути повторно використаний в інших проєктах.

Як розробити плагін Eleventy для оптимізації зображень?

Візьмемо реальний кейс: інтернет-магазин на Eleventy з сотнями картинок. Потрібно генерувати WebP та AVIF, робити декілька розмірів, а в вихідниках — прозорі PNG. Ми написали плагін на базі @11ty/eleventy-img:

const Image = require("@11ty/eleventy-img");
const path = require("path");

module.exports = function(eleventyConfig, options = {}) {
  const cfg = {
    widths: [320, 640, 960, 1280, 1920],
    formats: ["avif", "webp", "jpeg"],
    outputDir: "./_site/assets/images/",
    urlPath: "/assets/images/",
    sharpOptions: { quality: 82 },
    ...options
  };

  eleventyConfig.addAsyncShortcode("img", async function(src, alt, sizes = "(max-width: 768px) 100vw, 1200px", classList = "") {
    const srcPath = src.startsWith("http") ? src : path.join("src", src);
    try {
      const metadata = await Image(srcPath, cfg);
      return Image.generateHTML(metadata, { alt, sizes, loading: "lazy", decoding: "async", class: classList });
    } catch (e) {
      console.warn(`[img] Помилка: ${src}`);
      return `<img src="${src}" alt="${alt}" loading="lazy">`;
    }
  });
};

Шорткод {% img "src", "alt" %} в шаблоні генерує <picture> з AVIF, WebP та JPG. Плагін замінює собою ручну оптимізацію і зменшив розмір збірки на 40%. Подібний підхід можна застосувати до будь-яких повторюваних завдань: від конвертації Markdown до генерації sitemap.

Як тестувати кастомний плагін Eleventy?

Для тестування використовуйте Jest або Mocha. Запустіть Eleventy в тестовому режимі, передавши конфігурацію з плагіном, та перевірте вихідні файли. Також тестуйте окремі функції плагіна: фільтри, шорткоди, асинхронні операції. Приклад тесту для нашого плагіна:

const plugin = require('./img-plugin');
const Eleventy = require('@11ty/eleventy');

test('генерує picture з AVIF', async () => {
  const elev = new Eleventy('./test/src', './test/_site', {
    config: function(eleventyConfig) {
      eleventyConfig.addPlugin(plugin, { widths: [640] });
    }
  });
  const result = await elev.toJSON();
  expect(result[0].content).toContain('<picture>');
});

Це гарантує, що плагін працює коректно при змінах. Для комплексних плагінів варто додати тести на обробку помилок: наприклад, при недоступному зовнішньому API або пошкодженому зображенні. Використовуйте mock-об'єкти для емуляції мережевих запитів.

Чому кастомний плагін швидший за готовий?

Готові плагіни часто перевантажені: включають зайвий функціонал, складно конфігуруються, рідко оновлюються. Кастомний плагін пишеться під конкретне завдання, легше підтримується і працює швидше за рахунок відсутності мертвого коду. Наприклад, готовий плагін для зображень може тягнути залежності для форматів, які вам не потрібні, а кастомний — лише необхідні. Порівняння:

Кастомний плагін — це інвестиція в швидкість та якість збірки.

Процес роботи

1. Аналітика: розбираємо поточний проєкт, виявляємо повторювані завдання.
2. Проектування: проектуємо API плагіна — вхідні параметри, конфіг, значення, що повертаються.
3. Реалізація: пишемо код з тестами (Jest), використовуємо async/await, обробку помилок.
4. Тестування: запускаємо збірку з плагіном, перевіряємо вихідні файли.
5. Деплой: підключаємо плагін до проєкту, документуємо використання.

Строки та вартість

Вартість розраховується індивідуально. Оцінка проєкту — безкоштовно. Зв'яжіться з нами — ми підберемо оптимальне рішення під ваш бюджет.

Що входить в результат

• Вихідний код плагіна з коментарями.
• Документація по встановленню та налаштуванню.
• Тести (Jest) для ключових сценаріїв.
• Тиждень підтримки після деплою.

Розповсюджені помилки при розробці: забувають обробляти помилки в асинхронних шорткодах, не перевіряють типи вхідних даних, використовують синхронні операції там, де потрібні async. Наш процес це виключає.

Ми гарантуємо якість: досвід на ринку більше 5 років, 50+ реалізованих проєктів. Отримайте безкоштовну консультацію — обговоримо ваш проєкт і запропонуємо оптимальне рішення. Економія бюджету та часу на підтримку — ось що ви отримуєте з кастомним плагіном. Ваша вигода — зниження витрат на хостинг та прискорення розробки.

Детальніше про API Eleventy на GitHub.

Типи сайтів: технічне завдання, а не маркетинг

Ми бачимо, як команди витрачають бюджет на невідповідний стек. Лендинг на Next.js зі статичною генерацією та корпоративний сайт з CMS — принципово різні інфраструктури, навіть якщо зовні схожі. Помилка на старті веде до переплати за хостинг у 5–10 разів і низької швидкості завантаження. Core Web Vitals (LCP, INP, TTFB) для кожного типу сайту мають свої пріоритети: для лендингу критичний LCP, для корпоративного — TTFB через динамічний контент.

За нашими даними, до 40% проєктів переплачують на хостингу через неправильний вибір технології. Статичний сайт на CDN обходиться в 5 разів дешевше за WordPress на VPS за тих самих навантажень. Нижче розберемо чотири типи сайтів, їхні типові технічні помилки та рішення, які ми застосовуємо на практиці. Маємо 8 років досвіду та понад 120 успішних проєктів у різних нішах.

Як обрати правильний тип сайту?

Вибір визначає стек, інфраструктуру та бюджет на підтримку. Покрокова інструкція:

1. Визначте мету: продаж (лендинг), інформування (корпоративний) чи швидкий контакт (візитка).
2. Оцініть частоту оновлення контенту: щодня — потрібна CMS, раз на місяць — вистачить Markdown у Git.
3. Виберіть стек за продуктивністю: статика для візиток, Next.js з ISR для корпоративних, GSAP для промо.

Як не помилитися з вибором CMS?

Якщо редактори нетехнічні — WordPress з Gutenberg або ACF Pro закриває потреби. Для складних структур — headless CMS (Strapi, Directus) з фронтендом на Next.js. Якщо оновлення рідкі — Markdown в Git з Astro або Next.js, деплой по push в main. Ми використовуємо Repository pattern для уникнення N+1 запитів при роботі з ORM.

Сайт-візитка

Найкомпактніший формат: 1–5 сторінок, мінімум динаміки. Основне завдання — контактна інформація та перше враження. Технічно просто, але є типові помилки.

Занадто важкий стек. WordPress з 15 плагінами для 5 сторінок дає TTFB 800ms на shared хостингу. Ми пропонуємо статику: HTML/CSS/JS або Next.js з output: 'export', задеплоєне на Vercel або Cloudflare Pages. Жодного PHP, жодної бази даних — тільки CDN. TTFB < 50ms гарантовано. Економія на хостингу — до 70% на місяць.

Немає контактної форми з backend-валідацією. Форма лише з JS-валідацією — це декорація. Ми додаємо серверлесс endpoint (Netlify Functions або AWS Lambda) з rate-limiter та сповіщеннями.

Відсутність Schema.org розмітки. Google Knowledge Panel будується на LocalBusiness або Organization. Ми вбудовуємо розмітку в шаблон: адреса, телефон, години роботи.

Термін розробки: 2–3 тижні з дизайном.

Чому швидкість лендингу безпосередньо впливає на конверсію?

Лендинг — сторінка з однією метою: конверсія. Core Web Vitals критичні, оскільки платний трафік і Google використовує CWV у Quality Score.

Конкретний кейс: лендинг з hero-відео 8MB autoplay без preload="none" і три сторонні скрипти аналітики синхронно в <head>. LCP 9.4s, INP 780ms. Ми замінили відео на poster image з відкладеним завантаженням, скрипти перевели на async/defer і частково в Web Workers через Partytown. LCP став 1.8s, INP 140ms. Конверсія зросла на 23% тільки за рахунок швидкості.

A/B тестування — стандартна практика. Після закриття Google Optimize використовуємо open-source Growthbook або PostHog. Для Next.js застосовуємо edge middleware для розподілу трафіку на CDN без додаткового JS.

Термін: 2–4 тижні.

Корпоративний сайт

Корпоративний — CMS, багато сторінок, мультимовність, інтеграція з CRM. Ключове питання: хто редагує контент і як часто.

Якщо редактори нетехнічні — WordPress з Gutenberg або ACF Pro. Для складних структур — headless CMS (Strapi, Directus) з фронтендом на Next.js. Якщо оновлення рідкі — Markdown в Git з Astro або Next.js, деплой по push в main.

Продуктивність: сторінка "Про компанію" з 40 фото в оригіналі — LCP 12 секунд на мобільному. <Image> компонент Next.js з WebP і srcset вирішує без ручної роботи, знижуючи LCP до 2 секунд.

Багатомовність: Astrotomic Translatable на Laravel або next-intl. Структура URL — /uk/about, /en/about з hreflang.

Термін: 6–12 тижнів залежно від обсягу.

Промо-сайт

Промо — тимчасовий або постійний сайт під кампанію. Нестандартний дизайн, анімації. Стек: GSAP, Framer Motion, Three.js, Lottie.

Головна пастка — гальмівні анімації на мобільних. GPU-анімації через transform і opacity — нормально. box-shadow в анімації, filter: blur() на кожному кадрі, анімація width/height — 20fps на iPhone 12. will-change: transform допомагає точково.

prefers-reduced-motion — обов’язковий для accessibility.

Термін: 3–6 тижнів.

Як ми оптимізуємо продуктивність?

Для кожного проєкту проводимо аудит початкового стеку: аналізуємо TTFB, LCP, CLS, INP через Lighthouse та WebPageTest. Використовуємо tree-shake та bundle splitting для зменшення JS-бандла, для Next.js — React Server Components і Suspense для стрімінгу. Серверлесс функції дозволяють уникнути постійної вартості сервера — платите тільки за запити. Наприклад, корпоративний сайт на Next.js + Strapi дає TTFB <200ms, що у 5 разів менше ніж аналог на WordPress.

Автоматично конвертуємо зображення в WebP/AVIF, генеруємо srcset для всіх роздільних здатностей, використовуємо lazy loading з Intersection Observer. Для фонових зображень — техніка progressive loading.

Порівняльна таблиця

Вартість у кожному випадку розраховується індивідуально після вивчення технічного завдання. — Google рекомендує TTFB під 0.8s, у нас <0.2s.

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

• Аналітика та прототипування (структура, користувацькі сценарії)
• Дизайн-концепція (адаптивний, mobile-first)
• Верстка з оптимізацією LCP, CLS, INP
• Вибір та налаштування CMS (якщо потрібна)
• Інтеграція з CRM/маркетинговими інструментами
• Тестування (кросбраузерне, load-testing)
• Документація та передача доступів
• Навчання редакторів (відео + письмово)
• гарантія 3 місяці (безкоштовні правки)

Друга таблиця: порівняння підходів за продуктивністю

Статичний сайт швидший за WordPress у 10 разів за TTFB. Для консультації щодо вибору типу сайту та стеку зв'яжіться з нашими інженерами. Замовте розробку під ключ — ми оцінимо терміни та бюджет за 1 день. Напишіть нам, щоб отримати безкоштовний технічний аудит вашого проекту. Отримайте індивідуальну пропозицію з гарантією якості.