Otimização de Performance, SEO e Open Graph (22/09/2026) — 91 mobile / 98 desktop
Atualização (22/09/2026, fim do dia): depois de mais uma rodada de correções, a home saiu de 63/100 para 91/100 no mobile e 98/100 no desktop de Desempenho no Google PageSpeed Insights. Esta página documenta o histórico completo — o que foi encontrado, o que foi corrigido a cada rodada e o que ainda está por vir.
Resultado final desta rodada
Por que isso importa pro marketplace
- Conversão: cada segundo a mais de carregamento aumenta abandono, principalmente em 4G/celular (que é a maioria dos nossos compradores). Uma home mais rápida vende mais.
- Ranking no Google: desempenho (Core Web Vitals) é fator direto de ranqueamento de busca desde 2021. Nota baixa de performance = menos tráfego orgânico gratuito.
- Link bonito ao compartilhar: Open Graph correto é o que faz um link da Saara Online virar um card com imagem/título/descrição quando colado no WhatsApp, Instagram ou Facebook, em vez de um link pelado.
- Decisão orientada a dado: Google Analytics dá visibilidade real de tráfego/comportamento pra decisões futuras de produto e marketing.
O que foi corrigido — 1ª rodada (22/09/2026, tarde)
Imagens de produto pedindo tamanho errado
O componente do card de produto sempre pedia a imagem "pensando" num grid de 4 colunas no desktop e 1 no celular. Só que o grid real da home e das listagens é de 2/3/4/5/6 colunas dependendo da largura da tela. Resultado prático: no celular a imagem chegava com quase o dobro do tamanho necessário (750px de imagem pra caber num espaço de 341px). Corrigimos o cálculo em todos os pontos onde o card de produto aparece (home, categoria, busca, carrossel de recomendados).
Toda imagem da página marcada como "prioridade máxima"
Antes, os 48 cards de produto de uma página inteira competiam entre si por banda com a tag de "alta prioridade" — inclusive os que estavam fora da tela, ainda por vir no scroll. Agora só os primeiros 4 cards (os que realmente aparecem na primeira tela) recebem essa prioridade; o resto carrega sob demanda (lazy loading) normalmente.
Banner do rodapé (skyline) em PNG pesado
Convertido de PNG pra WebP: 299 KB → 64 KB (-78%), com o mesmo visual.
Carrossel de lojistas com dezenas de bolinhas de paginação
Com o número atual de lojistas em destaque, o carrossel "Ver mais" chegou a gerar mais de 40 bolinhas de navegação — cada uma marcada por acessibilidade como "área de toque pequena demais", além de inflar o HTML da página à toa. O carrossel já navega sozinho (autoplay) e por arraste, então as bolinhas foram removidas.
Cache de imagens/arquivos estáticos curto demais
Ajustamos o Next.js pra mandar o navegador guardar imagens otimizadas e arquivos estáticos (logos, ícones, banners) em cache por 1 ano em vez do padrão de 60 segundos. Achado importante nessa investigação: o Nginx Proxy Manager (o proxy reverso na frente do site) tinha a opção "Cache Assets" ligada, que ignorava e substituía esse cache por um teto de só 30 minutos pra tudo — anulando o ajuste feito no código. Desligamos essa opção pros domínios da loja, e o cache passou a funcionar de verdade (economia de cache ineficiente caiu de 356 KiB pra 14 KiB).
Vídeo do Story flutuante pesando quase 2 MB toda vez
O círculo de Stories que fica sempre visível na tela toca o vídeo completo em loop (até ~1,9 MB) só pra mostrar uma prévia pequena e repetitiva. Já preparamos um clipe dedicado — 4 segundos, tamanho de selo (160px), sem áudio — gerado automaticamente a partir do vídeo original só pra esse loop, com o vídeo completo (qualidade cheia) reservado pra quando o comprador abre o Story em tela cheia. Esse é o maior item que ainda falta entrar no ar — ver seção "O que ainda está por vir" abaixo.
SEO, Open Graph e Analytics
- Imagem e metadados de Open Graph configurados pra home (link com card bonito ao compartilhar).
sitemap.xmlgerado automaticamente pro Google indexar as páginas.- Google Analytics integrado (tela própria no admin pra configurar o ID, sem precisar mexer no banco).
O que foi corrigido — 2ª rodada (22/09/2026, noite)
Carrossel de banners da home competindo consigo mesmo pela imagem principal
Todo slide do carrossel de banners (não só o primeiro, visível) estava marcado como "alta prioridade" — nos dois tamanhos (mobile e desktop) de cada slide. Isso fazia a imagem que realmente aparece pro visitante (a maior parte do tempo de carregamento da página, tecnicamente chamada de LCP) esperar na fila atrás de imagens que nem estavam na tela ainda. Corrigido: só o primeiro slide carrega com prioridade agora — esse ajuste sozinho cortou o tempo de carregamento da imagem principal de 4,7s pra 2,4s.
Logo do lojista pedindo imagem 10x maior que o necessário
O selo com a logo da loja (no verso do card de produto e na busca de lojistas) estava pedindo a imagem enviada pelo lojista no tamanho original (até 1080×1080px) pra mostrar num espaço de 80×80px. Corrigido pra pedir só o tamanho realmente exibido.
TalkJS (sistema de mensagens) carregando escondido em toda página, pra todo mundo
Este foi o achado mais surpreendente da investigação: o sistema de mensagens (TalkJS) estava programado pra carregar um script de ~85-100 KiB assim que a página abria — mesmo pra quem nunca faz login, e mesmo sem nenhuma configuração ativa ainda pra esse recurso. Era um comportamento automático da própria biblioteca, disparado só por ela estar referenciada no código, independente de realmente ser usada. Corrigido pra só carregar quando de fato for usado.
Banner de cookies removido
Avaliação feita: a LGPD não exige um banner de consentimento nos moldes da lei europeia (GDPR) pra esse caso — removido. O Google Analytics passou a rodar direto pra todo mundo.
O que ainda está por vir
- Vídeo do Story (maior item pendente): a otimização já está pronta no código (clipe de 4s pro círculo, vídeo completo só na tela cheia) mas depende de um deploy do backend + rodar uma atualização no banco de dados — ainda não fizemos isso. Depois desse deploy, o Story que está ativo hoje ainda vai precisar ser reenviado pelo lojista pra ganhar o clipe pequeno (Stories já publicados não recebem isso automaticamente).
- ~300-400 KiB de JavaScript não usado em alguns pacotes carregados por completo — já identificamos uma parte (um componente puxando uma biblioteca de admin pesada à toa) mas tentamos uma correção que teve efeito colateral inesperado (piorou antes de melhorar) e preferimos não arriscar de novo sem investigar com uma ferramenta própria pra isso.
- Pequenos achados de acessibilidade (contraste de texto, nomes de botão pra leitor de tela).
Novas atualizações de performance estão por vir — essa página será atualizada conforme cada rodada for concluída.