● Статья · Cloudflare Blog · 6 августа 2026

Kitesurf: браузер для агентов, который живёт внутри Workers

Cloudflare за 12 недель собрала браузерный движок на Rust и Wasm, который целиком работает в V8-изолятах Workers. Он тратит в 3–7 раз меньше CPU и памяти, чем Chromium, и проигрывает ему по времени ответа.

✍️ Celso Martinho, Ruskin Constant, Rui Figueira, Luís Duarte 📅 6 августа 2026 16 мин 🌐 Cloudflare Blog
Главный тезис

Агенту не нужны вкладки, темы и пиксель-перфект — ему нужны токены, масштаб и цена запроса. Если выкинуть из браузера всё человеческое, остаётся движок, который помещается в обычный Worker и стоит в разы дешевле в пересчёте на сессию.

Обложка статьи Cloudflare Blog: Introducing Kitesurf, the agent-first browser that runs in V8 isolates on Cloudflare Workers
Читать оригинал на Cloudflare Blog ↗
TL;DR

Суть за минуту

🎯Другой потребитель

Chromium писали для людей. Агенту не нужны вкладки, расширения и плавный скролл, но нужны структурированный текст, предсказуемая цена и масштаб. Дать каждому агенту свой Chromium слишком дорого, поэтому веб оставался доступен только самым продвинутым и дорогим моделям.

🧩Четыре компонента

Engine держит CDP-сессию и всё состояние. PageScript поднимает изолят на каждую навигацию, парсит HTML и крутит JS. PageRenderer превращает сцену в пиксели. SandboxOutbound — единственный, кто ходит в сеть.

📊Цена против скорости

На корпусе из 14 URL Kitesurf тратит в 3,1–3,8 раза меньше CPU и в 4,7–7 раз меньше памяти, чем прогретый Chromium, но отвечает в 1,7–1,8 раза дольше. Пройдено 215 000+ сабтестов WPT.

01

Зачем агенту отдельный браузер

в статье

Вопрос «а не написать ли свой браузер» всплывал в Cloudflare каждые несколько месяцев и каждый раз откладывался: сложность не окупалась. В этот раз совпали два события. Wasm в Workers дозрел, появились Dynamic Workers, Durable Objects на SQLite, RPC между воркерами, service bindings и поднятые лимиты. Одновременно вырос Browser Run: агентам нужен браузер, без него многие задачи просто не решаются.

человеку в браузере агенту в браузере вкладки и сессии темы и расширения синхронизация устройств пиксель-перфект вёрстки скролл на 60 fps закладки и история всё это стоит памяти число токенов контекстное окно масштабируемость производительность стоимость запроса machine-readable контент и защита от prompt injection
схема конспекта: что выкинули, а что оставили

💸В чём была цена

Движки вроде Chromium несут накладные расходы, которые модели не нужны. Памяти и вычислений уходит столько, что отдельный инстанс на каждого агента становится непозволительным. Веб остаётся доступен только самым дорогим моделям с большим объёмом знаний, а остальные агентные сценарии отсекаются.

🛡️И другая модель угроз

Браузер на ноутбуке ходит по сайтам, которым вы доверяете. Агент идёт туда, куда его послала задача: произвольный код с произвольных источников. На первый план выходят prompt injection и безопасность инструментов, а не совместимость со всеми CSS-свойствами.

Итог. 12 недель назад команда задала вопрос заново, и ответ был единогласным: да. Kitesurf уже доступен бесплатно в бете внутри Browser Run.
02

Началось со ссылки в чате

в статье

Толчком стала obscura — headless-движок на Rust для AI-автоматизации с девизом «no Chrome, no Node.js, no dependencies». Порт на Workers делали с помощью AI-агента, и сперва получалось плохо. Заработало, когда агенту дали внятный план и определение успеха — достаточно подробное, чтобы он мог крутиться в цикле сам и задавать вопросы по ходу.

Скриншот переписки команды Cloudflare: ссылка на obscura, реплика про V8 и план первого дня с WS+CDP handshake рис. из статьи
Что показано: тот самый момент «nerd sniping». Реплика «It runs real JavaScript via V8» и вопрос «а что ещё исполняет настоящий JavaScript через V8?» приводят к «we should try to port this to workers…». В чёрном блоке — Todo первого дня: инициализация репозитория, сабмодуль, каркас воркера, рукопожатие WS+CDP.
03

Пять решений до первой строки кода

в статье

Команда понимала: путь от прототипа до браузера, полезного в продакшене, требует множества итераций, и без AI такой темп не удержать. Отсюда пять принципов, которые задали рамку всей работе.

🧪Тесты как ТЗ для агента

Web Platform Tests дают агентам чёткие критерии соответствия стандартам W3C. Люди подбирали порядок фич и занимались архитектурой и ревью подходов, а не проверкой каждого диффа глазами.

WPT проверяют соответствие стандартам, но не умение отрисовать живой сайт. Пробел закрыли интеграционными и визуальными регрессионными тестами: многошаговые сценарии Puppeteer гоняют реальные сайты одновременно в Chromium и Kitesurf и сверяют не только ассерты, но и картинку на каждом шаге.

🦀Rust там, где можно

Wasm в Workers позволяет брать быстрые пакеты на C, C++ и Rust. Но сборка через Emscripten с его слоями замоканных зависимостей даёт тяжёлый и медленный бинарник.

Поэтому выбрали нативный Rust и компиляцию прямо в WebAssembly через wasm-bindgen — без лишних слоёв эмуляции, максимально близко к железу.

🧯Падать в пустой кадр

Браузер обязан отрисовать весь ненадёжный и порой враждебный веб, ни разу не уронив страницу. Обработка исключений здесь не гигиена, а способ выжить на плохом вводе.

Правило приняли сразу: любой сбой деградирует до пустого кадра или пропавшего элемента, но не до мёртвой сессии. Ловить на каждой границе, по умолчанию отдавать безопасное и пустое, логировать столько, чтобы потом разобраться.

🔒Изоляция по умолчанию

Каждая загрузка страницы считается недоверенным вводом, каждая сессия начинается с чистого листа. Компоненты изолированы и получают доступ ровно к тем ресурсам, которые нужны для их работы.

Модель безопасности Workers построена вокруг изоляции, но платформа даёт только границу между изолятами. Дальше приложение само решает, чему что позволено трогать, и следит, чтобы ничего не протекло между страницами.

Схема: недоверенная страница, граница изолятов Workers, сетевой прокси, интернет рис. из статьи
Что показано: путь исходящего трафика. Недоверенная страница не видит сеть напрямую: сначала граница изолятов Workers, затем сетевой прокси, и только после этого интернет.

♻️Stateless, где получается

Состояние делает отказ дорогим. Если восстанавливать нечего, восстановление после падения сводится к новому запуску и повтору запроса.

Компонент без состояния одноразовый и параллельный по природе: его можно убить, как только он завис, запустить тысячу копий разом и держать ровно столько, сколько требует нагрузка. Для автоматизации это подходит идеально — трафик приходит всплесками, и дешевле всего поднять работу, которая стоит по факту потребления и исчезает по завершении.

04

Жизнь одного запроса

в статье

Клиент шлёт Page.navigate по CDP-вебсокету. Engine обходит и запекает статический граф модулей, поднимает через Worker Loader свежий изолят PageScript, тот парсит HTML, строит DOM и выполняет скрипты страницы. Дальше начинается цикл кадров: renderFrame по JSRPC, PageRenderer тянет сцену через RenderPort, растеризует её и отдаёт байты, а Engine пересылает клиенту Page.screencastFrame.

Диаграмма последовательности запроса: CDP Client, Engine, PageScript, PageRenderer, Blitz wasm и цикл кадров рис. из статьи
Что показано: полный путь запроса по пяти участникам. Внутри пунктирной рамки — цикл, который повторяется на каждый кадр: запрос кадра, вытягивание сцены, растеризация через stylo, taffy, parley и vello, JPEG-байты обратно и подтверждение screencastFrameAck от клиента.
Engine публичная дверь · хранит состояние сессии PageScript изолят на каждую навигацию DOM, CSS, JS, Wasm живёт, пока живёт страница PageRenderer сцена → пиксели сети нет вообще одноразовый, живёт кадр SandboxOutbound единственный выход наружу CORS, заголовки, cookies что не прошло политику → 403 поднимает Worker Loader вызов renderFrame по RPC права выданы Dynamic Workers состояние живёт только в Engine — остальные можно убить и поднять заново
схема конспекта: кто что держит и сколько живёт
КомпонентСостояниеДоступ в сетьВремя жизни
Engineсостояние сессиичерез SandboxOutboundвся CDP-сессия
PageScriptнетчерез SandboxOutboundодна навигация или OOPIF
PageRendererнет, только кэш403 deny-allодин вызов renderFrame
SandboxOutboundбанка cookies на страницуединственный выходзапрос

Таблица собрана из описаний компонентов в статье: Engine хранит состояние сессии, все остальные компоненты в тексте названы stateless.

05

Одна дверь наружу

в статье

Чтобы отрисовать чужую страницу, браузер тянет из интернета произвольные картинки, шрифты, CSS, JavaScript и Wasm. Это одна из самых опасных операций, которые он вообще делает. В Kitesurf её выполняет ровно один компонент — SandboxOutbound, и больше никто не касается сети напрямую; права раздают Dynamic Workers.

Схема сетевого доступа: Engine и PageScript ходят через SandboxOutbound, PageRenderer получает 403 deny-all рис. из статьи
Что показано: кому и что разрешено. Engine забирает главный документ и его скрипты, PageScript — всё остальное. У PageRenderer сети нет вообще, его запросы упираются в 403.

🚪Что делает шлюз

SandboxOutbound применяет CORS, подставляет заголовки, похожие на браузерные, фильтрует ответы и держит cookies каждой страницы в отдельной банке.

Всё, что не прошло политику, получает 403. Каждому компоненту достаётся ровно та сеть, которая ему нужна, и ничего сверх того.

Почему это работает. Ограничение живёт не в соглашении между разработчиками, а в платформе: доступ выдают Dynamic Workers, и обойти его изнутри компонента нельзя.
06

Engine: единственный публичный компонент

в статье

Engine держит вебсокет Chrome DevTools Protocol и HTTP REST API, отдаёт служебную страницу для внутреннего тестирования и хранит состояние каждой сессии. Остальные компоненты состояния не имеют. По словам авторов, из всех частей Kitesurf он самый простой, вопреки названию.

Схема Engine: CDP-клиент сверху, внутри состояние сессии, подготовка страницы и дирижёр, снизу SandboxOutbound, PageScript и PageRenderer рис. из статьи
Что показано: три роли Engine — держать состояние на время соединения, подготовить страницу (забрать документ и скрипты) и дирижировать: запустить PageScript и запросить кадры у PageRenderer.

🔌Зачем именно CDP

Протокол даёт совместимость с тем, что уже используют: Puppeteer, Playwright, chrome-remote-interface и сам фронтенд Chrome DevTools. Направьте их на Kitesurf — и они заработают.

На том же протоколе построен Browser Run, поэтому переключение сводится к одному параметру в адресе эндпоинта.

🧵Почему Engine хранит состояние

Состояние сессии где-то жить обязано: клиент открывает соединение и ждёт, что страница между командами никуда не денется. Cloudflare собрала его в одном компоненте, чтобы остальные остались одноразовыми.

07

PageScript: свежий изолят на каждую навигацию

в статье

Каждая следующая страница или внепроцессный iframe (OOPIF) получает через Dynamic Workers собственный долгоживущий изолят: чистый globalThis и объект document. Без Dynamic Workers, по прямому признанию авторов, Kitesurf не появился бы вовсе.

Схема изолята PageScript: bootstrap, script runner, JS-движок V8 или Boa, DOM в Wasm, выход в SandboxOutbound рис. из статьи
Что показано: устройство изолята. Bootstrap поднимает window и document, script runner выполняет скрипты по порядку, JS-движок читает и меняет живой DOM внутри Wasm, а за стилями, картинками, шрифтами и fetch() ходит в SandboxOutbound.

🧱Из чего собран парсинг

DOM наполняется результатами разбора HTML и выполнения всех скриптов. HTML и CSS разбирают части Blitz, модульного движка рендеринга, и Stylo, быстрый CSS-парсер Firefox. Оба написаны на Rust.

Каждый найденный тег <script> и каждый файл .wasm исполняется в том же изоляте.

🌀Отдельная история с eval

Нативный eval в Workers по соображениям безопасности не поддерживается, а поднять под него отдельный изолят нельзя: у него не будет доступа к globalThis.

Решение — Boa JS, движок ECMAScript на Rust, скомпилированный под Workers. Получается рантайм поверх рантайма. Авторы прямо пишут: выглядит неоптимально, так оно и есть, но редкие eval в чужом коде это обрабатывает. Когда в Workers появится нативная поддержка, от Boa уйдут.

08

PageRenderer: пиксели по одному RPC-вызову

в статье

Компонент превращает вычисленные объекты страницы в настоящие пиксели и работает в цикле с Engine. Когда движку нужен кадр, PageRenderer забирает у PageScript объект страницы (сцену), подтягивает внутренние шрифты и картинки из Static Assets, растеризует всё в буфер и возвращает его в формате, который поймёт клиент: JPEG, PNG или PDF.

Схема PageRenderer: получить сцену, дотянуть ассеты, растеризовать в Wasm, отдать JPEG, PNG или PDF рис. из статьи
Что показано: конвейер из четырёх шагов и обмен с Engine по JSRPC — renderFrame и renderPdf туда, пиксели обратно.

🖌️Кто рисует

Основную работу берёт на себя ещё один модуль Blitz — blitz-paint. Он опирается на Parley: та превращает символы в глифы, подбирает шрифты и разбивает текст на строки.

📞RPC вместо схем и токенов

У Workers есть встроенный RPC: можно вызывать методы других воркеров, передавать объекты и вызывать методы уже у них. Не нужны ни схемы API, ни типы, ни аутентификация — просто remoteFunction(...params).

Engine одним вызовом renderFrame() получает PNG. Рендерер не держит состояния страницы, только одноразовый кэш, поэтому движок спокойно убивает и перезапускает его на любом упавшем или зависшем вызове. Каждый запрос на отрисовку самодостаточен и допускает повтор.

09

215 000 тестов WPT и замеры против Chromium

в статье

Kitesurf проходит около 215 000 сабтестов WPT и прибавляет сотни каждую неделю. Области, которые важны агентам, — CSS, DOM, HTML, selection, SVG и XHR — покрыты уже прилично; даже streams, не самая нужная агенту вещь, поддержаны сносно.

График роста числа проходящих сабтестов WPT с мая по конец июля рис. из статьи
Что показано: рост идёт ступенями, а не плавно. До 7 июня линия почти прижата к нулю, затем два рывка в середине июня выводят её примерно к 178 000, дальше месяц плато и новый скачок в конце июля.
Таблица покрытия WPT по папкам: css, dom, html, encoding, selection и другие с долями pass и fail рис. из статьи
Что показано: полный отчёт по областям с цветными полосами pass, fail, timeout и crash. Ниже те же числа собраны в таблицу.
Область WPTФайлыСабтестыДоля
encoding/35 / 5111 572 / 11 62999,5%
selection/60 / 12733 647 / 34 05498,8%
dom/237 / 38953 422 / 55 05097,0%
svg/63 / 6563 / 6596,9%
xhr/3 / 418 / 1994,7%
html/893 / 149967 461 / 71 66194,1%
css/685 / 116821 137 / 25 17184,0%
url/16 / 348 250 / 9 96182,8%
streams/20 / 701 001 / 1 31176,4%
fetch/54 / 1881 485 / 2 53458,6%
wasm/35 / 99727 / 1 42251,1%
webidl/6 / 44196 / 45143,5%
webmessaging/21 / 13846 / 17726,0%

Числа считаны с отчёта WPT на картинке выше. Полный список областей — в оригинальном скриншоте.

Kitesurf против Chromium на корпусе из 14 URL

Медианы пяти прогонов quick-action в Browser Run. Chromium работает из прогретого пула.

МетрикаKitesurfChromium (прогретый пул)Разница
CPU: скриншот380 мс1 173 мсв 3,1 раза меньше CPU
CPU: извлечение HTML229 мс877 мсв 3,8 раза меньше
Память: скриншот57,8 MiB271,0 MiBв 4,7 раза меньше
Память: извлечение HTML39,4 MiB273,7 MiBв 7 раз меньше
Время ответа: скриншот1 148 мс637 мсв 1,8 раза медленнее
Время ответа: извлечение HTML820 мс472 мсв 1,7 раза медленнее
Скриншот одной страницы: три метрики, две системы длина полосы пропорциональна значению внутри пары CPU 380 мс · Kitesurf 1 173 мс · Chromium Память 57,8 MiB · Kitesurf 271,0 MiB · Chromium Время ответа 1 148 мс · Kitesurf 637 мс · Chromium счёт растёт от CPU и памяти, а не от секундомера
схема конспекта: те же цифры из таблицы, но глазами
И тест, без которого нельзя. Проект не считается законченным, пока на нём не запустился Doom. В статье Kitesurf открывает silentspacemarine.com из давнего эксперимента Cloudflare с многопользовательским Doom на Workers. в статье ↗
Почему Chromium быстрее на секундомере. JIT, который уже видел эту страницу, всегда обгонит холодный программный рендерер, и сегодня отрыв составляет около 1,7 раза. Основная его часть приходится на растеризацию и кодирование JPEG или PNG — это и оптимизируют. Зато Kitesurf выигрывает по памяти и CPU, то есть по тому, из чего складывается счёт: меньше памяти — больше сессий на той же машине.
10

Как включить прямо сейчас

в статье

Kitesurf доступен в Browser Run бесплатно на время беты, за лимитами на аккаунт. CDP-эндпоинт Browser Run принимает его как опцию, так что ваш нынешний клиент — Puppeteer, Playwright, chrome-remote-interface или любой агент, говорящий на MCP и CDP, — уже работает. Достаточно добавить к эндпоинту параметр browser=kitesurf.

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <API_TOKEN>\"}"
      ],
      "enabled": true
    }
  }
}

Конфигурация для Opencode из раздела документации «Using with MCP clients (CDP)».

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot?browser=kitesurf' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com"
  }' \
  --output "screenshot.png"

Быстрый скриншот через Quick Actions: тот же параметр browser=kitesurf в адресе.

Скриншот playground: слева отрисованная Kitesurf главная Wikipedia, справа панель Memory в Chrome DevTools с расходом по изолятам рис. из статьи
Что показано: в playground встроен фронтенд Chrome DevTools, поэтому можно смотреть развёрнутые элементы DOM, консоль и сетевую активность прямо во время отрисовки. Для панели Memory реализовали нужные инструкции CDP: она показывает расход WebAssembly по каждому изоляту, включая фреймы. На снимке Wikipedia стоит 69,5 МБ JS heap, из них Main — 25,6 МБ, PageRenderer — 24,5 МБ, Engine — 19,4 МБ.
11

Где выигрывает, а где пока нет

в статье

Kitesurf уже корректно рисует TodoMVC на vanilla, React, Vue, Angular и Preact, Wikipedia, Hacker News, блог Cloudflare и большую часть дашборда Cloudflare. Авторы описывают его как эфемерный, полностью изолированный движок без состояния, который существует ровно на время задачи и хорошо масштабируется под всплески агентной нагрузки.

Подходит

Агентам, которым нужна отрисовка страницы и которые готовы обменять пиксель-перфект Chromium на цену и масштаб.

Автоматизациям и приложениям на одиночных Quick Actions: извлечь содержимое страницы, сделать PDF или скриншот совместимого сайта.

извлечение HTMLскриншотыPDF всплески нагрузкитысячи параллельных сессий

Пока не подходит

Если нужно проигрывать видео, рисовать WebGL, проходить бот-челлендж с настоящими отпечатками TLS или держать десятиминутную авторизованную сессию с постоянным состоянием — берите Chromium, он остаётся вариантом по умолчанию в Browser Run.

Проверить конкретный сайт быстрее всего в публичном playground: смотрите консоль и метрики памяти.

видеоWebGLTLS-фингерпринт долгие сессии с авторизацией
этот список в статье ↗
12

Над чем работают прямо сейчас

в статье

Проекту двенадцать недель, первый коммит был в мае. Четыре направления работы команда называет открыто.

🔌Покрытие CDP

Сейчас реализовано подмножество протокола — столько, чтобы закрыть требования большинства агентов и инструментов автоматизации, включая надёжную инспекцию DOM и сети. Набор продолжают расширять.

🖼️Точность отрисовки

Скриншоты и PDF доводят до ума отдельно: модели часто работают с изображением лучше, чем с текстом под ним.

🧪Больше WPT

Добавляют веб-API и проходят новые тесты — это дорога к состоянию, пригодному для продакшена.

Эффективность

Бенчмарки CPU, памяти и времени ответа крутятся постоянно; над стоимостью работают вместе с другими командами Developer Platform.

Планы по открытому коду. Kitesurf собираются выложить в open source, когда будет готов. Цель — дать любому клиенту развернуть собственную версию в своём аккаунте.

Структура статьи

Клик по разделу открывает нужное место в оригинале. Cloudflare Blog не отдаёт якоря у заголовков, поэтому ссылки построены на scroll-to-text: Chrome, Edge и Safari проскроллят к тексту и подсветят его, Firefox откроет статью сверху.

How it started

читать ↗

obscura, порт на Workers с помощью AI-агента и пять принципов: тесты, Rust, обработка исключений, изоляция, отказ от состояния.

Скриншот переписки команды с ссылкой на obscuraрис.
Схема изоляции исходящего трафикарис.

How we built it

читать ↗

Жизнь запроса целиком, затем разбор четырёх компонентов: сеть, Engine, PageScript, PageRenderer.

Диаграмма последовательности запросарис.
Схема сетевого доступа компонентоврис.
Схема Engineрис.
Схема PageScriptрис.
Схема PageRendererрис.

Kitesurf passes 215,000+ WPT tests and growing

читать ↗

Динамика прохождения WPT, покрытие по областям и таблица бенчмарков против Chromium. Здесь же — Doom из старого эксперимента Cloudflare, запущенный в Kitesurf.

График роста сабтестов WPTрис.
Таблица покрытия WPT по областямрис.

Try it today in Browser Run

читать ↗

Параметр browser=kitesurf, конфиг MCP, curl для Quick Actions и playground со встроенным Chrome DevTools.

Скриншот playground с панелью Memoryрис.

When is Kitesurf better? · What Kitesurf is not yet able to do · Where it goes

читать ↗

Совместимые сайты, честный список того, что пока не работает, и четыре направления развития.

Final notes

читать ↗

Планы на open source, ссылки на playground, changelog и Discord.

Цитаты

«ИИ безразличны вкладки, темы, расширения и синхронизация между устройствами. Ему важны число токенов, контекстное окно, масштабируемость, производительность и стоимость».
AI doesn’t care about tabs, themes, browser extensions, or synchronization across devices. It cares about token count, context windows, scalability, performance, and costs.
— перевод конспекта, оригинал во вступлении в статье ↗
«Любой сбой деградирует до пустого кадра или пропавшего элемента, но никогда — до мёртвой сессии».
any failure degrades to a blank frame or a missing element, never a dead session
— правило обработки исключений в статье ↗
«Мы, по сути, исполняем рантайм поверх рантайма. Выглядит неоптимально, так оно и есть, но для редких eval в чужом коде работает достаточно хорошо».
We are basically executing a runtime on top of a runtime, which doesn’t seem optimal, and it isn’t, but it works well enough to handle the occasional evals we find in the code.
— про Boa JS в статье ↗
«Chromium выигрывает по секундомеру, потому что JIT, который уже видел эту страницу, всегда обгонит холодный программный рендерер».
Chromium wins the stopwatch because a JIT that has already seen this page always beats a cold software renderer — and today it does, by about 1.7x.
— разбор бенчмарков в статье ↗
#

В цифрах

12
недель от вопроса до публичной беты, первый коммит в мае
215 000+
сабтестов WPT проходит, плюс сотни каждую неделю
3,1×
меньше CPU на скриншот, чем у Chromium
меньше памяти при извлечении HTML
1,7–1,8×
проигрыш по времени ответа
69,5 МБ
JS heap на главной Wikipedia в playground
14
URL в корпусе, на котором мерили медианы пяти прогонов
4
компонента: Engine, PageScript, PageRenderer, SandboxOutbound

Как применить

Две группы шагов: попробовать сам Kitesurf и забрать инженерные приёмы, которые работают вне этого проекта.

// попробовать Kitesurf

Один параметр: добавьте browser=kitesurf к CDP-эндпоинту Browser Run и прогоните существующий сценарий Puppeteer или Playwright без правок кода.
Начните с одиночных задач: скриншот, PDF, извлечение HTML через Quick Actions. Это профиль, под который Kitesurf и делали.
Соберите свой корпус: прогоните целевые URL через playground и разложите их на две стопки — «рендерится» и «не рендерится». Другого способа узнать совместимость авторы не предлагают.
Оставьте Chromium там, где он нужен: видео, WebGL, бот-челленджи с проверкой TLS и долгие авторизованные сессии. Это разные инструменты, а не замена одного другим.
Мерьте счёт, а не секундомер: сравнивайте CPU и память, а не только время ответа. Kitesurf медленнее в 1,7–1,8 раза и при этом дешевле в 3–7 раз по ресурсам.
Смотрите панель Memory: в playground встроен Chrome DevTools с расходом по изолятам — так видно реальную цену конкретной страницы.

// забрать приёмы в свой проект

Дайте агенту готовый набор критериев: Cloudflare отдала AI не задачу «сделай хорошо», а конкретный корпус тестов с порядком фич. Найдите свой аналог WPT — контрактные тесты, golden-файлы, спецификацию с проверками.
Добавьте визуальную регрессию поверх юнит-тестов: многошаговый сценарий на реальных данных, который сверяет и ассерты, и результат на каждом шаге. Соответствие спецификации ещё не означает работоспособность.
Зафиксируйте правило деградации письменно: «сбой отдаёт пустой результат, но не роняет сессию». Ловить на каждой границе, отдавать безопасное пустое, логировать достаточно для диагностики.
Сведите выход наружу в один компонент: одна дверь в сеть, остальным — запрет на уровне платформы, а не договорённости. Тогда политику (CORS, заголовки, cookies) достаточно написать один раз.
Соберите состояние в одном месте: Kitesurf держит его только в Engine, поэтому рендерер можно убить на зависшем вызове и поднять заново. Проверьте, какие ваши сервисы держат состояние по привычке.
Сначала вычтите, потом оптимизируйте: выигрыш дало не ускорение Chromium, а отказ от того, что нужно только человеку. Составьте список функций, которые ваш потребитель не использует.
🧰

Ссылки и понятия

// упомянуто в статье

Kitesurf playgroundпубличная песочница: ввести URL, посмотреть отрисовку, открыть DevTools
Browser Runпродукт Cloudflare для headless-автоматизации, через него доступен Kitesurf
obscuraheadless-движок на Rust, с которого началась идея
Web Platform Testsобщий набор тестов соответствия стандартам W3C
Blitz · blitz-paintмодульный движок рендеринга на Rust; blitz-paint отвечает за отрисовку
StyloCSS-парсер Firefox на Rust
Boa JSдвижок ECMAScript на Rust, закрывает eval внутри Workers
Dynamic Workersподнимают изолят на навигацию и раздают права на сеть
RPC в Workersвызовы между воркерами без схем API и аутентификации
Changelog · Discordкуда смотреть за обновлениями и куда писать фидбэк

// ключевые понятия

CDPChrome DevTools Protocol: язык, на котором с браузером говорят Puppeteer, Playwright и DevTools
V8-изолятлёгкий изолированный контекст исполнения JavaScript; основа модели безопасности Workers
OOPIFout-of-process iframe: фрейм, вынесенный за пределы процесса страницы. В Kitesurf получает свой изолят PageScript
wasm-bindgenсвязка Rust и JavaScript при компиляции в WebAssembly, без слоёв Emscripten
Quick Actionsодиночные операции Browser Run: скриншот, PDF, извлечение содержимого
Prompt injectionатака через содержимое страницы, которое агент читает как инструкцию; в модели угроз агентного браузера идёт первым пунктом
stateless по умолчанию изоляция на уровне платформы одна дверь в сеть Rust → Wasm рантайм поверх рантайма для eval пока без видео и WebGL
×
Открыть в статье