CoreDash vs Request Metrics

Quem desenvolve o Request Metrics

O Request Metrics é desenvolvido pela equipa por trás do TrackJS. O Todd Gardner e o Eric Brandes criam ferramentas de monitorização há muito tempo. O produto é limpo e fácil de aprender e, se enviar um email ao suporte, fala com os engenheiros que o desenvolveram. Os clientes referem muito isso e, pelo que vi do produto, acredito.

Fui eu que criei o CoreDash, por isso tenha isso em conta. O Request Metrics faz algumas coisas melhor do que o CoreDash e vou destacá-las. Continuo a achar que o CoreDash é a melhor escolha após os primeiros meses, mas para certas equipas o Request Metrics é a ferramenta certa.

O que o Request Metrics faz bem

Sobretudo Long Animation Frames. Há um dashboard dedicado de LoAF onde pode separar frames causados por interações de frames causados por avaliação de scripts, e detalhar tudo por página e por script, até ao event listener ou callback de setTimeout que foi executado. Os LoAFs também são desenhados no waterfall de carregamento da página, que é onde fazem mais sentido. Há até um botão "Show Code" que abre o inline script para não ter de abrir as DevTools (vai buscar o script tal como está online agora, por isso logo após um deploy pode ser diferente do código que realmente correu). Se quiser saber o que é o LoAF e porque é importante para o INP, escrevi sobre a Long Animation Frames API no corewebvitals.io.

requestmetrics.com, outubro de 2026.

Também vai além do RUM. Desde janeiro de 2025, corre análises semanais com o Lighthouse em desktop e telemóvel para as páginas com mais tráfego, e inclui um dashboard de CrUX onde pode adicionar a origem pública de qualquer concorrente. As análises começam antes de instalar o que quer que seja, pelo que há dados para consultar logo no primeiro dia. No plano Professional, tem ainda monitorização de erros de JavaScript, monitorização de APIs, analítica de tráfego, funis e cronologias de sessão, tudo a partir do mesmo script.

A atribuição é boa. Os elementos de LCP e CLS surgem como seletores CSS prontos a colar nas DevTools, e o agente recolhe as subpartes do LCP (resource load delay, tempo de carregamento e render delay) ao lado do TTFB.

A privacidade é bem tratada: sem cookies, os endereços IP são convertidos em hash com salt e depois eliminados, os dados ficam guardados no Canadá e os clientes Enterprise podem optar por self-host ou por uma instância dedicada. A instalação é simples com um snippet de CDN ou módulo NPM, é segura para server side rendering e permite encaminhar o coletor através do próprio domínio para que os ad blockers não bloqueiem os beacons. Poucas ferramentas ajudam nisto, e a perda de beacons é um problema real.

O preço é previsível. Há um plano gratuito, o Essentials começa nos 34 $ por mês com faturação anual e utilizadores ilimitados, e nunca há faturas por excesso.

Se já utiliza o Request Metrics

Nesse caso, já está a medir os visitantes reais — e a maioria dos sites que audito não o faz. Trabalham com base em pontuações do Lighthouse e num relatório do Search Console que apenas mostra grupos de URLs. Qualquer monitorização de utilizadores reais é melhor do que nenhuma, e o Request Metrics é uma boa opção.

Se responde às perguntas que lhe faz, fique. Mudar de ferramenta de RUM custa o histórico e uma semana de trabalho, pelo que só compensa quando a ferramenta atual deixar de dar respostas. Para muitas equipas, isso acontece mais tarde, depois de esgotadas as correções fáceis e quando as perguntas começam a ser mais difíceis.

CoreDash vs Request Metrics em resumo

Preços e funcionalidades verificados em setembro de 2026.

Onde o CoreDash ganha vantagem mais tarde

Durante quanto tempo guarda os dados

O Request Metrics guarda 30 dias no Essentials e 90 dias no Professional. É suficiente para detetar uma regressão do deploy da semana passada, mas não para responder a "estamos mais rápidos do que em novembro passado?", pergunta que alguém faz sempre a seguir à Black Friday. O CoreDash guarda 6 meses no Starter, 1 ano no Standard, 3 anos no Studio e 8 anos no Enterprise.

Os limites de tráfego também funcionam de forma diferente. O Request Metrics calcula a capacidade por minuto e descarta as pageviews que ultrapassam o limite. São transparentes quanto a isso — é assim que garantem que nunca terá uma fatura surpresa — e a documentação recomenda contratar 1,5 a 2 vezes o tráfego previsto. Na maior parte dos dias não vai notar. Num dia de grandes vendas, o pico é descartado — logo a hora que queria analisar.

Documentação do Request Metrics sobre limites de tráfego, outubro de 2026.

E a diferença de preço aumenta com o tráfego. Por volta das 500 000 pageviews por mês, o Request Metrics Professional custa 88 $ por mês com faturação anual e 90 dias de histórico. O CoreDash Standard custa 31 $ com um ano de histórico. Para ser justo, o Professional inclui também monitorização de erros, funis e analítica, o que o CoreDash não tem, e utilizadores ilimitados contra os 10 do Standard. No CoreDash paga por pageviews e retenção, e todos os planos incluem todos os dashboards.

Fases do INP

O Request Metrics indica que elemento foi o alvo do INP, se foi um evento de teclado ou de ponteiro, e se a página ainda estava a carregar. Útil, mas fica por aí. O CoreDash divide ainda cada INP em input delay, processamento e apresentação, e associa-o ao URL do script LoAF, ao tipo de input e ao estado de carregamento. As fases indicam o que corrigir. Um input delay longo significa que havia outra coisa a bloquear a main thread quando o visitante clicou — normalmente um gestor de tags ou um script de consentimento. Um processamento longo significa que o seu próprio handler é lento. Uma apresentação longa significa que o render posterior é demasiado pesado. Duas páginas com o mesmo INP podem precisar de uma correção totalmente diferente e, muitas vezes, de uma equipa diferente.

Não encontrei qualquer detalhe sobre as fases do INP na documentação do Request Metrics (ainda não têm um guia de INP). Se o INP for o seu principal problema, verifique isso durante o período de teste.

No LCP a diferença é menor: o Request Metrics também recolhe as subpartes. O CoreDash acrescenta o tipo de elemento e se a imagem do LCP usou preload ou lazy loading — uma das primeiras coisas que verifico num LCP lento. O dashboard Diagnosis indica depois a correção adequada à sua stack.

O seu agente de IA pode ler a field data

Para mim, esta é a maior diferença. Não encontrei no Request Metrics uma API pública para ler dados de desempenho. A API presente na documentação é a API do browser agent, para enviar dados, e os dados saem através de exportações em CSV. Ainda assim, apostaram cedo na IA: em 2023 lançaram um assistente baseado no ChatGPT chamado Professor Sloth, integrado no dashboard.

O CoreDash tem uma API só de leitura e um servidor MCP no mesmo endpoint. O servidor MCP está incluído em todos os planos, até no Starter. Adicione-o ao Claude como conector personalizado, ou ao Claude Code, Cursor, Windsurf, VS Code ou Gemini CLI, e o agente pode consultar a field data diretamente. Algo como: dá-me o p75 de LCP em telemóvel para o checkout, agrupado por elemento de LCP, face à semana passada.

Também criei o CWV Superpowers, um agente gratuito com licença MIT. Encontra o pior estrangulamento nos dados do CoreDash, corre um Chrome trace nessa página e devolve uma correção de código (ficheiro, linha e diff) ou um relatório em HTML. Nunca olha para uma pontuação do Lighthouse. Escrevi sobre como isso funciona no artigo sobre corrigir o INP com um agente de IA.

Grande parte do meu próprio debugging começa com um agente a fazer perguntas à field data. Se os dados só saem em CSV, o agente não consegue perguntar nada, por muito bons que sejam os dashboards.

Agências

O Request Metrics disponibiliza relatórios white-label para agências no Professional, o que dá jeito se quiser enviar relatórios aos clientes em seu próprio nome. O CoreDash não é white-label. Em vez disso, a Agency API dá-lhe uma master key para criar, atualizar e eliminar projetos de clientes, e ler dados de todos eles. As pageviews são partilhadas entre clientes e existe apenas uma fatura. O utilizador cria os seus próprios relatórios e o CoreDash fornece os dados. Consulte os preços para agências.

Quando optar pelo Request Metrics

• Quer RUM, erros de JavaScript, monitorização de APIs e funis numa só ferramenta, com um único script. A monitorização de erros vem da equipa do TrackJS, que faz isto há anos.
• Passa a maior parte do tempo focado em Long Animation Frames e gosta de ter um dashboard de LoAF dedicado.
• Precisa de relatórios white-label para clientes.
• Os seus dados têm de ficar no Canadá, ou precisa de uma instância dedicada ou em self-host.
• O site cabe no plano gratuito, ou a equipa precisa de utilizadores ilimitados no plano de entrada.
• Quer análises de Lighthouse e dados de CrUX de concorrentes logo no primeiro dia, antes de instalar o que quer que seja.

Experimente no seu próprio site

A forma mais fácil de comparar é correr ambos durante duas semanas. Os dois scripts carregam de forma assíncrona e não interferem entre si. O teste do CoreDash dura 14 dias e não exige cartão de crédito, e pode instalá-lo com uma única tag de script ou com o plugin de WordPress. Consulte os preços, ou agende uma demo de 20 minutos e analiso os seus dados consigo.

Para outras ferramentas, veja todas as comparações do CoreDash.

Fontes: preços do Request Metrics, documentação de preços, limites de tráfego, guia de LoAF, guia de LCP, guia de CrUX, referência da API do browser agent, dados de utilizadores finais, lançamento do Unified Web Performance, anúncio do Professor Sloth. Tamanho do agente medido no rm.js v2.4.1.