Cómo Magic Square corrigió Core Web Vitals en 14 días y levantó el tráfico orgánico
Plataforma de descubrimiento de apps Web3 con LCP de 2.8s e INP de 380ms (ambos en rojo). SDK de wallet con eager-load en cada página. Imágenes IPFS sin cachear. La corrección fue táctica, quirúrgica y rápida.
Contexto del cliente
Magic Square es una app store Web3 y plataforma de descubrimiento. Los usuarios navegan dApps curadas en categorías de DeFi, NFT, gaming e infraestructura, con calificaciones de seguridad, info de auditorías y flujos directos de connect-and-use para cada app listada. El equipo había construido diferenciación real de producto alrededor del proceso de revisión de seguridad: cada app listada había sido auditada, respaldada por seguro y calificada.
El sitio era una aplicación Next.js con unas 800 páginas indexables: páginas de categoría, listings individuales de apps, páginas de revisión de seguridad, contenido del blog y el help center. La superficie de producto era sólida. El equipo de ingeniería era fuerte. El sitio cargaba lo suficientemente lento como para que nada de eso importara para SEO.
Magic Square vino a nosotros específicamente por Core Web Vitals porque habían estado monitoreando sus puntuaciones de PageSpeed Insights y viéndolas mantenerse en rojo a pesar de múltiples intentos de optimización. Se habían corrido auditorías Lighthouse, se habían desplegado correcciones y la data de campo (CrUX) seguía mostrando INP alrededor de 380ms y LCP alrededor de 2.8s en mobile. Ambos en rojo. Ambos bien dentro del territorio donde el algoritmo de Google estaba degradando activamente.
El equipo también se había estado preguntando por qué su tasa de citas en motores IA era más baja de lo que esperarían para una plataforma de curación y revisión. El tipo de sitio que los motores IA deberían amar (structured data sobre apps, calificaciones de seguridad, comparaciones) estaba siendo citado a tal vez un tercio de la tasa que sitios similares estaban logrando.
El problema
El problema de CWV se descomponía en tres contribuidores primarios.
Primero, la situación del SDK de wallet. Magic Square usa RainbowKit y wagmi para impulsar los flujos connect-and-use en cada listing de app. El SDK estaba siendo inicializado en cada mount de página incluyendo páginas de marketing, páginas de categoría, blog posts, el help center. Unos 250KB de JavaScript cargando en cada página incluso cuando el usuario no tenía intención de conectar una wallet. Esto costaba 200-300ms de TBT (Total Blocking Time) que se traducía directamente a puntuaciones INP.
Segundo, el problema de imágenes IPFS. Muchas de las apps listadas en Magic Square usan artwork alojado en IPFS para sus logos, banners y galerías de screenshots. El sitio estaba renderizando estos vía URLs directas de gateway IPFS. Los gateways IPFS públicos son no confiables para crawlers SEO y lentos para usuarios finales. El LCP de imagen estaba siendo martillado por la latencia de gateway IPFS; og:image fallaba al renderizar en previews sociales alrededor del 40% del tiempo.
Tercero, el ticker de la homepage. La homepage de Magic Square muestra un ticker que se actualiza en vivo con apps destacadas, alertas de seguridad y highlights de categoría. El ticker se cargaba e inicializaba inmediatamente en el mount de página con unos 80KB de JavaScript y una conexión WebSocket. Nada de esto era visible above the fold. Nada era necesario para el first paint. Pero estaba bloqueando el main thread durante la ventana crítica de INP.
Del lado del schema, Magic Square emitía schema Article genérico en todas las páginas de listing. Apps como Aave deberían haber sido Producto o FinancialProduct. Marketplaces NFT como OpenSea deberían haber sido Servicio. Las posiciones DeFi y productos de yield deberían haber sido FinancialProduct con propiedades específicas. El Article genérico era incorrecto para todos.
La auditoría
Auditoría de dos semanas. Los hallazgos de CWV eran la prioridad top clara porque eran factores de ranking de Google, no solo señales de motores IA.
Confirmamos que el SDK de wallet era el mayor contribuidor único a TBT e INP. Bundle analyzer mostró el SDK y sus dependencias representando alrededor del 60% del payload inicial de JavaScript en páginas de marketing. La corrección era directa: lazy-load del SDK detrás de un trigger de acción del usuario.
El problema de IPFS fue diagnosticado vía un trace de Performance en páginas de listing reales. Los fetches de imágenes desde gateways IPFS públicos estaban tomando 5-8 segundos en los peores casos. El cacheo de CDN con origin-pull desde un servicio de pinning confiable (Pinata) era el patrón correcto.
El problema del ticker era el menor contribuidor CWV pero aún material. Diferir su inicialización hasta después del first paint, más mover la conexión WebSocket a un bootstrap diferido con setTimeout, limpiaría el TBT restante.
El problema de schema era un work stream separado. Mapear cada tipo de app al schema correcto (Producto para items NFT, FinancialProduct para posiciones DeFi, Servicio para marketplaces, Cryptocurrency para lanzamientos de tokens) habilitaría tanto elegibilidad para rich results como lifts de citas en motores IA. Apilar Preguntas frecuentesPage con Speakable encima amplificaría el impacto AEO.
Secuenciamos el trabajo CWV-primero, schema-segundo. Las correcciones CWV eran críticas para ranking y podían enviarse en días. El trabajo de schema necesitaba más diseño (qué schema para qué tipo de app) y se beneficiaría de un sitio más rápido como fundación.
FREE WEB3 AUDIT
Consigue el mismo tipo de auditoría para tu sitio.
Ejecuta la misma auditoría Crawlux en tu dominio crypto. Primera auditoría gratis, informe PDF completo.
Primera auditoría gratis · Sin registro · 60 segundos · Full PDF report
El trabajo
Lazy-load de RainbowKit y wagmi
Refactorizamos el wallet provider en un componente wrapper que escucha por el click del botón de connect antes de cargar el SDK. Usamos dynamic imports de Next.js con ssr:false. Los botones de connect en todo el sitio fueron tagueados con un atributo data-connect-wallet que el componente wrapper escucha.
En páginas de marketing y páginas de contenido, el SDK ahora nunca carga en el mount inicial. En las páginas reales de interacción de app donde los usuarios intentan conectar, el SDK aún carga de forma eager porque el usuario está ahí para interactuar.
Este único cambio movió INP de alrededor de 380ms a bajo 200ms en las páginas afectadas. El Total Blocking Time cayó sustancialmente. El patrón ahora es estándar en páginas nuevas que el equipo de Magic Square construye.
Cachear imágenes IPFS a Cloudflare R2
Construimos un pipeline de upload que fetchea cada asset alojado en IPFS en la primera referencia, redimensiona a múltiples tamaños (1200x630 para OG, 800x600 para thumbnails de listing, 400x300 para previews de grid), sube a Cloudflare R2 con headers de cache agresivos y actualiza la referencia de la página para apuntar a la URL del CDN.
El hash IPFS se queda en la data subyacente (para permanencia y verificación). La URL del CDN es lo que se emite a crawlers y usuarios finales.
LCP mejoró sustancialmente dentro de días al poblarse el cache. La confiabilidad de renderizado de og:image pasó de alrededor del 60% (la tasa antigua del gateway IPFS) a efectivamente 100%. Los previews de Twitter, LinkedIn y Reddit todos empezaron a renderizar correctamente en todo el sitio.
Diferir el JS del ticker
Movimos la inicialización del ticker fuera del bundle principal y a una carga diferida con setTimeout que se dispara después del first paint. La conexión WebSocket se establece después de que la página esté completamente interactiva. El contenido above-the-fold renderiza sin impedimentos por la lógica del ticker.
Cambio más pequeño que la corrección del SDK de wallet pero eliminó el TBT residual que estaba previniendo que INP aterrizara limpiamente bajo 200ms. Con esto en su lugar, las puntuaciones INP en mobile se estabilizaron en el rango verde.
Schema dividido por tipo de contenido
Mapeamos el inventario de listings de app por categoría. Construimos schema por template con los tipos correctos: Product para marketplaces NFT e items, FinancialProduct para posiciones DeFi y protocolos de préstamos, Service para utilidades e infraestructura, Cryptocurrency para lanzamientos de tokens. Apilamos FAQPage con Speakable en cada página de listing. Los cssSelectors de Speakable apuntaban al bloque de calificación de seguridad, las entradas de FAQ y el resumen de auditoría.
Construimos la sección /security/ como un hub de contenido dedicado con su propio schema Preguntas frecuentesPage explicando el proceso de auditoría, cobertura de seguro y metodología de calificaciones de seguridad. Esto dio a los motores IA un destino estructurado para consultas tipo "¿la app X es segura?".
Resultados
El trabajo de CWV se envió en 14 días desde el kickoff. Dentro de esa ventana, tanto INP como LCP se movieron de rojo a verde en el percentil 75 en la data de campo de PageSpeed Insights.
El tráfico orgánico se levantó aproximadamente 60% en los 60 días siguientes al despliegue de CWV. El lift se concentró en consultas long-tail (nombres específicos de app más modificadores) que habían sido particularmente impactadas por la experiencia de página lenta.
Las citas en AI Overview aumentaron sustancialmente después de que el trabajo de schema se envió. ChatGPT y Perplexity ambos empezaron a citar a Magic Square en consultas de descubrimiento de app y seguridad donde previamente habían citado solo las apps subyacentes directamente.
La sección /security/ generó una porción desproporcionada del lift de conversión. La tasa de conversión (definida como el usuario clickeando a través para realmente usar una app listada) en páginas de contenido de seguridad vino 23% por encima del promedio del sitio. Los usuarios que aterrizaban en una página de revisión de seguridad estaban pre-calificados y convertían mejor.
5 lecciones tácticas que puedes aplicar
El lazy-loading del SDK de wallet es la corrección CWV Web3 de mayor ROI
RainbowKit, Web3Modal y wagmi cada uno cuesta 200-500KB de JS inicial. Eager-loadearlos en páginas de marketing donde los usuarios no tienen intención de conectar desperdicia todo el presupuesto de performance. Lazy-load detrás de un trigger de click y recupera 200-300ms de TBT instantáneamente.
Cachea las imágenes IPFS agresivamente. Siempre.
Los gateways IPFS públicos rutinariamente toman 5-8 segundos para servir imágenes. Twitter, LinkedIn y el crawler de Google todos tienen timeout antes de eso. Hosting dual: hash IPFS para permanencia (referenciado en contratos y metadata), URL del CDN para servir (en og:image, atributos src, schema). El plan gratuito de Cloudflare R2 cubre la mayoría de proyectos.
Schema dividido por tipo de contenido le gana al Article general
Una app store tiene múltiples tipos de contenido en una taxonomía. Los marketplaces NFT son Servicio. Las posiciones DeFi son FinancialProduct. Los lanzamientos de tokens son Cryptocurrency. Dividir schema por categoría de app habilita la elegibilidad para rich results por tipo. Article general en todo desperdicia la elegibilidad por completo.
El time-to-impact de CWV es el más rápido en SEO
CWV es único en que la data de laboratorio mejora inmediatamente y la data de campo (CrUX) se actualiza dentro de 28 días. La mayoría del trabajo SEO tiene una ventana de medición de 60-90 días. Las correcciones CWV muestran su trabajo dentro de cuatro semanas. Usa esto al priorizar planes de engagement para clientes que necesitan victorias tempranas.
Construye destinos de contenido antes de desplegar schema que apunte a ellos
Lanzamos schema Preguntas frecuentesPage con cssSelectors apuntando a secciones de /security/ que no estaban completamente pobladas. Funcionó pero fue desordenado. Mejor secuencia: construye el destino, poblalo, luego despliega schema que señalice a los motores IA a extraer de él.
El takeaway de AB
Magic Square fue el engagement más limpio de los cuatro porque los problemas eran tácticos y las correcciones bien entendidas. El patrón de lazy-load del SDK de wallet, el patrón de cacheo IPFS en CDN y el patrón de división de schema son todos cosas que desde entonces hemos codificado en módulos de auditoría de Crawlux.
El time-to-impact fue lo destacado. La mayoría del trabajo SEO tiene una ventana de medición de 60-90 días. El trabajo de CWV mostró mejora de data de laboratorio inmediatamente y mejora de data de campo dentro de la ventana CrUX de 28 días. El equipo pudo ver el cambio en sus propias mediciones dentro de dos semanas.
El trabajo de schema siguió un timeline más largo (60-90 días para impacto en ranking) pero el lift de citas AEO apareció dentro de tres semanas. Los motores IA re-crawlean frecuentemente. Las mejoras de schema aparecen en tasas de citas mucho más rápido que en rankings de Google.
Lo que haríamos diferente
One thing.
Habríamos construido el hub de contenido /security/ antes del trabajo de schema en lugar de junto a él. El trabajo de schema asumió que un destino existía para las entradas de FAQ de seguridad. El destino se construyó en paralelo con el schema. Esto era trabajable pero significó que el schema salió en vivo con algunas entradas de FAQ apuntando a secciones del hub de seguridad que no estaban completamente pobladas todavía. Secuenciar el hub primero habría significado lanzamientos de schema más limpios y una experiencia inicial más pulida.
Más allá de eso, el engagement corrió limpio. Las correcciones técnicas fueron aplicaciones de libro de texto de patrones que funcionan. El equipo ejecutó rápido. Los resultados fueron medibles.
Llevábamos un año persiguiendo mejoras de CWV sin progreso real. TG3 lo corrigió en dos semanas. El trabajo de schema se envió encima y el cambio de tasa de citas en motores IA ha sido un canal real para nosotros.
Ejecuta una auditoría Crawlux gratis en tu sitio
La auditoría identifica qué problemas de schema, técnicos y AEO están bloqueando tus rankings. El mismo framework de diagnóstico que usamos en Magic Square.
Ejecutar auditoría gratuita →Playbooks relacionados
Guías pilares
RUN YOUR OWN AUDIT
Mira lo que Crawlux encuentra en tu sitio.
Estos resultados vienen de la misma auditoría que puedes ejecutar gratis en tu propio dominio. Turnaround de 60 segundos.
Primera auditoría gratis · Sin registro · 60 segundos · Full PDF report