Imagina una tienda online de moda con 80.000 visitas al mes, un ticket medio de gama media y una tasa de conversión que lleva un año estancada en el 1,1%. La web es bonita, el catálogo está bien curado y las campañas funcionan. El cuello de botella no está en el producto: la página de categoría tarda 4,8 segundos en mostrar el primer bloque visible en móvil. Cada décima de segundo por encima del umbral es una venta que se va sin que aparezca en ningún panel de marketing.
Resumen
La velocidad de carga decide la conversión porque define en cuántos visitantes la web llega a tiempo. Las tres palancas que mueve esta decisión son la métrica de pintado del primer bloque útil (LCP), la respuesta a la primera interacción del usuario (INP) y la estabilidad visual del layout durante la carga (CLS). Cada milisegundo ganado por debajo de 2,5 segundos en LCP correlaciona con caídas de rebote y subidas medibles en tasa de conversión, mientras un INP por encima de 200 ms o un CLS por encima de 0,1 destruyen confianza incluso en webs visualmente correctas. La diferencia entre una web rápida y una web lenta no la marca el diseño sino el orden con el que se cargan los recursos, el peso real de las imágenes y la calidad de la base técnica desde el primer día de desarrollo.
Cómo se rompe la conversión cuando una web tarda en cargar
Una página lenta no pierde visitas por aburrimiento, las pierde por fricción acumulada. El usuario llega desde un anuncio o desde un resultado orgánico, ve una pantalla en blanco durante un par de segundos, escucha un click táctil que no responde, ve cómo el botón principal salta de posición justo cuando iba a pulsarlo y, sin formular ninguna queja consciente, cierra la pestaña. Ese ciclo es invisible en el panel de marketing porque no genera evento, no genera bounce de los útiles y no genera comentario. Solo deja un hueco entre las impresiones que recibe la web y las sesiones que llegan al carrito.
En móvil esta pérdida es mucho más severa que en escritorio. La conexión es peor, el dispositivo procesa más lento, las distracciones compiten con la atención y la paciencia es menor. Una web que en escritorio carga en 1,8 segundos puede tardar 4,5 en un terminal medio con red móvil real. La consecuencia operativa es directa: el grueso del tráfico (que en la mayoría de sectores es móvil) está experimentando una web distinta a la que ve el equipo que la diseñó desde un MacBook conectado a fibra. Esa brecha es el primer agujero por donde se desangra la conversión.
El segundo agujero llega después de la primera pintura. Un usuario que llega a ver la página todavía puede perderse si el primer click no responde, si el menú se atasca al desplegarse o si el formulario tarda en aceptar la primera tecla. La fricción se convierte en desconfianza, y la desconfianza es letal en negocios donde el visitante decide en segundos si vale la pena dejar sus datos o tirar de tarjeta. Aquí no se trata de optimizar para una métrica abstracta: se trata de evitar que la web rompa la promesa visual con la que el usuario entró.
Qué mide Google realmente con Core Web Vitals
Google publica desde 2020 tres métricas centradas en experiencia real de usuario, conocidas como Core Web Vitals. Cada una mide un momento crítico del ciclo de carga e interacción y cada una tiene un umbral por encima del cual la página se considera lenta. Estos umbrales no son arbitrarios: vienen de estudios sobre cuándo un visitante pierde paciencia o pierde confianza en lo que está viendo. La definición oficial y actualizada para 2026 está documentada en la guía Web Vitals de Google.
LCP — Largest Contentful Paint. Tiempo que tarda en aparecer el elemento principal de la página (la imagen hero, el bloque destacado, el bloque de texto grande). El umbral bueno está en 2,5 segundos. Por encima de 4 segundos el LCP se considera deficiente. Esta métrica refleja la sensación de «la página ya está aquí» que retiene al usuario o le hace abandonar.
INP — Interaction to Next Paint. Tiempo que tarda la web en responder a cualquier interacción del usuario: un click, una pulsación de tecla, un tap. El umbral bueno está en 200 milisegundos. Sustituyó en 2024 a FID, que solo medía el primer input. INP refleja la sensación de «la web responde» durante toda la sesión, no solo en el primer contacto.
CLS — Cumulative Layout Shift. Cantidad de movimiento inesperado del layout durante la carga. El umbral bueno está en 0,1. Sube cuando una imagen sin dimensiones explícitas empuja el contenido al cargar, cuando un banner se inserta tarde y mueve el botón principal, o cuando un anuncio aparece y desplaza la lectura. CLS refleja la sensación de «esta web no es de fiar» que vuelve atrás al usuario.
Las tres métricas se miden con datos reales de campo (Chrome User Experience Report) en intervalos de 28 días. Eso significa que aprobar una vez en un test de laboratorio no es suficiente: lo que cuenta es el percentil 75 de los usuarios reales que pasan por la web durante un mes. Mejorar las métricas exige actuar sobre la experiencia mayoritaria, no sobre el caso ideal.
Una web que cumple los tres umbrales Core Web Vitals tiene un 70% más de probabilidad de retener al usuario que una web que falla en alguno, según los estudios oficiales recogidos en la documentación de web.dev sobre impacto en negocio.
Datos reales del impacto de la velocidad en el negocio
El vínculo entre velocidad de carga y conversión no es una intuición de agencia: hay estudios de marcas con tráfico significativo que lo han medido en condiciones reales. Los siguientes casos son públicos, citados por Google en su documentación oficial, y muestran qué tipo de mejora se puede esperar al actuar sobre Core Web Vitals.
Rakuten 24 optimizó una landing con tráfico relevante para mejorar los tres Core Web Vitals y la comparó por test A/B durante un mes contra la versión original. El resultado fue una subida del 33,13% en tasa de conversión, del 53,37% en ingresos por visitante y del 11,26% en ticket medio. El caso completo está documentado en el case study oficial de Rakuten en web.dev.
Vodafone Italia midió que una mejora del 31% en LCP se tradujo en un 8% más de ventas en su ecommerce. La cifra no procede de una estimación: procede de un test controlado documentado por el propio equipo técnico y publicado por Google.
Renault redujo el rebote y subió conversión midiendo y optimizando exclusivamente LCP en sus páginas de configurador, donde el primer bloque visual es decisivo para retener al usuario que llega buscando un modelo concreto.
Nykaa mejoró su LCP un 40% y reportó un 28% más de tráfico orgánico procedente de ciudades de segundo y tercer nivel, donde las conexiones móviles son más lentas y la diferencia entre rápido y lento decide quién entra y quién no.
La lectura honesta de estos datos no es «si optimizo Core Web Vitals voy a subir mi conversión un 33%». Cada negocio parte de un punto distinto, opera en un sector con su propia elasticidad y tiene un público con su propia tolerancia a la espera. La lectura útil es otra: cuando una marca con tráfico significativo se molesta en medir el impacto de la velocidad, encuentra cifras de doble dígito en conversión. Eso descarta dos posturas habituales: la de quien dice que «Core Web Vitals es marketing técnico que no mueve nada» y la de quien promete subidas precisas sin haber medido antes el caso concreto.
El patrón se repite en sectores muy distintos: ecommerce de moda, automoción, retail farmacéutico y media. La elasticidad varía, pero la dirección es la misma. Una web más rápida convierte más, casi siempre. La incógnita es cuánto en tu caso concreto, y para responderla hace falta medir antes de optimizar.
Cómo medir la velocidad real de tu web sin herramientas caras
Medir Core Web Vitals no requiere licencias ni consultoras. Google publica las herramientas oficiales y suficientes para diagnosticar cualquier web pública sin coste. El error más común en este punto es confundir la medición de laboratorio (un test puntual desde un servidor) con la medición de campo (usuarios reales pasando por la web durante semanas). Las dos importan, pero la que decide el ranking y la que refleja la experiencia real es la de campo.
PageSpeed Insights es la herramienta principal. Combina datos de laboratorio (Lighthouse, prueba puntual) y datos de campo (CrUX, percentil 75 de usuarios reales en 28 días). Da una nota por dispositivo (móvil y escritorio) y un diagnóstico de los recursos que están causando los problemas. Para un análisis útil, conviene probar al menos tres tipos de URL: la home, una página de categoría o servicio y una página final de conversión (ficha de producto, formulario de contacto, checkout).
Search Console aporta la dimensión histórica. El informe Core Web Vitals dentro de Search Console muestra qué URLs están en bueno, mejorable o deficiente, agrupadas por patrón, con la evolución en los últimos tres meses. Es la fuente correcta para detectar si la web ha empeorado tras una actualización o un cambio de plantilla.
Chrome DevTools (pestaña Performance e Insights) permite reproducir la carga simulando dispositivos móviles de gama media y conexiones 3G/4G reales. Es donde se ve qué recurso concreto está tirando del LCP hacia arriba o qué script de tercero está bloqueando el hilo principal y arruinando el INP.
Web Vitals extension es una extensión gratuita de Chrome publicada por el propio equipo de Google que muestra los tres CWV de la página activa en tiempo real. Útil para auditar páginas con sesión iniciada o entornos staging.
Con estas cuatro fuentes se construye un diagnóstico honesto: una foto de campo (Search Console + PSI), una explicación técnica (DevTools) y una verificación rápida en cualquier URL (Web Vitals extension). Si la situación de partida es muy mala, conviene pasar este diagnóstico por una auditoría SEO básica que ordene por impacto los hallazgos en lugar de quedarse en la lista plana de avisos.
Optimizaciones que mueven la conversión, no solo la métrica
Subir nota en PageSpeed no es el objetivo; el objetivo es retener más visitantes y convertir más. Hay optimizaciones que mejoran la métrica sin mover la conversión (porque actúan sobre páginas con poco tráfico o sobre métricas técnicas que el usuario no percibe), y hay otras que mueven directamente el comportamiento del usuario porque atacan los momentos críticos del ciclo de compra. Estas son las que vale la pena priorizar.
Para mover LCP: comprimir y servir imágenes hero en AVIF o WebP con dimensiones explícitas, precargar las fuentes principales (preload hint), optimizar el tiempo de respuesta del servidor (TTFB por debajo de 600 ms) y evitar redirecciones encadenadas entre dominio y URL final. En WordPress, una caché de página decente y un CDN gratuito (Cloudflare en plan free es suficiente para arrancar) bajan el LCP de forma inmediata sin tocar código.
Para mover INP: fragmentar tareas largas de JavaScript (dividir scripts pesados en chunks que no bloqueen el hilo principal más de 50 ms), auditar y reducir scripts de terceros (chats, píxeles, widgets de reseñas) cargándolos en defer o solo cuando el usuario interactúa, y eliminar listeners innecesarios en el menú móvil. Aquí el atajo no existe: hay que ir uno por uno a los scripts cargados en la home y decidir cuáles son negociables.
Para mover CLS: declarar siempre ancho y alto en imágenes y vídeos (incluso los responsive con srcset), reservar el espacio de banners y consent banners antes de que carguen, evitar inserciones de bloques desde scripts tardíos y cuidar especialmente las cabeceras flotantes en móvil (un menú que aparece tras 200 ms desplaza todo lo de debajo y arruina el CLS de la primera pantalla).
El error de muchos rediseños es atacar las tres métricas en paralelo con la misma intensidad. La realidad operativa es que en la mayoría de PYMEs el LCP es lo que más mueve la conversión, el INP es lo segundo (especialmente en webs con carrito o formularios largos) y el CLS lo tercero. Atacar primero el LCP en las páginas con más tráfico y conversión suele ser la decisión con mayor retorno por hora invertida.
Este tipo de trabajo técnico está integrado en cualquier proyecto serio de diseño web orientado a conversión de Advanze, no como una optimización a posteriori sino como un requisito desde el primer prototipo. Una web pensada lenta y optimizada después siempre rinde menos que una web diseñada rápida desde la primera maqueta.
Si tu web ya está hecha y sospechas que la velocidad está dejando ventas sobre la mesa, una auditoría técnica te dice exactamente dónde están los frenos y cuánto retorno potencial hay en cada uno.
Cómo priorizar dónde acelerar primero
Una web típica de PYME tiene entre 30 y 300 URLs únicas, y no todas merecen la misma atención. Acelerar a la vez la home, las 40 páginas de blog, las 25 fichas de servicio y los 12 formularios de contacto es la forma más rápida de gastar el presupuesto sin mover la conversión. La priorización correcta sigue una matriz simple de impacto contra esfuerzo, aplicada sobre los datos reales de la web.
Paso 1: identificar las URLs críticas. En Google Analytics 4 o en la herramienta de medición activa, listar las 10-15 URLs que concentran el grueso del tráfico de entrada y de la conversión final. En la mayoría de webs esto es la home, dos o tres páginas de categoría/servicio y la página de contacto o checkout. Estas son las que mueven el resultado del negocio si su velocidad mejora.
Paso 2: diagnosticar el LCP y el INP en cada una. Pasar cada URL crítica por PageSpeed Insights (versión móvil) y anotar el LCP, el INP y el CLS de campo. Si Search Console marca alguna URL crítica como deficiente, esa es prioridad máxima.
Paso 3: estimar esfuerzo. Cada problema técnico tiene una dificultad distinta. Comprimir imágenes y activar caché es bajo esfuerzo. Reescribir el menú móvil para que no bloquee el hilo principal es medio. Cambiar de hosting compartido a uno con NVMe y HTTP/3 es alto. La estimación honesta evita meterse en proyectos de seis semanas sin necesidad.
Paso 4: cruzar impacto y esfuerzo. Las optimizaciones de alto impacto y bajo esfuerzo se ejecutan primero, sin discusión. Las de alto impacto y alto esfuerzo se planifican como sprint dedicado. Las de bajo impacto y bajo esfuerzo se hacen en lotes para evitar dispersión. Las de bajo impacto y alto esfuerzo se descartan o se aplazan al rediseño.
Paso 5: medir 21-28 días después. Los datos de campo se actualizan en ventanas de 28 días. Tocar y medir al día siguiente no informa de nada útil. La paciencia es parte del método: la mejora real solo se confirma cuando el percentil 75 de usuarios reales refleja el cambio.
Este patrón de priorizar por impacto en conversión y no por nota en PageSpeed es el que diferencia una optimización útil de una optimización cosmética. Para validar que el impacto realmente está moviendo el negocio (y no solo la métrica), se cruza con eventos GA4 desde una capa de analítica web bien configurada. Sin esa medición, cualquier mejora queda sin atribuir y la siguiente decisión vuelve a ser una intuición.
Errores comunes que ralentizan una web sin que se note
Algunas decisiones aparentemente pequeñas son las que destruyen Core Web Vitals en webs visualmente bien hechas. Conocerlas evita meses de optimización sobre síntomas en lugar de causas.
La imagen principal de la home en JPG sin comprimir, de 1,8 MB, sin dimensiones declaradas y sin formato moderno. Es la causa número uno de LCP en deficiente. Convertir a AVIF/WebP y declarar dimensiones suele bajar el LCP entre 800 ms y 1,8 segundos.
Los sliders cargan tres o cinco imágenes hero a la vez, todas pesando lo mismo que pesaría la única que el usuario va a ver. Además generan reflows constantes que disparan CLS. Cuestan caro y casi nadie pasa más allá del primer slide.
WordPress con 32 plugins activos casi siempre arrastra scripts duplicados, hojas de estilo cargadas en todas las páginas aunque solo las use una y eventos jQuery que bloquean el hilo principal. Reducir a los 10-15 imprescindibles suele bajar el INP un 30%.
El banner de consent que carga después de la primera pintura, ocupa la mitad de la pantalla y desplaza todo el contenido. Es responsable directo del 80% de los CLS deficientes en webs corporativas.
Una fuente externa de Google Fonts cargada en bloqueo del render añade entre 200 y 500 ms de LCP. Con preload, font-display swap y self-hosting el coste cae a casi cero.
Un hosting de 2,99€/mes con cientos de webs en el mismo servidor responde lento incluso con la web perfectamente optimizada. El TTFB por encima de 1 segundo es indicio claro y suele ser el suelo invisible que impide bajar el LCP por mucho que se trabaje el frontend.
Chat, píxel de Meta, Google Tag Manager con 40 etiquetas, widget de reseñas, mapa embebido y banner de promociones. Cada uno suma entre 50 y 200 ms al INP. Cargarlos en defer, lazy o solo bajo interacción del usuario suele recuperar todo el margen perdido.
El patrón común de estos errores es que ninguno se ve a simple vista. La web parece moderna, parece cuidada y parece rápida desde el ordenador del equipo de marketing. Pero el usuario real, con su móvil, su conexión y su impaciencia, ve algo muy distinto. La única forma de salir de este punto ciego es medir con datos de campo y diseñar el orden de carga de cada bloque desde el primer prototipo, no como capa de optimización a posteriori.
Cuando una web nace pensada para rendimiento, esos errores no aparecen: el hero se entrega ya optimizado, el menú móvil no bloquea el hilo principal, los plugins están auditados y el hosting es el adecuado al volumen real. Esa diferencia es lo que separa una web que convierte de una web que parece bonita.
Checklist accionable para empezar esta semana
Estos siete puntos se pueden ejecutar en una semana sin rediseñar la web y suelen recuperar la mayor parte del margen perdido en Core Web Vitals:
- Pasar la home y dos URLs clave por PageSpeed Insights en versión móvil y anotar LCP, INP y CLS de campo. Esa es la base contra la que medir cualquier mejora.
- Comprimir y convertir a WebP/AVIF las cinco imágenes más pesadas de cada plantilla, declarando ancho y alto explícitos en HTML.
- Auditar plugins activos y desactivar los que no son imprescindibles, prestando atención a los que cargan JS en todas las páginas aunque solo se usen en una.
- Mover los scripts de terceros a defer o cargarlos bajo interacción (chat al primer click, mapa al primer scroll, widget de reseñas en lazy load).
- Servir tipografías propias con preload + font-display swap y eliminar la carga externa de Google Fonts en bloqueo de render.
- Activar caché de página y CDN gratuito (Cloudflare basta para empezar) y verificar TTFB por debajo de 600 ms desde España.
- Programar verificación en Search Console a los 28 días para confirmar que los cambios se reflejan en datos de campo y no solo en el laboratorio.
Este checklist no sustituye una optimización profunda, pero sí filtra el 80% de los problemas habituales en webs de PYME. Si tras ejecutarlo el LCP sigue por encima de 4 segundos o el INP por encima de 500 ms en URLs críticas, el problema no es de optimización superficial: es de arquitectura técnica, de hosting o de la propia plantilla, y conviene plantearse si compensa seguir parcheando o abordar un diseño web pensado desde cero para rendimiento.
La decisión entre seguir optimizando una base débil o reconstruir bien tiene un componente de coste, otro de tiempo y otro de riesgo. El criterio honesto es comparar el coste acumulado de optimizaciones puntuales durante 12 meses contra el coste de un proyecto único bien hecho. Hay casos donde optimizar gana y casos donde reconstruir gana; sin medir, cualquier respuesta es ideológica. Cuando el balance se inclina hacia rehacer, conviene revisar antes la decisión entre plantilla y desarrollo a medida para no repetir los mismos cuellos de botella en la siguiente versión.
Preguntas frecuentes
¿Cuánto debe tardar en cargar una web para considerarla rápida?
El umbral oficial de Google para considerar una web rápida es 2,5 segundos en LCP (Largest Contentful Paint) medido en el percentil 75 de usuarios reales. Por debajo de 2 segundos en móvil real es claramente competitivo y por encima de 4 segundos se considera lento. El número en escritorio puede ser mejor, pero el que decide es el de móvil porque ahí está la mayor parte del tráfico en casi todos los sectores.
¿La velocidad de carga afecta al SEO o solo a la conversión?
Afecta a ambas cosas. Google usa Core Web Vitals como uno de los factores de ranking dentro de su sistema de page experience desde 2021, por lo que una web lenta tiene menos probabilidad de aparecer alto en resultados orgánicos y, por tanto, encaja directamente en cualquier estrategia de posicionamiento orgánico bien planteada. Y los usuarios que llegan a una web lenta convierten menos. El doble impacto es lo que hace que la velocidad sea probablemente la palanca con mayor retorno por hora invertida cuando una web ya tiene buen contenido.
¿Tener una buena nota en PageSpeed Insights garantiza más ventas?
No directamente. La nota de PageSpeed combina varias métricas y puede subir con optimizaciones que el usuario apenas percibe. Lo que mueve ventas es la experiencia real: LCP por debajo del umbral en las páginas de mayor tráfico y conversión, INP que responda al primer click y CLS que no mueva botones bajo el dedo del usuario. La nota es un proxy útil para diagnosticar, pero no es el objetivo final.
¿Cuánto tiempo tarda en notarse una mejora de velocidad en las métricas?
Los datos de campo de Search Console y PageSpeed Insights se actualizan en ventanas de 28 días, así que el primer cambio visible suele aparecer entre la tercera y la cuarta semana tras desplegar la mejora. El impacto en conversión y rebote puede notarse antes en Google Analytics, dentro de las primeras 1-2 semanas, especialmente si la mejora afecta a páginas con tráfico significativo.
¿Vale la pena cambiar de hosting para mejorar la velocidad?
Vale la pena cuando el TTFB (tiempo de respuesta del servidor) está por encima de 800 ms-1 segundo medido desde España. En ese caso, optimizar el frontend tiene un techo bajo porque el problema está en la base. Si el TTFB ya está por debajo de 400-500 ms, el hosting no es el cuello de botella y conviene atacar imágenes, scripts y plugins antes de migrar.
¿Una web sobre WordPress puede ser igual de rápida que una hecha a medida?
Sí, con criterio. Un WordPress bien montado (theme ligero, plugins auditados, caché bien configurada, imágenes optimizadas y hosting adecuado) puede aprobar Core Web Vitals con holgura. El problema habitual no es WordPress en sí, sino la combinación de theme cargado, decenas de plugins acumulados y hosting compartido. La diferencia entre rápido y lento en WordPress no la marca el CMS, la marca el cuidado técnico de quien lo configura.
Convierte la velocidad en una ventaja medible
Una auditoría técnica honesta te dice exactamente cuánta conversión está dejando sobre la mesa tu web actual y cuál es el orden correcto para recuperarla. Sin promesas vagas, sin trabajos innecesarios y con un plan ajustado a tu sector.