Menú

Hablemos

Blog

Core Web Vitals: paso a paso antes de vender online

Core Web Vitals para fabricantes con canal directo: audita ficha, listado y pedido antes de abrir mercado online. Criterio real desde Sabadell.

Core Web Vitals: paso a paso antes de vender online
Imagen generada con OpenAI

Los Core Web Vitals son tres métricas de Google (LCP, INP y CLS) que miden si una página carga el contenido principal a tiempo, responde al clic y no salta mientras se usa. Un fabricante con canal directo debe auditarlas en ficha de producto, listado B2B y formulario de pedido antes de abrir mercado online: si esas URLs fallan en móvil, el catálogo no convierte y el anuncio paga visitas que rebotan. El criterio es de operación, no de marketing: primero las páginas que venden.

Qué miden los Core Web Vitals en una web de fabricante

No son una nota de diseño. Son tres lecturas de lo que le pasa a alguien que entra con el móvil desde el polígono, el almacén o el coche.

LCP marca cuándo aparece el bloque grande: la foto del SKU, la tabla de medidas o el héroe. Si tarda, el comercial vuelve al PDF. INP mide si el clic en “solicitar oferta”, en el filtro de familia o en el selector de acabado responde o se queda mudo. CLS mide si la página salta: el botón se mueve, la tarifa se corre, el formulario pega un brinco cuando carga el banner.

El canal directo ya existe: delegado, teléfono, email, a veces un PDF. Abrir mercado online es dejar que el cliente haga solo lo que hoy hace el equipo. Si la ficha no carga, ese salto no ocurre.

Un comercio de barrio en Sabadell o Barcelona sufre lo mismo en otra URL: la ficha, el horario, el pedido. En hostelería, la página de reservas. En un panel interno, el listado que el almacén abre veinte veces al día. La métrica no cambia. Cambia la URL que mueve dinero.

Si vais a encargar o rehacer la web, pedid que los Core Web Vitals se midan en esas URLs de venta, no solo en la home. Un Lighthouse verde en local no cuenta si el cliente entra por 4G.

Por qué medirlo antes de abrir el canal online

El error de calendario es habitual: se diseña el catálogo, se suben fotos de planta, se discute el precio público y, al final, “ya miraremos la velocidad”. Luego el primer mes de campañas enseña lo que ya estaba. La ficha tarda. El filtro se atasca. El formulario se mueve al cargar el chat.

Antes de abrir mercado el fabricante suele tener tres piezas. Un listado B2B con familias, referencias y, a veces, tarifa por cliente. Una ficha con foto, datos técnicos y descargables. Un formulario o un checkout corto para muestra, pedido mínimo o solicitud de oferta. Esas tres URLs son el producto. La home es el recibidor.

¿De qué sirve un anuncio a “máquinas de envasado” si la landing tarda en pintar la foto y el botón de contacto? El usuario no espera. El comercial tampoco, cuando consulta una referencia desde el almacén.

Abrir canal online multiplica el peso: más fotos, más variantes, más scripts, a veces un visor o un stock en vivo. Si no medís ahora, no tenéis línea base. Más adelante no sabréis si el problema es el héroe nuevo o el widget que alguien pegó porque el ERP ya lo tenía.

Paso a paso para auditar Core Web Vitals sin teatro

No hace falta un comité. Hace falta un listado de URLs, Search Console y una hora en móvil real.

Search Console o una prueba suelta

PageSpeed Insights sirve para ver una URL concreta. No sirve para decidir si “la web está bien”. Google reporta con datos de campo cuando hay tráfico suficiente. Search Console, informe de señales web, os dice qué plantillas fallan de verdad: móvil, 28 días, percentil 75. Eso es el suelo.

Si aún hay poco tráfico, no inventéis un aprobado. Medid laboratorio en las URLs de venta, en 4G y en un Android mediocre. Anotad LCP, INP, CLS, fecha, URL y dispositivo. Sin ese cuaderno, cada reunión reabre el mismo debate.

Las tres URLs que importan

  1. Una ficha representativa: foto real, PDF, tabla de medidas. No la SKU de demostración vacía.
  2. Un listado o buscador de familia: el que usaría un distribuidor para filtrar por material o diámetro.
  3. El formulario de pedido, muestra o oferta: el clic que hoy hace el comercial por teléfono.

Luego, si queda tiempo, la home y una landing de campaña. No al revés. En un catálogo B2B se decide en la ficha. En hostelería con reservas, en la ficha del local y el motor. Mismo método, otra URL. Anotad también chat, mapa, píxel, visor y fuentes. Muchas veces el LCP no es el servidor: es una imagen enorme y tres scripts que nadie pidió.

Criterio de decisión: qué tocar primero

El criterio no es sacar 100 en Lighthouse. Es dejar fuera de rojo las URLs que venden, en móvil, con dato de campo cuando exista. El resto espera.

  1. Imagen o bloque que pinta el LCP en ficha: peso, formato, tamaño real, prioridad de carga. Si el héroe es un JPG de plató a resolución de cartel, no hay CSS que lo salve.
  2. JavaScript que bloquea el INP: filtros hinchados, sliders, chats en todas las URLs, visores que cargan aunque nadie los abra.
  3. CLS de plantilla: reserva de espacio para foto, cookies, barra de “te llamamos”, fuentes que empujan el título tarde.
  4. Servidor y caché solo cuando el HTML tarda de verdad. Si el TTFB es alto en ficha y en listado, entonces sí: hosting, PHP, base de datos, CDN. Ahí entra cloud y sistemas, no un plugin de moda.

Si el listado tira de un ERP en vivo y cada filtro espera a un endpoint lento, comprimir el logo no basta. Hay que decidir qué dato va en caché, qué se consulta al vuelo y qué se deja para el panel interno. Una integración con el ERP que pinta stock en cada visita anónima tumba el LCP igual que un héroe pesado.

Un comercio local en Cataluña con catálogo corto puede cortar en un sprint. Un fabricante con miles de referencias, fotos de planta y tarifas por cliente no. Criterio por plantilla: una ficha bien, un listado bien, y se replica. No se “optimiza la web” como si fuera un solo archivo.

Regla operativa para terceros: no entran en la ficha si no cambian una decisión de compra en esa pantalla. El chat puede vivir en contacto. El mapa, en delegaciones. El stock en vivo, si hace falta, en un fragmento cacheado.

Error habitual: home de escaparate y ficha lenta

Se encarga un rediseño. La home queda limpia, vídeo de planta, premio. PageSpeed de la home mejora. El equipo respira. Nadie abre la ficha del SKU más buscado en el móvil del almacén.

Esa ficha arrastra una galería de ocho fotos en original, un PDF embebido, una tabla copiada del ERP y un mapa de delegaciones que nadie pidió en producto. El LCP se va. El CLS aparece cuando carga el bloque de relacionados. El INP se muere en el selector de variante.

Otro error: medir solo escritorio porque “nuestros clientes son empresas”. El comercial entra con el teléfono. El dueño del taller también. Google mira móvil primero. El dispositivo de prueba es el malo, no el iMac de dirección.

Tampoco vale esconder el peso detrás de un login. La clave no perdona un JavaScript hinchado. Si el catálogo B2B vive detrás de usuario, Search Console verá poco: el cuaderno de laboratorio importa más.

En un panel interno pasa igual: el listado de pedidos se construye entero en el cliente y el clic tarda. Si ese panel alimenta stock o estado de pedido en el canal online, el peso os saldrá por la ficha pública.

Mantenimiento y medición cuando el catálogo crece

Arreglar una ficha no es el final. El catálogo crece: nueva familia, nueva campaña, nuevo plugin, nueva landing con vídeo. Sin mantenimiento, los Core Web Vitals vuelven a rojo en silencio.

  • Search Console, señales web, revisión mensual. Plantillas en rojo, no vanidad de nota media.
  • Tres URLs fijas (ficha, listado, pedido) medidas en laboratorio el mismo día del mes, mismo dispositivo. Guardad captura y cifra.
  • Cambio de plugin, píxel o héroe por staging. No “lo puse un momento”.
  • Peso de la ficha tipo: HTML, CSS, JS, imagen LCP. Si esa imagen engorda, se nota antes que el ranking.

Si hay campañas, el anuncio no se enciende sobre una URL en rojo. Es no pagar por un rebote.

En un comercio local de Barcelona con veinte referencias, esta cadencia es ligera. En un fabricante que empieza a publicar tarifas y stock, es la diferencia entre un catálogo usable y un PDF con dominio.

Preguntas frecuentes

¿Qué umbral de Core Web Vitals debo mirar en la ficha?

Mirad el percentil 75 en móvil, no la media ni el escritorio. LCP por debajo de 2,5 s, INP por debajo de 200 ms y CLS por debajo de 0,1 es el corte que usa Google. Si la ficha o el listado están en rojo, no discutáis la home. Arreglad la plantilla que vende y volved a medir a los 28 días de campo, o en laboratorio si aún no hay tráfico.

¿Sirve PageSpeed Insights para decidir si abro la tienda?

Sirve para diagnosticar una URL, no para dar el sí al canal online. Una nota alta en la home no dice nada del pedido. Usad PageSpeed en ficha, listado y formulario, y contrastad con Search Console cuando haya datos de campo. La decisión se toma sobre esas tres URLs, en móvil.

¿Si la home está en verde, ya puedo invertir en anuncios?

No. El anuncio aterriza en ficha o en landing de familia. Si esas URLs tienen LCP alto o un formulario que salta, pagáis el clic y perdéis la solicitud. Medid la URL de destino. Encended campaña cuando esa URL aguante en 4G.

¿Cada cuánto hay que volver a medir?

Una vez al mes las tres URLs fijas, y siempre que alguien toque plantilla, plugin, píxel o foto de producto. Cada familia nueva puede romper el LCP. Si no hay dueño de esa revisión, la métrica se pudre y el siguiente rediseño empieza otra vez desde cero.

¿Hace falta cambiar de CMS para mejorar los Core Web Vitals?

Casi nunca es el primer paso. WordPress o PrestaShop bien servidos, con imagen a tamaño y sin un cajón de plugins, llegan al corte. Cambiad de stack solo si el listado B2B o el pedido no caben, o si el servidor no da más.

En Chocola Studio (Sabadell) medimos las URLs que venden y dejamos un plan que el equipo puede mantener. Si vais a abrir canal online y queréis trabajar los Core Web Vitals en ficha, listado y pedido, escribidnos y lo vemos con datos, no con una nota de la home.

← Todos los artículos