Performance VTEX: como alcanzar Lighthouse 90+ en la practica
Alcanzar Lighthouse 90+ en una tienda VTEX es posible, pero requiere trabajo tecnico intencional. La plataforma, especialmente en Store Framework, tiende a generar bundles pesados por la naturaleza del sistema de apps. Cada app instalada agrega JavaScript al bundle, y tiendas con muchas apps facilmente superan 1MB de JS comprimido. Esta guia presenta tecnicas practicas probadas en tiendas reales para elevar los scores de Lighthouse sin sacrificar funcionalidades.
Auditoria de apps instaladas
El primer paso es auditar todas las apps instaladas. Ejecuta vtex list en el workspace de produccion para ver la lista completa. Para cada app, pregunta: esta app aun se usa? Existe alternativa mas liviana? El beneficio justifica el impacto en el bundle? Apps de terceros son los mayores culpables. Reviews que cargan frameworks enteros, popups con jQuery, herramientas de personalizacion que agregan 300KB+ de JS. Remueve apps no esenciales y sustituye por alternativas mas livianas. En un caso real, remover 5 apps no utilizadas redujo el bundle en 400KB y mejoro el LCP de 4.2s a 2.1s.
Optimizacion de imagenes
Las imagenes son responsables de la mayor parte del peso de una pagina de e-commerce. En VTEX, usa el servicio de redimensionamiento nativo: agrega parametros de ancho y alto en la URL de la imagen (?width=800&height=600). Configura lazy loading en todas las imagenes debajo del fold. La imagen hero debe tener preload via tag link rel=preload en el head. Define width y height explicitos en todos los elementos img para evitar CLS. Usa formatos modernos: el CDN de VTEX soporta conversion automatica a WebP. Para banners, usa picture con srcset para servir tamanos diferentes por breakpoint.
Fuentes y CSS
Fuentes custom sin configuracion adecuada causan flash de texto invisible (FOIT) o flash de texto no estilizado (FOUT), impactando LCP y CLS. Configura font-display: swap en todas las @font-face. Haz preload de las fuentes criticas con link rel=preload as=font crossorigin. Limita el numero de pesos y estilos: cada variacion agrega 20-50KB. Para CSS, evita estilos inline en bloques. Usa CSS Handles eficientemente, sin selectores profundamente anidados. Remueve CSS de apps desinstaladas que puede permanecer en el bundle por cache.
JavaScript y hydration
El mayor desafio de performance en Store Framework es el JavaScript. La hydration completa de React en el client significa que todo el HTML renderizado en el servidor necesita re-procesarse en el browser. Para mitigar: usa React.lazy con Suspense para componentes pesados debajo del fold. Evita useEffect con fetch en el montaje del componente. Prefiere datos del servidor via GraphQL con cache. Configura defer en scripts de terceros (analytics, chat, pixels). Retrasa la carga de componentes interactivos hasta la interaccion del usuario. Para scripts de GTM, usa la estrategia de carga post window load.
Cache y CDN
VTEX tiene una capa de cache en el edge que necesita configuracion correcta. Para paginas de categoria y busqueda, configura cache de pagina con duracion adecuada (5-15 minutos es buen estandar). Para APIs GraphQL, usa la directiva @cacheControl con maxAge y scope PUBLIC para datos que no dependen del usuario. Headers de cache en assets estaticos deben tener max-age largo (1 ano) con fingerprinting en el nombre del archivo. Monitorea cache hits vs misses. Un hit ratio debajo de 80% indica problemas de configuracion.
Monitoreo continuo
Performance no es un proyecto con inicio y fin. Es un proceso continuo. Configura alertas de Core Web Vitals en Search Console. Ejecuta Lighthouse CI en cada deploy. Monitorea Real User Metrics (RUM) con web-vitals integrado a GA4. Compara metricas de campo (CrUX) con metricas de lab (Lighthouse) mensualmente. Cuando instales una nueva app, mide el impacto antes y despues. Define un budget de performance: tamano maximo del bundle, LCP maximo aceptable, CLS cero. Si una nueva feature supera el budget, optimiza antes de ir a produccion.
El camino headless: cuando optimizar no alcanza
Si la tienda tiene decenas de apps, el bundle supera 1.5MB, y cada optimizacion puntual genera retorno marginal, es hora de considerar el camino headless. Dos opciones: migrar a FastStore (frontend Next.js manteniendo backend VTEX) o adoptar deco.cx como capa de frontend independiente. En ambos casos, el resultado es Lighthouse 90+ consistente sin necesidad de optimizar app por app. El backend VTEX sigue intacto. Solo la capa de presentacion cambia. La inversion es mayor que optimizacion puntual (USD 6.000-16.000 para reconstruir el frontend), pero el resultado es sustentable a largo plazo. Para proyectos VTEX nuevos en 2025, comenzar con FastStore desde el inicio evita acumular deuda tecnica de performance.