Performance de plataforma e-commerce B2B com catálogos grandes: o que testar antes de contratar
Performance é o requisito não funcional mais fácil de prometer e mais difícil de entregar. Em uma demo, qualquer plataforma é rápida — banco de dados vazio, usuário único, servidor dedicado para a demonstração. Em produção, com 8.000 SKUs sincronizando com o ERP, 150 compradores acessando simultaneamente e picos de pedido às 9h da manhã de segunda-feira, a realidade é diferente.
Distribuidoras que descobrem o problema de performance depois do go-live enfrentam um dilema difícil: migrar para outra plataforma (custoso e traumático) ou conviver com um portal lento que prejudica a adoção. A única forma de evitar esse dilema é testar performance com dados reais antes de assinar o contrato.
Por que performance é mais crítica no B2B do que no B2C
No B2C, um site lento perde clientes para o concorrente. O comprador impaciente fecha a aba e abre outro site.
No B2B, a dinâmica é diferente — e em alguns aspectos mais severa:
Catálogos estruturalmente maiores. Uma distribuidora industrial pode ter 80.000 SKUs. Uma distribuidora de alimentos pode ter 15.000 produtos com variações por embalagem e gramatura. Servir catálogos dessa dimensão com busca e filtragem rápidas exige arquitetura específica — não basta uma plataforma e-commerce genérica escalada verticalmente.
Sessões de compra mais longas e intensivas. O comprador B2B não acessa o portal, encontra o produto em 30 segundos e sai. Ele navega por categorias, compara produtos, verifica especificações técnicas, monta listas de 40 itens. Uma sessão de compra B2B pode durar 20 a 40 minutos. Performance degradada em qualquer ponto desse processo causa abandono.
Picos de acesso concentrados. No varejo online, o tráfego é distribuído ao longo do dia e da semana. No B2B, os pedidos se concentram em janelas específicas — segunda-feira de manhã, véspera de fim de mês, início de promoção de fábrica. A plataforma precisa suportar o pico, não a média.
Integração em tempo real com ERP. Cada consulta de estoque, cada verificação de preço, cada envio de pedido é uma chamada à API do ERP. Com 100 usuários simultâneos fazendo pedidos, isso representa centenas de chamadas simultâneas ao ERP. Se a plataforma não gerencia esse volume com circuit breakers e cache adequado, o ERP começa a falhar — e o portal junto.
Confiança operacional. No B2B, a plataforma é infraestrutura de operação, não canal de vendas opcional. Quando o portal está lento, os pedidos voltam para o WhatsApp. Quando voltam para o WhatsApp, a adoção construída ao longo de meses começa a erosão.
Métricas de performance para portais B2B
Antes de testar, defina o que você vai medir. As métricas de performance para portais B2B são diferentes das métricas padrão de Web Vitals do Google — porque o contexto de uso é diferente.
Tempo de carregamento da listagem de catálogo
O que medir: tempo entre o clique em uma categoria e a exibição dos primeiros produtos na tela (First Contentful Paint da listagem).
Por que importa: é a primeira interação do comprador com o catálogo. Se demorar mais de 2 segundos, a percepção de lentidão é imediata.
Meta: abaixo de 1,5 segundos para listagens com até 50 produtos por página.
O que afeta: número total de SKUs no catálogo (não só os da página atual — o banco de dados precisa fazer a query de filtro em todo o catálogo), número de filtros disponíveis (cada filtro adicional é uma dimensão a mais para indexar), imagens de produto não otimizadas.
Tempo de resposta da busca
O que medir: tempo entre o usuário terminar de digitar um termo e os resultados aparecerem.
Por que importa: no B2B, o comprador frequentemente sabe o que quer e usa a busca diretamente. Uma busca lenta é um atrito que aumenta o abandono.
Meta: abaixo de 800ms para buscas em catálogos de até 20.000 SKUs. Abaixo de 1,5 segundos para catálogos maiores.
O que afeta: arquitetura de busca (plataformas que usam busca nativa do banco de dados relacional são estruturalmente mais lentas que plataformas com índice de busca dedicado como Elasticsearch ou Algolia), número de campos indexados, sinônimos e regras de busca configuradas.
Tempo de adição ao carrinho
O que medir: tempo entre o clique em "adicionar ao carrinho" e a confirmação visual de que o produto foi adicionado.
Por que importa: o comprador B2B adiciona dezenas de produtos ao carrinho em uma sessão. Se cada adição demorar 2 segundos, o processo de montagem do pedido leva muito mais tempo do que deveria.
Meta: abaixo de 500ms para adição ao carrinho. A verificação de estoque em tempo real pode acontecer em background — o produto é adicionado imediatamente e o estoque é verificado de forma assíncrona.
Tempo de checkout e envio do pedido
O que medir: tempo entre o clique em "confirmar pedido" e a tela de confirmação com número do pedido.
Por que importa: é o momento de maior ansiedade do comprador. Uma espera de 10 segundos após clicar em confirmar gera incerteza ("o pedido foi?") e às vezes gera cliques duplos — dois pedidos idênticos enviados ao ERP.
Meta: abaixo de 3 segundos para confirmação inicial no portal. O processamento no ERP pode ser assíncrono — o portal confirma o recebimento do pedido e processa a integração em background.
Tempo de sincronização de estoque (latência de integração)
O que medir: tempo entre uma mudança de estoque no ERP e a atualização no portal.
Por que importa: latência alta de sincronização significa que o portal está mostrando dados de estoque desatualizados — levando a pedidos de produtos indisponíveis e a oversell.
Meta: abaixo de 5 minutos para operações com estoque volátil (alimentos, produtos sazonais). Abaixo de 30 minutos é aceitável para produtos com estoque estável.
Como testar com catálogos de diferentes tamanhos
O teste de performance precisa ser feito com volume de dados representativo do que estará em produção — não com a amostra de 500 produtos da PoC.
Catálogos de até 10.000 SKUs (médio porte)
Nessa faixa, a maioria das plataformas B2B de mercado médio funciona adequadamente se bem configurada. O teste deve focar em:
Busca com termos ambíguos e parciais: buscar "fil" em vez de "filtro", buscar por código parcial ("FLT-" para encontrar produtos cujo código começa com FLT). Plataformas com busca robusta retornam resultados relevantes; plataformas com busca básica só funcionam com o termo exato.
Filtragem combinada: aplicar 3 filtros simultaneamente (categoria + marca + disponibilidade). Medir o tempo de re-renderização da lista.
Paginação em listagens grandes: navegar até a página 20 de uma categoria com 500 produtos. A performance não deve degradar nas últimas páginas.
Catálogos de 10.000 a 50.000 SKUs (grande porte)
Nessa faixa, a arquitetura de busca começa a fazer diferença. Plataformas sem motor de busca dedicado começam a apresentar latência perceptível.
O que testar especificamente:
Importe o catálogo completo no ambiente de PoC — não uma amostra. Execute busca com termos genéricos que retornam centenas de resultados ("válvula", "embalagem", "parafuso") e meça o tempo de resposta. Se demorar mais de 2 segundos com o catálogo completo, vai demorar mais em produção com carga adicional.
Execute filtragem com múltiplos atributos em categorias com 1.000+ produtos. Meça o tempo de aplicação de cada filtro adicional — a degradação deve ser mínima (cada filtro adicional adicionando menos de 200ms ao tempo de resposta).
Catálogos acima de 50.000 SKUs (enterprise)
Nessa faixa, apenas plataformas com arquitetura de busca dedicada (Elasticsearch, Algolia, OpenSearch) conseguem entregar performance adequada de forma consistente.
O que verificar antes de contratar:
Peça ao fornecedor para demonstrar a plataforma com um catálogo de tamanho similar ao seu — em produção com um cliente real, não em ambiente de demo. Peça o tempo de resposta de busca documentado em um relatório de monitoring, não em uma demo ao vivo onde o cache pode estar quente.
Pergunte especificamente: qual é o motor de busca utilizado? Como o índice é atualizado quando novos produtos são adicionados ao ERP? Quanto tempo leva para um produto novo aparecer nos resultados de busca após ser cadastrado?
Teste de carga: simulando pedidos simultâneos em pico
O teste de carga é o teste mais revelador — e o que mais fornecedores tentam evitar durante o processo de avaliação.
Como estruturar o teste
Defina o cenário de pico: qual é o pior caso razoável de uso simultâneo? Para uma distribuidora com 800 clientes ativos, se 10% acessar o portal ao mesmo tempo no momento de pico (uma segunda-feira de manhã após comunicado de promoção), são 80 usuários simultâneos. Use esse número como base.
Simule comportamento real, não só acesso: um teste de carga que apenas faz requisições GET na home page não é representativo. Simule o fluxo completo: login → busca → navegação pelo catálogo → adição de múltiplos produtos ao carrinho → checkout. Cada etapa tem perfil de carga diferente no servidor e no ERP.
Aumente a carga gradualmente: comece com 10 usuários simultâneos, suba para 30, 50, 80, 120. Observe onde a performance começa a degradar. O ponto de degradação revela o limite real da arquitetura.
O que medir durante o teste:
- Tempo de resposta médio e percentil 95 (P95) em cada nível de carga
- Taxa de erros (requisições que falharam ou retornaram erro)
- Comportamento da integração com ERP sob carga (o ERP está sendo sobrecarregado pelas chamadas da plataforma?)
Red flags no teste de carga:
- Tempo de resposta que dobra ao aumentar a carga de 30 para 50 usuários (indica gargalo arquitetural, não só de hardware)
- Taxa de erros acima de 1% em qualquer nível de carga
- ERP ficando lento ou instável durante o teste (indica que a plataforma não tem rate limiting adequado nas chamadas à API do ERP)
Performance em mobile: por que importa mais do que parece
Uma percepção comum em e-commerce B2B é que "nossos clientes compram no computador". Em operações com compradores de pequeno varejo, restaurantes, farmácias e pequenos estabelecimentos, mais de 50% dos acessos ao portal já acontecem pelo smartphone.
Mesmo onde a maioria ainda usa desktop, a tendência é de crescimento do mobile — especialmente para consultas rápidas de estoque e pedidos de reposição feitos fora do escritório.
O que testar em mobile:
Acesse o portal por 4G (não por Wi-Fi) com um smartphone de especificação mediana — não o último iPhone. Navegar pelo catálogo, fazer uma busca, adicionar produtos ao carrinho e concluir o checkout deve ser possível sem zoom, sem scroll horizontal e sem elementos que ficam cortados.
Gargalos comuns de performance mobile:
Imagens de produto não otimizadas para mobile — a plataforma está servindo imagens de 2MB para cada produto em uma listagem de 50 produtos. Em 4G, isso resulta em carregamento lento e consumo de dados excessivo.
Layout não adaptado para touch — botões pequenos demais para dedos, elementos que exigem mouse hover para funcionar, formulários de checkout que não ativam teclado numérico em campos de quantidade.
Perguntas técnicas para fazer ao fornecedor
Estas perguntas separam fornecedores com arquitetura robusta de fornecedores que escalam por força bruta (servidores maiores) sem arquitetura adequada:
Sobre busca: "Qual é o motor de busca utilizado — busca nativa do banco de dados relacional ou motor dedicado (Elasticsearch, Algolia, OpenSearch)? Como o índice é atualizado? Qual o SLA para um produto novo aparecer nos resultados de busca?"
Sobre cache: "Quais componentes do portal têm cache? Como o cache é invalidado quando dados mudam no ERP? Quando o preço de um cliente é atualizado no ERP, em quanto tempo o portal reflete a mudança — e isso é tempo real ou aguarda a expiração do cache?"
Sobre integração com ERP sob carga: "A plataforma tem rate limiting nas chamadas à API do ERP para evitar sobrecarga? Como a plataforma se comporta se o ERP ficar indisponível por 30 minutos durante pico de uso?"
Sobre evidências reais: "Vocês têm um cliente com catálogo de tamanho similar ao meu em produção há pelo menos 12 meses? Posso ver o relatório de monitoring de performance desse cliente (uptime, tempo de resposta médio, P95) nos últimos 30 dias?"
A última pergunta é a mais importante. Qualquer fornecedor pode prometer performance — poucos conseguem mostrar evidências de produção com volume real.
Red flags de performance que aparecem na demo mas ninguém aponta
Demo com catálogo vazio: a demo usa 50 produtos "de exemplo". Você não consegue ver como a busca funciona com 8.000 produtos porque o ambiente não tem esses dados. Insista em ver o sistema com um catálogo real de um cliente existente.
"Nossa plataforma é escalável": escalabilidade é necessária mas não suficiente. Escalar verticalmente (servidores maiores) resolve temporariamente, mas não resolve gargalos arquiteturais. Pergunte especificamente: como a plataforma escala horizontalmente? Quais componentes são stateless?
Tempo de checkout "instantâneo" na demo: na demo, o checkout é rápido porque não há integração real com ERP. O tempo de checkout em produção depende da latência da API do ERP. Peça para ver o checkout funcionando com integração real a um ERP de homologação.
Performance impressionante em desktop/Wi-Fi: a demo sempre acontece em conexão excelente e hardware premium. Peça para ver a demo em um laptop comum conectado por 4G.
A FastChannel disponibiliza relatórios de performance em produção com clientes de catálogo similar ao seu, e realiza testes de carga como parte do processo de avaliação técnica antes do contrato. Para entender a arquitetura da plataforma e solicitar evidências de performance, visite fastchannel.com.