Como a Magic Square corrigiu Core Web Vitals em 14 dias e elevou o tráfego orgânico
Plataforma de descoberta de apps Web3 com LCP de 2.8s e INP de 380ms (os dois em vermelho). SDK de wallet com eager-load em cada página. Imagens IPFS sem cachear. A correção foi tática, cirúrgica e rápida.
Contexto do cliente
A Magic Square é uma app store Web3 e plataforma de descoberta. Os usuários navegam dApps curadas em categorias de DeFi, NFT, gaming e infraestrutura, com classificações de segurança, info de auditorias e fluxos diretos de connect-and-use para cada app listada. A equipe tinha construído diferenciação real de produto em torno do processo de revisão de segurança: cada app listada tinha sido auditada, respaldada por seguro e classificada.
O site era uma aplicação Next.js com cerca de 800 páginas indexáveis: páginas de categoria, listings individuais de apps, páginas de revisão de segurança, conteúdo do blog e o help center. A superfície de produto era sólida. A equipe de engenharia era forte. O site carregava lento o suficiente para que nada disso importasse para SEO.
A Magic Square veio até nós especificamente por Core Web Vitals porque tinham estado monitorando seus scores de PageSpeed Insights e vendo-os se manter em vermelho apesar de múltiplas tentativas de otimização. Tinham rodado auditorias Lighthouse, tinham feito deploy de correções e a data de campo (CrUX) seguia mostrando INP em torno de 380ms e LCP em torno de 2.8s em mobile. Os dois em vermelho. Os dois bem dentro do território onde o algoritmo do Google estava degradando ativamente.
A equipe também tinha estado se perguntando por que sua taxa de citações em motores IA era mais baixa do que esperariam para uma plataforma de curadoria e revisão. O tipo de site que os motores IA deveriam amar (structured data sobre apps, classificações de segurança, comparações) estava sendo citado a talvez um terço da taxa que sites similares estavam alcançando.
O problema
O problema de CWV se decompunha em três contribuidores primários.
Primeiro, a situação do SDK de wallet. A Magic Square usa RainbowKit e wagmi para impulsionar os fluxos connect-and-use em cada listing de app. O SDK estava sendo inicializado em cada mount de página incluindo páginas de marketing, páginas de categoria, blog posts, o help center. Cerca de 250KB de JavaScript carregando em cada página mesmo quando o usuário não tinha intenção de conectar uma wallet. Isso custava 200-300ms de TBT (Total Blocking Time) que se traduzia diretamente em scores INP.
Segundo, o problema de imagens IPFS. Muitas das apps listadas na Magic Square usam artwork hospedado em IPFS para seus logos, banners e galerias de screenshots. O site estava renderizando estes via URLs diretas de gateway IPFS. Os gateways IPFS públicos são não confiáveis para crawlers SEO e lentos para usuários finais. O LCP de imagem estava sendo martelado pela latência de gateway IPFS; og:image falhava ao renderizar em previews sociais em torno de 40% do tempo.
Terceiro, o ticker da homepage. A homepage da Magic Square mostra um ticker que se atualiza ao vivo com apps destacadas, alertas de segurança e highlights de categoria. O ticker se carregava e inicializava imediatamente no mount de página com cerca de 80KB de JavaScript e uma conexão WebSocket. Nada disso era visível above the fold. Nada era necessário para o first paint. Mas estava bloqueando o main thread durante a janela crítica de INP.
Do lado do schema, a Magic Square emitia schema Article genérico em todas as páginas de listing. Apps como Aave deveriam ter sido Product ou FinancialProduct. Marketplaces NFT como OpenSea deveriam ter sido Service. As posições DeFi e produtos de yield deveriam ter sido FinancialProduct com propriedades específicas. O Article genérico era incorreto para todos.
A auditoria
Auditoria de duas semanas. Os achados de CWV eram a prioridade top clara porque eram fatores de ranking do Google, não apenas sinais de motores IA.
Confirmamos que o SDK de wallet era o maior contribuidor único a TBT e INP. Bundle analyzer mostrou o SDK e suas dependências representando em torno de 60% do payload inicial de JavaScript em páginas de marketing. A correção era direta: lazy-load do SDK atrás de um trigger de ação do usuário.
O problema de IPFS foi diagnosticado via um trace de Performance em páginas de listing reais. Os fetches de imagens desde gateways IPFS públicos estavam levando 5-8 segundos nos piores casos. O cacheamento de CDN com origin-pull desde um serviço de pinning confiável (Pinata) era o padrão correto.
O problema do ticker era o menor contribuidor CWV mas ainda material. Diferir sua inicialização até depois do first paint, mais mover a conexão WebSocket para um bootstrap diferido com setTimeout, limparia o TBT restante.
O problema de schema era um work stream separado. Mapear cada tipo de app ao schema correto (Product para items NFT, FinancialProduct para posições DeFi, Service para marketplaces, Cryptocurrency para lançamentos de tokens) habilitaria tanto elegibilidade para rich results como lifts de citações em motores IA. Empilhar FAQPage com Speakable em cima amplificaria o impacto AEO.
Sequenciamos o trabalho CWV-primeiro, schema-segundo. As correções CWV eram críticas para ranking e podiam ser enviadas em dias. O trabalho de schema precisava de mais design (qual schema para qual tipo de app) e se beneficiaria de um site mais rápido como fundação.
FREE WEB3 AUDIT
Consiga o mesmo tipo de auditoria para seu site.
Rode a mesma auditoria Crawlux no seu domínio crypto. Primeira auditoria grátis, relatório PDF completo.
Primeira auditoria grátis · Sem cadastro · 60 segundos · Full PDF report
O trabalho
Lazy-load de RainbowKit e wagmi
Refatoramos o wallet provider em um componente wrapper que escuta pelo click do botão de connect antes de carregar o SDK. Usamos dynamic imports de Next.js com ssr:false. Os botões de connect em todo o site foram tagueados com um atributo data-connect-wallet que o componente wrapper escuta.
Em páginas de marketing e páginas de conteúdo, o SDK agora nunca carrega no mount inicial. Nas páginas reais de interação de app onde os usuários tentam conectar, o SDK ainda carrega de forma eager porque o usuário está ali para interagir.
Essa única mudança moveu INP de em torno de 380ms para abaixo de 200ms nas páginas afetadas. O Total Blocking Time caiu substancialmente. O padrão agora é padrão em páginas novas que a equipe da Magic Square constrói.
Cachear imagens IPFS para Cloudflare R2
Construímos um pipeline de upload que faz fetch de cada asset hospedado em IPFS na primeira referência, redimensiona para múltiplos tamanhos (1200x630 para OG, 800x600 para thumbnails de listing, 400x300 para previews de grid), sobe para Cloudflare R2 com headers de cache agressivos e atualiza a referência da página para apontar para a URL do CDN.
O hash IPFS fica na data subjacente (para permanência e verificação). A URL do CDN é o que se emite a crawlers e usuários finais.
LCP melhorou substancialmente dentro de dias conforme o cache se populava. A confiabilidade de renderização de og:image passou de em torno de 60% (a taxa antiga do gateway IPFS) para efetivamente 100%. Os previews de Twitter, LinkedIn e Reddit todos começaram a renderizar corretamente em todo o site.
Diferir o JS do ticker
Movemos a inicialização do ticker para fora do bundle principal e para um carregamento diferido com setTimeout que se dispara depois do first paint. A conexão WebSocket se estabelece depois de que a página esteja completamente interativa. O conteúdo above-the-fold renderiza sem impedimentos pela lógica do ticker.
Mudança menor que a correção do SDK de wallet mas eliminou o TBT residual que estava prevenindo que INP aterrissasse de forma limpa abaixo de 200ms. Com isso no lugar, os scores INP em mobile se estabilizaram no range verde.
Schema dividido por tipo de conteúdo
Mapeamos o inventário de listings de app por categoria. Construímos schema por template com os tipos corretos: Product para marketplaces NFT e items, FinancialProduct para posições DeFi e protocolos de empréstimos, Service para utilidades e infraestrutura, Cryptocurrency para lançamentos de tokens. Empilhamos FAQPage com Speakable em cada página de listing. Os cssSelectors de Speakable apontavam ao bloco de classificação de segurança, as entradas de FAQ e o resumo de auditoria.
Construímos a seção /security/ como um hub de conteúdo dedicado com seu próprio schema FAQPage explicando o processo de auditoria, cobertura de seguro e metodologia de classificações de segurança. Isso deu aos motores IA um destino estruturado para consultas tipo "a app X é segura?".
Resultados
O trabalho de CWV foi enviado em 14 dias desde o kickoff. Dentro dessa janela, tanto INP como LCP se moveram de vermelho para verde no percentil 75 na data de campo de PageSpeed Insights.
O tráfego orgânico subiu aproximadamente 60% nos 60 dias seguintes ao deploy de CWV. O lift se concentrou em consultas long-tail (nomes específicos de app mais modificadores) que tinham sido particularmente impactadas pela experiência de página lenta.
As citações em AI Overview aumentaram substancialmente depois de que o trabalho de schema foi enviado. Tanto ChatGPT como Perplexity começaram a citar a Magic Square em consultas de descoberta de app e segurança onde previamente tinham citado apenas as apps subjacentes diretamente.
A seção /security/ gerou uma porção desproporcional do lift de conversão. A taxa de conversão (definida como o usuário clicando através para realmente usar uma app listada) em páginas de conteúdo de segurança veio 23% acima da média do site. Os usuários que aterrissavam em uma página de revisão de segurança estavam pré-qualificados e convertiam melhor.
5 lições táticas que você pode aplicar
O lazy-loading do SDK de wallet é a correção CWV Web3 de maior ROI
RainbowKit, Web3Modal e wagmi cada um custa 200-500KB de JS inicial. Fazer eager-load deles em páginas de marketing onde os usuários não têm intenção de conectar desperdiça todo o orçamento de performance. Lazy-load atrás de um trigger de click e recupere 200-300ms de TBT instantaneamente.
Cacheie as imagens IPFS agressivamente. Sempre.
Os gateways IPFS públicos rotineiramente levam 5-8 segundos para servir imagens. Twitter, LinkedIn e o crawler do Google todos têm timeout antes disso. Hosting dual: hash IPFS para permanência (referenciado em contratos e metadata), URL do CDN para servir (em og:image, atributos src, schema). O plano gratuito de Cloudflare R2 cobre a maioria dos projetos.
Schema dividido por tipo de conteúdo le gana al Article general
Uma app store tem múltiplos tipos de conteúdo em uma taxonomia. Os marketplaces NFT são Service. As posições DeFi são FinancialProduct. Os lançamentos de tokens são Cryptocurrency. Dividir schema por categoria de app habilita a elegibilidade para rich results por tipo. Article geral em tudo desperdiça a elegibilidade por completo.
O time-to-impact de CWV é o mais rápido em SEO
CWV é único em que a data de laboratório melhora imediatamente e a data de campo (CrUX) se atualiza dentro de 28 dias. A maioria do trabalho SEO tem uma janela de medição de 60-90 dias. As correções CWV mostram seu trabalho dentro de quatro semanas. Use isso ao priorizar planos de engagement para clientes que precisam de vitórias iniciais.
Construa destinos de contenido antes de implantar schema que apunte a ellos
Lançamos schema FAQPage com cssSelectors apontando para seções de /security/ que não estavam completamente populadas. Funcionou mas foi bagunçado. Melhor sequência: construa o destino, popule-o, depois faça deploy de schema que sinalize aos motores IA para extrair dele.
O takeaway de AB
A Magic Square foi o engagement mais limpo dos quatro porque os problemas eram táticos e as correções bem entendidas. O padrão de lazy-load do SDK de wallet, o padrão de cacheamento IPFS em CDN e o padrão de divisão de schema são todos coisas que desde então codificamos em módulos de auditoria de Crawlux.
O time-to-impact foi o destaque. A maioria do trabalho SEO tem uma janela de medição de 60-90 dias. O trabalho de CWV mostrou melhora de data de laboratório imediatamente e melhora de data de campo dentro da janela CrUX de 28 dias. A equipe pôde ver a mudança em suas próprias medições dentro de duas semanas.
O trabalho de schema seguiu um timeline mais longo (60-90 dias para impacto em ranking) mas o lift de citações AEO apareceu dentro de três semanas. Os motores IA re-crawleiam frequentemente. As melhorias de schema aparecem em taxas de citações muito mais rápido que em rankings do Google.
O que faríamos diferente
One thing.
Teríamos construído o hub de conteúdo /security/ antes do trabalho de schema em vez de junto a ele. O trabalho de schema assumiu que um destino existia para as entradas de FAQ de segurança. O destino se construiu em paralelo com o schema. Isso era trabalhável mas significou que o schema saiu ao vivo com algumas entradas de FAQ apontando para seções do hub de segurança que não estavam completamente populadas ainda. Sequenciar o hub primeiro teria significado lançamentos de schema mais limpos e uma experiência inicial mais polida.
Além disso, o engagement rodou limpo. As correções técnicas foram aplicações de livro-texto de padrões que funcionam. A equipe executou rápido. Os resultados foram mensuráveis.
Estávamos há um ano perseguindo melhorias de CWV sem progresso real. A TG3 corrigiu em duas semanas. O trabalho de schema foi enviado em cima e a mudança de taxa de citações em motores IA tem sido um canal real para nós.
Rode uma auditoria Crawlux grátis no seu site
A auditoria identifica quais problemas de schema, técnicos e AEO estão bloqueando seus rankings. O mesmo framework de diagnóstico que usamos na Magic Square.
Rodar auditoria gratuita →Playbooks relacionados
Guias pilares
RUN YOUR OWN AUDIT
Veja o que o Crawlux encontra no seu site.
Estes resultados vêm da mesma auditoria que você pode rodar grátis no seu próprio domínio. Turnaround de 60 segundos.
Primeira auditoria grátis · Sem cadastro · 60 segundos · Full PDF report