CoreDash vs New Relic Browser
O New Relic Browser é uma monitorização de utilizadores reais razoável dentro de uma excelente plataforma de observabilidade. O CoreDash só faz Core Web Vitals. Na primeira semana não vai notar grande diferença entre os dois; só ao fim de alguns meses de dados é que isso começa a importar.
O New Relic é, antes de mais, uma plataforma de APM
Se o backend já corre no New Relic, a monitorização de Browser pode já estar ativa. Se não estiver, fica a funcionar ainda esta tarde. O agente de APM pode injetar o script de browser por si, sem mexer em templates. É uma boa razão para o usar como ferramenta de RUM.
Criei o CoreDash, por isso esta página não é neutra. Vou tentar ser justo e, com o New Relic, isso não é difícil: não falta o que elogiar.
O que o New Relic Browser faz bem
O mais importante: faz algo que nenhuma ferramenta apenas de RUM consegue, CoreDash incluído. Com distributed tracing, pode seguir uma página lenta até ao serviço de backend, à query da base de dados e ao host onde foi executada. Quando um TTFB mau afinal se deve a uma query SQL lenta, o New Relic mostra a query. Digo constantemente a clientes que o problema de TTFB está no servidor. Os clientes do New Relic podem mesmo ir lá ver.
newrelic.com, outubro de 2026.
Os dados de Core Web Vitals também são melhores do que se costuma pensar. O código-fonte do browser agent é público no GitHub e a versão 1.322.0 inclui a biblioteca web-vitals 6.2.1 da Google com attribution. Assim, cada LCP traz as quatro subpartes (TTFB, load delay, load duration, render delay), o seletor do elemento, a tag e o URL do recurso. O INP inclui as três fases, o target da interação, o tipo de interação e o load state. O CLS regista o elemento responsável pelo maior shift, o respetivo valor e quando ocorreu.
Outras coisas de que gosto:
- O Session Replay está ligado às tabelas de Core Web Vitals e mostra primeiro as sessões com LCP mau. Assim, pode ver a visita real em que o LCP demorou seis segundos, em vez de olhar para um percentil.
- NRQL. Todos os atributos em todos os eventos podem ser consultados, incluindo os seus próprios atributos personalizados, e pode criar um dashboard ou um alerta com base em qualquer um deles.
- O plano gratuito: 100 GB de ingestão por mês e um utilizador full-platform. É generoso.
- Lançamentos frequentes do agente, e é compatível com SPAs e micro-frontends. O respetivo servidor MCP Ground Truth passou a GA em setembro de 2026.
Se já o utiliza
Se hoje já mede os visitantes reais com o New Relic, está à frente da maioria dos sites que vejo. Esses continuam a tentar adivinhar através de testes do Lighthouse e à espera 28 dias que o CrUX lhes diga que algo correu mal. Se responde às suas perguntas, mantenha-o. O resto desta página aborda o que acontece após meses e anos de dados.
Lado a lado
Preços e funcionalidades verificados em setembro de 2026.
| CoreDash | New Relic Browser | |
|---|---|---|
| O que é | RUM para Core Web Vitals, nada mais | O módulo de browser de uma plataforma completa de observabilidade (APM, infraestrutura, logs, synthetics) |
| Script | Menos de 2 KB, async | Loader síncrono no head, o restante async. 10,2 a 25,4 kB com gzip consoante a variante do agente, valor anunciado de menos de 15 ms por carregamento de página |
| Atribuição do LCP | Quatro fases, elemento, tipo de elemento, estado de preload/fetchpriority/lazy loading, URL da imagem | Quatro subpartes, seletor do elemento, tag, URL do recurso |
| Atribuição do INP | Três fases, elemento, tipo de input, load state, URL do script via Long Animation Frames | Três fases, target, tipo de interação, load state. Sem Long Animation Frames |
| Atribuição do CLS | Elemento deslocado, causa do shift, momento do shift | Target do maior shift, valor e momento |
| CrUX ao lado dos dados próprios | Sim | Não que tenha encontrado |
| Tracing de backend | Não | Sim, distributed tracing integrado no APM |
| Session replay | Não (stream de pageviews em direto com waterfall de pedidos por pageview) | Sim, 10% das sessões por omissão, 100% das sessões com erros |
| Retenção de dados | 6 meses (Starter) até 8 anos (Enterprise) | Eventos de browser em bruto durante 8 dias por omissão, 98 dias com Data Plus |
| IA / MCP | Servidor MCP com ferramentas de Core Web Vitals em todos os planos, além do agente gratuito CWV Superpowers | Servidor MCP Ground Truth, mais de 30 ferramentas gerais, Core Web Vitals através de NRQL. Ferramentas de análise com IA requerem o add-on Advanced Compute |
| Preço | A partir de 16 $/mês com faturação anual, calculado por pageviews, todos os dashboards incluídos em todos os planos | Gratuito até 100 GB/mês e 1 utilizador full, depois 0,40 $ ou 0,60 $ por GB mais lugares de utilizador |
| Quem pode aceder aos ecrãs de Core Web Vitals | Todos os utilizadores do plano (3 no Starter, 10 no Standard, ilimitados a partir do Studio) | Utilizadores Core ou full-platform. O plano gratuito inclui um utilizador full-platform; a partir daí, o Core custa 49 $/mês e o full-platform entre 99 $ (Standard) e 349 $ (Pro, anual) por utilizador. Utilizadores básicos gratuitos só têm acesso a NRQL e dashboards personalizados |
| Vários sites / agências | Planos para agências com pageviews partilhadas, uma fatura única e uma chave mestra de API | Múltiplas aplicações de browser por conta, uma fatura de ingestão partilhada, sem produto para agências |
O que muda ao fim de alguns meses
Oito dias de dados em bruto
Os Core Web Vitals costumam degradar-se aos poucos. Uma atualização de um plugin em março acrescenta 80 ms, uma nova ferramenta de consentimento em maio adiciona outros 150 e, em junho, alguém troca a hero image. Ninguém repara até o Search Console ficar cor de laranja. Nessa altura, quer saber o que mudou. Para isso, precisa de dados anteriores ao problema.
Na opção predefinida Original data do New Relic, os eventos de browser em bruto (PageView, PageViewTiming e afins) são guardados durante 8 dias. O Data Plus alarga o prazo para 98 dias a 0,60 $ por GB em vez de 0,40 $, e cada bloco extra de 30 dias custa mais 0,05 $ por GB. Alguns agregados são mantidos por mais tempo (o Apdex e o tempo de carregamento da página por tempo indefinido), mas não lhe dizem qual foi o elemento de LCP que ficou mais lento em março.
Documentação do New Relic, gestão da retenção de dados, outubro de 2026.
O CoreDash guarda um ano no Standard, três anos no Studio e oito no Enterprise, tudo incluído no preço do plano. Pode comparar o mês de junho deste ano com o de junho do ano passado para o mesmo template de página, segmentado por dispositivo e país. O CoreDash também mostra os dados do CrUX da Google ao lado dos seus próprios números. Não encontrei nenhuma integração com o CrUX no New Relic.
Que script tornou aquele clique lento
As fases de INP do New Relic são úteis. Se o processamento demorar 400 ms, sabe que a causa é o event handler, mas não de quem. Na maioria dos sites em que trabalho, os cliques lentos no telemóvel vêm de terceiros, normalmente do tag manager ou de um widget de chat. O browser agent não é compatível com Long Animation Frames, pelo que não lhe consegue dar o URL do script necessário para corrigir o problema.
O CoreDash regista o URL do script LoAF nas interações lentas, para que possa agrupar o INP por script e ver que fornecedor lhe custa mais (o meu artigo sobre Long Animation Frames explica como isso funciona). No LCP, a prioridade do LCP diz se a imagem de LCP teve preload, se tinha fetchpriority alto ou se usava lazy loading. Uma hero image com lazy loading ainda é algo que encontro com demasiada frequência. O dashboard de Diagnosis transforma isso num detalhe por fase com a correção para a sua stack. O New Relic até captura os atributos, mas para ver o p75 do LCP por elemento ou por fase a documentação remete quase sempre para NRQL e dashboards próprios.
Ferramentas MCP para Core Web Vitals
O New Relic tem um servidor MCP em GA, o que é mais do que a maioria dos fornecedores de RUM tem. Foi concebido para observabilidade em geral, o que faz sentido numa plataforma onde a maioria das dúvidas diz respeito ao backend. Contudo, nenhuma das mais de 30 ferramentas é sobre o browser ou Core Web Vitals. Por isso, um agente que queira o seu INP tem primeiro de escrever NRQL sobre PageViewTiming. E as ferramentas de análise por IA são faturadas à parte como Advanced Compute.
O servidor MCP do CoreDash tem três ferramentas, todas dedicadas aos Core Web Vitals. O get_metrics devolve o p75 (ou do p50 até ao p95) com a respetiva classificação e a divisão bom/precisa de melhorias/mau, agrupado por qualquer dimensão. O get_timeseries diz ao agente se uma métrica está a melhorar, estável ou a piorar. O get_histogram apresenta a distribuição. Está incluído em todos os planos do CoreDash, incluindo no Starter. O Claude liga-se via OAuth como conector personalizado, e ferramentas como o Claude Code, Cursor, Windsurf, VS Code e Gemini CLI também funcionam (guia de configuração).
Depois há o CWV Superpowers, um agente gratuito com licença MIT. Recolhe os field data do CoreDash, corre um trace no Chrome com throttling de telemóvel, descobre o que ocupa a maior parte do tempo e gera um diff com ficheiro e linha. Nunca olha para a pontuação do Lighthouse.
O endpoint de MCP é também uma API HTTPS convencional. Se quiser Core Web Vitals nos seus próprios relatórios, faz um POST de JSON e recebe JSON de volta, sem nenhuma linguagem de query para aprender.
Pagar para mais pessoas verem
Os utilizadores básicos gratuitos do New Relic não conseguem aceder aos ecrãs de monitorização de Browser. Se um especialista em SEO ou um cliente quiser ver os Core Web Vitals, precisa de uma licença Core a 49 $/mês ou de uma licença full-platform. O volume de ingestão também aumenta com o tráfego, porque cada métrica de cada visualização de página é um evento PageViewTiming separado. Num site movimentado, os dados de browser acumulam-se e a fatura sobe a cada pico de tráfego. Faturas inesperadas surgem com frequência nas avaliações do New Relic.
O preço do CoreDash também depende das pageviews, pelo que um site maior paga mais. Mas os utilizadores e os dashboards não custam mais nada. O Starter inclui 3 utilizadores, o Standard 10, o Studio e superiores não têm limite, e todos os planos têm todos os dashboards. As agências têm planos para agências com pageviews partilhadas entre clientes e uma Agency API para criar um projeto por cliente a partir das suas próprias ferramentas.
Quando optar antes pelo New Relic Browser
Se já paga pelo New Relic APM, mantenha o Browser ligado. Conseguir seguir uma página lenta até ao backend vale muito e, em problemas de TTFB que começam no servidor, nenhuma ferramenta apenas de RUM consegue fazer isso.
O New Relic também faz sentido se precisar de session replay, rastreio de erros de JavaScript e monitorização de AJAX no mesmo local dos Core Web Vitals; se necessitar de FedRAMP ou HIPAA (Enterprise); ou se tiver um site pequeno com menos de 100 GB por mês e um engenheiro que goste de escrever NRQL. Este último cenário não custa nada.
Ou use os dois. O script do CoreDash tem menos de 2 KB e é async, pelo que funciona ao lado do agente do New Relic sem interferir.
Experimente ao lado do New Relic
Adicione o snippet do CoreDash ao lado do agente do New Relic e dê-lhe duas semanas. Ambos utilizam a biblioteca web-vitals da Google, pelo que estará a comparar exatamente a mesma coisa no seu próprio tráfego. O período de avaliação é de 14 dias, sem cartão de crédito. Consulte os preços ou agende uma demonstração se quiser que lhe mostre o produto.
Ver também: todas as comparações, CoreDash vs Datadog.
Fontes: Preços do New Relic, Código-fonte do browser agent do New Relic, Notas de lançamento do browser agent v1.322.0, Retenção de dados do New Relic, Tipos de utilizador do New Relic, Impacto do browser agent no desempenho, Referência de ferramentas MCP do New Relic, Session Replay nas tabelas de Core Web Vitals, Avaliações do New Relic no Capterra.