SPA на React/Vue/Angular з динамічним контентом: Googlebot бачить порожній <div id="root">, а контент підвантажується асинхронно. Трафік з пошуку — нуль, хоча бізнес-логіка працює. Ми стикалися з цим десятки разів. Dynamic Rendering — перевірений спосіб подати ботам статичний HTML без переписування фронтенду. Цей підхід офіційно рекомендований Google Search Central як прийнятне рішення, коли SSR неможливий. Але пам'ятайте: це костиль, не архітектура. Якщо можете впровадити SSR/SSG — робіть це.
Як працює Dynamic Rendering?
Dynamic Rendering — це прошарок: nginx перевіряє User-Agent, і якщо це бот — запит іде на headless Chrome (Puppeteer або Rendertron), який рендерить сторінку і повертає готовий HTML. Людина отримує звичайний SPA. Self-hosted рішення з Redis-кешем обходиться значно дешевше SaaS-аналогів при об'ємі >50k сторінок, а економія на серверних потужностях у порівнянні з повним SSR сягає 70%.
Коли Dynamic Rendering — єдиний вихід?
- SPA на React/Vue/Angular без SSR — білд міняти не можна.
- Немає часу або бюджету на переписування під SSR.
- Окремі розділи (лендінги, вітрини) з проблемами індексації, а основне застосування працює нормально.
- Тимчасове рішення: SSR в плані, але потрібно індексуватися вже зараз.
Не застосовуйте Dynamic Rendering, якщо SSR/SSG доступний — накладні витрати на підтримку інфраструктури не виправдані.
Порівняння підходів: self-hosted vs SaaS
| Критерій | Self-hosted (Rendertron/Puppeteer) | SaaS (Prerender.io) |
|---|---|---|
| Контроль | Повний: кеш, конфіги, версії Chrome | Обмежений налаштуваннями провайдера |
| Вартість | Оренда сервера (залежить від об'єму) | Від $50/міс за 10k сторінок |
| Продуктивність | Налаштовується: Redis, кластеризація | Залежить від провайдера |
| SLA | Ваш SRE | Гарантії провайдера (зазвичай 99.9%) |
Порівняння Rendertron і кастомного Puppeteer
| Критерій | Rendertron | Кастомний Puppeteer |
|---|---|---|
| Складність налаштування | Низька (готовий Docker-образ) | Середня (потрібне написання обробника) |
| Гнучкість | Обмежена | Повна: контроль над кожним кроком |
| Продуктивність | Хороша (до 100 запитів/сек на 4 GB RAM) | Оптимізована (блокування ресурсів, кастомні очікування) |
| Підтримка | Google, але проект з низькою активністю | Спільнота Puppeteer |
Ми частіше рекомендуємо self-hosted для компаній, які вже використовують Docker і Redis. SaaS — швидкий старт без адміністрування.
Як ми налаштовуємо Dynamic Rendering: кейс з нашої практики
Один з наших клієнтів — інтернет-магазин на Vue 2 + Nuxt (без SSR). Google індексував тільки головну, товари не потрапляли у видачу. Ми розгорнули кастомний prerender на Puppeteer з Redis-кешем за 2 дні. Результат: через місяць індекс виріс на 230%, органічний трафік — на 180%.
Стек: Node.js 18, Puppeteer 21, Redis 7, Docker Compose, nginx. Ключове — заблокували запити до зображень і шрифтів всередині Puppeteer, що скоротило час рендерингу з 4 до 1.2 секунди.
Процес роботи: від аудиту до деплою
- Аналітика — перевіряємо, які сторінки не індексуються (Search Console, crawl logs).
- Проектування архітектури — вирішуємо, self-hosted чи SaaS, схема nginx, кеш.
- Реалізація — пишемо конфіги nginx, код prerender-сервера, інтеграція з Redis.
- Тестування — імітуємо ботів, перевіряємо, що HTML містить контент, LCP < 2.5 сек.
- Деплой і моніторинг — CI/CD, дашборди з метриками (кількість рендерів, кеш-hit ratio, помилки).
Що входить в роботу (deliverables)
- Конфігурація nginx з маппінгом User-Agent.
- Docker-образ prerender-сервера (Rendertron або кастомний Puppeteer).
- Інтеграція з Redis (кеш + інвалідація при деплої).
- Документація з експлуатації та скрипти для моніторингу.
- Гарантія: 2 тижні пост-релізної підтримки (виправлення багів, консультації).
Типові помилки та як їх уникнути
- Не налаштований кеш — кожен запит рендериться заново, сервер падає. Рішення: Redis з TTL, черга на рендеринг.
- Puppeteer споживає 200+ MB RAM на сторінку — не вистачає пам'яті. Рішення: обмежити кількість паралельних рендерів, використовувати
--single-process. - Боти не бачать контент через таймаути — сторінка завантажується довше 30 сек. Рішення: збільшити
waitUntil, додатиwaitForSelector. - Dynamic Rendering включений для всього сайту — роботи завантажують мільйони сторінок, витрати зростають. Рішення: обмежити по robots.txt або по URL-патернах.
Строки та як замовити
Базове налаштування (nginx + Rendertron + Redis) — від 2 до 3 робочих днів. Кастомна розробка з Puppeteer та додатковими оптимізаціями — від 5 днів. Оцінимо проект безкоштовно — напишіть, надішлемо ТЗ та кошторис. Отримайте консультацію прямо зараз.
Чому обирають нас: багаторічний досвід на ринку, 40+ проектів з SEO-інфраструктури. Даємо гарантію на результати індексації. Зв'яжіться з нами для детального аудиту.
Моніторинг та налагодження
Перевірити, що бот отримує HTML, можна через curl:
curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" \ https://company.com/product/42 | grep -c "product-title" Якщо число > 0 — все ок. В Production додаємо заголовок X-Prerendered: true та логуємо метрики в Prometheus.
// Додати маркер готовності контенту window.prerenderReady = false // ... після завантаження даних: window.prerenderReady = true // Puppeteer: await page.waitForFunction(() => window.prerenderReady === true, { timeout: 10000 }) Інфраструктурні поради
- Ресурси: під кожну сторінку Puppeteer виділяє ~150 MB RAM. На сервері з 4 GB RAM можна тримати 10–15 одночасних рендерів.
- Кеш: використовуйте Redis Cluster при об'ємі >100k сторінок.
- Відмовостійкість: ставте кілька prerender-серверів за балансувальником.
Dynamic Rendering — не панацея, але робочий інструмент для складних випадків. Якщо у вас SPA і проблеми з індексацією — ми допоможемо. Замовте налаштування прямо зараз.