No artigo anterior eu contei que um app de avaliações custava 1.900 milissegundos de LCP na minha loja. Ele injetava Google Fonts por conta própria, sem opção de desligar, e não existia jeito limpo de contornar.
A decisão foi remover o app. Só que remover significava perder 332 avaliações acumuladas ao longo de anos — e prova social é o que sustenta conversão em loja de produto artesanal.
Este artigo mostra o que eu construí no lugar: um sistema de avaliações inteiro em JSON estático servido pelo CDN da própria loja, com 14 KB comprimidos e zero requisição externa.
A resposta curta
Avaliações de produto são dados que quase nunca mudam. Não precisam de banco de dados, nem de API, nem de aplicativo rodando em tempo real. Precisam ser lidos rápido e exibidos.
A arquitetura que resolve isso é a mais simples possível: um arquivo JSON estático hospedado no CDN que você já paga, buscado uma única vez, renderizado por JavaScript puro. Sem dependência externa, sem mensalidade, sem fonte de terceiro entrando no seu caminho crítico.
O custo total do meu sistema é uma requisição de 14 KB para o mesmo domínio que já está aberto.
Por que um app de avaliações custa tão caro
O problema não é o conceito de avaliação. É o que vem junto com o aplicativo.
Um app de avaliações típico carrega, no mínimo:
- Um ou mais arquivos JavaScript de um domínio externo
- Uma folha de estilo própria, também externa
- Frequentemente uma fonte, também externa
- Uma ou mais chamadas de API para buscar as avaliações em tempo real
São de três a cinco conexões novas, cada uma com o ciclo completo de consulta DNS, conexão TCP e negociação TLS. E como isso tudo costuma ficar acima da dobra, na página de produto, entra direto no caminho crítico.
No meu caso o agravante era a fonte. Como detalhei em Google Fonts está destruindo o LCP da sua loja, a fonte externa sozinha respondia por quase dois segundos.
E aqui está o detalhe que me convenceu: eu estava pagando mensalidade para tornar minha loja mais lenta.
O que o sistema precisava fazer
Antes de escrever qualquer código, listei o que o app realmente entregava e que eu não podia perder:
| Recurso | Precisa? |
|---|---|
| Selo com estrelas na grade de produtos | Sim |
| Selo com estrelas na página de produto | Sim |
| Bloco completo com resumo e cartões | Sim |
| Distribuição por número de estrelas | Sim |
| Paginação das avaliações | Sim |
| Dados estruturados para o Google | Sim |
| Formulário de coleta de novas avaliações | Adiável |
| Moderação, e-mail automático, foto do cliente | Não |
Essa última coluna é a parte importante. A maioria dos recursos de um app existe para justificar o preço, não porque a sua loja usa. Eu não usava foto de cliente, não usava e-mail automático de solicitação, não usava resposta do lojista.
Cortando o que não era usado, sobrou algo que cabe em dois arquivos.
A arquitetura: JSON estático no CDN
O sistema tem três peças.
1. O arquivo de dados
Um único JSON com todas as avaliações, hospedado no CDN da própria plataforma da loja. No meu caso:
- 332 avaliações
- 118 produtos
- Cerca de 14 KB depois da compressão
Catorze kilobytes. Menos que a maioria dos ícones que as lojas carregam sem pensar.
A estrutura é direta:
{
"reviews": [
{
"handle": "renda-guipir-branca-10cm",
"rating": 5,
"author": "Maria S.",
"date": "2026-03-14",
"title": "Qualidade excelente",
"body": "A renda chegou antes do prazo e o acabamento é impecável."
}
]
}
Nenhum campo a mais do que o necessário para renderizar. Cada campo extra é peso multiplicado por 332.
2. O JavaScript
Um arquivo em IIFE — função anônima autoexecutável — sem framework, sem dependência, sem variável vazando para o escopo global.
O fluxo é linear:
- Uma única chamada
fetchno arquivo JSON - Agrupamento das avaliações por
handlede produto - Renderização do que a página em questão precisa
- Injeção do JSON-LD para o Google
A parte que mais importa para performance: a busca acontece uma vez por carregamento de página, e o resultado serve tanto o selo quanto o bloco completo. Nada de uma chamada por produto na grade.
3. O CSS
Estilo próprio, na mesma folha do tema. Estrelas em SVG inline, cartões seguindo as cores da loja. Zero fonte adicional — o sistema usa a tipografia que a página já carregou.
Por que product.handle — e a armadilha desse casamento
A ligação entre avaliação e produto é feita pelo handle, que é a parte final da URL do produto.
É a escolha certa porque o handle está disponível no frontend sem nenhuma consulta adicional, e é estável enquanto ninguém mexer na URL.
E aí está a armadilha: se você mudar a URL de um produto, as avaliações dele somem silenciosamente.
Não dá erro. Não aparece aviso. O JavaScript procura pelo handle novo, não encontra nada, e renderiza o produto sem avaliação nenhuma. Você só descobre semanas depois, olhando por acaso.
Duas proteções que eu recomendo:
Guarde também o ID do produto no JSON, como campo secundário. Se o handle falhar, você tem por onde recuperar.
Crie uma rotina de verificação. Um script simples que percorre os handles do JSON e confere se cada um ainda existe na loja. Rodar uma vez por mês evita a surpresa.
Se eu fosse começar de novo hoje, casaria por ID e usaria o handle apenas como reserva. Foi a decisão que eu tomaria diferente.
O JSON-LD que traz as estrelas para o Google
Este é o item que a maioria das implementações caseiras esquece — e é o que faz as estrelas amarelas aparecerem no resultado da busca.
O sistema injeta, na página de produto, um bloco de dados estruturados com a nota agregada:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Renda Guipir Branca 10cm",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.8",
"reviewCount": "12",
"bestRating": "5",
"worstRating": "1"
}
}
</script>
Três cuidados que fazem diferença:
A nota precisa ser calculada, não fixa. Injete o valor real vindo do JSON, arredondado para uma casa decimal.
reviewCount precisa bater com o que está visível na página. Se o schema diz 12 e a página mostra 8, o Google trata como inconsistência e pode ignorar o bloco inteiro.
Só injete em produto que tenha avaliação. Schema de nota agregada em produto sem nenhuma avaliação é erro de marcação.
Vale validar no Teste de Resultados Ricos do Google depois de publicar. Leva dois minutos e evita meses de estrelas que nunca aparecem.
O que eu perdi ao sair do app
Seria desonesto listar só ganhos. O que ficou pelo caminho:
A coleta automática. O app enviava e-mail depois da entrega pedindo avaliação. Isso eu não reconstruí — e é a maior perda real.
A moderação com interface. Hoje, adicionar avaliação significa editar o JSON manualmente e subir de novo. Funciona para volume baixo. Não escala.
Foto enviada pelo cliente. Não uso, mas quem usa precisaria de hospedagem de imagem e otimização, o que muda o cálculo por completo.
Resposta do lojista. Também não uso, mas é campo simples de adicionar no JSON se um dia precisar.
Para uma loja com volume moderado de avaliações, essas perdas são aceitáveis. Para uma loja que recebe dezenas de avaliações por semana, provavelmente não são.
O que ainda está pendente
Sendo direto: a coleta de novas avaliações está suspensa.
Não existe formulário ativo na loja. As 332 avaliações são o acervo migrado do app antigo, e qualquer avaliação nova precisa ser adicionada manualmente ao JSON.
É dívida técnica reconhecida, não detalhe escondido. O plano para resolver tem duas rotas possíveis:
Rota simples: um formulário que envia para um endpoint, que grava numa planilha, e um script que regenera o JSON a partir dela. Rústico, mas funciona.
Rota melhor: uma função serverless que recebe a avaliação, valida, grava em banco e regenera o JSON no CDN automaticamente. Mais trabalho, mas fecha o ciclo sem intervenção manual.
Enquanto isso não acontece, o sistema entrega perfeitamente a parte de exibição — que é a que afeta conversão e velocidade.
Vale a pena para a sua loja?
Depende de três respostas.
Quantas avaliações novas você recebe por mês? Até uma dúzia, atualização manual é tranquila. Acima disso, você precisa da coleta automatizada antes de migrar.
Você usa os recursos avançados do app? Foto de cliente, moderação em fila, e-mail automático, resposta pública. Se usa dois ou mais, o app provavelmente se paga.
Você consegue medir o custo dele? Se nunca mediu, meça antes de decidir. Pode ser que o seu app seja leve e o problema esteja em outro lugar.
O meu caso era claro: recursos avançados não usados, volume baixo de avaliações novas, e um custo de quase dois segundos por carregamento. A conta não fechava de jeito nenhum.
Perguntas frequentes
Sistema de avaliações próprio prejudica o SEO?
Não, desde que inclua os dados estruturados. O que o Google lê para exibir as estrelas é o JSON-LD com aggregateRating, e ele funciona igual vindo de app ou de código próprio. O que prejudica SEO é página lenta — que é justamente o que o app estava causando.
Quantas avaliações cabem num JSON estático?
Muito mais do que parece. As minhas 332 avaliações de 118 produtos ocupam cerca de 14 KB comprimidos. Mesmo com dez vezes esse volume você estaria em torno de 140 KB, o que ainda é menos que uma única foto de produto mal otimizada. Acima disso, vale dividir o JSON por coleção.
E se eu mudar a URL de um produto?
As avaliações daquele produto param de aparecer, silenciosamente. É a principal fragilidade do casamento por handle. A proteção é guardar também o ID do produto no JSON e rodar uma verificação periódica conferindo se todos os handles ainda existem.
Preciso saber programar para fazer isso?
Precisa saber JavaScript básico e ter acesso aos arquivos do tema. Não é projeto de iniciante absoluto, mas também não exige framework nem backend. São dois arquivos e um JSON.
Como migrar as avaliações que já existem no app?
Quase todo app de avaliações permite exportar em CSV. Você exporta, converte para o formato JSON que o seu sistema espera, confere se os handles batem com os produtos atuais e sobe o arquivo. A conversão em si é um script de vinte linhas.
Dá para fazer isso em qualquer plataforma de loja?
O conceito sim: JSON estático, uma requisição, renderização no cliente. O que muda é onde você hospeda o arquivo e como acessa o identificador do produto no frontend. A ideia funciona em Shopify, WooCommerce ou loja feita à mão.
Resumindo
Avaliação de produto é dado que quase não muda, e dado que quase não muda não precisa de aplicativo rodando em tempo real. Precisa de um arquivo bem servido.
Trocar o app por um JSON estático de 14 KB no CDN eliminou a mensalidade, removeu de três a cinco conexões externas do caminho crítico e devolveu os 1.900 milissegundos que o app custava.
A contrapartida honesta é que eu perdi a coleta automática de avaliações novas, e essa dívida ainda está em aberto. Para o meu volume, compensou. Antes de decidir pelo seu caso, meça quanto o seu app custa hoje — pode ser que ele seja leve e o gargalo esteja em outro lugar.
Continue lendo em Performance: