Los Core Web Vitals son tres m\u00e9tricas que describen la experiencia de carga tal como la vive un usuario real. El LCP mide el tiempo de visualizaci\u00f3n del contenido principal. El CLS cuantifica los saltos de dise\u00f1o mientras la p\u00e1gina se construye. El INP mide el retardo entre una acci\u00f3n del usuario y la respuesta visible de la interfaz. <\/p>\n
El matiz que casi todo el mundo pasa por alto est\u00e1 en el m\u00e9todo de evaluaci\u00f3n. Google no retiene la media de tus visitas. Retiene el percentil 75<\/sup>, sobre una ventana deslizante de 28 d\u00edas, y separa el m\u00f3vil del escritorio. Dicho de otro modo, tres visitantes de cada cuatro deben pasar por debajo del umbral para que la m\u00e9trica se valide. Un sitio r\u00e1pido para la mayor\u00eda pero catastr\u00f3fico para el cuarto de usuarios en 4G degradada fracasa. <\/p>\n Esta mec\u00e1nica explica por qu\u00e9 tantos sitios muestran una puntuaci\u00f3n Lighthouse de 95 en local y permanecen en rojo en la Search Console. La puntuaci\u00f3n Lighthouse simula una visita en condiciones fijas. Los Core Web Vitals, en cambio, provienen del Chrome User Experience Report, la base de datos que Chrome alimenta con las visitas reales de los usuarios que han aceptado el env\u00edo de estad\u00edsticas. <\/p>\n Los umbrales oficiales de Google: LCP inferior o igual a 2,5 segundos, CLS inferior o igual a 0,1, INP inferior o igual a 200 milisegundos. Entre 2,5 y 4 segundos, entre 0,1 y 0,25, entre 200 y 500 milisegundos, la m\u00e9trica se clasifica como \u00abnecesita mejorar\u00bb. M\u00e1s all\u00e1, se clasifica como \u00abdeficiente\u00bb. Una URL solo se considera conforme si las tres m\u00e9tricas pasan simult\u00e1neamente. <\/p>\n<\/div>\n Estos tres indicadores tienen una historia cambiante. El FID, First Input Delay, fue reemplazado por el INP el 12 de marzo de 2024 porque solo med\u00eda el retardo antes del procesamiento de la primera interacci\u00f3n, lo que dejaba pasar interfaces realmente lentas. El INP hizo que miles de sitios WordPress sobrecargados de scripts pasaran inmediatamente a rojo cuando hasta entonces mostraban un FID c\u00f3modo. En las auditor\u00edas que realizamos desde entonces, es la m\u00e9trica que falla con m\u00e1s frecuencia. <\/p>\n El Largest Contentful Paint registra el momento en que el elemento de contenido m\u00e1s grande visible en la ventana inicial termina de mostrarse. En la pr\u00e1ctica, casi siempre se trata de la imagen de banner, un v\u00eddeo de fondo o el bloque de t\u00edtulo principal. Google eligi\u00f3 esta m\u00e9trica porque corresponde al momento en que el visitante estima que la p\u00e1gina est\u00e1 ah\u00ed. <\/p>\n Optimizar sin saber qu\u00e9 elemento se mide hace perder semanas. La pesta\u00f1a Performance de las DevTools de Chrome muestra un marcador LCP directamente en la l\u00ednea de tiempo, y PageSpeed Insights nombra el elemento en cuesti\u00f3n en la secci\u00f3n de diagn\u00f3sticos. En un sitio de presentaci\u00f3n, es el visual de hero en el 80 % de los casos. En una ficha de producto, es la imagen principal del producto. En un art\u00edculo de blog, a menudo es el t\u00edtulo H1 cuando la imagen destacada se carga en diferido. <\/p>\n Un LCP de 4,8 segundos no dice nada mientras no est\u00e9 desglosado. El primer segmento es el TTFB, el tiempo que tarda tu servidor en devolver el primer byte. El segundo es el retardo antes del descubrimiento del recurso, es decir, la diferencia entre la llegada del HTML y el momento en que el navegador comprende que debe descargar esa imagen. El tercero es la descarga del recurso. El cuarto es el retardo de renderizado, a menudo causado por un CSS o un JavaScript bloqueante. <\/p>\n Este desglose lo cambia todo, porque cada segmento requiere una correcci\u00f3n diferente. Un TTFB de 1,2 segundos se soluciona del lado del alojamiento y la cach\u00e9 del servidor, nunca comprimiendo im\u00e1genes. Un retardo de descubrimiento elevado se soluciona eliminando el lazy loading en el elemento LCP y a\u00f1adiendo un atributo La precarga merece una menci\u00f3n especial porque a menudo se emplea mal. Declarar una decena de recursos en Google recomienda un TTFB por debajo de 800 milisegundos para dejar un margen suficiente a los otros tres segmentos. En un WordPress compartido en PHP 7.4 sin cach\u00e9 de objetos, este umbral es inalcanzable independientemente del trabajo realizado en el front. Es el primer punto que verificamos durante una auditor\u00eda SEO t\u00e9cnica<\/a>, incluso antes de mirar el contenido. <\/p>\n El Cumulative Layout Shift mide los desplazamientos inesperados de los elementos durante la carga. Cada desplazamiento recibe una puntuaci\u00f3n que combina la fracci\u00f3n de la pantalla afectada y la distancia recorrida por el elemento. El CLS retenido es el de la peor ventana de sesi\u00f3n, una ventana de 5 segundos como m\u00e1ximo, con un intervalo de un segundo entre dos desplazamientos. <\/p>\n Nadie se queja de un CLS elevado, y eso es precisamente lo que lo hace peligroso. El visitante que apunta a un bot\u00f3n y hace clic en un banner publicitario porque la p\u00e1gina se ha movido no rellena un formulario de contacto para se\u00f1alarlo. Se va. En los sitios de comercio electr\u00f3nico que auditamos, un CLS superior a 0,25 acompa\u00f1a casi sistem\u00e1ticamente una tasa de abandono anormal en la ficha de producto. <\/p>\n Las im\u00e1genes sin atributos A continuaci\u00f3n vienen los contenidos inyectados din\u00e1micamente por encima de la l\u00ednea de flotaci\u00f3n: banners de consentimiento, barras de promoci\u00f3n, notificaciones de stock. Cada uno empuja todo lo dem\u00e1s hacia abajo. La soluci\u00f3n consiste en reservar la altura por adelantado con un contenedor de dimensi\u00f3n fija, o superponer el elemento en lugar de insertarlo en el flujo. <\/p>\n Las fuentes web constituyen la tercera causa. Cuando una fuente personalizada reemplaza la fuente de respaldo, las m\u00e9tricas tipogr\u00e1ficas cambian y el texto se reorganiza. La pareja Los iframes y las integraciones de terceros cierran la marcha. Un mapa, un reproductor de v\u00eddeo o un widget de opiniones de clientes que se dimensiona despu\u00e9s provoca un desplazamiento sistem\u00e1tico. Reservar la relaci\u00f3n de aspecto en CSS soluciona el problema sin tocar el servicio de terceros. <\/p>\n Un CLS limpio no se corrige despu\u00e9s, se concibe. En un sitio construido correctamente desde la maqueta, con relaciones de aspecto de imagen definidas y zonas reservadas para cada elemento as\u00edncrono, la m\u00e9trica cae naturalmente por debajo de 0,05.<\/p>\n<\/div>\n El Interaction to Next Paint mide el tiempo entre una interacci\u00f3n y la actualizaci\u00f3n visible de la pantalla. A diferencia del FID al que reemplaz\u00f3, observa todas las interacciones de la visita, no solo la primera, y retiene la m\u00e1s lenta o casi. En las p\u00e1ginas que superan unas cincuenta interacciones, el algoritmo ignora un caso extremo por tramo de cincuenta para evitar que un incidente aislado penalice el conjunto. <\/p>\n El INP se descompone en retardo de entrada, tiempo de procesamiento y retardo de presentaci\u00f3n. El retardo de entrada corresponde a la espera antes de que el navegador pueda siquiera empezar a procesar el clic, porque el hilo principal est\u00e1 ocupado con otra cosa. El tiempo de procesamiento es la duraci\u00f3n de ejecuci\u00f3n de tus gestores de eventos. El retardo de presentaci\u00f3n cubre el rec\u00e1lculo del dise\u00f1o y el renderizado. <\/p>\n En la gran mayor\u00eda de los casos encontrados en WordPress, el culpable es el retardo de entrada, y el culpable detr\u00e1s del culpable es un script de terceros. Un gestor de etiquetas que carga seis herramientas de seguimiento, un widget de chat en directo, un m\u00f3dulo de opiniones, un p\u00edxel publicitario: cada uno a\u00f1ade tareas largas que monopolizan el hilo principal. El visitante hace clic, no pasa nada durante 600 milisegundos, vuelve a hacer clic. <\/p>\n La primera medida consiste en hacer el inventario de los scripts de terceros y suprimir aquellos de los que nadie consulta los datos. En los sitios que retomamos en mantenimiento WordPress<\/a>, no es raro desactivar tres herramientas de seguimiento redundantes instaladas en \u00e9pocas diferentes por proveedores sucesivos. <\/p>\n La segunda consiste en diferir lo que se puede diferir. Un widget de chat no tiene ninguna raz\u00f3n para cargarse antes de la primera interacci\u00f3n del visitante. Cargarlo al primer scroll o al pasar el rat\u00f3n por el bot\u00f3n libera el hilo principal durante la fase cr\u00edtica. <\/p>\n La tercera consiste en dividir las tareas largas. Un gestor de eventos que ejecuta 400 milisegundos de c\u00e1lculo de un bloque debe devolver el control al navegador entre dos etapas, con <\/p>\n <\/a><\/p>\n Confundir estas dos fuentes es el error metodol\u00f3gico m\u00e1s extendido. Los datos de campo provienen de tus visitantes reales y constituyen la \u00fanica fuente utilizada por Google para la evaluaci\u00f3n. Los datos de laboratorio provienen de una simulaci\u00f3n ejecutada bajo demanda, en un entorno estandarizado. Los primeros dicen d\u00f3nde est\u00e1s. Los segundos dicen por qu\u00e9. <\/p>\n La herramienta muestra los dos bloques en la misma p\u00e1gina. Arriba, la evaluaci\u00f3n de la experiencia de usuario real, extra\u00edda del Chrome User Experience Report sobre 28 d\u00edas. Abajo, el diagn\u00f3stico Lighthouse y su lista de oportunidades. El bloque superior es el que cuenta para el posicionamiento. El bloque inferior es el que te dice qu\u00e9 corregir. <\/p>\n Una p\u00e1gina con poco tr\u00e1fico no tiene suficientes visitas para alimentar el informe. PageSpeed Insights pasa entonces a los datos del dominio completo, lo que oculta totalmente el comportamiento de la URL probada. Una ficha de producto lenta puede as\u00ed mostrar un verde tranquilizador heredado de la p\u00e1gina de inicio. <\/p>\n El informe Se\u00f1ales web esenciales agrupa las URLs por similitud de estructura y se\u00f1ala los grupos en fallo. Es la herramienta que permite comprender que un problema proviene de una plantilla y no de una p\u00e1gina. Cuando 240 fichas de producto aparecen en el mismo grupo en rojo, la correcci\u00f3n se hace una vez en la plantilla y cubre el conjunto del cat\u00e1logo. Este razonamiento por plantilla es central en un proyecto de SEO e-commerce<\/a>, donde el volumen de URLs hace imposible cualquier correcci\u00f3n unitaria. <\/p>\n Cuenta 28 d\u00edas despu\u00e9s de una correcci\u00f3n para ver la Search Console pasar a verde. La ventana deslizante del informe integra progresivamente las nuevas visitas. Validar una correcci\u00f3n se hace en laboratorio en una hora, confirmarla sobre el terreno lleva un mes. <\/p>\n<\/div>\n La biblioteca oficial web-vitals de Google permite recopilar las tres m\u00e9tricas directamente en el navegador de tus visitantes y enviarlas a tu herramienta de an\u00e1lisis. El inter\u00e9s es segmentar por tipo de dispositivo, por navegador, por p\u00e1gina y por pa\u00eds, lo que el informe agregado no permite. En un sitio multiling\u00fce que sirve Andorra, Francia y Espa\u00f1a, esta segmentaci\u00f3n revela a veces que el problema se limita a una zona geogr\u00e1fica mal cubierta por el CDN. <\/p>\n WordPress no es lento por naturaleza. Se vuelve lento por acumulaci\u00f3n: un tema gen\u00e9rico cargado de funcionalidades no utilizadas, treinta extensiones de las cuales doce inyectan su CSS en todas las p\u00e1ginas, un constructor de p\u00e1ginas configurado por defecto, un alojamiento compartido. Cada capa a\u00f1ade unos cientos de milisegundos. <\/p>\n Ninguna optimizaci\u00f3n front compensa un servidor lento. PHP 8.2 o superior, OPcache activo, cach\u00e9 de objetos persistente con Redis, cach\u00e9 de p\u00e1gina completo, HTTP\/2 como m\u00ednimo: esta base divide habitualmente el TTFB por tres. En un sitio con tr\u00e1fico internacional, un CDN que sirve los recursos est\u00e1ticos desde un punto de presencia cercano al visitante completa el dispositivo. Es exactamente lo que cubre una oferta de alojamiento infogestionado<\/a>, por oposici\u00f3n a un alojamiento compartido de unos pocos euros al mes donde tu sitio comparte sus recursos con cientos de otros. <\/p>\n Tres acciones en orden. Servir WebP o AVIF en lugar de JPEG, lo que reduce el peso de un 30 a un 50 % a calidad visual constante. Redimensionar realmente los archivos en lugar de dejar que el navegador reduzca una imagen de 3000 p\u00edxeles de ancho en un contenedor de 800. Aplicar el lazy loading en todas partes excepto en el elemento LCP, con El principio cabe en una frase: cargar en una p\u00e1gina solo lo que esa p\u00e1gina utiliza. Un formulario de contacto que inyecta su CSS y su JavaScript en la totalidad del sitio cuando solo aparece en una URL representa un desperdicio puro. La carga condicional de los recursos por extensi\u00f3n, la puesta en l\u00ednea del CSS cr\u00edtico en el documento y el aplazamiento del resto constituyen lo esencial del trabajo. <\/p>\n Elementor Pro arrastra una reputaci\u00f3n de pesadez ampliamente heredada de sus versiones antiguas y de configuraciones dejadas por defecto. Las funcionalidades experimentales a activar son conocidas: carga optimizada de recursos, carga del CSS bajo demanda, iconos de fuente en l\u00ednea, salida DOM optimizada. Eliminan varias decenas de kilobytes en cada p\u00e1gina. <\/p>\n El resto depende del m\u00e9todo de construcci\u00f3n. Los contenedores flexbox reemplazan ventajosamente el antiguo apilamiento secci\u00f3n, columna, widget, que multiplicaba los niveles de anidamiento y sobrecargaba el \u00e1rbol del documento. Desactivar las bibliotecas de iconos y las animaciones no utilizadas suprime peticiones enteras. En nuestros proyectos de sitio a medida<\/a>, limitamos voluntariamente el n\u00famero de widgets de terceros y reescribimos en HTML y CSS nativos los bloques cuya versi\u00f3n widget cuesta demasiado en rendimiento. <\/p>\n Esta disciplina tiene un l\u00edmite que hay que asumir. En un sitio que acumula ocho a\u00f1os de contenidos, tres redise\u00f1os parciales y una biblioteca de extensiones heredada, la optimizaci\u00f3n marginal alcanza un techo. Un redise\u00f1o de sitio web<\/a> cuesta a menudo menos que doce meses de correcciones sucesivas sobre una base estructuralmente comprometida, y da un resultado que el remiendo nunca alcanzar\u00e1. <\/p>\n Una instalaci\u00f3n WordPress de varios a\u00f1os acumula silenciosamente peso invisible desde el front. Las revisiones de art\u00edculos se cuentan a veces en decenas de miles de l\u00edneas, las tablas de las extensiones desinstaladas permanecen en su sitio, las entradas transitorias caducadas nunca se purgan. Cada petici\u00f3n de p\u00e1gina atraviesa esta masa y el TTFB se alarga unos cuantos milisegundos en cada capa. <\/p>\n La limpieza se hace con copia de seguridad previa, nunca en caliente en un sitio en producci\u00f3n. Limitar el n\u00famero de revisiones conservadas, purgar las tablas hu\u00e9rfanas, indexar correctamente las columnas interrogadas por las extensiones voraces: la ganancia rara vez es espectacular tomada aisladamente, pero se suma a las dem\u00e1s y evita la deriva lenta que se constata en los sitios dejados sin seguimiento. Es precisamente lo que cubre un contrato de mantenimiento<\/a> serio, a diferencia de una simple vigilancia de disponibilidad. <\/p>\n Queda la cuesti\u00f3n del n\u00famero de extensiones, sobre la cual circulan muchas aproximaciones. Treinta extensiones ligeras y bien codificadas pesan menos que cinco extensiones que cargan cada una su biblioteca JavaScript completa en todas las p\u00e1ginas del sitio. El criterio \u00fatil no es la cantidad, es el peso realmente inyectado p\u00e1gina por p\u00e1gina, que la pesta\u00f1a Red de las DevTools revela en unos minutos. <\/p>\n Hay que ser honesto sobre el peso de estas m\u00e9tricas en el algoritmo. Los Core Web Vitals son una se\u00f1al de clasificaci\u00f3n, confirmada y documentada por Google, pero una se\u00f1al entre cientos. Un sitio perfectamente optimizado t\u00e9cnicamente y vac\u00edo de contenido \u00fatil nunca pasar\u00e1 por delante de una p\u00e1gina de referencia lenta en una consulta competitiva. La pertinencia y la autoridad siguen por delante. <\/p>\n Su influencia se manifiesta en dos situaciones precisas. La primera es el arbitraje entre p\u00e1ginas de calidad comparable: a pertinencia equivalente, la experiencia de p\u00e1gina desempata. En una consulta donde diez resultados tratan el mismo tema con la misma seriedad, la diferencia se juega ah\u00ed. La segunda es el presupuesto de rastreo. Un servidor lento reduce el n\u00famero de p\u00e1ginas que Google explora por sesi\u00f3n, lo que ralentiza la indexaci\u00f3n de las novedades en los sitios voluminosos. <\/p>\n El efecto indirecto pesa sin embargo m\u00e1s que el efecto directo. Una p\u00e1gina lenta aumenta la tasa de rebote, reduce el n\u00famero de p\u00e1ginas vistas por visita y hace caer la tasa de conversi\u00f3n. Estos comportamientos acaban por leerse en los datos que Google recopila a escala de la web. Un t\u00fanel de compra que tarda cuatro segundos en reaccionar a cada clic pierde carritos antes incluso de perder posiciones. <\/p>\n Es tambi\u00e9n la raz\u00f3n por la cual tratamos el rendimiento como una restricci\u00f3n de dise\u00f1o y no como una fase de optimizaci\u00f3n final. Un sitio concebido con un presupuesto de rendimiento definido desde la maqueta no necesita ser recuperado despu\u00e9s. Los proyectos visibles en nuestras realizaciones<\/a> se entregan directamente en verde, sin extensi\u00f3n milagrosa instalada en el \u00faltimo minuto. <\/p>\n El orden cuenta tanto como las acciones. Muchos proyectos fracasan porque empiezan por lo m\u00e1s visible en lugar de por lo m\u00e1s determinante. <\/p>\n Esta secuencia se aplica tanto a un sitio de presentaci\u00f3n<\/a> de doce p\u00e1ginas como a un cat\u00e1logo de varios miles de referencias. Solo cambia la amplitud del trabajo por etapa. En un sitio e-commerce<\/a>, la etapa tres y la etapa cinco representan por s\u00ed solas la mayor\u00eda del esfuerzo, porque las fichas de producto concentran las im\u00e1genes pesadas y los scripts de personalizaci\u00f3n. <\/p>\n Una observaci\u00f3n sobre el presupuesto. El rendimiento no es una l\u00ednea opcional del presupuesto, es una consecuencia de las elecciones de arquitectura hechas al principio. Un proyecto construido sobre un tema gen\u00e9rico comprado por 60 euros costar\u00e1 m\u00e1s caro corregirlo en tres a\u00f1os que un desarrollo limpio. Nuestro simulador de precio de sitio web<\/a> da una horquilla realista en unos minutos, y el art\u00edculo que detalla cu\u00e1nto cuesta un sitio web en 2026<\/a> explica lo que cubre cada partida. <\/p>\nLCP: el elemento m\u00e1s grande visible decide tu percepci\u00f3n de velocidad<\/h2>\n
Identificar el elemento LCP antes de intentar cualquier cosa<\/h3>\n
Descomponer el LCP en cuatro segmentos<\/h3>\n
fetchpriority=\"high\"<\/code>. Un tiempo de descarga excesivo requiere WebP o AVIF, un redimensionamiento real y un CDN. Un retardo de renderizado largo delata una hoja de estilos demasiado pesada o una fuente web mal declarada. <\/p>\npreload<\/code> equivale a no priorizar nada en absoluto: el navegador se encuentra con diez urgencias simult\u00e1neas y el ancho de banda se reparte entre ellas. Una sola precarga bien dirigida a la imagen LCP, asociada a un preconnect<\/code> hacia el dominio que la aloja cuando proviene de un CDN, produce una ganancia neta. M\u00e1s all\u00e1, el efecto se invierte. <\/p>\nloading=\"lazy\"<\/code> a todas las im\u00e1genes del sitio, incluida la del hero. El navegador retrasa entonces la descarga del elemento LCP y la m\u00e9trica se dispara. La imagen visible en la carga nunca debe diferirse.\n<\/div>\nCLS: la inestabilidad visual que tus visitantes sufren sin decirlo<\/h2>\n
Las cuatro causas que producen el 90 % del CLS<\/h3>\n
width<\/code> y height<\/code> encabezan la lista. Sin estas dimensiones, el navegador no puede reservar el espacio y el texto sube bruscamente cuando la imagen se carga. La correcci\u00f3n consiste en dos atributos, y WordPress los a\u00f1ade nativamente desde la versi\u00f3n 5.5 para las im\u00e1genes insertadas mediante el editor, pero no siempre para las inyectadas por un tema o un constructor de p\u00e1ginas. <\/p>\nfont-display: swap<\/code> y size-adjust<\/code> limita el fen\u00f3meno, siempre que se precargue el archivo de fuente y se aloje en tu propio dominio en lugar de ir a buscarlo a un tercero. <\/p>\nINP: la m\u00e9trica que sanciona los sitios sobrecargados de scripts<\/h2>\n
Tres componentes, tres responsables diferentes<\/h3>\n
Reducir el INP sin romper las funcionalidades<\/h3>\n
scheduler.yield()<\/code> cuando est\u00e1 disponible o un simple aplazamiento de ejecuci\u00f3n. El trabajo total sigue siendo id\u00e9ntico, pero la interfaz responde entre los segmentos. <\/p>\nMedir tus Core Web Vitals: datos de campo frente a datos de laboratorio<\/h2>\n
PageSpeed Insights, el punto de partida<\/h3>\n
La Search Console, para razonar a escala del sitio<\/h3>\n
Medir en tus propios visitantes<\/h3>\n
Corregir los Core Web Vitals en WordPress y Elementor<\/h2>\n
El alojamiento y el TTFB, la base<\/h3>\n
Las im\u00e1genes, el yacimiento m\u00e1s rentable<\/h3>\n
fetchpriority=\"high\"<\/code> en este \u00faltimo. <\/p>\nEl CSS y el JavaScript, la disciplina de la carga<\/h3>\n
Elementor, los ajustes que cambian las cosas<\/h3>\n
La base de datos y las extensiones, la partida que nadie mira<\/h3>\n
El impacto real en tu posicionamiento, sin exageraci\u00f3n<\/h2>\n
El m\u00e9todo de intervenci\u00f3n, en el orden que produce resultados<\/h2>\n
\n