Alexandre Caramaschi

doi:10.2139/ssrn.6460680

MCP com Chrome: Automação com IA · Capítulo 14 de 16 · 36 min

Medir carregamento sem mentir para o cliente

Número excelente em laboratório e site lento no celular do cliente têm duas causas: página aquecida em cache e dado de laboratório vendido como real.

Este capítulo faz parte do curso gratuito MCP com Chrome: Automação com IA.

Para executivos

O que é: medir o tempo de carregamento de forma honesta, separando a página que você já visitou (veloz porque está em cache) da experiência de quem chega pela primeira vez, e separando o teste de laboratório do dado de usuários reais. Por que importa: um número bonito, colhido do jeito errado, vira constrangimento no instante em que o cliente abre o site no próprio celular e ele continua lento. A sua decisão: exigir que todo número de performance chegue rotulado, dizendo se é laboratório ou campo e se foi medido a frio ou com cache quente. O que delegar: rodar as três medições e apontar qual fase concentra o tempo. O passo a passo para operar vem logo abaixo.

Glossário rápido

Laboratório e campo

Laboratório é uma corrida única com pista fechada: a sua máquina, uma limitação simulada, um resultado. Campo é a média de milhares de corridas reais, em aparelhos e redes que você não escolhe, agregada ao longo de semanas. O primeiro explica por que está lento; o segundo diz quantos usuários sentem isso.

Medição a frio e cache quente

Cache quente é reabrir uma página já visitada, com os arquivos guardados e a conexão pronta, o que sempre parece rápido. Medição a frio parte de um perfil limpo, como o visitante novo que decide ficar ou sair, e é o único número que serve para relatório.

Suponha que você pede ao agente (o assistente de IA que opera o navegador por você) para medir a página de uma clínica odontológica: o número volta excelente, você monta o slide e apresenta. O dono abre o site no celular dele, na frente de todo mundo, e diz que continua lento. A partir daí a reunião deixa a performance de lado e passa a tratar da sua credibilidade.

Quase sempre as duas causas são estas, e nenhuma delas aparece no relatório. A primeira: a medição pegou a página já aquecida, com tudo em cache. A segunda: o número de laboratório foi apresentado como se descrevesse a experiência dos usuários reais.

Regra de ouro

Dado de laboratório serve para diagnosticar a causa. Dado de campo serve para afirmar como está a experiência. Os dois são úteis, e misturá-los num único número é o que quebra a conversa com o cliente.

O mecanismo da primeira causa é banal e por isso passa despercebido. Se você já visitou a página nesta mesma aba, os arquivos estáticos estão no cache do disco, a conexão com o servidor já foi negociada, o DNS já foi resolvido e o JavaScript já foi compilado uma vez.

A segunda visita não repete nenhum desses custos. Ela mede um cenário que o visitante novo, aquele que decide se fica ou sai, nunca vive.

Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.

A ordem das chamadas decide o que entra na gravação. Quando o trace começa antes da navegação, a região sombreada some do arquivo e o carregamento inicial simplesmente não foi medido.

Daí vem a regra de ordem que a documentação do servidor MCP do Chrome deixa explícita: com reload ou autoStop ativos, navegue até a URL antes de iniciar a gravação. Quem inverte grava um trace que começa com a página já carregada, olha o resultado e conclui que não existe problema de carregamento. O problema existe, ele apenas ficou fora do arquivo.

jsonc

// Configuração do servidor MCP oficial do time do Chrome.
// Vai no arquivo de configuração de servidores MCP do seu cliente.
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        // Perfil temporario, criado agora e descartado ao fechar o navegador.
        // Medicao comeca sempre de um estado limpo, sem cache herdado.
        "--isolated"
      ]
    }
  }
}

Não meça performance apontando o servidor para o seu Chrome pessoal com a flag de conexão a um navegador já em execução. Além de entregar ao agente todas as suas sessões autenticadas, o perfil de uso diário chega cheio de extensões, cookies e cache, e cada uma dessas coisas contamina a medida. Perfil isolado é a condição mínima para o número significar alguma coisa.

FluxoFazer as três medições na ordem certa

1. AQUECIDA        navegar -> navegar de novo -> gravar sem emulação
                   resultado bonito, imprestável para relatório

2. A FRIO          perfil isolado -> emular rede lenta e CPU 4x
                   -> navegar -> gravar com reload
                   este é o número que descreve o visitante novo

3. A FRIO + FIX    aplicar UMA correção vinda do insight
                   -> repetir exatamente a medição 2
                   só muda uma variável, então a diferença tem causa

jsonc

// Sequencia de chamadas da medicao 2 (a frio, aparelho modesto).
// Cada linha e uma chamada de ferramenta do servidor chrome-devtools.

// 1. Emule o aparelho ANTES de navegar, para que a propria navegacao
//    ja aconteca sob a condicao que voce quer medir.
emulate {
  "networkConditions": "Slow 3G",
  "cpuThrottlingRate": 4,
  "viewport": "412x915x2.6"
}

// 2. Va ate a URL. Este passo e o que a documentacao exige antes
//    de gravar quando reload ou autoStop estao ativos.
navigate_page { "url": "https://exemplo.com.br/lp" }

// 3. Grave. reload:true recarrega a pagina dentro da gravacao,
//    entao o carregamento inteiro entra no trace.
performance_start_trace { "reload": true, "autoStop": true }

// 4. Com autoStop:true a gravacao encerra sozinha quando a pagina
//    estabiliza. Se voce usar autoStop:false, encerre a mao:
// performance_stop_trace {}

PromptPedido ao agente para a medição a frio

Meça o carregamento de https://exemplo.com.br/lp simulando um aparelho modesto.

Ordem obrigatória, não inverta:
1. Chame emulate com networkConditions Slow 3G, cpuThrottlingRate 4 e viewport de celular.
2. Só depois chame navigate_page para a URL.
3. Só então inicie o trace com reload true e autoStop true.

Quando o trace terminar, liste os insights disponíveis e analise o LCPBreakdown.
Me diga qual fase da decomposição domina o tempo, em milissegundos e em porcentagem do total.

Não proponha correção ainda. Nesta primeira rodada eu quero apenas o diagnóstico.
Se alguma chamada falhar, me diga qual e pare, não tente contornar mudando a ordem.

Repare no motivo de emular antes de navegar. A emulação vale para a aba, não para a requisição que já saiu. Se você navega primeiro e desacelera depois, o documento inicial chegou em banda cheia e só os recursos seguintes sofreram a limitação.

A combinação de desaceleração de processador em 4 vezes com um perfil de rede lenta é a receita padrão para representar em laboratório um aparelho modesto. Os valores aceitos pela ferramenta de emulação são explícitos: Offline, Slow 3G, Fast 3G, Slow 4G e Fast 4G para rede, além de cpuThrottlingRate, viewport, userAgent, colorScheme, geolocation e cabeçalhos HTTP extras. Escolha e registre no relatório quais valores você usou, porque sem eles o número não é reproduzível.

Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.

A decomposição do maior elemento de conteúdo separa o tempo total em fases. A fase dominante é o que transforma um número solto em recomendação acionável.

Um trace sem leitura de insight é só um arquivo grande. O servidor expõe performance_analyze_insight, que recebe o nome do insight e o identificador do conjunto devolvido pela gravação, e LCPBreakdown é justamente o que decompõe o tempo até o maior elemento aparecer.

jsonc

// O insightSetId vem no resultado da propria gravacao.
// Nao invente o valor: copie o que o trace devolveu.
performance_analyze_insight {
  "insightName": "LCPBreakdown",
  "insightSetId": "<id devolvido por performance_start_trace>"
}

MockupLer o insight da medição a frio

LCPBreakdown
Elemento: <img class="hero" src="/hero.webp">

Tempo até o primeiro byte ......  620 ms   14%
Atraso até começar a baixar .... 2380 ms   54%   <-- domina
Download do recurso ............  980 ms   22%
Atraso até pintar o elemento ...  420 ms   10%
                                 -------
Total                            4400 ms

Números ilustrativos, apenas para treinar a leitura.

Na prática

Cada fase aponta para um tipo de correção diferente, e é isso que separa diagnóstico de palpite. Primeiro byte alto olha para servidor e cache de resposta. Atraso até começar a baixar olha para descoberta do recurso: a imagem só foi pedida depois que o navegador processou folha de estilo ou script. Download longo olha para peso, formato e compressão. Atraso até pintar olha para trabalho na linha principal segurando a pintura.

Depois de aplicar a correção, repita a medição exatamente com os mesmos valores de emulação e o mesmo perfil isolado. Mudar a receita entre a medição antes e a medição depois produz uma comparação que não prova nada, e costuma produzir melhora aparente onde não houve melhora nenhuma.

Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.

Laboratório é uma execução com limitação simulada. Campo é a distribuição de muitas visitas reais, em aparelhos e redes que você não escolhe, agregada ao longo de semanas.

Falta a parte que salva a reunião: a rotulagem. Auditoria de laboratório roda uma vez, com limitação simulada, na sua máquina. O indicador de experiência que o cliente vê em painéis oficiais vem de campo, agregado numa janela de semanas, com visitas reais.

São duas perguntas diferentes. Laboratório responde por que está lento. Campo responde quantos usuários sentem isso.

Guia prático: Core Web Vitals das páginas de uma campanha

Um detalhe da ferramenta muda a receita: no chrome-devtools-mcp, lighthouse_audit não mede performance. Ela devolve acessibilidade, SEO, boas práticas e navegação agêntica; para tempo de carregamento, LCP, INP e CLS, a ferramenta certa é performance_start_trace. Quem pede "rode o Lighthouse e me dê a nota de performance" recebe outra coisa e às vezes nem percebe.

Medição a frio das landings de uma campanha, com rótulo de laboratório e campo

Seis passos por página. Para uma campanha com três landings, reserve meia hora.

Passo 1: Liste as páginas de entrada reais da campanha, uma por grupo de anúncios, sem as UTMs
Mede-se a página, não a URL do clique. Parâmetros de campanha só criam variações do mesmo endereço.
Deu certo quando: Uma lista curta de URLs, cada uma com o grupo de anúncios que a usa.
Erro comum: Medir só a home do site enquanto a verba vai para outras páginas.
Passo 2: Decida o envio de URL ao CrUX: em página ainda não publicada, suba o servidor com --no-performance-crux
As ferramentas de performance podem mandar a URL do trace para a API do CrUX, para trazer dado de campo ao lado do laboratório. Página secreta de pré-lançamento não deve sair da máquina.
Deu certo quando: Landing de lançamento medida sem consulta ao CrUX; landing pública medida com dado de campo.
Erro comum: Medir a página de uma campanha ainda sob sigilo com a consulta de campo ligada.
Passo 3: Emule o aparelho antes de navegar: emulate com rede Slow 4G ou Fast 3G, CPU 4x e viewport de celular
A maior parte do tráfego de mídia paga chega pelo celular. Fixe a receita no relatório para a medição de depois repetir a de antes.
Deu certo quando: A receita de emulação aparece escrita no topo da tabela.
Erro comum: Trocar a receita entre a medição antes e a medição depois da correção.
Passo 4: Navegue até a página e grave com performance_start_trace, reload e autoStop ligados
Depois, peça performance_analyze_insight com LCPBreakdown para saber qual fase domina o tempo até o maior elemento.
Deu certo quando: Um trace com LCP, CLS e a decomposição do LCP em quatro fases.
Erro comum: Iniciar o trace antes de navegar: a página já carregada esconde o problema.
Passo 5: No painel Performance do DevTools, compare o número local com o dado de campo
A visão de métricas mostra o valor local ao lado do percentil 75 de campo, quando a página tem tráfego suficiente no CrUX. Em aplicação de página única, a medição de navegação suave já aparece completa nos insights.
Deu certo quando: A tabela final tem duas colunas separadas: laboratório (sua máquina) e campo (usuários reais, 28 dias).
Erro comum: Somar ou tirar média entre laboratório e campo para apresentar um número só.
Passo 6: Rode três vezes a frio e apresente a mediana por página
Uma execução única oscila. Se as três variam mais que a melhora que você quer mostrar, o resultado ainda é ruído.
Deu certo quando: Uma linha por landing, com mediana, receita e rótulo.
Erro comum: Apresentar o melhor dos três.

No fim você tem: Uma tabela de landings da campanha com LCP e CLS de laboratório e campo separados, a fase que domina o LCP e a receita de medição escrita.

Painel Performance do Chrome DevTools com a seção Local and field metrics marcada como SOFT NAV: o cartão de LCP mostra o valor local ao lado do percentil 75 de campo, e o cartão de CLS faz o mesmo, cada um com uma frase comparando a medição local com a experiência dos usuários. — Valor local e percentil 75 de campo lado a lado, também em navegação suave. Fonte: Chrome for Developers, What's new in DevTools (Chrome 152), agosto de 2026.

A tabela do entregável fica assim, com o rótulo dentro da própria tabela e não numa nota de rodapé que ninguém lê

Medição	Condição	Tempo até o maior elemento	Natureza do dado
1. Aquecida	Cache quente, sem emulação	1,1 s	Laboratório, execução única. Não usar em relatório
2. A frio	Perfil isolado, Slow 3G, CPU 4x	4,4 s	Laboratório, execução única
3. A frio após correção	Mesma receita da medição 2	2,6 s	Laboratório, execução única

Escreva, abaixo da tabela, a linha que justifica descartar a primeira medição: ela mediu uma visita repetida, com os arquivos já em cache e a conexão já negociada, cenário que o visitante novo não vive. O relatório está pronto quando cada um dos três números traz o rótulo de laboratório e a condição em que foi colhido.

Uma execução única oscila. Antes de afirmar que a correção melhorou, rode a medição a frio três vezes e apresente a mediana, mantendo a receita idêntica. Se as três execuções variarem mais do que a diferença que você quer comemorar, o que você tem ainda é ruído.

Checkpoint

Critério de sucesso observável: sua tabela mostra diferença relevante entre a medição aquecida e a medição a frio; você aponta, com número e porcentagem, qual fase da decomposição domina o tempo até o maior elemento; a terceira medição repete exatamente a receita da segunda e muda apenas a correção aplicada; e os três números aparecem rotulados como dado de laboratório, execução única. Nenhum deles é descrito como a experiência dos usuários reais.

A decisão que cabe a você

A sua parte é impor o rótulo antes do número. Peça que cada tempo de carregamento apresentado diga a condição em que foi colhido e nunca deixe um dado de laboratório ser vendido como a experiência dos seus usuários reais. Sem essa etiqueta o relatório é impossível de repetir e vale tanto quanto um palpite.

Seu caderno neste capítulo

Abrir o caderno completo

Selecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.

Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.

Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.

Conexões deste capítulo

Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.

Estude antes

Conceitos deste capítulo

O mesmo assunto em outros cursos

Ver este capítulo no mapa do conhecimento

Leve uma ideia para a prática

Escolha uma atividade no painel e volte a este curso quando quiser.

Atividades e evolução ficam reunidas no painel da sua conta.

MCP com Chrome: Automação com IA · Capítulo 14 de 16 · 36 min

Medir carregamento sem mentir para o cliente

Número excelente em laboratório e site lento no celular do cliente têm duas causas: página aquecida em cache e dado de laboratório vendido como real.

Este capítulo faz parte do curso gratuito MCP com Chrome: Automação com IA.

Para executivos

Glossário rápido

Laboratório e campo

Medição a frio e cache quente

Regra de ouro

A segunda visita não repete nenhum desses custos. Ela mede um cenário que o visitante novo, aquele que decide se fica ou sai, nunca vive.

Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.

A ordem das chamadas decide o que entra na gravação. Quando o trace começa antes da navegação, a região sombreada some do arquivo e o carregamento inicial simplesmente não foi medido.

jsonc

// Configuração do servidor MCP oficial do time do Chrome.
// Vai no arquivo de configuração de servidores MCP do seu cliente.
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        // Perfil temporario, criado agora e descartado ao fechar o navegador.
        // Medicao comeca sempre de um estado limpo, sem cache herdado.
        "--isolated"
      ]
    }
  }
}

FluxoFazer as três medições na ordem certa

1. AQUECIDA        navegar -> navegar de novo -> gravar sem emulação
                   resultado bonito, imprestável para relatório

2. A FRIO          perfil isolado -> emular rede lenta e CPU 4x
                   -> navegar -> gravar com reload
                   este é o número que descreve o visitante novo

3. A FRIO + FIX    aplicar UMA correção vinda do insight
                   -> repetir exatamente a medição 2
                   só muda uma variável, então a diferença tem causa

jsonc

// Sequencia de chamadas da medicao 2 (a frio, aparelho modesto).
// Cada linha e uma chamada de ferramenta do servidor chrome-devtools.

// 1. Emule o aparelho ANTES de navegar, para que a propria navegacao
//    ja aconteca sob a condicao que voce quer medir.
emulate {
  "networkConditions": "Slow 3G",
  "cpuThrottlingRate": 4,
  "viewport": "412x915x2.6"
}

// 2. Va ate a URL. Este passo e o que a documentacao exige antes
//    de gravar quando reload ou autoStop estao ativos.
navigate_page { "url": "https://exemplo.com.br/lp" }

// 3. Grave. reload:true recarrega a pagina dentro da gravacao,
//    entao o carregamento inteiro entra no trace.
performance_start_trace { "reload": true, "autoStop": true }

// 4. Com autoStop:true a gravacao encerra sozinha quando a pagina
//    estabiliza. Se voce usar autoStop:false, encerre a mao:
// performance_stop_trace {}

PromptPedido ao agente para a medição a frio

Meça o carregamento de https://exemplo.com.br/lp simulando um aparelho modesto.

Ordem obrigatória, não inverta:
1. Chame emulate com networkConditions Slow 3G, cpuThrottlingRate 4 e viewport de celular.
2. Só depois chame navigate_page para a URL.
3. Só então inicie o trace com reload true e autoStop true.

Quando o trace terminar, liste os insights disponíveis e analise o LCPBreakdown.
Me diga qual fase da decomposição domina o tempo, em milissegundos e em porcentagem do total.

Não proponha correção ainda. Nesta primeira rodada eu quero apenas o diagnóstico.
Se alguma chamada falhar, me diga qual e pare, não tente contornar mudando a ordem.

Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.

A decomposição do maior elemento de conteúdo separa o tempo total em fases. A fase dominante é o que transforma um número solto em recomendação acionável.

jsonc

// O insightSetId vem no resultado da propria gravacao.
// Nao invente o valor: copie o que o trace devolveu.
performance_analyze_insight {
  "insightName": "LCPBreakdown",
  "insightSetId": "<id devolvido por performance_start_trace>"
}

MockupLer o insight da medição a frio

LCPBreakdown
Elemento: <img class="hero" src="/hero.webp">

Tempo até o primeiro byte ......  620 ms   14%
Atraso até começar a baixar .... 2380 ms   54%   <-- domina
Download do recurso ............  980 ms   22%
Atraso até pintar o elemento ...  420 ms   10%
                                 -------
Total                            4400 ms

Números ilustrativos, apenas para treinar a leitura.

Na prática

Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.

Laboratório é uma execução com limitação simulada. Campo é a distribuição de muitas visitas reais, em aparelhos e redes que você não escolhe, agregada ao longo de semanas.

São duas perguntas diferentes. Laboratório responde por que está lento. Campo responde quantos usuários sentem isso.

Guia prático: Core Web Vitals das páginas de uma campanha

Medição a frio das landings de uma campanha, com rótulo de laboratório e campo

Seis passos por página. Para uma campanha com três landings, reserve meia hora.

Passo 1: Liste as páginas de entrada reais da campanha, uma por grupo de anúncios, sem as UTMs
Mede-se a página, não a URL do clique. Parâmetros de campanha só criam variações do mesmo endereço.
Deu certo quando: Uma lista curta de URLs, cada uma com o grupo de anúncios que a usa.
Erro comum: Medir só a home do site enquanto a verba vai para outras páginas.
Passo 2: Decida o envio de URL ao CrUX: em página ainda não publicada, suba o servidor com --no-performance-crux
As ferramentas de performance podem mandar a URL do trace para a API do CrUX, para trazer dado de campo ao lado do laboratório. Página secreta de pré-lançamento não deve sair da máquina.
Deu certo quando: Landing de lançamento medida sem consulta ao CrUX; landing pública medida com dado de campo.
Erro comum: Medir a página de uma campanha ainda sob sigilo com a consulta de campo ligada.
Passo 3: Emule o aparelho antes de navegar: emulate com rede Slow 4G ou Fast 3G, CPU 4x e viewport de celular
A maior parte do tráfego de mídia paga chega pelo celular. Fixe a receita no relatório para a medição de depois repetir a de antes.
Deu certo quando: A receita de emulação aparece escrita no topo da tabela.
Erro comum: Trocar a receita entre a medição antes e a medição depois da correção.
Passo 4: Navegue até a página e grave com performance_start_trace, reload e autoStop ligados
Depois, peça performance_analyze_insight com LCPBreakdown para saber qual fase domina o tempo até o maior elemento.
Deu certo quando: Um trace com LCP, CLS e a decomposição do LCP em quatro fases.
Erro comum: Iniciar o trace antes de navegar: a página já carregada esconde o problema.
Passo 5: No painel Performance do DevTools, compare o número local com o dado de campo
A visão de métricas mostra o valor local ao lado do percentil 75 de campo, quando a página tem tráfego suficiente no CrUX. Em aplicação de página única, a medição de navegação suave já aparece completa nos insights.
Deu certo quando: A tabela final tem duas colunas separadas: laboratório (sua máquina) e campo (usuários reais, 28 dias).
Erro comum: Somar ou tirar média entre laboratório e campo para apresentar um número só.
Passo 6: Rode três vezes a frio e apresente a mediana por página
Uma execução única oscila. Se as três variam mais que a melhora que você quer mostrar, o resultado ainda é ruído.
Deu certo quando: Uma linha por landing, com mediana, receita e rótulo.
Erro comum: Apresentar o melhor dos três.

No fim você tem: Uma tabela de landings da campanha com LCP e CLS de laboratório e campo separados, a fase que domina o LCP e a receita de medição escrita.

A tabela do entregável fica assim, com o rótulo dentro da própria tabela e não numa nota de rodapé que ninguém lê

Medição	Condição	Tempo até o maior elemento	Natureza do dado
1. Aquecida	Cache quente, sem emulação	1,1 s	Laboratório, execução única. Não usar em relatório
2. A frio	Perfil isolado, Slow 3G, CPU 4x	4,4 s	Laboratório, execução única
3. A frio após correção	Mesma receita da medição 2	2,6 s	Laboratório, execução única

Checkpoint

A decisão que cabe a você

Seu caderno neste capítulo

Abrir o caderno completo

Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.

Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.

Medir carregamento sem mentir para o cliente

Glossário rápido

Guia prático: Core Web Vitals das páginas de uma campanha

Medição a frio das landings de uma campanha, com rótulo de laboratório e campo

A tabela do entregável fica assim, com o rótulo dentro da própria tabela e não numa nota de rodapé que ninguém lê

Seu caderno neste capítulo

Conexões deste capítulo

Estude antes

Conceitos deste capítulo

O mesmo assunto em outros cursos

Leve uma ideia para a prática

Privacidade e cookies

Medir carregamento sem mentir para o cliente

Glossário rápido

Guia prático: Core Web Vitals das páginas de uma campanha

Medição a frio das landings de uma campanha, com rótulo de laboratório e campo

A tabela do entregável fica assim, com o rótulo dentro da própria tabela e não numa nota de rodapé que ninguém lê

Seu caderno neste capítulo

Conexões deste capítulo

Estude antes

Conceitos deste capítulo

O mesmo assunto em outros cursos

Leve uma ideia para a prática

Privacidade e cookies