Core Web Vitals ecommerce: mejora ficha y checkout movil

No persigas una nota abstracta

Diagnostico

Core Web Vitals no es una puntuacion decorativa para presentar en una reunion. Google lo define como un conjunto de metricas de experiencia real: carga, respuesta a la interaccion y estabilidad visual. En ecommerce, esas tres cosas ocurren justo donde se decide la venta: ficha de producto, selector de variante, boton de compra, carrito y checkout movil.

La trampa habitual es abrir PageSpeed Insights, mirar una nota global y pedir a desarrollo que la suba. Ese enfoque mezcla sintomas, paginas y dispositivos. Una tienda necesita separar plantillas comerciales: categoria, ficha, carrito, checkout, blog y home. La pagina que mas trafico recibe no siempre es la que mas margen protege.

El objetivo operativo es otro: detectar que plantilla falla, que metrica la frena, que recurso o script la provoca y que impacto puede tener en ventas, SEO o soporte. Si una ficha tarda en mostrar la imagen principal, el problema no se arregla igual que un checkout que se queda bloqueado despues de tocar el campo de codigo postal.

• LCP mira cuando aparece el contenido principal, normalmente imagen o bloque hero de la ficha.
• INP mira si la pagina responde rapido cuando el comprador toca filtros, variantes, carrito o campos.
• CLS mira si la interfaz se mueve y cambia de sitio mientras el comprador intenta leer o comprar.

Empieza por las plantillas que venden

Priorizacion

Una auditoria ecommerce de Core Web Vitals empieza con una lista corta de URLs reales. No elijas solo la home. Selecciona una categoria con filtros, una ficha de bestseller, una ficha con muchas variantes, carrito, checkout si puede medirse sin exponer datos sensibles, y una pagina editorial que atraiga trafico organico.

Despues cruza esas URLs con Search Console, analitica y negocio. Una ficha con poco trafico pero alto margen puede merecer prioridad. Una categoria que concentra sesiones moviles puede explicar por que sube el coste de adquisicion. Un checkout que falla en INP puede no salir en los informes publicos de CrUX si no hay datos suficientes, pero seguir costando pedidos cada dia.

La pregunta no es que pagina tiene peor nota. La pregunta es que plantilla combina trafico, intencion de compra, margen y friccion. Esa matriz evita gastar dos semanas optimizando un articulo antiguo mientras el boton de anadir al carrito depende de cuatro scripts de reviews, chat, bundles y tracking.

LCP: imagen, precio y contenido inicial

Carga

En una ficha ecommerce, LCP suele estar ligado a la imagen principal del producto, el bloque de titulo y precio, o una cabecera demasiado pesada. Si ese contenido llega tarde, el comprador percibe que la tienda es lenta aunque el resto de la pagina acabe cargando despues.

La solucion no es borrar calidad visual. Es servir la imagen correcta, con dimensiones conocidas, formato moderno, prioridad solo cuando sea realmente el elemento principal y una version movil que no obligue a descargar un archivo pensado para escritorio. Tambien importa el servidor: cache, compresion, TTFB y exceso de redirecciones pueden retrasar todo lo demas.

Revisa especialmente sliders de producto, videos automaticos, apps de personalizacion, scripts de opiniones y banners promocionales por encima del pliegue. Si compiten con la imagen principal, el navegador puede dedicar recursos a elementos que no ayudan a decidir la compra.

• Define width y height en imagenes para evitar recalculo y saltos.
• Prioriza solo la imagen principal visible; no marques como critica toda la galeria.
• Comprueba fichas con variantes, porque algunas cargan otra imagen, otro precio o otro bloque de disponibilidad.
• Mide movil por separado: una ficha rapida en escritorio puede ser torpe en 4G y pantalla pequena.

INP: boton, filtros y checkout bajo presion

Interaccion

INP es especialmente delicado para tiendas online porque mide respuesta a interacciones. No basta con que la pagina aparezca rapido; tiene que reaccionar cuando el usuario toca talla, color, cantidad, filtro, anadir al carrito, cupon, envio o metodo de pago.

Los culpables suelen estar en JavaScript de terceros, listeners demasiado amplios, validaciones sin debounce, widgets que recalculan el DOM completo y tracking que se ejecuta justo despues de cada gesto. El usuario no ve el script, pero si siente el bloqueo: toca un boton, no pasa nada, vuelve a tocar, duplica una accion o abandona.

Una buena auditoria reproduce acciones comerciales, no solo carga la URL. En categoria, abre filtros y ordena. En ficha, cambia variantes, pulsa anadir al carrito y abre el minicart. En checkout, escribe direccion, aplica cupon y cambia envio. Cada interaccion lenta debe quedar asociada a un script, componente o dependencia concreta.

• Audita apps de reviews, chat, personalizacion, bundles, recomendaciones y etiquetas de publicidad.
• Mueve trabajo no critico fuera del gesto principal y separa tracking de la respuesta visual inmediata.
• Reduce re-renderizados de componentes grandes cuando solo cambia una variante o una linea del carrito.
• Prueba en movil real o emulacion restrictiva; el INP suele empeorar cuando el dispositivo tiene menos CPU.

CLS: cuando la pagina se mueve mientras compras

Estabilidad

CLS suele parecer un detalle estetico hasta que ocurre en el peor momento: un banner de descuento desplaza el boton, una barra de envio gratuito empuja el contenido, las reviews aparecen tarde, el selector de talla cambia de alto o una imagen sin dimensiones mueve media ficha.

En ecommerce, estos saltos afectan confianza y errores. Un comprador que iba a tocar una variante puede acabar pulsando otra cosa. Una politica de devoluciones que se carga tarde puede desplazar el precio. Un modulo de upsell que aparece dentro del carrito puede cambiar el total justo cuando el usuario esta revisando.

La reparacion requiere disciplina de layout: reservar espacio para imagenes, banners, widgets y mensajes; cargar fuentes sin movimientos bruscos; controlar popups; y decidir que elementos merecen aparecer antes de la compra. Si un modulo no aporta decision, no debe romper la estabilidad del area critica.

• Reserva espacio para carruseles, reviews, badges, mensajes de envio y modulos de pago aplazado.
• Evita inyectar banners sobre el boton de compra una vez que la ficha ya esta visible.
• Prueba con cookies nuevas y recurrentes: consent banners, popups y descuentos cambian el CLS real.
• Mira PDP y checkout despues de seleccionar variantes, porque ahi aparecen muchos saltos ocultos.

Plan de 14 dias para arreglar lo que importa

Ejecucion

Dia 1 y 2: elige plantillas y recoge datos. Usa Search Console para grupos de URLs, PageSpeed Insights para campo y laboratorio, y analitica propia para trafico, conversion, dispositivo y valor por plantilla. Si falta CrUX por bajo trafico, documenta la limitacion y no inventes conclusiones.

Dia 3 a 5: identifica causas. Para LCP, revisa imagen principal, prioridad, cache, servidor y recursos bloqueantes. Para INP, reproduce interacciones y localiza scripts largos. Para CLS, graba la carga y cambios de estado con banners, reviews, variantes, carrito y checkout.

Dia 6 a 10: aplica cambios pequeños y reversibles. Elimina o aplaza scripts no criticos, optimiza imagenes, reserva espacios, reduce apps duplicadas y controla banners. No mezcles diez cambios sin medicion, porque despues no sabras que arreglo movio la aguja.

Dia 11 a 14: valida y decide siguiente lote. Repite medicion en movil, compara eventos de negocio y deja monitorizacion semanal. Core Web Vitals se degrada cuando se instalan nuevas apps, se cambian themes, se anaden popups o se redisenan fichas sin revisar plantillas clave.

• Metrica tecnica: LCP, INP, CLS y TTFB como diagnostico.
• Metrica comercial: conversion movil, add-to-cart rate, abandono de checkout y revenue por plantilla.
• Metrica operativa: numero de scripts, peso de imagenes, apps activas y cambios de theme pendientes.
• Cadencia: revision semanal de plantillas criticas y revision obligatoria antes de escalar campañas.