Skip to main content

Otimização de Performance, SEO e Open Graph (22/09/2026)

Em 22/09/2026 rodamos o Google PageSpeed Insights contra a home da loja (loja.saaraonline.com.br) pela primeira vez de forma sistemática. O resultado expôs uma nota de Desempenho 63/100 (Largest Contentful Paint de 6,9s — bem lento) e algumas lacunas de SEO/Open Graph e conformidade que valiam a pena fechar de uma vez. Esta página documenta o que foi encontrado, o que já foi corrigido e o que ainda está em aberto.

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.
  • LGPD: banner de consentimento de cookies é exigência legal, não só boa prática.
  • Decisão orientada a dado: Google Analytics dá visibilidade real de tráfego/comportamento pra decisões futuras de produto e marketing.

O que já foi corrigido e subido pra produção (22/09/2026)

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). Economia estimada pelo próprio relatório: ~700 KB por carregamento de página.

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.

Vídeo do Story flutuante pesando quase 2 MB toda vez

O círculo de Stories que fica sempre visível na tela estava tocando o vídeo completo em loop (até ~1,9 MB) só pra mostrar uma prévia pequena e repetitiva. Agora existe um clipe dedicado — 4 segundos, tamanho de selo (160px), sem áudio — gerado automaticamente a partir do vídeo original só pra esse loop; o vídeo completo (em qualidade cheia) só carrega quando o comprador realmente abre o Story em tela cheia.

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 — evita re-baixar a mesma imagem a cada visita.

SEO, Open Graph, LGPD e Analytics

  • Imagem e metadados de Open Graph configurados pra home (link com card bonito ao compartilhar).
  • sitemap.xml gerado automaticamente pro Google indexar as páginas.
  • Banner de consentimento de cookies (LGPD).
  • Google Analytics integrado.

Pendências encontradas (ainda não resolvidas)

Proxy reverso anulando o cache que acabamos de configurar

Ao investigar direto na VPS, encontramos a causa raiz de boa parte do problema de "cache ineficiente" apontado pelo relatório: o Nginx Proxy Manager tem a opção "Cache Assets" ativada tanto pra loja.saaraonline.com.br quanto pra slb.saaraonline.com.br (o servidor de arquivos/imagens do backend). Essa opção ignora e substitui qualquer cabeçalho de cache que o Next.js ou o backend já mandem, forçando um tempo de cache de só 30 minutos pra tudo — inclusive os arquivos com nome já "travado por hash" do Next (que poderiam ficar em cache por 1 ano com segurança) e as imagens de produto enviadas pelos lojistas (que nunca mudam de endereço). Ou seja: o ajuste de cache feito no código do storefront hoje só vai ter efeito completo depois que essa configuração do proxy for revista. Correção identificada, ainda não aplicada (pendente de permissão pra edição direta na VPS).

Itens do relatório ainda não atacados

  • ~304 KB de JavaScript não utilizado em alguns chunks (7959, 5591, 1910) — vem de bibliotecas carregadas por completo mesmo quando só uma parte é usada na tela.
  • Solicitações que bloqueiam a renderização inicial (~230ms estimados).
  • Alguns achados de acessibilidade menores (botões sem nome acessível, contraste de texto no rodapé).

Próximo passo natural: reaplicar o teste do PageSpeed Insights depois do deploy de hoje pra medir o ganho real, e seguir atacando os itens da lista de pendências.