Optimiza la velocidad de una página web (Core Web Vitals)

La velocidad de una página web no depende únicamente de cuánto tarda en aparecer el contenido. El rendimiento moderno debe analizar también (mediante los Core Web Vitals) cómo se carga el contenido principal, cómo responde la interfaz a las acciones del usuario y si el diseño permanece estable mientras se renderiza.

Por eso, en Web avanzada sabemos de primera mano que optimizar una web profesional requiere analizar diferentes capas: servidor, red, HTML, CSS, JavaScript, imágenes, fuentes, caché y recursos de terceros.

En este contexto aparecen los Core Web Vitals, las métricas que Google utiliza para evaluar determinados aspectos de la experiencia real de los usuarios. Actualmente, las tres métricas principales son LCP, INP y CLS. INP sustituyó a FID como Core Web Vital en marzo de 2024.

Pero conseguir una buena puntuación no consiste en perseguir un 100/100 en PageSpeed Insights. El objetivo debe ser construir una página que cargue rápidamente, responda correctamente y mantenga una experiencia estable.

¿Qué son los Core Web Vitals?

Los Core Web Vitals son un conjunto de métricas orientadas a medir aspectos concretos de la experiencia de usuario.

Las tres métricas principales son:

• Métrica: LCP. Mide la velocidad de carga del contenido principal. Se considera bueno un umbral de ≤ 2,5 s

• Métrica: INP. Es la capacidad de respuesta ante las interacciones. Un buen umbral estaría en ≤ 200 ms

• Métrica: CLS. Mide la estabilidad visual de la página. Un umbral aceptable está en ≤ 0,1

Estas métricas no deben analizarse de forma aislada. Una página puede cargar rápidamente y, sin embargo, responder lentamente a los clics. También puede ser interactiva y sufrir desplazamientos visuales mientras termina de cargar.

Por tanto, una optimización completa debe trabajar las tres dimensiones.

LCP: cómo mejorar la carga del contenido principal

LCP (Largest Contentful Paint) mide el tiempo necesario para que se renderice el elemento de contenido de mayor tamaño visible dentro del viewport.

Habitualmente puede tratarse de:

• Una imagen principal.

• Un bloque de texto.

• Un encabezado.

• Un banner.

• Un elemento visual destacado.

Para obtener una buena experiencia, el objetivo es mantener el LCP en 2,5 segundos o menos.

El servidor también influye en el LCP

Uno de los errores habituales consiste en intentar solucionar todos los problemas de rendimiento modificando únicamente el frontend.

Sin embargo, antes de que el navegador pueda renderizar el contenido necesita recibir la respuesta del servidor.

Aquí entra en juego el TTFB (Time to First Byte).

Un TTFB elevado puede estar relacionado con:

• Hosting con pocos recursos.

• Consultas de base de datos lentas.

• Procesamiento excesivo en servidor.

• Aplicaciones mal optimizadas.

• Falta de caché.

• Latencia de red.

• Configuraciones incorrectas del servidor.

Por eso, si el servidor tarda demasiado en comenzar a responder, optimizar únicamente las imágenes o minificar CSS puede tener un impacto limitado.

Optimizar la imagen LCP

Si el elemento LCP es una imagen, hay que prestar especial atención a su tamaño y prioridad.

Algunas medidas habituales son:

• Utilizar WebP o AVIF cuando resulte apropiado.

• Servir la imagen con las dimensiones necesarias.

• Evitar cargar una imagen de 3000 píxeles cuando solo se muestran 800.

• Utilizar srcset y sizes para adaptar las imágenes.

• Comprimir los archivos.

• Evitar cargar como lazy la imagen que constituye el contenido principal.

• Priorizar su descarga cuando sea necesario.

Por ejemplo, una imagen responsive puede utilizar diferentes recursos dependiendo del tamaño del viewport:

<img
  src="imagen-800.webp"
  srcset="
    imagen-400.webp 400w,
    imagen-800.webp 800w,
    imagen-1200.webp 1200w"
  sizes="(max-width: 768px) 100vw, 800px"
  width="1200"
  height="800"
  alt="Descripción de la imagen">

El objetivo no es simplemente reducir el peso de todas las imágenes. Es entregar al navegador el recurso adecuado en el momento adecuado.

INP: cómo mejorar la capacidad de respuesta

INP (Interaction to Next Paint) analiza cómo responde una página a las interacciones del usuario.

Por ejemplo:

• Hacer clic en un botón.

• Abrir un menú.

• Escribir en un formulario.

• Seleccionar una opción.

• Interactuar con un componente dinámico.

Una web puede mostrar rápidamente su contenido inicial y, sin embargo, sentirse lenta cuando el usuario intenta utilizarla.

Para conseguir un INP considerado bueno, el objetivo es 200 ms o menos.

El problema de las tareas largas de JavaScript

Uno de los principales enemigos del INP son las long tasks, tareas de JavaScript que mantienen ocupado el hilo principal durante demasiado tiempo.

Cuando el navegador está ejecutando JavaScript intensivo puede retrasar otras operaciones, incluida la respuesta a las acciones del usuario.

Algunas causas frecuentes son:

• Frameworks utilizados de forma excesiva.

• Plugins con demasiado JavaScript.

• Librerías innecesarias.

• Scripts de terceros.

• Procesamiento complejo en el navegador.

• Código JavaScript mal optimizado.

• Ejecución de demasiadas operaciones después de una interacción.

Por eso, reducir el tamaño de un archivo JavaScript no siempre es suficiente.

También hay que analizar qué hace ese código y cuándo lo ejecuta.

Técnicas para reducir el impacto de JavaScript

Entre las estrategias más utilizadas están:

• Eliminar JavaScript que no se utiliza.

• Dividir el código en módulos.

• Aplicar code splitting.

• Cargar determinados módulos bajo demanda.

• Retrasar scripts que no son críticos.

• Evitar ejecutar código innecesario durante la carga inicial.

• Reducir el trabajo realizado en el hilo principal.

• Optimizar los manejadores de eventos.

• Revisar las librerías de terceros.

En aplicaciones grandes puede ser especialmente interesante cargar funcionalidades únicamente cuando son necesarias.

Por ejemplo, una funcionalidad relacionada con un formulario que aparece al final de una página no necesariamente tiene que formar parte del JavaScript crítico que se ejecuta inmediatamente al cargar el sitio.

CLS: cómo evitar movimientos inesperados

CLS (Cumulative Layout Shift) mide la estabilidad visual.

Un ejemplo clásico es una página que comienza a mostrar un texto y, unos instantes después, carga una imagen situada encima.

El texto se desplaza hacia abajo.

El usuario puede estar a punto de pulsar un botón y, de repente, el botón cambia de posición.

Además de resultar molesto, este comportamiento puede provocar errores de interacción.

El objetivo es mantener el CLS en 0,1 o menos.

Reservar espacio para las imágenes

Una de las técnicas más importantes consiste en definir las dimensiones de las imágenes.

<img
  src="producto.webp"
  width="800"
  height="600"
  alt="Producto">

También puede utilizarse CSS mediante aspect-ratio cuando el diseño lo requiera.

.producto-imagen {
  aspect-ratio: 4 / 3;
  width: 100%;
}

De esta forma, el navegador puede reservar el espacio antes de que termine de descargar la imagen.

Fuentes y CLS

Las fuentes web también pueden afectar a la estabilidad visual.

El navegador puede comenzar mostrando una fuente alternativa y sustituirla posteriormente por la fuente definitiva.

Ese cambio puede modificar:

• Anchura del texto.

• Altura de los bloques.

• Saltos de línea.

• Posición de otros elementos.

Por ello conviene revisar la estrategia de carga de fuentes, reducir las variantes innecesarias y utilizar correctamente font-display.

TTFB: el rendimiento empieza antes del navegador

Aunque TTFB no sea uno de los tres Core Web Vitals, es una métrica especialmente relevante durante el análisis del rendimiento.

El navegador necesita recibir los primeros bytes antes de comenzar determinadas fases del procesamiento.

Un TTFB elevado puede hacer que toda la cadena de carga comience tarde.

Para reducirlo podemos revisar:

Hosting

No todos los alojamientos ofrecen el mismo rendimiento.

Hay que considerar:

• Recursos disponibles.

• CPU.

• Memoria.

• Tipo de almacenamiento.

• Saturación del servidor.

• Ubicación del centro de datos.

• Configuración del servidor web.

Caché

La caché puede evitar que el servidor tenga que generar continuamente la misma respuesta.

Dependiendo de la arquitectura pueden utilizarse diferentes niveles:

• Caché del navegador.

• Caché HTTP.

• Caché de página.

• Caché de objetos.

• Caché de consultas.

• CDN.

Una estrategia de caché bien diseñada puede reducir considerablemente el trabajo necesario para generar determinadas páginas.

Optimización de HTML y CSS

El HTML también puede afectar al rendimiento.

Una estructura excesivamente compleja puede aumentar el trabajo que realiza el navegador.

Conviene revisar:

• Cantidad de elementos DOM.

• HTML innecesariamente complejo.

• CSS que nunca se utiliza.

• Hojas de estilo excesivamente grandes.

• CSS bloqueante.

• Estilos duplicados.

CSS crítico

En determinados proyectos puede ser interesante priorizar el CSS necesario para renderizar el contenido visible inicialmente.

El resto puede cargarse posteriormente.

Sin embargo, esta técnica debe aplicarse con criterio. Una implementación incorrecta puede generar problemas de mantenimiento o incluso empeorar la experiencia.

JavaScript: menos no siempre significa mejor

Uno de los errores más habituales en la optimización consiste en pensar únicamente en el tamaño de los archivos.

Un JavaScript de 200 KB puede ser más problemático que uno de 500 KB si el primero ejecuta operaciones costosas durante la carga inicial.

Por eso conviene analizar:

Descarga → parseo → compilación → ejecución

Cada una de estas fases puede tener un coste.

Herramientas como Chrome DevTools permiten analizar el Performance panel y localizar tareas largas, actividad del hilo principal y operaciones costosas.

La pregunta correcta no es únicamente:

¿Cuánto pesa mi JavaScript?

También debemos preguntarnos:

¿Cuánto trabajo obliga a realizar al navegador?

Carga diferida de recursos

No todos los recursos de una página tienen la misma prioridad.

Una estrategia habitual consiste en diferenciar entre:

Recursos críticos

Necesarios para mostrar e interactuar con el contenido inicial.

Recursos no críticos

Necesarios posteriormente.

Las imágenes que aparecen debajo del primer viewport, por ejemplo, pueden cargarse de forma diferida:

<img
  src="imagen.webp"
  loading="lazy"
  width="800"
  height="600"
  alt="Descripción">

Pero hay que evitar aplicar lazy loading indiscriminadamente.

Una imagen que constituye el contenido LCP puede necesitar un tratamiento diferente.

La optimización consiste precisamente en establecer prioridades de carga, no simplemente en retrasar todo.

Scripts de terceros: un problema frecuente

Google Analytics, gestores de etiquetas, mapas, chats, vídeos, widgets, publicidad y otros servicios externos pueden añadir recursos y ejecución de JavaScript.

Cada integración debería justificarse.

Conviene revisar:

• Qué scripts se cargan.

• Cuándo se cargan.

• Cuánto pesan.

• Cuánto JavaScript ejecutan.

• Qué funcionalidades aportan.

• Si realmente son necesarios.

Una web puede estar perfectamente optimizada internamente y perder buena parte de su rendimiento debido a diez scripts externos.

CDN: cuándo puede ser útil

Una CDN (Content Delivery Network) permite distribuir determinados recursos desde servidores ubicados en diferentes regiones.

Esto puede reducir la distancia entre el usuario y el servidor que entrega determinados contenidos.

Una CDN puede ser especialmente interesante para:

• Imágenes.

• CSS.

• JavaScript.

• Fuentes.

• Vídeos.

• Archivos estáticos.

Sin embargo, utilizar una CDN no soluciona automáticamente todos los problemas de rendimiento.

Si una aplicación genera lentamente una página dinámica, primero hay que investigar el origen de esa lentitud.

HTTP/2, HTTP/3 y protocolos modernos

El protocolo utilizado también forma parte de la arquitectura de rendimiento.

HTTP/2 introdujo mejoras importantes frente a HTTP/1.1, entre ellas la multiplexación de solicitudes.

HTTP/3 utiliza QUIC sobre UDP y puede ofrecer ventajas especialmente relacionadas con determinadas condiciones de red y establecimiento de conexiones.

Por tanto, al analizar una web profesional también conviene comprobar:

• Protocolo HTTP utilizado.

• TLS.

• Compresión.

• Configuración del servidor.

• Caché.

• Conexiones.

• CDN.

No obstante, cambiar de protocolo no compensa una aplicación mal optimizada.

Compresión de recursos

Los recursos de texto deben servirse comprimidos cuando sea posible.

Entre las tecnologías habituales encontramos:

• Gzip.

• Brotli.

Brotli puede proporcionar una buena compresión para determinados recursos de texto, aunque la elección debe depender de la configuración del servidor y del tipo de contenido.

También hay que evitar comprimir recursos que ya utilizan formatos comprimidos de manera eficiente, como determinados archivos de imagen.

Cómo medir realmente el rendimiento

Una optimización profesional debe comenzar con mediciones.

Entre las herramientas más útiles encontramos:

PageSpeed Insights

Permite consultar datos de laboratorio y, cuando están disponibles, datos de usuarios reales.

Es útil para detectar problemas relacionados con rendimiento y recibir oportunidades de mejora.

Google Search Console

El informe de Core Web Vitals permite analizar el rendimiento de las URL agrupadas según los datos disponibles de usuarios reales.

Lighthouse

Permite realizar auditorías de rendimiento, accesibilidad, buenas prácticas y SEO.

Chrome DevTools

Es especialmente interesante cuando necesitamos investigar técnicamente el origen de un problema.

El panel Performance permite analizar la actividad del navegador y localizar operaciones que consumen demasiado tiempo.

Datos de laboratorio frente a usuarios reales

Esta diferencia es fundamental.

Una prueba de laboratorio se realiza bajo unas condiciones determinadas.

Los datos de campo reflejan experiencias reales de usuarios con diferentes:

• Dispositivos.

• Conexiones.

• Ubicaciones.

• Navegadores.

• Capacidades de hardware.

Por eso una web puede obtener un resultado excelente en una prueba concreta y presentar problemas en determinadas situaciones reales.

Para optimizar correctamente hay que combinar ambas perspectivas.

¿Una buena puntuación en PageSpeed significa que la web está optimizada?

No necesariamente.

Una puntuación alta es útil, pero no debe convertirse en el objetivo final.

Google indica expresamente que obtener buenos resultados en Core Web Vitals no garantiza aparecer en las primeras posiciones de sus resultados. La experiencia de página es más amplia y sus sistemas también consideran la relevancia y otros factores.

Por eso no tiene demasiado sentido obsesionarse con conseguir un determinado número si para lograrlo sacrificamos funcionalidades importantes o empeoramos la experiencia.

La pregunta debería ser:

¿La página carga rápido, responde bien y ofrece una experiencia estable a usuarios reales?

Checklist técnico de optimización

Antes de considerar terminada una auditoría de rendimiento, podemos revisar:

Servidor

• ☐ TTFB razonable.

• ☐ Hosting correctamente dimensionado.

• ☐ Caché configurada.

• ☐ Compresión activada.

• ☐ HTTP/2 o HTTP/3 disponible cuando proceda.

• ☐ CDN correctamente configurada.

Imágenes

• ☐ Formatos modernos.

• ☐ Dimensiones adecuadas.

• ☐ srcset y sizes.

• ☐ Compresión.

• ☐ Lazy loading para imágenes no críticas.

• ☐ Imagen LCP correctamente priorizada.

CSS

• ☐ CSS innecesario eliminado.

• ☐ Recursos bloqueantes revisados.

• ☐ CSS crítico correctamente gestionado.

• ☐ Hojas de estilo optimizadas.

JavaScript

• ☐ Código innecesario eliminado.

• ☐ Scripts de terceros revisados.

• ☐ Tareas largas identificadas.

• ☐ Code splitting cuando sea necesario.

• ☐ Carga diferida de funcionalidades no críticas.

• ☐ Eventos e interacciones optimizados.

Renderizado

• ☐ LCP ≤ 2,5 s.

• ☐ INP ≤ 200 ms.

• ☐ CLS ≤ 0,1.

• ☐ Elementos visuales estables.

• ☐ Fuentes correctamente gestionadas.

Medición

• ☐ PageSpeed Insights.

• ☐ Search Console.

• ☐ Lighthouse.

• ☐ Chrome DevTools.

• ☐ Datos de usuarios reales.

Optimizar una web es analizar toda la cadena

La velocidad de una página web no depende de un único factor.

Una imagen pesada puede perjudicar el LCP. Un JavaScript mal planteado puede empeorar el INP. Una fuente o un banner sin espacio reservado puede aumentar el CLS. Un servidor lento puede retrasar todo el proceso antes incluso de que el navegador empiece a renderizar.

Por eso, una optimización profesional debe analizar la cadena completa:

Servidor → red → HTML → CSS → JavaScript → recursos → renderizado → interacción

Además, las métricas deben analizarse con datos reales siempre que sea posible.

Los Core Web Vitals son una herramienta muy útil para detectar problemas, pero no sustituyen a una auditoría técnica completa.

¿Necesitas mejorar la velocidad de una página web?

En Web Avanzada analizamos el rendimiento de páginas web desde una perspectiva técnica, revisando tanto el frontend como los recursos, el servidor y los elementos que pueden afectar a la experiencia del usuario.

El objetivo no es simplemente conseguir una puntuación alta en una herramienta.

Es conseguir una web que cargue rápido, responda correctamente, sea estable y esté preparada para usuarios reales y buscadores.

Si tu página obtiene malos resultados en LCP, INP o CLS, una auditoría técnica puede ayudarte a identificar qué está provocando el problema y qué actuaciones tienen realmente impacto.

Una web rápida no se consigue añadiendo un único plugin de optimización. Se consigue midiendo, identificando cuellos de botella y optimizando cada parte del proceso.