Resposta curta
Lentidão em Power BI quase sempre nasce de quatro causas, nessa ordem de frequência: volume que não precisava estar no modelo, relacionamentos que forçam o motor a percorrer tabelas grandes, medidas que recalculam o que poderia estar pronto e transformação pesada acontecendo na hora errada. Reduzir visuais trata o sintoma.
Separe os dois problemas
Abrir devagar e atualizar devagar têm causas diferentes e são frequentemente confundidos.
A abertura lenta aponta para o modelo e para as medidas: o que o motor precisa calcular para desenhar a tela. A atualização lenta aponta para a origem e para a transformação: de onde o dado vem e o que acontece com ele no caminho. Tratar os dois como “o relatório está pesado” leva a otimizar o lugar errado.
Volume que não precisava estar ali
A causa mais comum é também a mais simples: o modelo carrega mais do que a decisão exige.
- Colunas trazidas por inércia — campos de texto livre e identificadores únicos que ninguém usa custam caro em compressão.
- Granularidade excessiva — guardar cada transação quando o painel só lê o dia agrega volume sem agregar leitura. Detalhe pode continuar acessível sob demanda.
- Histórico completo por padrão — dez anos no modelo quando a gestão analisa dois, e os oito restantes existem apenas para o caso de alguém perguntar.
Modelo que obriga o motor a trabalhar demais
O Power BI foi feito para modelo em estrela: tabelas de fato ligadas a dimensões pequenas. Quando o desenho foge disso, o custo aparece em cada interação.
Relacionamentos muitos-para-muitos, filtros bidirecionais e cadeias longas de tabelas obrigam o motor a percorrer o caminho inteiro para responder um clique. Tabelas achatadas, que repetem descrição em milhões de linhas, comprimem mal e ocupam memória que poderia estar sendo usada para calcular.
DAX que recalcula o que já poderia estar pronto
Medidas que iteram linha a linha sobre a tabela de fatos, cálculos que reconstroem o contexto de filtro a cada visual e comparações de período criadas na mão em vez de usar uma tabela de datas adequada: cada um desses padrões é aceitável em um modelo pequeno e insustentável quando a base cresce.
A regra prática é decidir onde o cálculo pertence. O que é fixo e sempre igual pode ser resolvido antes, na carga. O que depende da seleção do usuário precisa ficar em medida.
Transformação no lugar errado
Quando junções, filtros e limpeza acontecem no Power Query a cada atualização, a mesma transformação é repetida indefinidamente — e repetida também em cada relatório que consome a mesma origem.
Empurrar esse trabalho para a origem (uma view no banco ou uma camada tratada na plataforma de dados) muda a natureza do problema: o dado chega pronto e a atualização passa a ser carga, não processamento.
O ponto em que otimizar deixa de resolver
Existe um limite a partir do qual ajustar o arquivo só compra tempo. Ele costuma aparecer com sinais claros: várias fontes combinadas dentro do relatório, a mesma transformação replicada em vários arquivos, janela de atualização estourando e volume crescendo mês a mês.
Nesse ponto o problema saiu do relatório e virou arquitetura. A resposta é uma camada de dados própria, com transformação centralizada e o Power BI voltando a fazer o que faz bem: modelar e apresentar.
Perguntas frequentes
- Reduzir a quantidade de visuais ajuda?
- Ajuda pouco, e apenas quando há muitos visuais complexos na mesma página. Cada visual dispara consultas, então reduzir dá um ganho perceptível em casos extremos — mas se o modelo é o gargalo, o problema volta assim que alguém filtrar.
- Vale a pena usar DirectQuery para melhorar a performance?
- Raramente por performance. DirectQuery serve quando o requisito é dado sempre atual ou quando o volume não cabe em memória; em troca, cada interação vira consulta ao banco. Modelo importado bem construído costuma ser mais rápido para leitura analítica.