Cloudflare Browser Rendering і Browser Run: сесії, ліміти та архітектура автоматизації

Cloudflare Browser Run надає доступ до керованого браузера Chrome без потреби налаштовувати власний сервер. Його використовують, щоб відображати сторінки з JavaScript, робити скриншоти, генерувати PDF, тестувати інтерфейси й виконувати браузерні сценарії за допомогою AI-агентів.

За запитом Cloudflare Browser Rendering досі можна знайти інформацію про цей продукт, але станом на 2026 рік актуальною назвою продукту є Browser Run. Він добре підходить для одноразового відображення сторінок і дозволених завдань зі збору даних, але тривалі авторизовані сесії потребують окремого підходу до збереження стану. Якщо основна складність пов’язана з антибот-перевірками, спочатку розберіть, як працює Cloudflare для вебскрейпінгу, а вже потім обирайте інструмент запуску браузера.

Практичний вибір зводиться до трьох архітектурних підходів:

• Browser Run як хмарний рендерер для сторінок, які можна легально обробляти без постійного профілю користувача
• локальний або серверний Playwright, Puppeteer чи Selenium, коли потрібен повний контроль над середовищем
• профільна інфраструктура, де файли cookie, localStorage, проксі, цифровий відбиток і налаштування акаунта зберігаються в узгодженому середовищі

Для процесів без написання коду можуть бути корисними візуальні сценарії автоматизації.

Як співвідносяться назви Browser Rendering і Browser Run

Cloudflare Browser Rendering є попередньою назвою продукту, а Browser Run, його актуальною назвою. У документації Cloudflare прямо вказано, що Browser Run раніше називався Browser Rendering, тому в пошуку і статтях обидві назви можуть траплятися одночасно.

На практиці варто орієнтуватися на Browser Run. Саме так називаються поточні сторінки з Quick Actions, Playwright, Puppeteer, CDP, лімітами й тарифами. Якщо в старій статті або в прикладі коду ще трапляється browser-rendering, це не обов’язково свідчить про застарілий API, але перевіряти маршрут, SDK і дату документації потрібно окремо.

Якщо команда планує керувати браузерними задачами через AI-агентів, окремо оцініть Afina MCP для AI-агентів. Так ви не змішаєте вибір хмарного runtime з вибором інструмента оркестрації.

Для SEO й технічного пошуку варто враховувати обидві назви:

• cloudflare browser rendering як старий високочастотний запит
• cloudflare browser run як актуальна назва продукту
• browser run limits як запит про квоти та помилки 429
• browser run sessions як запит про повторне використання браузера
• cloudflare headless chrome як запит про механіку запуску

Таке розділення економить час під час налагодження. Якщо команда шукає помилку Browser time limit exceeded, їй потрібна сторінка лімітів Browser Run. Якщо вона читає старий огляд про Browser Rendering, треба перевірити, чи не змінилися значення лімітів після перейменування.

Які способи запуску й керування браузером доступні зараз

У Browser Run є два основні способи роботи: прості Quick Actions і повні Browser Sessions. Перший режим підходить для разових запитів, другий підходить для сценаріїв, де код керує вкладками, подіями, DOM і життєвим циклом браузера.

Quick Actions працюють як готові HTTP-операції. За їх допомогою можна отримати HTML, зробити скриншот, згенерувати PDF, отримати Markdown, зібрати посилання або запустити завдання з обходу сторінок. Це зручно для завдань, у яких не потрібно створювати складний сценарій із використанням Playwright. Наприклад, сервіс моніторингу може раз на годину знімати скриншот власної сторінки після розгортання оновлення або перевіряти, чи правильно працює SSR на сторінці з великою кількістю JavaScript.

Browser Sessions забезпечують детальніше керування браузером. У цьому режимі можна використовувати Puppeteer, Playwright і CDP для сценаріїв, у яких код відкриває сторінки, очікує появи елементів, натискає кнопки, читає localStorage або запускає кілька вкладок в одному браузері. Для команд, які вже використовують Playwright або Puppeteer, це один із найпростіших способів переходу: змінюється підключення, а логіку тестів або обходу сторінок здебільшого можна зберегти.

Для перевірки підключення можна використати мінімальний приклад із Playwright. У ньому BROWSER_CDP_URL означає адресу CDP-підключення, отриману для вашого браузерного сеансу. Конкретний спосіб отримання адреси залежить від обраного способу запуску Browser Run.

import { chromium } from 'playwright';

const browser = await chromium.connectOverCDP(process.env.BROWSER_CDP_URL);
try {
  const context = browser.contexts()[0] ?? await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com', { waitUntil: 'domcontentloaded' });
  console.log(await page.title());
} finally {
  await browser.close();
}

Це приклад керування вже доступним CDP-сеансом, а не повна інструкція з його створення у Cloudflare. Для робочого середовища додайте обробку помилок і контроль часу виконання.

Browser Run не є універсальною заміною всього набору браузерних інструментів. Це хмарне середовище виконання для певного класу завдань. Якщо завдання триває близько хвилини й не потребує постійного профілю користувача, Browser Run виглядає логічно. Якщо потрібно повторно працювати на сайті в тому самому профілі, потрібен збережений профіль, а не просто новий Chrome у безголовому режимі.

Не всі робочі процеси можна віднести лише до одного з цих варіантів. Часто в одному продукті співіснують короткі завдання з обробки та відображення сторінок для технічних перевірок і окрема профільна інфраструктура для операторської роботи.

Як перевіряти ліміти сесій, запусків і паралельних браузерів

Ліміти Browser Run залежать від плану Cloudflare Workers і типу використання. Free-план має 10 хвилин browser time на день, 3 одночасні Browser Sessions, 1 новий браузер кожні 20 секунд, 60 секунд idle timeout і 1 Quick Actions request кожні 10 секунд.

На Workers Paid модель інша. У лімітах Cloudflare вказано відсутність денного обмеження browser hours, 200 одночасних Browser Sessions за замовчуванням, 3 нові браузери на секунду, 60 секунд idle timeout і 30 Quick Actions requests на секунду. У тарифах при цьому зазначено 10 browser hours на місяць у плані, $0.09 за додаткову browser hour, 10 concurrent browsers у вартості плану для Browser Sessions і $2.00 за додатковий concurrent browser за середньомісячним розрахунком.

Важливо не змішувати два різні числа. Ліміт 200 concurrent browsers у документації лімітів означає технічну межу за замовчуванням для Paid. У тарифах 10 concurrent browsers означають включену вартість, після якої з'являється плата за середньомісячну пікову паралельність. Саме через це команда може технічно запустити більше, ніж входить у базовий тариф.

Почніть перевірку з короткого сценарію, а не з робочого навантаження:

1. зафіксуйте план Cloudflare Workers і дату перевірки
2. запустіть одну Quick Action і збережіть X-Browser-Ms-Used
3. запустіть одну Browser Session і закрийте її через browser.close()
4. повторіть запуск серією та відстежте появу HTTP 429
5. перевірте idle timeout без команд протягом 60 секунд
6. повторіть тест із keep_alive, якщо сценарій має паузи між діями
7. звірте підсумок із dashboard Browser Run

Під час такої перевірки причиною проблеми нерідко виявляється не обмеження Cloudflare, а помилка в коді. Наприклад, браузер не закривається в блоці finally, сесія залишається активною до завершення часу очікування, а облік браузерного часу триває. Така помилка може призвести до непередбачених витрат.

Після такого тесту команда вже бачить не абстрактний тариф, а власний характер навантаження. Це краща основа для бюджету, ніж результати стороннього тестування з іншими сторінками й іншим кодом.

Як оцінити витрати на типовому робочому сценарії

Вартість Browser Run рахується не за кількістю сторінок, а за browser time і, для Browser Sessions, за середньомісячною паралельністю. Тому два сценарії з однаковими 100 000 URL можуть коштувати по-різному: легкі сторінки з Quick Actions споживуть мало часу, а складні односторінкові застосунки зі скриптами, медіафайлами й тривалим очікуванням networkidle2 потребуватимуть більше часу.

Окрему увагу варто приділити невдалим запитам і перевищенню часу очікування. Cloudflare вказує, що Quick Actions із waitForTimeout не додають billable browser hours, але це не привід робити необмежену кількість повторних спроб. Повторні спроби швидше вичерпують ліміти запитів, збільшують чергу завдань і ускладнюють аналіз журналів.

Краще спершу зменшити вагу сторінки, вимкнути завантаження непотрібних ресурсів, якщо це дозволяє сценарій, чітко виставити waitForSelector і не очікувати повного припинення мережевої активності там, де сторінка постійно тримає аналітику або websocket.

Розгляньмо спрощений розрахунок для Workers Paid, якщо команда використовує 50 browser hours на місяць. Перші 10 годин входять у план, решта 40 годин множиться на $0.09. Browser time у такому прикладі дає $3.60 понад базовий план. Якщо Browser Sessions у середньому за місяць одночасно використовували в середньому 15 браузерів, 10 входять у тариф, ще 5 множаться на $2.00. Разом це $10.00 за паралельність. У сумі додаткові витрати становлять $13.60, без урахування ціни самого Workers Paid плану.

Для власного сценарію використовуйте просту формулу:

1. виміряйте середній browser time на одну сторінку
2. помножте його на місячну кількість сторінок
3. переведіть секунди в години
4. відніміть включені 10 годин на Workers Paid
5. помножте залишок на $0.09
6. окремо порахуйте середньомісячний daily peak concurrent browsers
7. додайте плату за concurrent browsers понад включений обсяг

Після розрахунку корисно зібрати порівняльну таблицю витрат: одна колонка для Quick Actions, друга для Browser Sessions, третя для власної інфраструктури. У ній одразу видно, чи платить команда за реальний рендеринг, чи за простої, повторні спроби й надмірну паралельність.

У такому порівнянні Browser Run зазвичай простіше запустити, натомість власна інфраструктура дає більше гнучкості. Рішення залежить від того, що дорожче саме для вашої команди: інфраструктура чи обмеження керованого середовища.

Витрати на Quick Actions зазвичай легше оцінити, якщо сценарій складається з коротких незалежних дій. Якщо потрібна сесія, вкладки й CDP, рахунок залежить від того, чи закривається браузер одразу після виконання завдання. Для власної автоматизації поза Cloudflare варто порівняти цю модель із витратами на сервер, чергу завдань, оновлення браузерів, моніторинг і підтримку Playwright-стеку. Залежно від навантаження та вимог до інфраструктури Cloudflare може виявитися як економнішим, так і дорожчим рішенням.

Коли потрібен керований хмарний браузер, а коли власні профілі

Керований хмарний браузер варто обирати для завдань, у яких браузер є одноразовим виконавцем, а не постійним профілем користувача. Це скриншоти, PDF, QA-перевірки, краулінг власних сторінок, генерація прев'ю, рендеринг контенту для системи, яка має право отримувати ці сторінки.

Окремі профілі потрібні там, де важливо зберігати стан між запусками. Авторизований акаунт, файли cookie, локальне сховище, історія сесії, стабільний проксі, часова зона, мова, WebGL, Canvas і User-Agent мають узгоджуватися. Якщо кожен запуск починається з чистого середовища, сайт може сприймати кожен запуск як нове браузерне середовище. Для завдань, пов’язаних із цифровими відбитками та ознаками безголового браузера корисно окремо прочитати про виявлення headless-браузерів, бо проблема часто не в коді, а в тому, як середовище виглядає з боку сайту.

Порівняння нижче допомагає швидко відсікти неправильну архітектуру:

Отже, для одноразових завдань із відображення сторінок варто спочатку розглянути Browser Run. Якщо потрібен повний контроль над кодом і середовищем, доцільніший власний Playwright. Для тривалої роботи з авторизованими акаунтами та збереження їхнього стану краще підходять ізольовані браузерні профілі.

Для Afina практичний сенс з'являється не в простому скриншоті, а в роботі з браузерними профілями: окремі браузерні профілі, локальна автоматизація, API, проксі й контроль середовища зібрані для завдань, у яких важливо зберігати стан між запусками. Якщо потрібно керувати сценаріями програмно, перегляньте окремий матеріал про API Afina. Це не замінює Browser Run для швидкого відображення сторінок, але закриває інший клас завдань.

Матеріал надано виключно в ознайомчих та освітніх цілях. Для скрейпінгу й автоматизації перевіряйте правила платформи, robots.txt, умови доступу до даних і юридичні обмеження у вашій юрисдикції. Browser Run краще залишити для дозволених, коротких і добре вимірюваних браузерних дій. Профілі й Afina доречні там, де робочий процес залежить від стабільного стану, ізоляції акаунтів і керованої автоматизації, а не від одноразового запуску headless Chrome.