Performance Analyzer no Power BI: encontre a lentidão

O Performance Analyzer no Power BI, ou Analisador de Desempenho, ajuda a investigar o carregamento dos elementos de um relatório. A ferramenta registra durações por visual e interação. O diagnóstico deve partir de uma tarefa reproduzível, como selecionar um mês ou abrir o detalhe de um cliente.

Este roteiro organiza uma investigação com registro inicial, hipótese, alteração e comparação. Ele evita trocar gráficos ou reescrever medidas por tentativa. O objetivo é melhorar a experiência de uso mantendo os mesmos resultados e sem confundir tempo de consulta com tempo de desenho na tela.

1. Reproduza a tarefa antes de medir

Descreva a reclamação de forma concreta. “O painel está lento” não indica qual ação exige investigação. Anote página, filtros, período, perfil de acesso e sequência de cliques. Confirme se o problema ocorre ao abrir o relatório, alterar uma seleção ou navegar entre páginas.

Faça o teste com dados e ambiente comparáveis aos usados na operação. Registre versão do arquivo, data da base e modo de conexão. Uma página rápida com poucas linhas de teste pode continuar lenta na base completa; por isso, a condição da medição precisa acompanhar o resultado.

2. Abra o Performance Analyzer no Power BI

No Desktop, use a faixa Otimizar e abra o Analisador de Desempenho. Inicie a gravação e execute a sequência definida. A documentação oficial da Microsoft, consultada em 6 de outubro de 2026, descreve a gravação, a atualização de visuais e a exportação do registro.

Faça uma interação por vez para interpretar o resultado. Depois, interrompa a gravação e identifique os visuais envolvidos. Uma seleção pode atualizar várias partes da página; observar somente o gráfico clicado ignora outros elementos que participaram da mesma tarefa.

3. Separe consulta, desenho e outras atividades

O registro distingue o tempo da consulta DAX, linguagem de expressões de análise de dados, do tempo de exibição do visual. A categoria de outras atividades pode incluir preparação e espera. Esses componentes orientam hipóteses diferentes: cálculo, desenho ou coordenação entre elementos.

Não interprete uma duração alta em “Outros” como prova de fórmula ruim. Examine os demais visuais e repita a sequência. Os tempos podem incluir espera por operações anteriores. Somar todas as durações como se fossem etapas independentes também pode produzir uma estimativa inadequada do tempo percebido.

4. Monte uma linha de base repetível

Execute a mesma sequência algumas vezes e guarde os resultados individualmente. Diferencie a primeira execução das seguintes, pois condições de cache e carregamento podem influenciar o tempo. Não descarte a primeira medição quando o problema relatado é justamente a abertura inicial.

Em um exemplo hipotético, um visual registra 2,4 segundos na primeira execução e 0,8 nas seguintes. Esses valores não são referência de mercado. Eles apenas mostram que escolher uma execução favorável pode esconder a experiência que motivou a análise.

5. Priorize o visual e a interação relevantes

Liste os elementos mais demorados na tarefa que o usuário realiza com frequência. Considere também a importância da informação. Um detalhe consultado raramente pode receber prioridade menor que uma seleção diária, mesmo que sua duração isolada seja maior.

Converse com quem usa o painel antes de retirar um gráfico. A página de indicadores de vendas ajuda a relacionar os visuais às decisões comerciais. Preserve a informação necessária e investigue formas de apresentá-la com menos trabalho de consulta ou desenho.

6. Inspecione a consulta do visual

Use a opção de copiar consulta para examinar o que o visual solicita. Compare os filtros e agrupamentos com a pergunta de negócio. Uma tabela com muitos detalhes pode pedir informação que o usuário não precisa ver inicialmente. Verifique se reduzir esse detalhe mantém a utilidade.

Teste uma hipótese de cada vez, numa cópia do relatório. Se alterar uma medida, confira linhas e totais em cenários conhecidos. O roteiro de validação de totais em DAX apoia a verificação funcional. Uma resposta mais rápida só serve quando continua correta.

7. Revise o custo da apresentação

Se o tempo de desenho predomina, avalie quantidade de elementos exibidos, detalhamento e componentes usados. Uma tabela extensa pode ser mais útil com busca, filtros e uma página de detalhe. Essa decisão deve seguir o fluxo real de trabalho, sem ocultar dados necessários para a ação.

Teste mudanças de apresentação mantendo o mesmo recorte de dados. Num exemplo hipotético, uma página lista milhares de linhas embora o gestor procure um cliente por vez. Acrescentar uma seleção obrigatória pode reduzir o trabalho, mas precisa ser avaliado com o usuário para não dificultar a tarefa.

8. Investigue a fonte em cenários DirectQuery

DirectQuery é um modo de conexão que consulta a fonte para obter dados. Nesse cenário, a investigação pode precisar alcançar o banco e sua capacidade de resposta. Não atribua toda demora ao desenho do relatório sem verificar se a consulta externa está retornando no tempo esperado.

A orientação de diagnóstico da Microsoft, consultada em 6 de outubro de 2026, organiza a investigação entre relatório, modelo e ambiente. Encaminhe consultas e condições de teste ao responsável pela fonte quando a hipótese exigir análise além do arquivo.

Quando comparar alternativas de navegação, confira se o usuário continua conseguindo encontrar a informação sem conhecer códigos internos. Uma seleção que melhora a duração, mas exige procurar o cliente em outra ferramenta, pode aumentar o tempo total da tarefa. Avalie o percurso completo, não somente o visual.

9. Compare resultados sem misturar condições

Repita a sequência original após a mudança e compare execuções equivalentes. Mantenha filtros, identidade, conexão e volume de dados. Se a base mudou entre medições, registre a diferença. Um ganho aparente pode vir de uma redução de linhas, e não da alteração proposta.

Valide também ações próximas: limpar filtros, selecionar outro cliente e voltar à página inicial. Uma otimização pode melhorar um caso e piorar outro. Registre o resultado de cada cenário para decidir se o ganho atende ao uso predominante ou apenas a uma demonstração específica.

10. Guarde evidências e monitore após a liberação

Exporte o registro de desempenho e associe cada teste à versão do arquivo. Documente problema, hipótese, mudança, resultado funcional e durações observadas. Não prometa um percentual universal de melhoria; informe o que foi medido e em quais condições.

O modelo editável de Vendas pode ser adaptado à operação e submetido ao mesmo diagnóstico. A resposta depende da base, das medidas e do ambiente do projeto. Após liberar a mudança, peça ao usuário para repetir a tarefa original e mantenha o caso documentado para investigar regressões futuras.

Defina um critério de aceite local antes de encerrar: a tarefa deve apresentar os mesmos números e cumprir a expectativa acordada no ambiente de uso. Se a melhora for insuficiente, retome a hipótese com as evidências coletadas, sem acumular alterações que impeçam identificar qual delas mudou o comportamento.