Bất kỳ stack AI agent nào chạm vào web đều phải chạy headless Chromium ở đâu đó — để scrape, chụp screenshot, hoặc điền form thay người dùng. Chromium là lựa chọn mặc định vì nó là engine trình duyệt duy nhất đã được thử lửa ở quy mô đó. Cloudflare vừa ra mắt thứ đặt câu hỏi ngược lại điều đó: Kitesurf, một trình duyệt xây từ đầu, chuyên cho workload của AI agent, không dùng Chromium chút nào.
Tôi đã chạy fleet headless browser cho scraping và test automation nhiều năm nay, nên với lời quảng cáo “cùng API CDP, chi phí tài nguyên chỉ bằng một phần nhỏ” — đây là kiểu tuyên bố tôi muốn kiểm chứng bằng số liệu trước khi tin. Cloudflare đã công bố benchmark thật. Dưới đây là những gì họ thực sự nói, và tôi sẽ triển khai cái này ở đâu so với việc giữ nguyên Chromium.
Kitesurf Thực Sự Là Gì
Kitesurf không phải là fork của Chromium hay wrapper quanh một engine có sẵn. Nó được lắp ráp từ ba thành phần trưởng thành, lấy từ nguồn khác nhau, mỗi cái làm một việc:
- Blitz — layout engine của Servo, xử lý box model, flexbox, grid, và hình học render
- Stylo — CSS engine của Firefox, xử lý selector matching và tính toán style
- Boa — JavaScript engine viết bằng Rust, thực thi script trang
Đây là lựa chọn có chủ đích: thay vì viết mới layout engine hay CSS engine từ đầu (một công trình nhiều năm mà Chromium, Firefox, và Safari đều đã trả giá đắt), Cloudflare ghép các engine hiện có, được duy trì độc lập, đã pass các bộ conformance thật.
Kiến trúc tách thành ba phần cô lập:
flowchart LR
A[Agent Request] --> B[Engine Worker]
B --> C[PageScript - Boa JS]
B --> D[PageRenderer - Blitz+Stylo]
C --> E[CDP Response]
D --> E- Engine Worker — điều phối vòng đời trang và sở hữu interface CDP (Chrome DevTools Protocol)
- PageScript — chạy Boa, thực thi JavaScript của trang trong môi trường cô lập
- PageRenderer — chạy Blitz + Stylo, tạo ra output layout và paint
Điểm mấu chốt: toàn bộ chạy bên trong một V8 isolate của Cloudflare Workers, không phải container hay VM. Đây là phần thực sự thay đổi bài toán kinh tế: không có process tree Chromium, không có GPU process, không có overhead OS trên mỗi instance — chỉ là một isolate khởi động trong vài mili-giây.
Những Con Số Quan Trọng
Benchmark của chính Cloudflare, chạy so với headless Chromium trên các workload screenshot và extract nội dung tương đương:
| Chỉ số | Kitesurf so với Chromium |
|---|---|
| CPU usage | Ít hơn 3.1–3.8 lần |
| Memory usage | Ít hơn 4.7–7.0 lần |
| Tốc độ wall-clock | Chromium nhanh hơn 1.7–1.8 lần |
| Web Platform Tests pass | 215,000+ |
Dòng cuối cùng quan trọng hơn vẻ ngoài — 215k+ WPT pass nghĩa là đây không phải renderer đồ chơi vỡ trên trang thực tế; nó theo sát chuẩn web thật, cùng bộ test mà các hãng trình duyệt dùng nội bộ.
Số CPU/memory là điểm nhấn, nhưng nói thật: Chromium vẫn nhanh hơn về wall-clock thô, vì Boa không có JIT compiler như Chromium. Với trang SPA nặng JS — tính toán nhiều phía client — Chromium sẽ xong nhanh hơn mỗi request. Kitesurf thắng về chi phí-trên-mỗi-request ở quy mô lớn, không phải độ trễ-trên-mỗi-request.
Thực Hành: Cùng Code, Khác Backend
Phần thực sự quan trọng cho việc áp dụng: Kitesurf nói CDP, cùng giao thức mà Puppeteer và Playwright đã dùng để điều khiển Chromium. Nghĩa là hầu hết code automation hiện có không cần đổi — chỉ trỏ tới endpoint khác.
// Code Puppeteer hiện có, trỏ tới Chromium
const browser = await puppeteer.connect({
browserWSEndpoint: 'wss://chrome.example.com/session',
});
// Cùng code, trỏ tới endpoint Kitesurf trên Workers
const browser = await puppeteer.connect({
browserWSEndpoint: 'wss://kitesurf.example.workers.dev/session',
});
const page = await browser.newPage();
await page.goto('https://example.com/product-listing');
const data = await page.evaluate(() => {
return Array.from(document.querySelectorAll('.price')).map(el => el.textContent);
});
await browser.close();
Không cần viết lại. Đó mới là thành tựu kỹ thuật thật sự ở đây — không phải engine mới, mà là việc biến engine mới thành drop-in replacement cho bề mặt CDP mà mọi người đã code sẵn.
Tôi Sẽ Triển Khai Cái Này Ở Đâu
Kitesurf hợp lý khi:
- Bạn chạy một fleet worker scraping/extraction AI agent ở volume thật, nơi chi phí CPU/memory tăng tuyến tính theo quy mô fleet — giảm 3-7x tài nguyên là giảm thẳng vào hóa đơn hạ tầng.
- Workload chủ yếu là extraction (đọc DOM, chụp screenshot, điền form) thay vì chạy logic JS nặng phía client.
- Bạn muốn sandbox cấp isolate mà Workers cho miễn phí khi chạy phiên browsing do agent điều khiển, có thể không đáng tin — không có container chung, không có bề mặt escape process giữa các tenant.
- Độ trễ cold-start quan trọng. Một V8 isolate khởi động trong vài mili-giây; một process Chromium mới thì không.
Giữ headless Chromium khi:
- Trang đích của bạn là SPA nặng JS mà tốc độ thực thi JIT-compiled thực sự quan trọng — hiệu năng cấp interpreter của Boa sẽ hiện ra thành độ trễ thật trên code client tính toán nặng.
- Bạn cần khả năng tương thích site tối đa ngay bây giờ. Chromium có nhiều năm xử lý edge-case cho trang hỏng, không chuẩn mà một engine mới, dù conformant tới đâu, chưa tích lũy được.
- Team bạn đã có kiến thức vận hành sâu về Chromium/Puppeteer và chi phí hiện tại thực ra không phải vấn đề đáng giải quyết.
Xu Hướng Điều Này Xác Nhận
Tín hiệu thú vị không phải “Cloudflare xây một trình duyệt” — mà là workload của agent đang phân kỳ đủ xa khỏi workload duyệt web của con người đến mức một trình duyệt tối ưu riêng cho agent (chỉ headless, không cần render cho người xem, concurrency cao, chi phí-trên-mỗi-request là metric chính) giờ đáng để xây thay vì chỉ chạy headless trình duyệt hướng-người-dùng. Đây cùng pattern tôi đã thấy diễn ra trong inference serving, nơi runtime đa dụng cuối cùng bị thay thế bởi runtime chuyên biệt theo workload một khi volume đủ lớn để biện minh.
Tôi sẽ không rút ngay pipeline Puppeteer/Chromium đang production hôm nay — khoảng cách trưởng thành về tương thích site hiếm gặp là có thật, và còn sớm. Nhưng nếu bạn đang dựng mới một fleet agent-browsing từ đầu và workload của bạn nặng về extraction hơn là tương tác, hãy benchmark Kitesurf trên trang thực tế của bạn trước khi mặc định chọn Chromium. Khả năng tương thích CDP nghĩa là bài test đó chỉ tốn một buổi chiều, không phải một cuộc viết lại.
Thuận Lương là Technical Lead với hơn 15 năm kinh nghiệm về .NET, cloud architecture, và hệ thống AI. Anh viết về những bài học thực tế từ việc xây dựng hệ thống production.