Otimização de Performance, SEO e Open Graph (22/09/2026) — 91 mobile / 98 desktop

EmAtualização (22/09/20262026, rodamosfim odo 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 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.Insights. Esta página documenta o histórico completo — o que foi encontrado, o que já foi corrigido a cada rodada e o que ainda está empor aberto.vir.

Resultado final desta rodada

AntesDepois Desempenho (mobile, 4G lento)6391 Desempenho (desktop)—98 Largest Contentful Paint (mobile)6,9s2,4s Total Blocking Time (mobile)160ms170ms Cache ineficiente356 KiB14 KiB (o resto é de terceiro, fora do nosso controle) Imagens maiores que o necessário921 KiB64 KiB

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— subido1ª pra produçãorodada (22/09/2026)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). 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 segundossegundos. 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 — evitaanulando re-baixaro ajuste feito no código. Desligamos essa opção pros domínios da loja, e o cache passou a mesmafuncionar imagemde 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 cadapartir visita.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, LGPDGraph 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.
• 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 denos cookiesmoldes da lei europeia (LGPD).GDPR)

pra esse caso — removido. O Google Analytics integrado.passou a rodar direto pra todo mundo.

Pendências encontradas (ainda não resolvidas)

Proxy reverso anulando o cacheO que acabamosainda deestá configurar

por

Aovir investigar

diretoVídeo nado VPS,Story encontramos(maior item pendente): 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 backendotimização já mandem,está 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 feitopronta no código do(clipe storefrontde hoje4s pro círculo, vídeo completo só vaina tertela efeitocheia) completomas depoisdepende quede essaum configuraçãodeploy do proxybackend for+ revista.rodar Correçãouma identificada,atualização no banco de dados — ainda não aplicadafizemos (pendenteisso. deDepois permissãodesse deploy, o Story que está ativo hoje ainda vai precisar ser reenviado pelo lojista pra ediçãoganhar diretao naclipe VPS).pequeno

Itens(Stories dojá relatório aindapublicados não atacados

recebem

isso automaticamente). ~304300-400 KBKiB de JavaScript não utilizadousado em alguns chunkspacotes (7959, 5591, 1910) — vem de bibliotecas carregadascarregados por completo mesmo— quandojá sóidentificamos uma parte é(um usadacomponente napuxando tela.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. Solicitações que bloqueiam a renderização inicial (~230ms estimados). AlgunsPequenos achados de acessibilidade menores (botões sem nome acessível, contraste de textotexto, nonomes rodapé)de botão pra leitor de tela).

PróximoNovas passo natural: reaplicar o teste do PageSpeed Insights depois do deployatualizações de hojeperformance praestão medirpor ovir ganho— real,essa epágina seguirserá atacandoatualizada osconforme itenscada darodada listafor de pendências.concluída.