Browserless: avaliação do Chrome como serviço que você pode controlar

Browserless é o Chrome headless empacotado como um serviço que você mesmo hospeda. O contêiner Docker fica rodando direto, recebe trabalho via HTTP ou WebSocket e aplica limites compartilhados de admissão, em vez de ser importado por cada cliente. Nos testes REST feitos aqui, o serviço manteve zero processos do Chrome em repouso, criou processos do Chrome enquanto uma requisição estava ativa e voltou a zero depois. O que fica em pool é a capacidade do serviço e a fila, não um conjunto verificado de processos de navegador já aquecidos.

Eu executei a v2.55.0 em um ambiente local controlado — inicialização decomposta em etapas, controle de admissão em três configurações, fidelidade dos endpoints contra uma referência conhecida, um soak de 30 sessões e o limite de timeout. O comportamento útil foi operacional, não um ganho de velocidade: os limites de admissão corresponderam às respostas visíveis no cliente, e os pontos fracos vieram mais da forma de implantação do que da ferramenta em si.

O resultado mais útil não foi um número de latência. O Browserless não faz o Chrome iniciar mais rápido — ele coloca uma política de entrada no Chrome: um número fixo de sessões lá dentro, uma fila atrás e um HTTP 429 para todo o resto. Esse teto passou de 4 para 8 para 10 quando alterei duas variáveis de ambiente, e a própria contabilidade do contêiner bateu com os status codes do meu cliente em cada requisição.

O que o Browserless realmente é

É aqui que muita gente se confunde. Browserless não é uma biblioteca que você importa e chama. É uma imagem Docker — ghcr.io/browserless/chromium — que você executa como um serviço de longa duração. Ela faz a mediação das tarefas de navegador e expõe isso de duas formas: endpoints REST (/content, /scrape, /screenshot, /pdf, além de /function e /unblock) e uma interface CDP/WebSocket para a qual Puppeteer e Playwright podem fazer connect().

Eu testei a superfície REST. O caminho via WebSocket é real e bastante usado, mas não foi medido aqui.

A versão testada foi v2.55.0, verificada em 27 de julho de 2026.

O número de estrelas muda com o tempo; trate isso como um retrato do momento.

O gate de licença: SSPL-1.0 ou comercial

O repositório oferece o Browserless sob SSPL-1.0 ou uma licença comercial da Browserless. Leia o LICENSE atual e as orientações oficiais de implantação open source da Browserless antes de escolher o caminho. Este artigo não fez análise jurídica de produtos comerciais, aplicações fechadas, sistemas de CI, serviços hospedados ou implantações internas, então não classifica esses cenários por licença. Peça ao responsável jurídico ou a quem cuida de licenciamento para avaliar o modelo de implantação e distribuição.

A Browserless também vende planos hospedados. Preços e definições de unidades de uso mudam com frequência e não fizeram parte deste teste self-hosted; confirme isso no site oficial em vez de tratar uma tabela antiga aqui como prova de compra.

Como o modelo de sessão funciona por baixo dos panos

O caminho REST medido se comportou como trabalho de navegador por requisição, mas este harness não inspecionou os internos do Browserless a fundo o bastante para distinguir um novo processo de navegador de qualquer estratégia possível de reaproveitamento de contexto. O que ele mostrou é mais simples: zero processos do Chrome em repouso, 11 processos da família Chrome durante uma requisição ativa e zero após a execução sequencial. Não houve evidência de um pool de navegadores já aquecidos nessa configuração.

O serviço Node de longa duração aceita um número limitado de jobs de navegador, coloca uma fila para outro conjunto limitado e recusa o restante. Trate esse modelo de admissão como o contrato arquitetural medido abaixo. Não infira reaproveitamento de processo ou de contexto pela palavra “pool”; o harness de tempo não consegue provar isso.

O controle de admissão tem dois ajustes:

• CONCURRENT — quantas sessões rodam ao mesmo tempo.
• QUEUED — quantas requisições adicionais podem aguardar uma vaga.

O endpoint /config do contêiner reportou os padrões CONCURRENT=10, QUEUED=10, TIMEOUT=30000. Qualquer coisa além de CONCURRENT + QUEUED é recusada imediatamente.

A autenticação não é opcional. A v2 do Browserless sempre exige um token — se você não definir TOKEN, ele gera um valor aleatório e o imprime no stdout na inicialização. Cada chamada REST leva ?token=.

Para observabilidade, você tem /pressure (running, queued, CPU, memory, recently rejected), /sessions e /config. Também existe uma exportação JSON em /metrics, mas ela exige METRICS_JSON_PATH e eu não usei. E a imagem roda dumb-init como PID 1, que é a resposta documentada às reclamações de processos zumbis que acompanham o Chrome em contêineres há anos.

Realidade da configuração: um comando e quatro coisas que ninguém coloca nele

A linha de instalação que todo mundo cita realmente é só um docker run. O que vem ao redor disso é o que você precisa planejar.

A imagem tem 4,34 GB. Esse é o número que deve moldar suas expectativas, não a latência de inicialização. O manifesto traz tanto linux/arm64 quanto linux/amd64; no meu host arm64, o Docker puxou a variante nativa arm64. (O user-agent do Chrome dentro do contêiner ainda mostra X11; Linux x86_64 — isso é o UA cosmético do Chrome no Linux, não emulação. uname -m retorna aarch64. As pessoas abrem bug sobre isso.)

Usei --shm-size=2g em todas as medições. O harness não incluiu uma execução de controle com o /dev/shm padrão do Docker, então este artigo não pode dizer que 2 GiB seja universalmente obrigatório nem quantificar o ponto de falha. Ajuste isso para a quantidade de navegadores e para a carga de trabalho.

O token é uma preocupação de implantação, não uma formalidade. Sem ele, qualquer pessoa que consiga acessar a porta 3000 pode controlar um navegador na sua rede.

Rede de contêiner é problema seu. Meu fixture rodava no host, então o contêiner acessava isso por host.docker.internal (no colima isso é mapeado com --add-host host.docker.internal:host-gateway). Eu validei que o contêiner realmente conseguia alcançar o fixture com um curl bruto antes de confiar em qualquer medição.

Meu ambiente: colima 0.10.3 (6 CPU / 11,6 GiB) com Docker 29.2.1 no macOS 26.5.2 arm64. O harness usou apenas a biblioteca padrão do Python 3. Para PNG e PDF, ele checou assinaturas de arquivo, não validade do decodificador, dimensões, número de páginas, completude ou fidelidade visual.

Uma inicialização mínima equivalente usa a imagem fixada, um token explícito e a alocação de memória compartilhada usada aqui:

docker run --rm -p 3000:3000 --shm-size=2g \
  -e TOKEN=replace-with-a-secret \
  ghcr.io/browserless/chromium:v2.55.0

Depois que /pressure?token=... responde, um POST /content?token=... autenticado com um corpo JSON contendo a URL de destino exercita o caminho REST. Chamadores em produção também precisam de retry limitado com jitter para respostas 429; repetir imediatamente só disputa novamente a mesma fila cheia.

O custo da inicialização, decomposto

Três boots novos com docker run, medianas com mínimo–máximo:

A linha do meio é fácil de interpretar demais. Ela não mede a inicialização do navegador isoladamente e não mostra que o Browserless inicia o Chrome mais rápido do que uma biblioteca no mesmo processo. É uma ida e volta HTTP para dentro de um contêiner, somada a trabalho do navegador, navegação e transferência da resposta. A diferença de cerca de 0,17 s entre a primeira e as demais chamadas pode incluir efeitos de sistema de arquivos, SO, Chrome, Node ou cache do contêiner. Como os processos do Chrome estavam em zero em repouso e o harness não capturou trace CDP nem timeline de processo para essas chamadas, ele não consegue atribuir essa diferença ao reaproveitamento do navegador nem ao custo de inicialização “amortizado”.

Além disso: esses são números do colima VM no macOS. Linux em bare metal vai ser diferente. Não repasse 0,78 s para o time de SRE como se fosse portátil.

Na prática: encontrando o teto, dos dois lados

O contrato CONCURRENT + QUEUED → 429 é repetido em todo lugar e demonstrado em lugar nenhum.

A configuração: uma rota de fixture que dorme 5 segundos no servidor, para que cada requisição ocupe de forma confiável uma sessão por um tempo conhecido. Depois, dispare simultaneamente CONCURRENT + QUEUED + 4 requisições e veja o que volta — enquanto uma thread separada de amostragem consulta /pressure para ler a contabilidade interna do contêiner.

Três coisas saíram daqui.

O teto é exatamente CONCURRENT + QUEUED, sempre. As respostas bem-sucedidas foram 4, 8 e 10 — a soma configurada em cada caso. As recusas foram exatamente o excesso, que era 4 nas três execuções.

O teto muda. Ele não é um valor fixo embutido na imagem; é o que você configurar. Ir de 4 → 8 → 10 ajustando variáveis de ambiente é o que faz isso ser útil e não apenas curiosidade.

E os dois sinais são independentes. Os status codes do meu cliente vieram de respostas HTTP reais; /pressure veio da própria contabilidade interna do contêiner, consultada por uma thread diferente. Eles concordaram nessas três execuções curtas. Isso torna /pressure um candidato a sinal de produção, mas não um contrato completo de autoscaling: frequência de coleta, semântica de reset, agregação entre réplicas e comportamento sob cargas mistas mais longas ainda precisam de validação.

Uma nuance que as contagens de sucesso/falha escondem. Uma requisição enfileirada não falha — ela espera, e pode esperar bastante. Em (2, 2) com trabalho de 5 segundos, as respostas bem-sucedidas chegaram entre 5,7 s e 11,0 s, com mediana de 8,3 s. Portanto, a latência ponta a ponta chegou a aproximadamente duas durações de sessão. O harness não capturou timestamps separados de admissão e execução, então não pode atribuir todo o atraso ao tempo de fila.

O que isso parece em um job real

Imagine que você renderiza 4.000 páginas de produto em PDF toda noite, e cada página leva cerca de 5 segundos. Você define CONCURRENT=5, QUEUED=5. Seu teto de throughput é 5 páginas por 5 segundos — uma página por segundo — então o job leva cerca de 67 minutos se o fluxo ficar exatamente cheio o tempo todo. Isso é aritmética baseada em comportamento medido, não um benchmark, mas é a aritmética que você deveria fazer antes de implantar.

Qualquer requisição que chegue depois que todas as vagas de execução e fila estiverem ocupadas pode receber um 429 imediatamente; o disparo simultâneo não garante qual requisição ordinal perde a corrida. Um orquestrador de jobs deve tratar essa resposta como backpressure e usar retry limitado com jitter. Caso contrário, corre o risco de perder páginas enquanto a contabilidade superior do job continua — um risco operacional, não um cenário de falha demonstrado por este harness.

Na prática: o que os endpoints realmente enxergam

Para testar a fidelidade de renderização de forma honesta, a página de fixture esconde o texto marcador de qualquer pessoa que não esteja rodando um navegador real. A string visível Runtime Injected Marker 88 é montada a partir de fragmentos JavaScript no momento do carregamento, então não existe nenhum literal contíguo para ela em bytes enviados pelo servidor. Um fetch estático simples dessa página devolve 702 bytes sem nenhum dos marcadores.

O /content retornar 811 bytes com o marcador injetado significa que um Chromium real renderizou a página antes do HTML voltar. O /scrape extraiu um valor de um nó que só existe depois que o JavaScript roda. Ambos funcionaram com zero código de automação no cliente — um único POST autenticado.

Esse é o argumento real. Na mesma rodada de testes, um crawler estático perdeu totalmente esse tipo de conteúdo, e as bibliotecas de navegador no mesmo processo (chromedp, rod, Selenium) só pegaram depois que eu escrevi uma espera explícita. O Browserless capturou isso com uma requisição no formato de um curl. Você troca código de automação por peso operacional.

Há dois limites nessa afirmação. A evidência cobre as classes de conteúdo do meu fixture, não uma pesquisa da web moderna. E /unblock, o endpoint anti-detecção, foi deixado de lado de propósito — nenhum desses resultados deve ser lido como uma alegação de capacidade anti-bot. /function, /download e /performance também não foram testados.

Na prática: uma checagem curta de resíduos

O Chrome em contêiner tem fama de deixar cadáveres para trás, então rodei 30 sessões sequenciais com CONCURRENT=3 e contei processos dentro do contêiner.

Antes de confiar em qualquer coisa, calibre o detector. Enquanto uma sessão estava em andamento, o enumerador de /proc leu 11 processos da família Chrome (browser, zygote, GPU, renderers, utilities). Isso importa: prova que o instrumento consegue enxergar o Chrome, então o zero após a execução é uma medição, não cegueira. Um teste de vazamento que reporta “0 processos” sem provar que consegue contar não vale nada.

Depois de 30 sessões: 0 processos do Chrome, 0 zumbis. Os únicos sobreviventes foram dumb-init, node, Xvfb, start.sh e sh. /sessions mostrou 0 em repouso.

Memória do contêiner, pelo docker stats — o número visível para o operador, não o RSS de um processo isolado:

Crescimento líquido em 30 sessões: cerca de 9,5 MB, e a curva amostrada estabilizou depois da sessão 10. Isso é inconsistente com um vazamento linear simples por sessão nesse curto intervalo. O aquecimento do Node é uma explicação plausível, não algo que essa contagem de processos e série de memória consigam provar.

Escopo: 30 sessões sequenciais é um soak pequeno, não um teste de endurance nem de concorrência. Os avisos antigos de listeners do EventEmitter que aparecem no tracker de issues são o tipo de coisa que pode surgir depois de horas e milhares de sessões, e eu não rodei isso. A conclusão suportada é apenas que nenhum acúmulo de processos Chrome ou zumbis foi observado nessa janela na v2.55.0.

O limite de timeout

TIMEOUT é documentado como um ajuste. Eu quis ver ele disparar.

Com TIMEOUT=5000, uma sessão que tentou segurar a página por 15 segundos retornou HTTP 408 em 5,007 s em vez de travar. Essa única observação confirma a aplicação do limite perto do valor configurado. Ela não revela a implementação do timer nem prova a limpeza da vaga; um teste mais forte repetiria a tentativa, observaria /sessions e /pressure voltarem ao estado ocioso e então confirmaria que uma requisição seguinte recupera a vaga liberada.

A armadilha da migração: PREBOOT é inerte, e não avisa

De tudo que medi, este é o resultado que eu mais gostaria que alguém me entregasse antes de uma atualização.

O Browserless 2.0.0 removeu PREBOOT e KEEP_ALIVE — o changelog diz que foram removidos por serem confusos, pouco úteis e causarem bugs. Faz sentido. O problema é o que acontece quando uma configuração v1 é copiada e colada em v2, que é a forma mais comum de upgrade.

Executei o contêiner com -e PREBOOT=true e medi contra o padrão:

Todos os tempos ficam dentro da própria faixa mínimo–máximo do braço padrão — é ruído, não efeito. E nada foi pré-aquecido: o contêiner com PREBOOT=true fica em repouso sem nenhum navegador ativo, idêntico a um sem a flag. Mais dois sinais, nenhum deles numérico:

• /config não expõe nenhuma chave preboot. As chaves são concurrent, queued, timeout, token, maxCPU, maxMemory, retries e outras.
• Nenhum erro. Nenhum aviso. Nada nos logs do contêiner.

Então uma configuração PREBOOT da v1 no v2 é um no-op silencioso em inicialização normal e checagens de log. A chave ausente em /config somada ao comportamento inalterado é o sinal detectável; o Browserless não emite rejeição explícita nem aviso. Uma checagem de migração precisa inspecionar a configuração aplicada, em vez de tratar uma inicialização verde como prova de que toda variável de ambiente fez efeito.

KEEP_ALIVE é o caso oposto, e os dois não devem ser misturados. Ele foi removido na mesma release, mas não é silencioso — uma verificação pontual do contêiner mostra que ele registra Environment variable of "KEEP_ALIVE" is deprecated and ignored. ali no stdout. Esse é um aviso adequado para o operador. Eu não passei KEEP_ALIVE pelo mesmo harness medido que usei para PREBOOT, então estou relatando isso como uma checagem, não como uma medição. Mas a direção já é clara o bastante para importar: só PREBOOT é a armadilha silenciosa. O Browserless é mais honesto com KEEP_ALIVE do que um resumo genérico do tipo “a v2 ignora suas flags da v1” faria parecer.

Prós e contras

Prós

• Controle de admissão que se comporta exatamente como documentado e muda com a configuração — comprovado em três tetos diferentes, pelos status codes do cliente e pela própria contabilidade do servidor ao mesmo tempo.
• /pressure bateu com contagens visíveis de running, queued e rejected em três execuções curtas; vale avaliá-lo como uma entrada candidata para autoscaling e alertas.
• Renderização real de Chromium com zero código de automação no cliente: um único POST autenticado expôs DOM injetado por JS que um fetch estático da mesma página não vê.
• Nenhum acúmulo de processos Chrome foi observado em uma execução sequencial de 30 sessões; a contagem final foi de 0 processos Chrome e 0 zumbis.
• Um teste de TIMEOUT retornou 408 em 5,007 s contra um orçamento de 5,000 s; limpeza e liberação da vaga não foram verificadas separadamente.
• Autenticação ligada por padrão: todos os quatro endpoints REST retornam 401 sem token.
• Um docker run para um serviço pronto em cerca de 0,78 s, e um primeiro render 0,32 s depois disso.

Contras

• Imagem de 4,34 GB. Esse é o custo honesto principal, e ele aparece no seu registry, no cache do CI e no tempo de deploy frio.
• SSPL-1.0 ou licença comercial da Browserless. Avalie os termos atuais exatos contra o seu modelo de implantação e distribuição.
• PREBOOT da v1 é aceito e ignorado silenciosamente na v2 — sem erro, sem aviso, sem chave em /config.
• Você está operando um serviço, não adicionando uma dependência: um contêiner, um token, um caminho de rede, um teto de admissão e responsabilidade por upgrades.
• Requisições enfileiradas elevaram a latência ponta a ponta para cerca de duas durações de sessão na execução (2, 2); o tempo de fila separado não foi medido.
• O timing REST medido inclui uma ida HTTP e não isola o custo de iniciar o navegador nem prova reaproveitamento de navegador.

Quem deve usar e quem não deve

O Browserless faz sentido quando mais de uma coisa precisa de navegador. Um serviço de renderização compartilhado entre vários apps, um time que quer screenshots e PDFs atrás de um endpoint HTTP em vez de uma dependência do Chrome em cada serviço, um pipeline de jobs que realmente precisa de um teto de capacidade com backpressure mensurável — esse é o formato que ele atende. Se você já roda Docker e alguém é responsável pelo deploy, a história operacional é clara: admissão previsível, backpressure observável e nenhum acúmulo de processos Chrome ou zumbis no teste sequencial de 30 sessões.

Também é a escolha certa se a alternativa for cada serviço da sua stack instalar seu próprio Chromium. Centralizar isso em um contêiner com token e teto é, de fato, uma boa troca arquitetural.

Evite se você está escrevendo um único script. Baixar 4,3 GB e subir um contêiner para que um arquivo Python só pegue uma página renderizada é muita cerimônia para um trabalho pequeno — uma biblioteca de navegador no seu processo faz isso sem serviço separado. Evite se os termos SSPL não funcionam para o seu produto comercial e você não consegue resolver isso. Evite se o que você realmente quer é um navegador que já venha pré-aquecido sem custo frio, porque PREBOOT não vai oferecer isso na v2. E evite se o seu problema real é tratamento anti-bot, porque isso vive em um endpoint que eu deliberadamente não testei e sobre o qual não vou me comprometer.

Alternativas, incluindo onde o Thunderbit entra

A comparação que vale fazer não é Browserless contra outro contêiner. É sobre onde o navegador vive e quem é responsável por mantê-lo funcionando.

Leitura relacionada: review do Browsertrix Crawler.

Leitura relacionada: review do chromedp.

Se você quer um navegador dentro do seu próprio processo e não se importa em escrever os waits, uma biblioteca é mais leve e não exige implantação. Escrevi sobre esse lado na comparação Playwright versus Puppeteer e no panorama mais amplo dos melhores projetos open source de scraping.

Se você não quer operar um navegador de jeito nenhum, nosso próprio Thunderbit é uma alternativa gerenciada. O Browserless devolve material renderizado que o seu código interpreta; o Thunderbit pode devolver Markdown ou dados compatíveis com schema enquanto o provedor cuida da infraestrutura de renderização. Este artigo não benchmarkou latência, capacidade, comportamento de falha, qualidade de extração nem custo do Thunderbit, então a tabela descreve fronteiras de responsabilidade, não uma comparação de desempenho.

Leitura relacionada da mesma rodada de testes: a review do Crawl4AI cobre um pipeline de Markdown com navegador que você mesmo opera, e o resumo de ferramentas de web scraping mapeia a categoria mais ampla.

Experimente o Thunderbit para Extração de Dados da Web

Veredito

Vale a pena rodar Browserless? Sim, se vários chamadores precisam de trabalho de navegador, alguém pode operar o contêiner e sua revisão de licença aprova o modelo de implantação. Em três execuções sintéticas de admissão, a contagem aceita bateu com CONCURRENT + QUEUED, o excesso recebeu 429 e /pressure coincidiu com as contagens visíveis no cliente. Em uma checagem sequencial separada de 30 sessões, nenhum processo Chrome nem zumbi se acumulou. Um teste de timeout retornou 408 próximo ao limite configurado. São observações úteis e limitadas, não garantias universais.

Ainda assim, dimensione o compromisso com honestidade. É uma imagem de 4,34 GB e um serviço que você opera, não uma dependência que você adiciona; este teste não estabeleceu comparação de velocidade com uma biblioteca de navegador em processo. O que ele compra é um navegador que você pode racionar: um teto conhecido e backpressure mensurável. Na checagem sequencial de 30 sessões, nenhum acúmulo de processos Chrome ou zumbis foi observado. Os custos são peso de implantação e uma licença que você precisa ler. Se você está renderizando meia dúzia de páginas a partir de um único script, essa troca não compensa. Se você está operando uma camada de renderização da qual vários serviços dependem, compensa — só confira suas variáveis de ambiente da v1 ao entrar, porque PREBOOT vai ficar ali parecendo estar empregado enquanto não faz absolutamente nada.

Experimente o Thunderbit para Extração de Dados da Web Get Started Free

Perguntas frequentes

O Browserless deixa o Chrome headless mais rápido? Este teste não consegue responder isso. O endpoint HTTP ficou responsivo 0,78 s depois de docker run; a primeira chamada /content levou então 0,32 s, e as chamadas seguintes no mesmo contêiner ficaram em cerca de 0,15 s. Esses números combinam ida e volta HTTP, trabalho do navegador, navegação e transferência da resposta. O harness não isolou o tempo de inicialização, não rastreou reaproveitamento de processos e não publicou um benchmark comparável em processo. Use o Browserless como uma fronteira de serviço compartilhado e controle de admissão, depois meça sua própria rota de latência.

O que acontece quando você excede o limite de concorrência do Browserless? Você recebe um HTTP 429 imediato. O teto é exatamente CONCURRENT + QUEUED, e eu confirmei isso em três configurações: (2,2) aceitou 4 e rejeitou 4, (3,5) aceitou 8 e rejeitou 4, (5,5) aceitou 10 e rejeitou 4. O endpoint /pressure do servidor mostrou contagens correspondentes de running, queued e recentlyRejected em todas as vezes. Importante: requisições na fila não falham, elas esperam — em (2,2) com trabalho de 5 segundos, as respostas bem-sucedidas levaram entre 5,7 s e 11,0 s. Faça o cliente tratar 429 como backpressure com retry e backoff.

O PREBOOT ainda funciona na v2 do Browserless? Não. PREBOOT foi removido na 2.0.0, e a v2 aceita -e PREBOOT=true sem erro nem aviso, mas não faz nada com isso. Confirmei a inércia de três formas: a latência foi indistinguível do padrão, um contêiner PREBOOT=true ocioso tinha 0 processos do chrome esperando, e /config não expõe nenhuma chave preboot. Se você migrou uma configuração da v1, suas instâncias não estão pré-aquecidas. Observe que KEEP_ALIVE, removido na mesma release, realmente registra um aviso de “deprecated and ignored” — então o problema de falha silenciosa é específico de PREBOOT.

O Browserless é gratuito para uso comercial? O repositório oferece SSPL-1.0 ou uma licença comercial da Browserless, mas este artigo não mapeia cenários comerciais específicos ou fechados para uma dessas opções. Revise o LICENSE atual e as orientações oficiais de implantação, depois peça à pessoa responsável por licenciamento de software para avaliar seu modelo de implantação e distribuição.

O Browserless deixa processos zumbis do Chrome para trás? Nenhum se acumulou na janela curta testada. Após 30 sessões sequenciais, o contêiner tinha 0 processos Chrome e 0 zumbis, com apenas dumb-init, node, Xvfb, start.sh e sh permanecendo. O detector contou 11 processos da família Chrome enquanto uma sessão estava ativa, então ele não estava cego. A memória do contêiner foi de 294 MiB para 303 MiB e então estabilizou nas amostras. Isso não é um resultado de endurance de várias horas, nem de concorrência, nem de milhares de sessões.