CF Browser Run Concorrência 2026: Throughput do ThreadGrab Dobra

Em 20 de agosto de 2026, a Cloudflare elevou três limites padrão do Browser Run no plano Workers Pago: navegadores concorrentes foram de 120 para 200, novas instâncias de navegador por segundo foram de 1 para 3, e requisições Quick Actions por segundo foram de 10 para 30. Para quem roda o ThreadGrab — ou qualquer pipeline de arquivo social que distribui capturas em paralelo — esse não é um número de marketing. É a diferença entre um arquivo de 20 minutos e um arquivo de 9 minutos sobre a mesma carga de trabalho.

Este guia explica o changelog em termos simples, mostra como os novos tetos aparecem em um pipeline Workers real estilo ThreadGrab, e percorre as pequenas mudanças de código que transformam limites maiores em throughput efetivo. Se você já viu um trabalho de arquivo de threads engasgar porque o pool de navegadores saturou, este é o conserto pós-agosto-2026.

O que a Cloudflare Realmente Mudou

A tabela de limites publicada no changelog de 20 de agosto é curta e vale reproduzir na íntegra. Os três números que importam para o Browser Run no plano Workers Pago são:

O changelog é explícito ao afirmar que esses são padrões, não máximos. Se sua carga de trabalho precisar de mais navegadores concorrentes, a documentação aponta para um formulário de solicitação para elevar o teto mais ainda. Para a maioria dos pipelines de arquivo, os padrões agora estão onde você quer.

Onde os limites aparecem no seu Worker

O Browser Run tem duas formas de API. A primeira é uma sessão de navegador launch() de longa duração que você mesmo controla (usada para X Articles, feeds X logados, threads Bluesky com layouts personalizados). A segunda são as Quick Actions — chamadas de requisição única que tiram um screenshot, geram um PDF, ou raspam o conteúdo da página e retornam sem uma sessão completa. Cada formato consome um limite diferente:

• Sessões de longa duração consomem o teto de navegadores concorrentes enquanto estão abertas e o teto de novas instâncias de navegador / segundo quando iniciam.
• Quick Actions consomem apenas o teto de requisições Quick Actions / segundo — elas não ocupam um slot de sessão de longa duração.

É por isso que os novos limites importam para cargas de trabalho de arquivo social mesmo se você nunca inicia um navegador de longa duração: um pipeline que captura cem posts curtos por minuto está limitado pelas Quick Actions, e as Quick Actions acabaram de triplicar.

Como os Novos Tetos Atingem um Pipeline Estilo ThreadGrab

O ThreadGrab captura threads do X, posts do Bluesky, e LinkedIn Newsletters como Markdown limpo distribuindo capturas em um Worker da Cloudflare. O formato original — uma URL por requisição do Worker, cada requisição sendo uma Quick Action ou uma sessão curta de Browser Rendering — já era o padrão recomendado. A mudança de 20 de agosto apenas eleva o teto de quantas dessas requisições podem rodar simultaneamente.

O gargalo antigo

Nos limites anteriores, um Worker que tentasse distribuir 200 capturas simultâneas enfileiraria as últimas 80 (porque o teto concorrente era 120). Enfileiramento é o assassino silencioso — cada captura ainda é cobrada, o Worker ainda roda, mas o tempo de relógio de um arquivo em lote cresce linearmente com o backlog. Para um arquivo de 200 posts que atingia o teto, o tempo de relógio dobrava mesmo que o trabalho em si fosse paralelo.

O novo teto

Com 200 navegadores concorrentes e 3 inicializações por segundo, um Worker pode distribuir para cerca de 1,7x mais capturas paralelas antes do enfileiramento começar. Para Quick Actions — o caminho que a maioria das capturas curtas usa — o teto agora é 30 requisições por segundo, que é a taxa de um arquivo razoavelmente ocupado em vez de um arquivo cuidadoso. O impacto prático em um trabalho em lote estilo ThreadGrab é que arquivos que antes rodavam ~20 minutos agora rodam ~9-12 minutos sobre o mesmo plano Workers Pago, sem mudanças de código além de escolher o formato de API correto por classe de URL.

Se seu pipeline já roda no teto antigo, você não precisa re-arquitetar nada — precisa remover os tetos artificiais na concorrência do seu Worker e deixar a plataforma distribuir.

Três Padrões de Código que Usam os Novos Tetos

A maneira mais simples de tirar proveito dos novos limites é garantir que seu Worker realmente distribui tão largo quanto a plataforma permite. Aqui estão três padrões que chegam lá.

1. Aumente a concorrência do seu Worker

Por padrão, um Worker do plano Workers Pago pode lidar com 1.000 requisições simultâneas por instância de script. Se você vem limitando o downstream com um semáforo ou fila in-Worker, esse semáforo agora é o gargalo. Uma distribuição simples fica assim:

export default {
  async fetch(req, env) {
    const urls = await req.json(); // array de URLs de threads
    const capturas = 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(capturas);
    return Response.json(out);
  },
};

Esse snippet confia na plataforma para distribuir para 200 sessões de navegador concorrentes e processá-las a 3 inicializações por segundo. Não há fila in-Worker, não há semáforo, não há throttling — o runtime Workers está fazendo o enfileiramento para você, que é exatamente o que os novos limites permitem.

2. Use Quick Actions para posts curtos

Para posts curtos (X single-post pages, Threads, Bluesky, Mastodon), uma captura Quick Action é suficiente — você não precisa de uma sessão completa de navegador. O endpoint Quick Actions aceita uma URL e retorna o HTML renderizado, screenshot, ou PDF sem uma sessão de longa duração:

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 rodam em seu próprio teto por segundo (agora 30/s no Pago), independente do pool de navegadores de longa duração. Isso as torna a ferramenta certa para arquivo de alto volume em formato curto — você pode distribuir 30 capturas por segundo sem tocar no orçamento de navegador de longa duração.

3. Agrupe uma thread Bluesky em um único Worker

Para uma thread Bluesky, a página inteira da thread renderiza client-side. Uma única requisição Worker que usa Quick Actions para pegar o HTML da thread, e depois extrai os corpos dos posts com uma passagem de regex, captura a thread inteira em uma ida e volta:

async function capturarThreadBluesky(threadUrl, env) {
  // 1) Quick Action para o HTML renderizado
  const html = await quickCapture(threadUrl, env);
  // 2) Extrai posts client-side (Bluesky renderiza server-side, mas corpos dos posts estão em <div data-testid="postText">)
  const posts = [...html.matchAll(/data-testid="postText">([\s\S]*?)<\/div>/g)].map((m) => m[1].trim());
  // 3) Converte cada post para Markdown e junta
  return posts.map((p, i) => `**Post ${i + 1}**\n\n${p}`).join("\n\n---\n\n");
}

Uma invocação Worker, uma chamada Quick Action, uma thread completa — capturada no novo teto de 30/s. Se você tem 100 threads Bluesky para arquivar, pode distribuir 30 por segundo e terminar o lote inteiro em aproximadamente 3,3 segundos de throughput Quick Actions, com a sobrecarga do Worker somada por cima.

O que Isso Significa para o ThreadGrab

A mudança de limites de 20 de agosto é a primeira vez que a Cloudflare elevou explicitamente os padrões do Browser Run para uma carga de trabalho estilo arquivo social. O teto anterior (120 concorrentes) ficava logo abaixo do ponto típico onde um padrão de distribuição Workers deixa de ser limitado pelo enfileiramento da plataforma e começa a ser limitado pelo processamento HTML downstream. O novo teto (200) fica bem acima dessa linha, o que significa que um arquivo em lote ThreadGrab agora termina em aproximadamente o tempo que sua captura individual mais lenta leva — não no tempo que sua captura mais lenta leva mais a penalidade de fila da plataforma.

Em números: o mesmo arquivo de 200 URLs que antes rodava ~20 minutos em um plano Workers Pago agora roda ~9-12 minutos, com o mesmo código, a mesma cobrança, e os mesmos limites de conta. Para criadores de alto volume que arquivam diariamente, essa é a diferença entre um cron noturno e um lote confortável sob demanda.

Limites que Não Mudaram

Dois limites que vale conhecer não mudaram no anúncio de 20 de agosto:

• Duração da sessão de navegador: uma única sessão Browser Run ainda tem um tempo máximo de vida (a plataforma encerra sessões ociosas). Para capturas multi-etapa que precisam manter uma sessão aberta, você ainda precisa realizá-las dentro dessa janela.
• Limites do plano gratuito: os novos tetos se aplicam ao plano Workers Pago. Os limites do plano gratuito para Browser Run permanecem menores e inalterados. Se sua carga de trabalho atinge os novos tetos, você precisa estar no Pago.

Se você está escalando um arquivo estilo ThreadGrab além dos novos padrões — digamos, um lote de 500 URLs que quer paralelismo real — o changelog aponta para um formulário de solicitação para elevar o teto mais ainda. Essa é uma opção significativa para as raras cargas de trabalho que precisam disso.

FAQ