Otimização de Performance Salesforce para Empresas

Otimização de Performance no Salesforce para Grandes Organizações: Diagnóstico, Planejamento e Medição

A lentidão no Salesforce raramente é um problema singular; geralmente, é o acúmulo de telas poluídas, consultas não seletivas e automações redundantes. Este guia apresenta um método de diagnóstico em camadas – navegador, tela, servidor, dados, integração – e métricas que comprovam a melhoria.

Tempo de leitura: 3 minAtualizado em: 2026-07-30

A Resposta Curta

O desempenho insatisfatório no Salesforce é um sintoma cumulativo: uma Record Page com 14 componentes, três automações executando no mesmo evento de Save, uma consulta que varre um milhão de registros e uma integração que extrai dados em horário de pico. A única maneira de aprimorar sem desperdiçar orçamento é medir por camadas, identificar a camada dominante e tratá-la — e então medir novamente.

As Cinco Camadas e o Que Medir em Cada Uma

Camada	Sintoma Típico	Ferramenta de Medição	Tratamento Comum
Navegador e Rede	Lentidão apenas para alguns usuários	Lightning Usage App por usuário	Latência organizacional, versão do navegador, VPN
Tela e Componentes	EPT alto em uma página de registro central	EPT por Página, Debug Mode	Redução de componentes, carregamento progressivo, Tabs
Automação	Save lento, Timeout em atualização em massa	Debug Logs, Flow Interviews	Consolidação de Flows, transição para assíncrono
Dados e Consultas	Relatórios falhando, List View travada	Query Plan, Apex Jobs	Filtragem seletiva, Index, arquivamento
Integração	Picos de carga em horários fixos	Event Monitoring, API Usage	Bulk API, janelas de execução, Throttling

Lidando com Grandes Volumes de Dados

Acima de aproximadamente um milhão de registros em um Objeto, as regras do jogo mudam. O Data Skew — por exemplo, 200 mil Accounts associadas ao mesmo Owner ou Parent — cria bloqueios de linha e retarda qualquer atualização em massa. A solução é a distribuição de propriedade, e não a adição de hardware, que de qualquer forma não está sob seu controle. Paralelamente, é aconselhável considerar o arquivamento: registros fechados de cinco anos atrás, que ninguém mais consulta, encarecem qualquer consulta que execute uma varredura.

Telas: Menos É Mais Rápido

A Record Page média em uma organização legada acumula componentes a uma taxa de dois a três por ano, porque cada stakeholder solicita "apenas mais um widget". Cada componente Lightning realiza suas próprias chamadas. Duas ações geram a maior parte do ganho: mover componentes secundários para Tabs separados que são carregados apenas sob clique, e aplicar o Component Visibility por Record Type ou perfil, de modo que o usuário veja apenas o que é relevante para ele. A combinação de ambos reduz o EPT em dezenas de percentagens sem alteração no código.

A Ordem de Operações que Funciona

Comece com uma semana de medição sem alterações, para estabelecer um Baseline confiável para cinco telas centrais e três processos chave. Em seguida, trate as telas — esta é a parte mais barata e rápida. Na terceira etapa, unifique as automações por Objeto, e somente na quarta etapa toque nas consultas e no modelo de dados. As integrações são tratadas em paralelo, se a medição indicou que são a causa.

A lógica desta ordem é econômica: as primeiras camadas são baratas e reversíveis, as últimas são caras e exigem testes de regressão. Mais informações sobre o assunto estão disponíveis em Salesforce Health Check e Sinais para uma Atualização de Sistema.

Riscos Comuns e Ações Preventivas

O grande risco é a otimização sem Baseline: dez alterações são implementadas, os usuários ainda reclamam, e não há como saber o que realmente ajudou. A medição pré e pós-cada mudança significativa é uma condição, não um luxo.

Um segundo risco é tratar o sintoma mais ruidoso. A tela sobre a qual mais se reclama não é necessariamente a mais lenta — às vezes, é simplesmente a que é aberta mais vezes ao dia. Um terceiro risco é modificar automações sem cobertura de testes: a unificação de Flows é a ação com o maior potencial para quebrar silenciosamente a lógica de negócios.

Como Medir o Sucesso

Quatro métricas são suficientes: EPT médio nas cinco telas principais, tempo de Save no processo de negócios primário, número de falhas de Timeout e Governor Limit por mês, e a porcentagem de consultas que demoram mais de cinco segundos. Uma quinta métrica — complementar e não técnica — é o número de reclamações de desempenho no Service Desk, que deve diminuir com a melhoria real.

Perguntas Frequentes

Por onde começar quando os usuários reclamam que 'o sistema está lento'?

Pela medição, não pela suposição. O Lightning Usage App mostra quais telas estão lentas e para quais usuários, e o EPT para cada Record Page indica o componente problemático. Uma reclamação geral sem medição quase sempre leva à correção do componente errado.

O que é uma consulta não seletiva e por que é um problema crítico?

É uma consulta cujo filtro não é suportado por um índice, forçando a varredura de uma tabela grande. Acima de um milhão de registros, ela falha por timeout ou retarda qualquer processo que dependa dela. A solução: filtrar por campos indexados, evitar NULL e LIKE abertos, e solicitar um Custom Index.

Quando uma Skinny Table é justificada?

Quando há um relatório ou List View central que puxa poucos campos de um Objeto com milhões de registros, e a filtragem já é otimizada. É uma solicitação ao Suporte Salesforce, e não uma configuração autônoma, que resolve a leitura – não a escrita ou automação pesada.

A substituição de Process Builder por Flow melhora a performance?

Na maioria dos casos, sim, mas não por causa da ferramenta em si, e sim pela consolidação. O real ganho vem da redução do número de automações executadas no mesmo Objeto e da movimentação de trabalho pesado para processamento assíncrono, não apenas pela transição.

Que nível de melhoria é razoável esperar?

Em um projeto focado de diagnóstico e tratamento, uma redução de 30% a 50% no tempo de carregamento das telas mais pesadas, dentro de seis a dez semanas, é uma meta realista. Melhorias maiores geralmente exigem a mudança do modelo de dados ou da arquitetura de integração.