Chrome DevTools Protocol: o motor invisível por trás de toda automação de browser

TL;DR

O Chrome DevTools Protocol (CDP) é o protocolo de comunicação que permite a qualquer programa controlar um browser Chrome remotamente via WebSocket. Puppeteer, Playwright, Selenium 4 e Lightpanda são todos abstrações construídas em cima do CDP. Quem entende o protocolo diretamente ganha acesso a capacidades que as abstrações escondem — interceptação de requests, modificação de responses, monitoramento de performance em tempo real, extração de APIs ocultas. Para solopreneurs, isso significa uma classe de produtos de automação que poucos sabem construir.

Toda ferramenta de automação de browser que você conhece tem um segredo em comum.

Puppeteer fala com o Chrome. Playwright fala com o Chrome. Lightpanda implementa compatibilidade com Chrome. Selenium 4, chromedp, Pyppeteer — todos falam com o Chrome.

E quando falam com o Chrome, todos usam o mesmo canal: o Chrome DevTools Protocol.

O CDP é o protocolo de baixo nível que permite a qualquer programa enviar comandos para um browser e receber eventos dele. É uma interface WebSocket com centenas de APIs organizadas por domínios funcionais. É o que torna possível, via código, dizer ao Chrome: “abra esta URL”, “intercepte este request”, “execute este JavaScript”, “tire um screenshot desta região”.

Puppeteer e Playwright existem porque o CDP é poderoso mas verboso. Eles são APIs de alto nível construídas sobre o protocolo. Mas ao usar essas abstrações, você troca poder por conveniência.

Quem usa Puppeteer controla um browser. Quem entende CDP controla o protocolo. A diferença é o que você pode construir com isso.

Este guia mostra o que você perde nessa troca — e como recuperar esse poder.

O que é o Chrome DevTools Protocol

O Chrome DevTools Protocol é a API oficial do Chrome para inspeção e controle remoto do browser.

Ele não surgiu como ferramenta de automação. Surgiu como ferramenta de debug.

A origem: ferramenta de debug que virou protocolo de automação

O CDP foi criado para que as ferramentas de desenvolvedor do Chrome (DevTools — o painel que você abre com F12) pudessem se comunicar com o processo do browser. Quando você abre o DevTools e inspeciona um elemento, está consumindo o CDP. Quando você monitora requests na aba Network, está consumindo o CDP. Quando você profileia performance na aba Performance, está consumindo o CDP.

Em algum momento, a equipe do Chrome percebeu que se o DevTools conseguia fazer isso via protocolo, qualquer programa poderia fazer o mesmo.

O CDP foi aberto para uso externo. E o ecossistema de automação de browser como conhecemos hoje nasceu.

Como o Chrome expõe o CDP

Quando você inicia o Chrome com a flag --remote-debugging-port=9222, ele começa a aceitar conexões WebSocket nessa porta.

google-chrome --headless --remote-debugging-port=9222 --no-sandbox

A partir desse momento, qualquer cliente WebSocket pode se conectar a ws://localhost:9222 e começar a enviar comandos JSON para o browser.

É simples assim. O CDP é uma API WebSocket com mensagens JSON. Sem binários. Sem formatos proprietários. Tudo que você precisa é de uma conexão WebSocket e saber quais mensagens enviar.

Como o CDP funciona por dentro

WebSocket como canal de comunicação

O CDP usa WebSocket porque é bidirecional. O cliente (seu programa) envia comandos ao browser. O browser executa e responde. Mas o browser também pode enviar eventos espontaneamente — quando uma aba navega, quando um request começa, quando um elemento muda no DOM.

Essa bidirecionalidade é fundamental. Não é um modelo request/response simples. É um canal de comunicação contínuo onde ambos os lados podem iniciar mensagens.

Domínios do CDP: cada domínio controla uma área

O CDP está organizado em domínios. Cada domínio controla uma área funcional específica do browser:

Isso não é uma lista parcial — são mais de 40 domínios. Cada um com dezenas de comandos e eventos.

Quando você usa page.goto(url) no Puppeteer, por baixo está sendo enviado um comando Page.navigate via CDP. Quando você usa page.screenshot(), é Page.captureScreenshot. Quando você faz page.evaluate(fn), é Runtime.evaluate.

Estrutura de comandos e eventos

Cada mensagem CDP é um objeto JSON com estrutura simples.

Comando (cliente → browser):

{
  "id": 1,
  "method": "Page.navigate",
  "params": {
    "url": "https://exemplo.com"
  }
}

Resposta (browser → cliente):

{
  "id": 1,
  "result": {
    "frameId": "ABCD1234",
    "loaderId": "EFGH5678"
  }
}

Evento (browser → cliente, sem solicitação):

{
  "method": "Network.requestWillBeSent",
  "params": {
    "requestId": "12345",
    "request": {
      "url": "https://api.exemplo.com/dados",
      "method": "GET"
    }
  }
}

O campo id correlaciona comandos com respostas. Eventos não têm id — eles chegam quando o browser decide emitir.

Um request CDP na prática

Para entender o CDP concretamente, veja o que acontece quando você navega até uma URL usando CDP puro (sem Puppeteer):

1. Cliente envia: Network.enable  → ativa captura de eventos de rede
2. Cliente envia: Page.navigate   → navega para a URL
3. Browser emite: Network.requestWillBeSent (para cada request iniciado)
4. Browser emite: Network.responseReceived (para cada response recebida)
5. Browser emite: Page.loadEventFired (quando a página carregou)
6. Cliente envia: Runtime.evaluate  → executa JavaScript na página
7. Browser responde: resultado do JavaScript

Tudo isso são mensagens JSON via WebSocket. Tudo que Puppeteer faz é traduzir métodos JavaScript amigáveis para esse fluxo de mensagens.

CDP vs Puppeteer vs Playwright: entendendo as camadas

Quando você escreve código de automação, está operando em uma de três camadas:

Puppeteer e Playwright são bibliotecas excelentes. Elas resolvem 95% dos casos de uso. Mas elas tomam decisões por você — e às vezes essas decisões te limitam.

O que Puppeteer esconde de você

1. Acesso a eventos de rede brutos

Puppeteer permite interceptar requests via page.on('request'), mas com limitações. O CDP permite acesso total ao domínio Network e Fetch, incluindo modificação de headers, substituição completa de responses, e captura de corpos de responses que Puppeteer nem expõe por padrão.

2. Sessões CDP paralelas

O CDP suporta múltiplas sessões independentes na mesma aba (via Target.attachToTarget). Puppeteer não expõe isso diretamente. Isso é útil para cenários de debugging avançado e monitoramento paralelo.

3. Acesso ao domínio Performance

O CDP tem um domínio Performance completo com métricas como ScriptDuration, LayoutDuration, TaskDuration. Puppeteer expõe apenas page.metrics() — uma versão limitada.

4. Controle de cache e storage

Via CDP você pode limpar selectivamente cache, IndexedDB, localStorage por origin. Útil para testes de estado limpo sem reiniciar o browser inteiro.

5. Streaming de screenshots

O CDP suporta Page.startScreencast — streaming contínuo de frames do browser como imagens. Perfeito para gravar sessões ou criar previews ao vivo. Puppeteer não expõe isso.

Quando usar CDP direto faz sentido

Use CDP direto quando:

• Precisar de funcionalidades que Puppeteer/Playwright não expõem
• Estiver construindo sua própria biblioteca de automação
• Precisar de controle granular sobre o protocolo (ex: sessões paralelas)
• Estiver otimizando performance e cada mensagem importa
• Estiver implementando compatibilidade CDP em outro browser (como faz o Lightpanda)

Use Puppeteer/Playwright quando:

• Precisar de automação padrão (navegação, formulários, screenshots)
• Quiser cross-browser (Playwright suporta Firefox e WebKit)
• Tiver prazos e precisar de produtividade

O mais comum na prática: usar Puppeteer como base mas acessar CDP diretamente para funcionalidades específicas.

Usando CDP diretamente: primeiros passos

Conectando ao Chrome via WebSocket

Com o Chrome rodando em modo debug:

# Inicia Chrome headless com debugging habilitado
google-chrome \
  --headless \
  --remote-debugging-port=9222 \
  --no-sandbox \
  --disable-gpu

Agora você pode consultar as abas disponíveis:

curl http://localhost:9222/json

Resposta:

[{
  "id": "ABCD1234",
  "type": "page",
  "url": "about:blank",
  "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/ABCD1234"
}]

O campo webSocketDebuggerUrl é o endpoint que você usa para controlar essa aba.

Exemplo 1: CDP puro com Node.js

Sem nenhuma biblioteca de automação. Apenas WebSocket:

const WebSocket = require('ws');
const http = require('http');

async function getCDPUrl() {
  return new Promise((resolve) => {
    http.get('http://localhost:9222/json', (res) => {
      let data = '';
      res.on('data', chunk => data += chunk);
      res.on('end', () => {
        const tabs = JSON.parse(data);
        resolve(tabs[0].webSocketDebuggerUrl);
      });
    });
  });
}

async function main() {
  const wsUrl = await getCDPUrl();
  const ws = new WebSocket(wsUrl);
  let messageId = 0;

  const send = (method, params = {}) => {
    const id = ++messageId;
    ws.send(JSON.stringify({ id, method, params }));
    return id;
  };

  ws.on('open', () => {
    // Habilita eventos de rede
    send('Network.enable');

    // Navega para uma URL
    send('Page.navigate', { url: 'https://exemplo.com' });
  });

  ws.on('message', (data) => {
    const msg = JSON.parse(data);
    console.log(JSON.stringify(msg, null, 2));
  });
}

main();

Você verá no console todos os eventos — requests de rede, navegação, carregamento da página — em tempo real. Isso é o CDP em sua forma mais pura.

Exemplo 2: Acessando CDP via Puppeteer (o melhor dos dois mundos)

Na prática, o fluxo mais útil é usar Puppeteer para o trabalho pesado e acessar o CDP diretamente quando precisar de algo específico.

Puppeteer expõe o objeto CDPSession para isso:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();

  // Cria uma sessão CDP direta para esta aba
  const client = await page.createCDPSession();

  // Habilita captura de eventos de rede via CDP
  await client.send('Network.enable');

  // Evento CDP direto: captura TODOS os requests
  client.on('Network.requestWillBeSent', (event) => {
    console.log(`[REQUEST] ${event.request.method} ${event.request.url}`);
  });

  // Evento CDP direto: captura TODAS as responses
  client.on('Network.responseReceived', (event) => {
    console.log(`[RESPONSE] ${event.response.status} ${event.response.url}`);
  });

  await page.goto('https://exemplo.com', { waitUntil: 'networkidle2' });

  await browser.close();
})();

O que você vê: todos os requests que a página faz — incluindo chamadas para APIs de terceiros, analytics, CDNs — com URLs, métodos, status codes. Informação que o DevTools do Chrome mostra na aba Network, agora acessível programaticamente.

Exemplo 3: Interceptando e modificando requests

O domínio Fetch do CDP permite interceptar requests antes de serem enviados e modificá-los — ou até substituir completamente a resposta:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();
  const client = await page.createCDPSession();

  // Ativa interceptação de requests via CDP Fetch domain
  await client.send('Fetch.enable', {
    patterns: [{ urlPattern: '*', requestStage: 'Request' }]
  });

  client.on('Fetch.requestPaused', async (event) => {
    const { requestId, request } = event;

    // Bloqueia requests para domínios de analytics
    if (request.url.includes('google-analytics') ||
        request.url.includes('googletagmanager')) {
      await client.send('Fetch.failRequest', {
        requestId,
        errorReason: 'BlockedByClient'
      });
      console.log(`[BLOQUEADO] ${request.url}`);
      return;
    }

    // Todos os outros requests continuam normalmente
    await client.send('Fetch.continueRequest', { requestId });
  });

  await page.goto('https://exemplo.com', { waitUntil: 'networkidle2' });

  console.log('Página carregada sem analytics');
  await browser.close();
})();

Caso de uso prático: scraping mais limpo, mais rápido (sem carregar scripts de terceiros), e sem disparar eventos de analytics que alertam o site sobre scrapers.

Exemplo 4: Extraindo dados de APIs ocultas via Network domain

Muitos sites modernos carregam dados via APIs XHR/Fetch que não aparecem no HTML. Para scrapers baseados em HTML, esses dados são invisíveis. Com CDP, você captura as respostas diretamente:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();
  const client = await page.createCDPSession();

  await client.send('Network.enable');

  const apiResponses = [];

  // Captura o corpo das respostas de API
  client.on('Network.responseReceived', async (event) => {
    const { requestId, response } = event;

    // Filtra apenas chamadas de API (JSON)
    if (response.mimeType === 'application/json') {
      try {
        // Obtém o corpo da resposta via CDP
        const result = await client.send('Network.getResponseBody', { requestId });
        const body = JSON.parse(result.body);
        apiResponses.push({
          url: response.url,
          data: body
        });
        console.log(`[API] ${response.url}`);
      } catch (e) {
        // Algumas responses expiram antes de capturar
      }
    }
  });

  await page.goto('https://exemplo.com', { waitUntil: 'networkidle2' });

  console.log(`\nAPIs capturadas: ${apiResponses.length}`);
  console.log(JSON.stringify(apiResponses, null, 2));

  await browser.close();
})();

Resultado: você captura os dados JSON que o site recebe das suas APIs internas — antes de qualquer processamento JavaScript. Para scraping de SPAs (React, Angular, Vue), isso é frequentemente mais limpo e estável do que tentar extrair dados do DOM renderizado.

Exemplo 5: Monitoramento de performance em tempo real

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();
  const client = await page.createCDPSession();

  // Ativa coleta de métricas de performance
  await client.send('Performance.enable');

  await page.goto('https://exemplo.com', { waitUntil: 'networkidle2' });

  // Coleta métricas CDP — mais completo que page.metrics()
  const { metrics } = await client.send('Performance.getMetrics');

  const metricMap = {};
  metrics.forEach(m => { metricMap[m.name] = m.value; });

  console.log('Métricas de Performance:');
  console.log(`  Script Duration:   ${metricMap.ScriptDuration?.toFixed(3)}s`);
  console.log(`  Layout Duration:   ${metricMap.LayoutDuration?.toFixed(3)}s`);
  console.log(`  Task Duration:     ${metricMap.TaskDuration?.toFixed(3)}s`);
  console.log(`  JS Heap Used:      ${(metricMap.JSHeapUsedSize / 1024 / 1024).toFixed(1)} MB`);
  console.log(`  DOM Nodes:         ${metricMap.Nodes}`);
  console.log(`  Documents:         ${metricMap.Documents}`);

  await browser.close();
})();

Caso de uso: auditar performance de sites de concorrentes, criar relatórios de performance como serviço, monitorar regressões em produção.

Automações avançadas que só o CDP permite

Capturar tráfego de rede de um site concorrente

Navegue até o site e capture todos os endpoints de API que ele usa. Descubra de quais CDNs ele depende, quais analytics usa, quais serviços de terceiros consome. Informação valiosa para análise competitiva.

client.on('Network.requestWillBeSent', ({ request }) => {
  // Filtra apenas domínios externos (não o próprio site)
  const url = new URL(request.url);
  if (!url.hostname.includes('exemplo.com')) {
    console.log(`[EXTERNO] ${url.hostname} — ${request.url.substring(0, 80)}`);
  }
});

Screenshot programático com controle total

// Screenshot de região específica da página
const screenshot = await client.send('Page.captureScreenshot', {
  format: 'png',
  clip: {
    x: 0,
    y: 0,
    width: 1280,
    height: 800,
    scale: 2 // retina quality
  }
});

const buffer = Buffer.from(screenshot.data, 'base64');
require('fs').writeFileSync('screenshot.png', buffer);

Emular dispositivos mobile e condições de rede

// Emula iPhone 14 Pro
await client.send('Emulation.setDeviceMetricsOverride', {
  width: 393,
  height: 852,
  deviceScaleFactor: 3,
  mobile: true,
  userAgent: 'Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X)...'
});

// Emula conexão 3G lenta
await client.send('Network.emulateNetworkConditions', {
  offline: false,
  downloadThroughput: 500 * 1024 / 8, // 500 Kbps
  uploadThroughput: 500 * 1024 / 8,
  latency: 400 // ms
});

Caso de uso: testar como o seu produto se comporta em condições reais de uso mobile no Brasil — onde conexões lentas são comuns.

Injetar código em qualquer página

// Executa antes de qualquer JavaScript da página
await client.send('Page.addScriptToEvaluateOnNewDocument', {
  source: `
    // Sobrescreve fetch para capturar todos os requests XHR
    const originalFetch = window.fetch;
    window.fetch = async function(...args) {
      console.log('[FETCH INTERCEPTADO]', args[0]);
      return originalFetch.apply(this, args);
    };
  `
});

Streaming de screenshots (screencast)

// Inicia gravação contínua da sessão
await client.send('Page.startScreencast', {
  format: 'jpeg',
  quality: 80,
  maxWidth: 1280,
  maxHeight: 720,
  everyNthFrame: 1
});

client.on('Page.screencastFrame', async ({ data, sessionId }) => {
  // Cada frame é um JPEG em base64
  // Você pode: salvar como vídeo, transmitir ao vivo, analisar com IA
  await client.send('Page.screencastFrameAck', { sessionId });
});

Caso de uso: gravar sessões de usuário para análise de UX, criar demos de produtos, implementar “browser ao vivo” em aplicações.

Oportunidades de produtos para solopreneurs

O CDP não é apenas técnica. É uma vantagem competitiva. Quem domina o protocolo pode construir produtos que a maioria dos developers não sabe criar.

1. Screenshot / PDF API como serviço

O produto: API que recebe uma URL e retorna um screenshot ou PDF da página renderizada.

Por que funciona: dezenas de saas usam isso — relatórios, thumbnails de links, previews de documentos. Mas a maioria é cara ($49+/mês para volumes pequenos).

Sua vantagem: você constrói com CDP + Lightpanda, operando com custo de infraestrutura 9x menor que competidores usando Chrome. Pode cobrar menos e ter margem maior.

Exemplo simples de API:

// Express + Puppeteer + CDP
app.get('/screenshot', async (req, res) => {
  const { url, width = 1280, height = 800 } = req.query;
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();
  const client = await page.createCDPSession();

  await page.setViewport({ width: +width, height: +height });
  await page.goto(url, { waitUntil: 'networkidle2' });

  const screenshot = await client.send('Page.captureScreenshot', {
    format: 'png'
  });

  await browser.close();
  res.set('Content-Type', 'image/png');
  res.send(Buffer.from(screenshot.data, 'base64'));
});

Monetização: $0.001 por screenshot. Com 1 milhão de screenshots/mês = $1.000/mês de receita.

2. Monitor de performance de sites

O produto: serviço que monitora performance de sites e envia alertas quando métricas degradam.

Por que existe demanda: Performance é diretamente ligada a conversão. Uma queda no LCP (Largest Contentful Paint) de 2s para 4s pode reduzir conversões em 25%. Empresas pagam para saber disso antes dos usuários.

CDP te dá: métricas via Performance.getMetrics e Page.getNavigationHistory, mais granulares que o que ferramentas externas conseguem via Lighthouse sozinho.

Monetização: $29-99/mês por site monitorado.

3. Extrator de dados de sites dinâmicos

O produto: serviço de scraping que lida com SPAs (React, Angular, Vue) — onde scrapers simples de HTML falham.

Por que é difícil para a concorrência: a maioria dos scrapers simples usa HTTP requests e parsing de HTML. Sites modernos carregam dados via JavaScript. Sem um browser real executando JavaScript, você não vê os dados.

Sua vantagem com CDP: captura direta de responses de APIs via Network.getResponseBody — antes de qualquer processamento JavaScript. Mais limpo, mais rápido e mais confiável que esperar o DOM renderizar.

Monetização: por request ou assinatura mensal. Ex: $49/mês para 10.000 páginas scrapeadas.

4. Audit de terceiros (vendor analysis)

O produto: análise automatizada de quais scripts de terceiros um site carrega, quanto cada um atrasa a performance, e qual risco de privacidade representa.

Por que tem valor: todo site carrega dezenas de scripts externos (analytics, chat, remarketing, A/B testing). Cada um é um ponto de falha, risco de privacidade e fonte de lentidão. Empresas precisam auditar isso.

CDP te dá: captura completa do tráfego de rede via Network.enable, tempo de carregamento de cada script, domínios externos acessados.

Monetização: relatório único ($99-299) ou monitoring contínuo ($49-99/mês).

5. Visual regression testing como serviço

O produto: comparação automática de screenshots entre versões do site para detectar regressões visuais não intencionais.

Por que é valioso: times de desenvolvimento precisam saber se um deploy quebrou a aparência de páginas críticas (homepage, checkout). Testar isso manualmente é inviável em escala.

CDP te dá: screenshots pixel-perfect com controle total sobre viewport, DPR, e condições de rede.

Monetização: integração com CI/CD, $29-99/mês por projeto.

Ferramentas reais construídas sobre CDP

Entender o ecossistema ajuda a identificar onde há espaço para novos produtos:

Cada uma dessas ferramentas é um produto construído sobre o protocolo. O CDP é a fundação, não o teto.

CDP e Lightpanda: o futuro da automação eficiente

Se você leu nosso artigo sobre Lightpanda, você sabe que ele oferece 9x menos consumo de memória que Chrome para automação headless.

A razão pela qual Lightpanda funciona com Puppeteer e Playwright é exatamente o CDP. Lightpanda implementa o Chrome DevTools Protocol como sua interface de comunicação. Isso significa que qualquer código que funciona com Chrome via CDP pode funcionar com Lightpanda — muitas vezes sem nenhuma modificação.

Do ponto de vista de protocolo, o browser é intercambiável. O que importa é quem fala o mesmo idioma: CDP.

Isso tem implicações práticas para quem está construindo produtos:

• Você pode prototipar com Chrome (mais estável, mais recursos)
• E escalar com Lightpanda (mais barato por conta de menor consumo de memória)
• Usando exatamente o mesmo código

Para um solopreneur com infraestrutura limitada, isso é uma vantagem significativa. A combinação de n8n para orquestração + CDP via Lightpanda para automação de browser cria uma stack de automação profissional a custo mínimo. Você também pode usar agentes de IA para controlar o navegador.

Conclusão

O Chrome DevTools Protocol é a infraestrutura invisível que move toda automação de browser moderna.

Puppeteer, Playwright, Lightpanda, Selenium 4 — todas essas ferramentas são abstrações construídas sobre um único protocolo WebSocket/JSON. Quando você entende o protocolo diretamente, você passa de usuário de ferramentas para construtor de ferramentas.

O que o CDP oferece que as abstrações escondem:

• Interceptação e modificação de qualquer request/response
• Captura de APIs ocultas de SPAs
• Métricas de performance granulares
• Streaming de screenshots
• Controle preciso sobre o processo do browser

Para solopreneurs, o CDP abre uma categoria de produtos de automação que poucos sabem construir: ferramentas de screenshot como serviço, monitors de performance, extractors de dados de SPAs, audits de terceiros.

A barreira de entrada é baixa. A maioria das pessoas para na abstração. Quem desce um nível encontra menos concorrência e mais oportunidade.

O protocolo existe há mais de uma década. A documentação é pública. As bibliotecas são gratuitas. A barreira de entrada é baixa para quem tem disposição técnica.

Mas o mercado de ferramentas baseadas em CDP ainda tem muito espaço. Isso é uma oportunidade.

Próximos passos:

• Para implementar automação em produção com browser eficiente: Lightpanda
• Para conectar agentes de IA ao navegador: Chrome DevTools MCP: como agentes de IA controlam o navegador
• Para orquestrar automações complexas: n8n para solopreneurs
• Para ganhar dinheiro com automações: Agentes Autônomos

Perguntas Frequentes (FAQ)

O CDP funciona apenas com Chrome? O CDP foi criado pelo Google para o Chrome/Chromium. Mas o Microsoft Edge também o suporta (é baseado em Chromium). Firefox tem seu próprio protocolo (Remote Debugging Protocol), e Playwright abstrai ambos. Lightpanda implementa o CDP para compatibilidade com ferramentas do ecossistema Chromium.

Preciso de código complexo para usar CDP direto? Não. O CDP é JSON via WebSocket — qualquer linguagem que suporte WebSocket pode usá-lo. Para Node.js, a biblioteca ws é suficiente. Para Python, websockets. Para Go, existe o pacote chromedp que oferece acesso CDP de alto nível.

CDP vs DevTools: são a mesma coisa? O DevTools (o painel F12 do Chrome) é uma aplicação que consome o CDP. O CDP é o protocolo. Quando você inspeciona um elemento no DevTools, o DevTools está enviando comandos CDP para o browser. Você pode fazer o mesmo via código.

Usar CDP diretamente é mais rápido que Puppeteer? Depende do caso. CDP direto elimina a camada de abstração, então em teoria tem menos overhead. Mas Puppeteer já é eficiente. A diferença de performance relevante não é entre CDP bruto e Puppeteer — é entre usar Chrome e usar um browser mais leve como Lightpanda.

Como eu sei quais comandos CDP existem? A documentação oficial do protocolo está em chromedevtools.github.io/devtools-protocol. Todos os domínios, comandos, eventos e parâmetros estão documentados. É longa, mas bem organizada.

CDP é estável o suficiente para produção? Sim. O CDP está em produção em ferramentas usadas por milhões de pessoas (Puppeteer, Playwright, Lighthouse). A camada estável do protocolo muda raramente. Existe uma distinção entre domínios estáveis e experimentais na documentação oficial.

Posso usar CDP com Python? Sim. A biblioteca pyppeteer é uma porta do Puppeteer para Python e usa CDP por baixo. Também existe playwright para Python, que é bem mantido. Para acesso CDP mais direto, websockets + a API do Chrome funciona.