Cómo revisar la velocidad de un blog: LCP, INP y CLS

Para revisar la velocidad de un blog, analice una URL pública en PageSpeed Insights y compare los resultados para móvil y ordenador. LCP, INP y CLS permiten distinguir la carga del contenido, la respuesta a las interacciones y la estabilidad visual. Separe los datos de usuarios reales del diagnóstico de laboratorio y corrija la causa del problema en lugar de centrarse únicamente en la puntuación.

¿Qué son LCP, INP y CLS?

Core Web Vitals es un conjunto de métricas de Google sobre la experiencia de uso de una página. Actualmente incluye las tres siguientes. En todas, un valor menor es mejor, pero miden aspectos distintos y utilizan unidades diferentes.

La guía de Google sobre Web Vitals utiliza el percentil 75 por separado para móvil y ordenador. Aproximadamente, indica el valor en el que se sitúan o por debajo del cual quedan el 75 % de las visitas observadas. No es una media ni el resultado más rápido de una prueba. Si las tres métricas tienen datos suficientes, todas deben ser buenas para superar la evaluación; un buen LCP no basta por sí solo.

Un artículo puede aparecer rápido y responder con retraso al abrir el menú. Otro puede responder bien, pero desplazarse cuando aparece un anuncio. Identifique qué experiencia falla antes de comprimir imágenes repetidamente para resolver un problema de velocidad que aún no ha localizado.

Ejecute una prueba en PageSpeed Insights

1. Elija la URL de un artículo público que se abra sin iniciar sesión. Excluya direcciones del editor o de vista previa.
2. Introdúzcala en PageSpeed Insights y ejecute el análisis.
3. En el resultado móvil, lea por separado la experiencia de los usuarios reales y el diagnóstico de rendimiento.
4. Consulte también el resultado para ordenador. Anote la URL, la fecha, el tipo de dispositivo, las métricas problemáticas y los principales hallazgos.

Seleccione formatos representativos, además del artículo más reciente: uno de texto, otro con muchas imágenes y otro con tablas o código, si su blog los utiliza. Así podrá distinguir un problema de la plantilla común de otro propio de un contenido concreto.

Compruebe si la URL analizada es distinta de la introducida. Si hubo una redirección, utilice ese mismo destino final en las comparaciones posteriores. Registrar las condiciones sirve para valorar los cambios con coherencia.

Diferencie los datos reales del resultado de laboratorio

Los datos de usuarios reales proceden del Informe de experiencia de usuario de Chrome (Chrome User Experience Report, CrUX) y abarcan los 28 días anteriores. Si la URL no tiene muestras suficientes, puede aparecer información del origen completo; si tampoco hay datos del origen, no se muestra esa experiencia. Un origen agrupa las páginas que comparten protocolo, host y puerto. El diagnóstico de laboratorio utiliza Lighthouse en un entorno simulado. La documentación de PageSpeed Insights explica ambas fuentes.

Obtener 90 puntos de rendimiento no equivale a superar Core Web Vitals con datos reales. Compruebe si la información corresponde a esa URL o al origen completo. La ausencia de datos no demuestra que la página sea rápida ni que tenga un problema.

El periodo de CrUX y la ejecución actual de Lighthouse utilizan muestras y condiciones distintas. El diagrama separa su procedencia y utilidad para facilitar la comparación después de un cambio.

Por ejemplo, sustituir una imagen puede mejorar una prueba de laboratorio de inmediato, mientras que el periodo de 28 días todavía incluye visitas anteriores al cambio. Compruebe primero que el nuevo archivo se muestra bien y que las pruebas comparables indican una mejora. Analice por separado la evolución posterior de los usuarios reales.

Que falte INP no significa que su valor sea cero. PSI puede superar la evaluación con datos insuficientes de INP si los percentiles 75 de LCP y CLS son buenos. Si faltan datos suficientes de LCP o CLS, no puede realizar la evaluación. Esta excepción figura en las condiciones de evaluación de PSI. Lea qué métricas están disponibles junto al resultado global.

LCP deficiente: localice qué retrasa el contenido principal

Identifique primero el elemento que el diagnóstico señala como contenido de mayor tamaño. Puede ser la imagen superior del artículo, un bloque de texto u otro elemento. No aplique la misma configuración de imagen a toda la página sin comprobarlo.

• Si es una imagen, compare sus dimensiones descargadas con el tamaño al que se muestra.
• Utilice dimensiones, compresión y formato adecuados, comprobando la claridad del texto y los detalles necesarios.
• Compruebe si la imagen LCP visible al entrar utiliza carga diferida. Una opción apropiada para imágenes inferiores puede retrasar ese contenido principal.
• Si el diagnóstico identifica la respuesta del servidor o recursos que bloquean el renderizado, investigue también esas causas.

La guía de optimización de LCP distingue la detección, descarga y presentación del contenido. Si necesita cambiar el formato, consulte cómo convertir imágenes a WebP. Si sigue llegando el archivo anterior, revise la caché y el recurso realmente solicitado.

Abra el desglose de LCP del diagnóstico para localizar el tiempo consumido en cada tramo. Empiece por el más largo o por las esperas evitables:

1. Tiempo hasta el primer byte (TTFB, Time to First Byte): desde el inicio de la navegación hasta recibir el primer byte del HTML. Revise la respuesta del servidor, las cadenas de redirección y el uso de caché.
2. Retraso de carga del recurso: la espera tras esa respuesta hasta que comienza la descarga de la imagen u otro recurso LCP. Compruebe la carga diferida o una detección tardía.
3. Duración de carga del recurso: la descarga del archivo. Es el tramo que intenta reducir directamente al ajustar tamaño y compresión.
4. Retraso de renderizado del elemento: la espera desde que llega el archivo hasta que se muestra. Si aún lo bloquean scripts o condiciones de visualización, reducir la imagen puede no mejorar el LCP total.

Un elemento LCP de texto que no requiere descargar otro recurso puede no tener esos tramos de descarga. Interprete el desglose según el elemento real identificado.

INP deficiente: revise qué ocurre tras la interacción

INP evalúa la respuesta hasta la siguiente actualización visual tras una interacción. Una tarea larga de JavaScript puede ocupar el hilo principal, encargado de ejecutar scripts y procesar la pantalla, y retrasar la entrada. La guía de optimización de INP separa el retraso de entrada, el procesamiento de eventos y la presentación.

Reproduzca acciones habituales en el móvil: abrir el menú, buscar y seguir un enlace del índice. Anote cuál se retrasa y revise los plugins, widgets y scripts externos activos en esa página para detectar funciones duplicadas o innecesarias.

El tiempo total de bloqueo (TBT, Total Blocking Time) de una prueba básica de Lighthouse ayuda a detectar tareas largas, pero no es INP. INP observa clics, toques y entradas de teclado; una visita que solo hace scroll o no interactúa puede no generar un valor. También debe distinguir la respuesta visual inmediata, como mostrar que una búsqueda está en curso, del tiempo necesario para recibir todos sus resultados del servidor. La definición y el alcance de INP explican estas diferencias.

Evite desactivar muchos plugins a la vez. Prepare una copia de seguridad o un entorno de pruebas y cambie una sola cosa cada vez para identificar su efecto. Si retrasa la ejecución de JavaScript, compruebe que siguen funcionando el menú, la búsqueda y los controles de consentimiento, además de revisar la puntuación.

CLS deficiente: reserve espacio para el contenido

Las imágenes, los anuncios y los elementos incrustados que llegan tarde pueden desplazar el artículo o el enlace que alguien iba a pulsar. La guía de optimización de CLS destaca las dimensiones de las imágenes y la reserva de espacio para contenido posterior.

• Indique width y height en las imágenes o reserve una relación de aspecto adecuada.
• Reserve espacio para anuncios y vídeos según el tamaño de pantalla.
• Compruebe que un espacio publicitario sin rellenar no se contrae de repente y provoca otro desplazamiento.
• Observe si se mueven el texto o los botones al cargar fuentes o banners.

El elemento señalado en un diagnóstico no tiene por qué ser la causa. Si se inserta un anuncio encima, puede aparecer registrado el artículo que se desplazó debajo. Revise también lo que se añadió inmediatamente antes del elemento. Una prueba de carga inicial puede omitir movimientos de anuncios o imágenes que aparecen al hacer scroll. Recorra el artículo público y compruebe también las interacciones con menús y controles de consentimiento.

Reducir espacios vacíos y mantener estable el diseño puede requerir ajustes. No presuponga que una altura publicitaria apropiada en ordenador sirve también en móvil. Revise el inicio, el centro y el final de artículos reales.

Vuelva a comprobar en condiciones comparables

1. Guarde la configuración, los archivos y los resultados anteriores.
2. Elija una causa importante y realice un cambio concreto.
3. Actualice las cachés necesarias y compruebe que el recurso modificado llega a la página pública.
4. Repita la prueba con la misma URL y tipo de dispositivo. Revise también menús, imágenes, anuncios y contenido.
5. Si se rompe una función o empeora otra métrica, revierta el cambio y vuelva a delimitar la causa.

Distinga las opciones que sirven recursos guardados de las que retrasan la ejecución de scripts. La comparación de plugins de caché para WordPress explica sus funciones. No active varias optimizaciones a la vez; conserve los ajustes necesarios para volver atrás.

No concluya que una modificación funciona por una pequeña diferencia en una sola ejecución. Compare los registros y los problemas recurrentes antes del siguiente cambio. Subir la puntuación rompiendo funciones que necesita el lector no es una mejora útil.

La visibilidad en buscadores tampoco depende solo de la velocidad. Las directrices de Google sobre experiencia de página indican que Core Web Vitals se utiliza en los sistemas de clasificación, pero un buen resultado no garantiza posiciones superiores. Mejore también la lectura del artículo y las acciones que necesitan realizar sus visitantes.