Como ver o consumo de banda do Chrome por aba no macOS

Você tem 40 abas do Chrome abertas, suas ventoinhas estão girando, e você está com 600 MB consumidos na hora sem culpado óbvio. O Activity Monitor mostra uma linha chamada "Google Chrome Helper (Renderer)" trinta e oito vezes. Nenhuma te diz qual aba é qual. Para ver banda do Chrome por aba no macOS, você precisa saber como o Chrome mapeia abas em processos e como ler os dados pelas próprias ferramentas do Chrome, mais um monitor por app que não se afoga em linhas de helper.

Aqui o setup prático, do modelo de processo aos passos acionáveis.

Modelo de processo do Chrome no macOS

Chrome é multi-processo por design. Cada aba — geralmente — roda no seu próprio processo renderer. Tem também:

• Processo browser — o processo principal do Chrome, UI, coordenação.
• Processo GPU — Google Chrome Helper (GPU), composição.
• Processos renderer — Google Chrome Helper (Renderer), um por grupo de frame de site, limitado pelo limite de processo do Chrome.
• Processos plugin / utility — para coisas como network service, storage, áudio.
• Processos de extensão — a maior parte das extensões ganha processo próprio classe-renderer.

Então uma sessão típica de Chrome tem 1 browser + 1 GPU + 10–40 renderers + um punhado de processos utility. No macOS, todos aparecem no Activity Monitor como linhas separadas com nomes quase idênticos.

Por isso "Banda do Chrome por aba no Mac" é pergunta mais difícil que "Banda total do Chrome". O SO vê PIDs. Você quer abas.

Como banda do Chrome por aba no Mac mapeia em processos

Chrome usa um modelo de site isolation. Duas abas do mesmo site (mesmo eTLD+1, por exemplo *.youtube.com) frequentemente compartilham um processo. Abas de sites diferentes ganham processos diferentes. iframes cross-site também podem gerar seus próprios processos.

Implicações práticas:

• Cinco abas de youtube.com podem ficar em um ou dois renderers.
• Cinco abas em youtube.com, github.com, twitter.com, news.ycombinator.com, nytimes.com vão ser cinco renderers diferentes.
• Um iframe de anúncio dentro de uma aba pode ter o próprio processo. A banda daquele iframe é atribuída a um processo que a aba visível ao usuário não parece "possuir".

Ferramenta 1: Chrome Task Manager (no Mac está no menu)

Chrome tem um task manager built-in. No macOS, não está amarrado a Shift-Esc por padrão — abra Janela → Task Manager na barra de menu do Chrome. (Ou use Visualizar → Desenvolvedor → Task Manager dependendo da versão do Chrome.)

O Task Manager mostra uma linha por processo do Chrome, incluindo:

• Nome da task (frequentemente o título da aba, ou o nome da extensão)
• Pegada de memória
• CPU
• Rede (taxa atual) — clique direito no header da coluna e habilite "Network" se não estiver visível.

Essa é a coisa mais próxima de "banda por aba no Chrome no Mac" nativa. Ordene por Network e você verá qual aba está atualmente transferindo mais dados.

Limites:

• Mostra taxa ao vivo, não uso cumulativo. Se uma aba carregou em rajada 200 MB uma hora atrás, o Task Manager não vai mostrar — só o que está fluindo agora.
• Um site compartilhado entre abas aparece uma vez, não por aba.
• iframes cross-site são listados como sua própria task com nomes crípticos.

Mesmo com os limites, Task Manager é o ponto de partida certo.

Ferramenta 2: um monitor por app que agrupa helpers

Chrome Task Manager te mostra abas neste momento. Você também quer uma visão longitudinal — o que o Chrome fez na última hora, dia ou semana — sem quarenta linhas de Google Chrome Helper (Renderer) poluindo a foto.

ova fica na sua barra de menu, amostra taxas por app a cerca de 1 Hz e agrupa cada PID auxiliar do Chrome sob uma única linha "Google Chrome". Você vê a taxa combinada, uma linha do tempo recente e os totais que precisa para "quanto usei hoje".

As duas ferramentas se complementam:

• Chrome Task Manager: qual aba está pesada agora.
• Monitor da barra de menu com agrupamento: quanto Chrome usou no total, quando os picos aconteceram, e como compara entre dias.

Um workflow de 5 minutos para achar vazamento de aba

Quando o Chrome parece pesado, esse é o loop:

1. Abra o ova na barra de menu. Anote a taxa atual do Chrome. Se está 0–50 KB/s, sem vazamento — vá olhar em outro lugar.
2. Se o Chrome está sustentado acima de 1 MB/s enquanto você não está navegando ativamente, abra o Task Manager do Chrome.
3. Ordene por Network decrescente. A linha do topo é seu culpado. Frequentemente é uma aba de vídeo pausada incorretamente, um websocket long-poll ou uma extensão descontrolada.
4. Anote o nome da task. Se é uma extensão, decida se você precisa. Se é uma aba, feche ou pause o que estava fazendo.
5. Observe o ova por 30 segundos depois. A taxa do Chrome deve cair. Se não cair, o vazamento está em outro lugar.

Esse é um diagnóstico de 60 segundos quando você tem o workflow.

Adicione um monitor quieto do Chrome à barra de menu

ova mostra uma única linha do Chrome com helpers combinados e linha do tempo navegável — local, assinado, ~3 MB.

Baixar para macOS

Surpresas comuns de banda do Chrome

Algumas coisas que pegam pessoas desprevenidas:

Pré-carregamento do YouTube

YouTube pré-carrega os próximos vários segundos de vídeo constantemente enquanto você assiste. Uma aba pausada continua pingando. Autoplay em segundo plano (quando você troca de aba) frequentemente continua carregando. Se tem múltiplas abas YouTube, mesmo pausadas podem comer banda.

Service Workers

Web apps modernos instalam service workers que rodam em segundo plano mesmo quando a aba não está focada. Gmail, Twitter, Slack web, Notion todos fazem isso. Buscam atualizações periodicamente. Fechar a aba normalmente para; às vezes o worker persiste até o navegador reiniciar.

Conexões long-poll

Alguns web apps mantêm uma conexão HTTP aberta como websocket de pobre. O tráfego parece pequeno mas constante. Em muitas abas soma.

Extensões

Uma extensão ruim pode fazer polling de uma API a cada segundo para sempre. Desabilite extensões uma de cada vez e observe seu monitor — a barulhenta vai se revelar.

Sync

Chrome Sync faz upload de bookmarks, histórico, senhas e abas abertas para sua conta Google. Normalmente minúsculo. Depois de uma importação grande de bookmarks, pode ser mensurável.

Lendo os dados: qual é uma taxa normal do Chrome?

Algumas linhas de base:

• Ocioso, 5–10 abas: 5–30 KB/s combinado.
• Navegação ativa, sem vídeo: picos durante carregamentos de página, idle no meio.
• Uma aba YouTube tocando 1080p: 600 KB/s – 1,5 MB/s sustentados.
• Duas abas YouTube: aproximadamente o dobro.
• Sync do Google Drive de uma pasta: pode saturar o uplink.
• Web app com polling ruim: 50–200 KB/s sustentado mesmo idle.

Se sua linha do Chrome no ova está acima de ~100 KB/s enquanto você não faz nada, algo está errado. Abra o Task Manager e ache.

Site isolation e iframes cross-site

Uma ruga ao rastrear banda: uma aba em que você está pode não ser a que está movendo os bytes. iframes de anúncio, players YouTube embutidos, widgets de comentários Disqus — cada um pode ser seu próprio processo sob site isolation.

No Task Manager do Chrome, esses aparecem com nomes como Subframe: https://example-cdn.com. Às vezes você verá um subframe consumindo mais que a aba pai. Isso é um pixel de tracking ou SDK de analytics agindo, e é uma dica para considerar um ad-blocker.

Economizando banda do Chrome sem desabilitar features

Algumas configurações do Chrome que movem a agulha:

1. Memory Saver (antes Tab Discarding)

Configurações → Performance → Memory Saver. Descarta abas inativas. Quando você volta, a aba recarrega, o que usa banda — mas em troca, a aba usa zero em segundo plano. Vitória líquida para a maior parte das cargas.

2. Preload pages: desligado

Configurações → Performance → Preload pages → No preloading. Por padrão Chrome pré-carrega páginas que prediz que você vai visitar. Desligar isso para downloads especulativos.

3. Aceleração de hardware

Não afeta banda diretamente mas reduz CPU durante reprodução de vídeo, o que deixa a pilha de rede trabalhar menos.

4. Bloqueie cookies de terceiros

Configurações → Privacidade e segurança → Cookies de terceiros → Bloquear. Reduz parte do tráfego de tracker. Alguns sites quebram — cheque caso a caso.

5. uBlock Origin ou similar

Um bloqueador real de ad/tracker é o maior poupador de banda para navegação típica. Páginas que carregavam 4 MB caem para 800 KB. O efeito no seu monitor é dramático se você nunca usou um.

Quando o Activity Monitor discorda do Chrome Task Manager

Você verá isso frequentemente:

• Activity Monitor mostra Google Chrome Helper (Renderer) em 50 MB recebidos no total.
• Chrome Task Manager mostra o mesmo renderer em "0 KB/s" agora.

Ambos estão certos. Activity Monitor é cumulativo desde o início do processo; Task Manager é taxa atual. Para conseguir cumulativo-por-aba, você precisa de uma ferramenta que agrega no tempo e mapeia PIDs em títulos de forma consistente — o que é difícil porque Chrome reusa processos para abas novas conforme antigas fecham.

Um compromisso prático: use ova para o total cumulativo do Chrome, use Task Manager para a taxa por aba ao vivo e aceite que cumulativo exato por aba é genuinamente difícil de medir no Chrome.

Encerrando

Banda do Chrome por aba que usuários de Mac querem ver se divide em duas perguntas: o que está pesado agora (use Task Manager do Chrome) e o que o Chrome usou na última hora (use um monitor por app com agrupamento de helpers). O SO te dá por processo, Chrome te dá por task, e a combinação te diz o que você precisa.

Abra o ova, abra o Task Manager do Chrome ao lado e passe cinco minutos observando ambos enquanto navega. Você vai flagrar pelo menos uma aba ou extensão que não percebia que estava te custando — a maioria das pessoas flagra.