CF Browser Run Concurrency 2026: Throughput ThreadGrab Naik Dua Kali Lipat

Pada 20 Agustus 2026, Cloudflare menaikkan tiga batas default untuk Browser Run pada paket Workers Berbayar: browser bersamaan naik dari 120 ke 200, instance browser baru per detik naik dari 1 ke 3, dan permintaan Quick Actions per detik naik dari 10 ke 30. Bagi siapa pun yang menjalankan ThreadGrab — atau pipeline arsip sosial apa pun yang menyebar ke ratusan tangkapan sekaligus — itu bukan angka pemasaran. Itu perbedaan antara arsip 20 menit dan arsip 9 menit pada beban kerja yang sama.

Panduan ini mengupas changelog dalam istilah sederhana, menunjukkan seperti apa batas baru dalam pipeline Workers gaya ThreadGrab yang nyata, dan menelusuri perubahan kode kecil yang mengubah batas lebih tinggi menjadi throughput aktual. Jika Anda pernah melihat pekerjaan arsip thread merangkak karena pool browser jenuh, inilah perbaikan pasca-Agustus-20.

Apa yang Sebenarnya Diubah Cloudflare

Tabel batas yang diterbitkan di changelog 20 Agustus pendek dan layak reproduced secara verbatim. Tiga angka yang penting untuk Browser Run pada paket Workers Berbayar adalah:

Changelog secara eksplisit menyatakan bahwa ini adalah default, bukan maksimum. Jika beban kerja Anda membutuhkan lebih banyak browser bersamaan, dokumentasi menunjuk ke formulir permintaan untuk menaikkan batas lebih lanjut. Untuk kebanyakan pipeline arsip, default sekarang sudah tepat di tempat yang Anda inginkan.

Di mana batas muncul di Worker Anda

Browser Run memiliki dua bentuk API. Yang pertama adalah sesi browser launch() yang berjalan lama dan Anda kontrol sendiri (digunakan untuk X Articles, feed X yang login, thread Bluesky di balik layout custom). Yang kedua adalah Quick Actions — panggilan satu-permintaan yang mengambil screenshot, menghasilkan PDF, atau mengikis konten halaman dan mengembalikannya tanpa sesi penuh. Setiap bentuk mengenai batas yang berbeda:

• Sesi jangka panjang memakan batas browser bersamaan saat terbuka dan batas instance browser baru / detik saat dimulai.
• Quick Actions hanya memakan batas permintaan Quick Actions / detik — mereka tidak menempati slot sesi jangka panjang.

Itulah mengapa batas baru penting untuk beban kerja arsip sosial meskipun Anda tidak pernah memulai browser jangka panjang: pipeline yang menangkap seratus post pendek per menit dibatasi oleh Quick Actions, dan Quick Actions baru saja dilipat tigakan.

Bagaimana Batas Baru Mengenai Pipeline Gaya ThreadGrab

ThreadGrab menangkap thread X, post Bluesky, dan LinkedIn Newsletter sebagai Markdown bersih dengan menyebarkan tangkapan melalui Worker Cloudflare. Bentuk asli — satu URL per permintaan Worker, setiap permintaan berupa Quick Action atau sesi Browser Rendering singkat — sudah menjadi pola yang direkomendasikan. Perubahan 20 Agustus hanya menaikkan langit-langit tentang berapa banyak dari permintaan tersebut yang dapat berjalan sekaligus.

Bottleneck lama

Pada batas sebelumnya, Worker yang mencoba menyebarkan 200 tangkapan simultan akan mengqueue 80 yang terakhir (karena batas bersamaan adalah 120). Queue adalah pembunuh diam-diam — setiap tangkapan tetap ditagih, Worker tetap berjalan, tetapi waktu dinding dari arsip batch tumbuh secara linier dengan backlog. Untuk arsip 200 post yang mencapai batas, waktu dinding menjadi dua kali lipat meskipun pekerjaannya sendiri paralel.

Batas baru

Dengan 200 browser bersamaan dan 3 peluncuran per detik, Worker dapat menyebar ke sekitar 1,7x lebih banyak tangkapan paralel sebelum queue terjadi. Untuk Quick Actions — jalur yang kebanyakan tangkapan pendek ambil — batasnya sekarang 30 permintaan per detik, yang merupakan laju crawler arsip yang cukup sibuk bukan yang hati-hati. Dampak praktis pada pekerjaan batch gaya ThreadGrab adalah arsip yang sebelumnya berjalan ~20 menit sekarang berjalan ~9-12 menit pada paket Workers Berbayar yang sama, tanpa perubahan kode selain memilih bentuk API yang tepat per kelas URL.

Jika pipeline Anda sudah berjalan pada batas lama, Anda tidak perlu re-arsitektur apa pun — Anda perlu menghilangkan langit-langit buatan dalam concurrency Worker Anda dan biarkan platform menyebar.

Tiga Pola Kode yang Menggunakan Batas Baru

Cara paling sederhana untuk memanfaatkan batas baru adalah memastikan Worker Anda benar-benar menyebar selebar yang diizinkan platform. Berikut tiga pola yang sampai di sana.

1. Naikkan concurrency Worker Anda

Secara default, Worker paket Workers Berbayar dapat menangani 1.000 permintaan simultan per instance skrip. Jika Anda telah membatasi downstream dengan semaphore atau antrian in-Worker, semaphore itu sekarang menjadi bottleneck. Penyebaran sederhana terlihat seperti ini:

export default {
  async fetch(req, env) {
    const urls = await req.json(); // array URL thread
    const tangkapan = urls.map(async (u) => {
      const r = await fetch("https://api.cloudflare.com/client/v4/accounts/" + env.CF_ACCOUNT_ID + "/browser-rendering/snapshot", {
        method: "POST",
        headers: { "Authorization": "Bearer " + env.CF_API_TOKEN, "Content-Type": "application/json" },
        body: JSON.stringify({ url: u, html: true, gotoOptions: { waitUntil: "networkidle0" } }),
      });
      const { result } = await r.json();
      return { url: u, html: result };
    });
    const out = await Promise.all(tangkapan);
    return Response.json(out);
  },
};

Snippet ini memercayai platform untuk menyebar ke 200 sesi browser bersamaan dan memprosesnya pada 3 peluncuran per detik. Tidak ada antrian in-Worker, tidak ada semaphore, tidak ada throttling — runtime Workers yang melakukan queue untuk Anda, yang persis seperti yang batas baru memungkinkan.

2. Gunakan Quick Actions untuk post pendek

Untuk post pendek (X single-post pages, Threads, Bluesky, Mastodon), tangkapan Quick Action sudah cukup — Anda tidak perlu sesi browser penuh. Endpoint Quick Actions menerima URL dan mengembalikan HTML yang di-render, screenshot, atau PDF tanpa sesi jangka panjang:

async function quickCapture(url, env) {
  const r = await fetch("https://api.cloudflare.com/client/v4/accounts/" + env.CF_ACCOUNT_ID + "/browser-rendering/quick-screenshot", {
    method: "POST",
    headers: { "Authorization": "Bearer " + env.CF_API_TOKEN, "Content-Type": "application/json" },
    body: JSON.stringify({ url, screenshotOptions: { type: "png", fullPage: true } }),
  });
  const { result } = await r.json();
  return result.screenshot; // base64 PNG
}

Quick Actions berjalan pada batas per detik mereka sendiri (sekarang 30/detik pada Berbayar), independen dari pool browser jangka panjang. Itu menjadikan mereka alat yang tepat untuk arsip volume tinggi dalam format pendek — Anda dapat menyebar 30 tangkapan per detik tanpa menyentuh anggaran browser jangka panjang sama sekali.

3. Batch tangkapan thread Bluesky dalam satu Worker

Untuk thread Bluesky, seluruh halaman thread me-render client-side. Satu permintaan Worker yang menggunakan Quick Actions untuk mengambil HTML thread, kemudian mengekstrak body post dengan pass regex, menangkap seluruh thread dalam satu round trip:

async function tangkapThreadBluesky(threadUrl, env) {
  // 1) Quick Action untuk HTML yang di-render
  const html = await quickCapture(threadUrl, env);
  // 2) Ekstrak post client-side (Bluesky me-render server-side, tapi body post ada di <div data-testid="postText">)
  const posts = [...html.matchAll(/data-testid="postText">([\s\S]*?)<\/div>/g)].map((m) => m[1].trim());
  // 3) Markdown-ify setiap post dan gabungkan
  return posts.map((p, i) => `**Post ${i + 1}**\n\n${p}`).join("\n\n---\n\n");
}

Satu invokasi Worker, satu panggilan Quick Action, satu thread lengkap — ditangkap pada batas baru 30/detik. Jika Anda punya 100 thread Bluesky untuk diarsipkan, Anda dapat menyebar 30 per detik dan menyelesaikan seluruh batch dalam sekitar 3,3 detik throughput Quick Actions, dengan overhead Worker ditambahkan di atasnya.

Apa Artinya Ini untuk ThreadGrab

Perubahan batas 20 Agustus adalah pertama kalinya Cloudflare secara eksplisit menaikkan default Browser Run untuk beban kerja gaya arsip sosial. Batas sebelumnya (120 bersamaan) berada tepat di bawah titik tipikal di mana pola Worker yang menyebar berhenti dibatasi oleh queue platform dan mulai dibatasi oleh pemrosesan HTML downstream. Batas baru (200) berada jauh di atas garis itu, yang berarti arsip batch ThreadGrab sekarang selesai dalam kira-kira waktu yang dibutuhkan tangkapan individunya yang paling lambat — bukan dalam waktu yang dibutuhkan tangkapan paling lambatnya ditambah penalti queue platform.

Dalam angka: arsip 200 URL yang sama yang sebelumnya berjalan ~20 menit pada paket Workers Berbayar sekarang berjalan ~9-12 menit, dengan kode yang sama, tagihan yang sama, dan batas akun yang sama. Untuk kreator bervolume tinggi yang mengarsipkan setiap hari, itulah perbedaan antara cron malam hari dan batch sesuai permintaan yang nyaman.

Batas yang Tidak Berubah

Dua batas yang worth knowing tidak berubah dalam pengumuman 20 Agustus:

• Durasi sesi browser: satu sesi Browser Run masih memiliki masa hidup maksimum (platform akan menghentikan sesi yang idle). Untuk tangkapan multi-langkah yang perlu menjaga sesi tetap terbuka, Anda masih perlu melakukannya dalam jendela itu.
• Batas paket gratis: batas baru berlaku untuk paket Workers Berbayar. Batas paket gratis untuk Browser Run tetap lebih rendah dan tidak berubah. Jika beban kerja Anda menyentuh batas baru, Anda perlu berada di paket Berbayar.

Jika Anda menskalakan arsip gaya ThreadGrab melampaui default baru — katakanlah, batch 500 URL yang ingin paralelisme sejati — changelog menunjuk ke formulir permintaan untuk menaikkan batas lebih lanjut. Itu adalah opsi yang berarti untuk beban kerja langka yang membutuhkannya.

FAQ