Web rápida sin obsesión: Core Web Vitals que sí importan

Una Core Web Vitals web bien trabajada no es la que presume de un 100 impecable en PageSpeed Insights como quien enseña abdominales en enero. Es la que carga lo importante sin hacer esperar, responde cuando el usuario toca, compra o despliega un menú, y no mueve los botones como si la pantalla tuviera hipo. Google mantiene tres métricas centrales para medir esa experiencia: LCP, INP y CLS, vinculadas respectivamente a carga, respuesta y estabilidad visual. Sus umbrales de referencia son claros: LCP en 2,5 segundos o menos, INP por debajo de 200 milisegundos y CLS inferior a 0,1.

La idea de fondo es menos romántica y más útil: una web rápida no se construye para seducir a una herramienta, sino para que una persona no abandone antes de leer, reservar, comparar o pagar. Google recomienda tener buenos Core Web Vitals para mejorar la experiencia y alinearse con lo que sus sistemas de ranking tienden a recompensar, pero también advierte que una puntuación perfecta perseguida solo por SEO puede no ser el mejor uso del tiempo. Vamos, que conviene afinar el motor, no dorar el salpicadero.

La velocidad que importa no siempre es la que luce mejor

Durante años, hablar de rendimiento web fue hablar de velocidad en abstracto. “La página va lenta”, “hay que optimizar”, “Google nos castiga”. Frases de comité, muchas veces lanzadas al aire con el mismo rigor que quien culpa a Mercurio retrógrado porque el checkout se cae. Los Core Web Vitals pusieron algo de orden en esa niebla: no miden toda la calidad de una web, pero sí tres síntomas bastante humanos. Cuánto tarda en aparecer lo principal. Cuánto tarda en reaccionar. Cuánto se mueve la interfaz cuando el usuario intenta hacer algo.

Eso cambia el enfoque. Una página puede abrir “rápido” en laboratorio y, aun así, ser torpe para el usuario real. Puede pintar un primer pantallazo aceptable, pero quedarse congelada cuando alguien intenta filtrar productos, abrir un acordeón, añadir al carrito o aceptar —con resignación medieval— el banner de cookies. También puede tener una home brillante, casi de escaparate de Apple, y perderlo todo en una ficha de producto cargada de scripts, vídeos, pop-ups, módulos de recomendación, reseñas embebidas y tres píxeles publicitarios peleándose por respirar.

La Core Web Vitals web sensata parte de una obviedad que se olvida demasiado: el usuario no navega en el MacBook del desarrollador, conectado por fibra, con la caché limpia y el navegador en estado virginal. Navega en un móvil de gama media, en un tren, con cobertura irregular, entre notificaciones, pestañas abiertas y batería cansada. El rendimiento no es una demo. Es barro.

Por eso, el dato de campo pesa tanto. El informe de Core Web Vitals de Search Console se basa en datos reales de uso, agrupa URL por estado, métrica y grupos de páginas similares, y trabaja con LCP, INP y CLS medidos a partir de usuarios reales. No es una lista exhaustiva de todas las URL indexadas ni sirve para diagnosticar quirúrgicamente cada página aislada, pero sí para detectar patrones de experiencia pobre en conjuntos relevantes del sitio.

LCP, INP y CLS: tres señales, tres problemas distintos

El Largest Contentful Paint, más conocido como LCP, mide cuándo se renderiza el elemento principal visible en la pantalla: una imagen hero, un bloque grande de texto, un vídeo o la pieza que da al usuario la sensación de que la página ya existe. No es “cuándo termina de cargar todo”, porque eso sería una trampa vieja. Una web moderna puede seguir descargando cosas durante un rato, como una cocina que sigue preparando platos, pero el comensal necesita ver algo sustancial pronto. Para Google, el objetivo recomendable es que el LCP ocurra en 2,5 segundos o menos para al menos el 75% de las visitas.

Aquí aparece una de las primeras confusiones. Optimizar LCP no significa solamente comprimir imágenes. A veces sí, claro: una imagen enorme subida a WordPress como si fuera un cartel de autopista puede hundir cualquier página. Pero el LCP también se ve afectado por el tiempo de respuesta del servidor, los recursos que bloquean el renderizado, la prioridad de carga del elemento principal, la forma en que se entrega el CSS, la cantidad de JavaScript inicial o el renderizado del lado del cliente. El problema rara vez vive en una sola habitación. Suele ocupar el piso entero.

El Interaction to Next Paint, INP, es la métrica que más ha cambiado la conversación reciente. Sustituyó a FID como Core Web Vital el 12 de marzo de 2024, porque FID medía solo una parte muy concreta de la primera interacción, mientras que INP ofrece una visión más completa de la capacidad de respuesta de la página durante la sesión. Esto es importante para ecommerce, medios, SaaS y webs con formularios: no basta con que la página aparezca; tiene que obedecer cuando se la toca. Una interfaz que tarda en abrir un menú o responder a un clic transmite algo peor que lentitud. Transmite desconfianza.

INP suele sufrir cuando el hilo principal del navegador está ocupado con JavaScript pesado, tareas largas, evaluación de scripts, renderizados complejos o árboles DOM demasiado grandes. Dicho en castellano de oficina: la web está intentando hacerlo todo a la vez y no escucha al usuario. Reducir el retraso de entrada, aligerar callbacks de eventos, dividir tareas largas y evitar que la carga inicial deje la página aparentemente visible pero funcionalmente atascada son medidas más útiles que rezar ante Lighthouse. Aunque, admitámoslo, hay quien ha probado cosas peores.

El tercer pilar, Cumulative Layout Shift, o CLS, mide la estabilidad visual. Es el responsable de esa escena irritante en la que vas a pulsar “comprar” y, de pronto, aparece un bloque publicitario, baja el botón y acabas tocando otra cosa. Una pequeña traición de píxeles. El objetivo recomendado es mantener CLS en 0,1 o menos para al menos el 75% de las visitas. Las causas habituales son imágenes sin dimensiones, anuncios o iframes sin espacio reservado, contenido inyectado dinámicamente y fuentes web que cambian el tamaño del texto al cargarse.

El error de mirar solo el semáforo

La obsesión con el verde ha hecho mucho daño. El informe marca “bueno”, “necesita mejorar” o “pobre”, y el cerebro humano, que no ha evolucionado para interpretar percentiles sino para huir de tigres, entra en modo alarma. Pero un color no cuenta toda la historia. Un ecommerce puede tener mal INP en fichas de producto por culpa de scripts de personalización, mientras que su blog vuela. Un medio puede tener buen LCP en artículos sencillos y un CLS desastroso en páginas con publicidad programática. Una web corporativa puede suspender en móvil por una única plantilla mal diseñada y, aun así, estar razonablemente bien en páginas de conversión.

La lectura madura consiste en cruzar métricas con negocio. No todas las URL pesan igual. Una landing con tráfico pagado y coste por clic alto no puede permitirse una experiencia torpe. Una página legal con tráfico mínimo quizá no merece una guerra técnica de tres semanas. Una ficha de producto con margen alto y visitas recurrentes sí. La velocidad, cuando se gestiona bien, se parece a la edición: cortar donde duele menos para que el conjunto respire mejor.

Datos de campo frente a laboratorio: la pelea que nadie debería ganar

El laboratorio sirve. Lighthouse, PageSpeed Insights, Chrome DevTools, WebPageTest y entornos similares ayudan a reproducir problemas, aislar causas y verificar mejoras. Sería absurdo despreciarlos. Pero el dato de laboratorio vive en una maqueta controlada: dispositivo simulado, red definida, condiciones repetibles. El dato de campo viene del mundo real, con su ruido, sus móviles viejos, sus redes malas, sus usuarios impacientes y sus sesiones desordenadas. Ambos pueden contradecirse sin que ninguno “mienta”.

Los datos de laboratorio se obtienen cargando una página en un entorno controlado, mientras que los datos de campo proceden de usuarios reales y reflejan dispositivos, redes y ubicaciones reales. Las herramientas de campo suelen usar el percentil 75, de modo que la evaluación no se hace con el usuario medio cómodo, sino con una parte suficientemente exigente de la distribución. Ahí está el matiz. Y el pinchazo para muchos informes bonitos.

Aquí es donde muchos proyectos se atascan. El desarrollador mira Lighthouse y dice: “Está bien”. Search Console dice: “No tanto”. El cliente mira PageSpeed y pregunta por qué en móvil sale un 62. El SEO abre otro informe. El CTO suspira. Alguien propone cambiar de hosting. Otro culpa al plugin de cookies. La reunión empieza a oler a café recalentado.

La forma razonable de trabajar no es elegir un bando, sino ordenar el diagnóstico. El dato de campo responde a la pregunta importante: qué viven los usuarios. El laboratorio ayuda a contestar la siguiente: por qué ocurre y cómo se arregla. Search Console enseña patrones; PageSpeed Insights ofrece una fotografía de URL; DevTools permite mirar la cascada de red, tareas largas, bloqueos del hilo principal y cambios de layout. CrUX, el Chrome User Experience Report, refleja cómo usuarios reales de Chrome experimentan destinos populares de la web, y sus datos alimentan herramientas de Google y el factor de experiencia de página en la búsqueda.

Search Console no es un bisturí, es un mapa

Conviene decirlo porque se malinterpreta a diario: el informe de Core Web Vitals en Search Console no está diseñado para decir con precisión quirúrgica qué le pasa a una URL concreta en cada momento. Agrupa páginas similares y muestra problemas por tipo de dispositivo, estado y métrica. También puede omitir URL si no hay suficiente volumen de datos. Para un sitio pequeño, esto puede ser frustrante: no aparece nada, o aparece tarde, o aparecen grupos que no coinciden con la arquitectura mental del equipo. Normal. El dato estadístico tiene sus manías.

Aun así, es un mapa útil. Si todas las fichas de producto fallan en móvil por LCP, se mira plantilla, imagen principal, servidor, CSS crítico y carga de recursos. Si los artículos fallan en CLS, toca revisar espacios reservados para anuncios, embeds, vídeos, newsletters incrustadas y fuentes. Si el problema es INP en páginas con filtros, comparadores o carritos, el sospechoso suele vestir de JavaScript.

La gracia está en no tratar el informe como una sentencia moral. Una web no es “buena” o “mala” porque un panel lo diga. Una web tiene cuellos de botella, prioridades, deuda técnica y decisiones de producto que a veces pesan más que el propio código. Meter un chat, un mapa, un sistema de reseñas, un tag manager con veinte etiquetas, un CMP de consentimiento, personalización, remarketing y un carrusel de ofertas puede parecer inocente en una hoja de ruta. En el navegador del usuario, todo eso pesa. Mucho. Como si a una bicicleta le colgamos tres maletas y luego nos sorprendemos de que no suba el puerto.

Cómo mejorar sin caer en la religión del 100

Una Core Web Vitals web optimizada empieza por lo obvio, aunque lo obvio tenga poco glamour. Para LCP, el primer paso es identificar cuál es el elemento LCP real en las plantillas críticas. No el que imaginamos. El real. En muchas páginas será la imagen principal; en otras, un titular, un bloque hero, un vídeo o incluso un contenedor que tarda demasiado en renderizarse por culpa del JavaScript. Una vez detectado, hay que darle prioridad: imagen en formato moderno, dimensiones correctas, compresión razonable, preload cuando proceda, caché, CDN si tiene sentido, servidor decente y CSS que no bloquee más de lo necesario.

El error clásico es optimizar miniaturas mientras el hero principal llega tarde. Como limpiar el felpudo con la casa ardiendo. También conviene desconfiar de la carga diferida mal aplicada. Hacer lazy load de la imagen que aparece arriba del todo es una manera elegante de pegarse un tiro en el LCP. El navegador necesita saber pronto qué recurso importa. Si se lo escondemos, no adivina. Bastante hace.

Para INP, el trabajo suele ser más áspero. Aquí no basta con comprimir una imagen y brindar. Hay que mirar scripts, dependencias, frameworks, hidratación, tareas largas, listeners, lógica de interacción y terceros. En WordPress, Shopify, PrestaShop, Magento o cualquier CMS vitaminado, muchas veces el problema no es “la web” en abstracto, sino el ecosistema de plugins, módulos y etiquetas añadidas con la alegría de quien llena un trastero. Cada script promete algo. Todos juntos piden peaje.

Reducir JavaScript innecesario, retrasar lo no crítico, dividir tareas largas, usar web workers cuando compense, simplificar componentes interactivos y revisar la carga de terceros puede mejorar la respuesta. Pero hay que medir. Desactivar cosas al azar, como quien apaga luces en una casa desconocida, puede romper analítica, consentimiento, pago o funcionalidades clave. Velocidad sí; sabotaje, no.

Para CLS, la disciplina suele ser más visual y menos épica: reservar espacio para imágenes, anuncios, iframes y embeds; declarar anchura y altura; cuidar las fuentes; evitar insertar bloques por encima del contenido ya cargado; no empujar botones ni formularios después de que el usuario haya empezado a interactuar. Los medios digitales conocen bien este infierno. También los ecommerce con banners promocionales, barras superiores, recomendaciones dinámicas y pop-ups que aparecen como vendedores demasiado entusiastas.

La mejora real suele venir de atacar plantillas, no páginas sueltas. Home, categoría, ficha de producto, artículo, landing, buscador interno, carrito, checkout. Cada familia tiene sus propios demonios. Medir por plantilla permite ahorrar tiempo y dinero. Arreglar una URL aislada para celebrar un pantallazo verde puede quedar bonito en una presentación, pero no transforma la experiencia de un sitio. Es maquillaje con iluminación cara.

SEO, conversión y reputación: el rendimiento también comunica

Los Core Web Vitals no son una varita mágica de posicionamiento. Google lo ha repetido con bastante claridad: la relevancia del contenido sigue siendo central, y una buena experiencia de página puede contribuir al éxito especialmente cuando hay varias páginas con contenido útil para una misma consulta. También recuerda que no existe una única señal de “page experience” y que Core Web Vitals convive con otros aspectos como HTTPS, experiencia móvil, exceso de anuncios, intersticiales intrusivos y claridad entre contenido principal y elementos secundarios.

Traducido al castellano de negocio: una web rápida ayuda, pero no salva contenido mediocre, arquitectura confusa, intención de búsqueda mal resuelta o producto débil. El SEO técnico no sustituye al criterio editorial ni comercial. Los Core Web Vitals eliminan fricción; no inventan demanda. Hacen que una buena página tenga menos obstáculos. Y eso ya es bastante.

En SEO, la velocidad funciona como higiene. Nadie entra en un restaurante porque los baños estén limpios, pero si no lo están quizá no vuelve. Una web que responde bien transmite solvencia. Una que se mueve, se congela o tarda en mostrar lo esencial genera una sospecha silenciosa: si esto falla antes de comprar, qué pasará después. El usuario quizá no sabe qué es INP, pero sabe perfectamente cuándo un botón parece de cartón piedra.

En ecommerce, esa percepción se convierte en dinero. Cada fricción añade duda. Un filtro que tarda, un carrito que no responde, una ficha que carga tarde, una imagen que salta, un checkout que parece respirar con dificultad. Nada de esto se vive como una métrica técnica. Se vive como desconfianza. Y la desconfianza no necesita argumentos; cierra la pestaña.

En medios y proyectos de contenido, el rendimiento afecta a lectura, páginas vistas, permanencia, publicidad y suscripción. Un artículo que carga tarde pierde lectores antes del primer párrafo. Un layout que se mueve por anuncios irrita. Un paywall o banner mal implementado puede destrozar la experiencia y, de paso, el CLS. La monetización no es enemiga de la velocidad, pero cuando se implementa a golpes puede parecerlo.

En sitios B2B, SaaS o servicios profesionales, el impacto es más discreto pero igual de relevante. Formularios que tardan, demos que se bloquean, páginas de pricing pesadas, scripts de tracking duplicados, landings con animaciones vistosas y rendimiento pobre. La web no grita “somos lentos”; murmura “quizá no somos tan fiables”. Peor.

La velocidad también se diseña

Hay una parte técnica evidente, pero el rendimiento empieza antes del código. Empieza en decisiones de diseño, contenido y negocio. Una home con vídeo de fondo, carrusel, animaciones, mapa, chat, testimonios, contador, pop-up, personalización, tipografía externa y cinco bloques hero alternativos no está “bien diseñada” si tarda en ser usable. Está diseñada contra el navegador. Y el navegador, pobre, hace lo que puede.

Diseñar para Core Web Vitals significa priorizar. Qué debe aparecer primero. Qué puede esperar. Qué interacción es crítica. Qué script aporta valor real. Qué elemento decorativo pesa demasiado. Qué imagen emociona y cuál solo rellena. La web rápida no siempre es minimalista, pero sí es honesta: no intenta cargar el escaparate, el almacén y el departamento legal en el primer segundo.

En programación web moderna, este debate se ha vuelto especialmente delicado con frameworks, renderizado del lado del cliente, hidratación y arquitecturas JavaScript pesadas. React, Vue, Angular, Next, Nuxt, Astro o soluciones híbridas pueden ofrecer experiencias excelentes o auténticos elefantes con zapatillas. La herramienta no absuelve. Un sitio estático mal construido puede ser lento; una aplicación compleja bien trabajada puede volar. La diferencia está en las decisiones: renderizado, partición de código, carga progresiva, caché, datos, componentes, terceros y criterio.

En CMS, el problema adopta otra forma. WordPress no es lento por naturaleza, igual que un coche no es lento porque tenga maletero. Pero se puede convertir en un desfile de plugins, constructores visuales, sliders, fuentes, shortcodes, píxeles y scripts cargados en todas las páginas aunque solo hagan falta en una. Shopify puede sufrir por apps. Prestashop y Magento, por módulos, temas y personalizaciones. Los tag managers, usados sin gobierno, son pequeños aeropuertos de JavaScript: entra de todo y nadie recuerda quién autorizó el vuelo.

La analítica también merece una frase aparte. Medir es imprescindible. Medirlo todo, duplicado y sin orden, no. Google Analytics, píxeles publicitarios, mapas de calor, herramientas de grabación, chats, tests A/B, afiliación, personalización, consent management platform… cada capa añade coste. Algunas valen la pena. Otras se quedaron ahí porque nadie se atrevió a borrarlas. En rendimiento web, el polvo también pesa.

La web rápida no necesita neurosis, necesita criterio

Los Core Web Vitals web que sí importan son los que conectan métrica y experiencia: LCP para mostrar pronto lo esencial, INP para responder sin torpeza y CLS para mantener la página quieta cuando el usuario actúa. No son el evangelio completo del SEO técnico, pero sí un termómetro bastante fiable de algo que Google, el negocio y el lector llevan años diciendo de formas distintas: una web debe respetar el tiempo de quien la usa.

La obsesión por el 100 es comprensible, incluso humana. Da placer ver el verde. Ordena el caos. Sirve para una captura en Slack y para una reunión tranquila. Pero el rendimiento serio no vive en la captura, vive en las plantillas críticas, en el móvil real, en el percentil 75, en el carrito que responde, en el artículo que no salta, en la imagen principal que aparece sin teatro, en el formulario que no se queda pensando como funcionario en agosto.

Una web rápida sin obsesión no renuncia a la ambición. Al contrario: deja de perseguir adornos técnicos y se concentra en lo que duele. Menos scripts inútiles, mejores prioridades de carga, imágenes tratadas con respeto, layouts estables, interacción ligera, datos de campo y decisiones que no confundan una herramienta con una persona. Porque el usuario no abre PageSpeed Insights antes de comprar. Abre la página. Espera. Toca. Mira. Decide. Y si la web le responde bien, quizá se queda. Ahí empieza todo.