Mejorar los Core Web Vitals en una web corporativa con muchas imágenes

Imaginemos una empresa que necesita mostrar su trabajo: un carpintero de interiores, un estudio fotográfico, una consulta con espacios que deben convencer. La web incluye una imagen de cabecera a pantalla completa, doce fotos de referencia, un vídeo incrustado, un fragmento de mapa, un widget de reservas y un banner de cookies. Cada uno de estos elementos tiene sentido por sí solo. Juntos dan lugar a una página que parece fluida en el ordenador del desarrollador y que se atasca de forma perceptible en un smartphone de gama media de hace tres años con red móvil.

Es una situación de partida típica, no la descripción de un caso concreto. Quien revisa la web en el ordenador de la oficina con fibra óptica no ve el problema. Quien la abre en el tren espera a la imagen de cabecera, ve saltar el texto, toca un menú y nota un retraso. Esta experiencia es el verdadero objeto de los Core Web Vitals: Google la resume en tres indicadores que describen la carga, la respuesta y la estabilidad visual.

El análisis técnico describe cómo examinaríamos y ordenaríamos una situación de partida así. No contiene series de mediciones de ningún cliente ni promesas sobre posiciones. Muestra mecanismos, compromisos y un orden de actuación que puede trasladarse a muchas webs con abundantes imágenes.

Nos importa mantener una actitud sobria. La velocidad no es un fin en sí mismo y no todas las webs tienen que alcanzar todos los umbrales. Una empresa con veinte visitas al día tiene otras prioridades que un portal con miles. Primero preguntamos si hoy los visitantes fracasan por el tiempo de carga y solo después cuánto esfuerzo merece la pena dedicarle. A veces la respuesta es que bastan tres intervenciones precisas y que el resto es cuestión de gustos.

Los Core Web Vitals constan de tres magnitudes. El Largest Contentful Paint (LCP) mide cuándo se ha terminado de dibujar el elemento visible más grande de la zona inicial, normalmente la imagen de cabecera o un titular grande; se considera bueno un valor de hasta 2,5 segundos. La Interaction to Next Paint (INP) describe la rapidez con la que la página reacciona visiblemente tras una entrada del usuario; es bueno un valor de hasta 200 milisegundos. El Cumulative Layout Shift (CLS) suma los desplazamientos inesperados del diseño; es bueno un valor de hasta 0,1.

En las webs con muchas imágenes confluyen varias causas. La imagen de cabecera se ha subido como exportación en bruto y pesa varios megabytes. Las tipografías web se cargan tarde, el texto aparece primero en una fuente sustituta y luego salta. Los scripts de terceros para seguimiento, mapas, chat y reservas compiten por la misma conexión y el mismo hilo principal. El banner de cookies empuja el contenido hacia abajo a posteriori o tapa justo el elemento que cuenta como LCP.

A ello se suma la carga del front-end: quien utiliza un framework suele enviar más JavaScript del que la página necesita para ser leída. El navegador tiene que cargarlo, analizarlo y ejecutarlo antes de que los menús y formularios respondan con fiabilidad. Esta fase de hidratación es una causa frecuente, pero rara vez detectada, de malos valores de INP.

Además, las causas se refuerzan entre sí. Una imagen de cabecera pesada ocupa la conexión mientras los scripts reclaman ancho de banda y tiempo de cálculo en paralelo. Un cambio de tipografía que apenas se notaría por sí solo se suma a un banner que se carga tarde y produce un salto perceptible. Por eso corregir un único punto rara vez supone un gran avance, mientras que tres pequeñas intervenciones en el lugar adecuado suelen lograr más que una gran reforma.

El error más frecuente empieza con una única ejecución de Lighthouse. Lighthouse y la parte de laboratorio de PageSpeed Insights simulan la carga de una página en condiciones predefinidas. Es valioso porque permite comparar cambios de forma reproducible. Pero es un modelo: el dispositivo, la red y la ubicación son supuestos, y no se produce ninguna interacción real. Por eso no existe un valor de laboratorio para el INP en el mismo sentido; como sustituto se utiliza el Total Blocking Time.

Los datos de campo proceden de visitantes reales. Los recoge el Chrome User Experience Report (CrUX), y la Search Console los muestra por separado para móvil y escritorio y agrupa URL con una estructura similar. Para la evaluación de los Core Web Vitals cuenta esta imagen de campo, durante un periodo móvil de unos 28 días. Eso significa también que una mejora no es visible al día siguiente.

Por eso separaríamos ambas fuentes. El campo dice si existe un problema para personas reales y en qué tipos de página. El laboratorio dice por qué, y si un cambio actúa en la dirección correcta. Las webs pequeñas con poco tráfico a veces no tienen datos de campo suficientes; entonces queda el laboratorio, complementado con mediciones propias en el navegador, como orientación provisional.

Un ejemplo práctico: la página de inicio muestra un buen LCP en el laboratorio, pero no en el campo. Las explicaciones posibles son visitantes con conexiones lentas, un banner de cookies que solo aparece en la primera visita y falta en la prueba, o contenidos dinámicos según la ubicación. Estas diferencias solo se detectan si se miran ambos lados y se configura el laboratorio de forma deliberadamente más realista, por ejemplo con red limitada y caché vacía.

El trabajo de rendimiento rara vez fracasa por falta de conocimientos, sino por falta de orden. Una auditoría arroja treinta observaciones y todas parecen igual de urgentes. Las ordenaríamos con dos criterios: cuánto influye el punto en uno de los tres indicadores en las páginas con más tráfico, y cuánto esfuerzo y riesgo implica el cambio.

Las imágenes y la entrega casi siempre van primero, porque ofrecen un gran efecto con un riesgo manejable. Siguen los scripts de terceros, donde importa si el servicio es realmente necesario. Después vienen las tipografías y la estabilidad del diseño. La reestructuración de la arquitectura de JavaScript suele quedar para el final, porque es cara y solo compensa si los pasos más baratos no bastan.

Como alternativa se suele ofrecer un plugin o un servicio de rendimiento que aplica optimizaciones de forma automática. Puede ayudar en webs sencillas. Pero en webs con una estructura propia carece del conocimiento sobre qué imagen es el LCP y qué script es prescindible. Utilizaríamos la automatización como herramienta, no como estrategia.

Un principio ayuda a elegir: primero eliminar, luego reducir, luego aplazar y solo al final acelerar. Un script que nadie necesita ya no genera costes. Una imagen que puede ser más pequeña carga más rápido que cualquier regla de caché. Lo que es necesario, pero no de inmediato, pasa a cargarse tras la primera interacción. Este orden ahorra esfuerzo y conduce a soluciones que seguirán funcionando dentro de dos años.

En las webs con muchas imágenes, el LCP suele depender de un único elemento. Tres preguntas deciden: ¿qué tamaño tiene el archivo?, ¿cuándo lo descubre el navegador? y ¿cuánto tarda en responder el servidor? Una imagen incluida como fondo en CSS o cargada más tarde mediante JavaScript el navegador la encuentra tarde. Como elemento de imagen real en el marcado, con prioridad alta, la descarga empieza antes.

En cuanto al formato, merece la pena considerar las alternativas modernas. WebP y AVIF comprimen bastante mejor que JPEG con una calidad comparable; AVIF requiere más tiempo de cálculo al codificar, y WebP está más ampliamente probado. Un camino razonable es ofrecer ambos mediante un elemento picture y mantener JPEG como alternativa. Lo decisivo sigue siendo el nivel de calidad: las fotos deben seguir transmitiendo calidad, y ningún valor de métrica justifica unas imágenes de referencia borrosas.

Las imágenes adaptables son la segunda palanca. Con srcset y sizes, un smartphone recibe un archivo del ancho adecuado en lugar de la versión de escritorio. Todas las imágenes situadas bajo la zona visible se cargan de forma diferida; la imagen de cabecera, no: nunca debe llevar loading="lazy", pues de lo contrario el LCP se retrasa artificialmente. Y cada imagen recibe ancho y alto, para que el navegador reserve el espacio.

También influye la elección del motivo. Una foto con mucha estructura fina, como vetas de madera o juntas de azulejos, se comprime peor que una superficie tranquila. A veces otro encuadre aporta más que cualquier ajuste del programa de codificación. Para la zona inicial conviene elegir un motivo que funcione en pantallas pequeñas y no solo en formato panorámico; así no hace falta enviar archivos enormes.

Una imagen optimizada sirve de poco si el servidor tarda en responder. Aquí entran en juego el alojamiento, la caché y una red de distribución de contenidos (CDN). Una CDN sirve archivos estáticos desde ubicaciones cercanas al visitante; para una web que llega sobre todo a clientes de habla alemana, la ganancia es menor que con un público internacional, pero existe. A menudo es más importante la caché: las imágenes, tipografías y scripts con nombres versionados pueden permanecer mucho tiempo en el navegador, mientras que el HTML se almacena poco tiempo o no se almacena.

Los scripts de terceros los revisamos uno a uno. ¿Qué función cumple el script, quién analiza los datos y puede cargarse más tarde o con un clic? Un mapa puede mostrarse como una imagen de vista previa estática que carga la versión interactiva solo después de tocarla. Un widget de chat puede arrancar tras la primera acción del usuario. Este patrón reduce la carga para los visitantes que nunca abren el servicio y encaja al mismo tiempo con un consentimiento respetuoso con la privacidad.

En el código cuenta lo que el navegador tiene que ejecutar al arrancar. Las páginas que consisten sobre todo en contenido apenas necesitan lógica en el cliente. El renderizado en el servidor, paquetes más pequeños, código dividido y zonas interactivas que solo se hidratan cuando hacen falta acortan las tareas largas del hilo principal. Esto repercute directamente en el INP, porque el navegador ya no hace esperar las entradas detrás de cálculos.

Una comprobación que ha demostrado su valor: iniciar una grabación en el panel de rendimiento del navegador, tocar un menú o un formulario y buscar tareas largas. Si allí aparece un bloque de varios cientos de milisegundos, la causa suele ser un único script o componente que hace demasiado al arrancar. Estos hallazgos son concretos y pueden corregirse de forma selectiva, en lugar de exigir en general «menos JavaScript».

El banner de cookies es un caso especial porque une dos intereses que chocan: los requisitos legales y el comportamiento de carga. Si se inserta a posteriori en el flujo del texto, lo desplaza todo y dispara el CLS. Es mejor reservar espacio o crearlo como una superficie superpuesta que no mueva el contenido. Además, el banner no debería ser el elemento visible más grande; de lo contrario, el LCP mide el banner en lugar de la imagen de cabecera.

En las tipografías web, el cambio de fuente nunca puede evitarse del todo, pero sí atenuarse. Pocos estilos, entrega propia desde el mismo servidor y la precarga del archivo más importante acortan la espera. Con font-display se controla lo que es visible mientras tanto, y los ajustes modernos de la fuente sustituta mantienen los saltos de línea casi idénticos. Así el salto pasa desapercibido.

Los carruseles y las imágenes que cambian automáticamente son otro caso: suelen cargar varias imágenes grandes aunque solo una sea visible, y la interacción con ellos sobrecarga el hilo principal. Aquí conviene preguntarse con honestidad si la galería necesita esa mecánica. Una cuadrícula tranquila con miniaturas de carga diferida y una vista ampliada al hacer clic cuenta la misma historia con menos carga. Es un asunto de diseño, no solo técnico, y lo decidiríamos juntos.

Un último caso especial son los vídeos. Un vídeo incrustado desde una plataforma suele cargar al abrir la página varios cientos de kilobytes de script, aunque apenas nadie lo reproduzca. Una imagen de vista previa con botón de reproducción que solo carga el reproductor al hacer clic mantiene la página ligera y muestra el mismo motivo. El vídeo se conserva; solo cambia el momento de la carga.

Primero, una valoración honesta sobre el posicionamiento. Los Core Web Vitals son una señal dentro de la experiencia de página, es decir, un factor entre muchos. Los contenidos que encajan con la búsqueda, los enlaces y la confianza suelen pesar más. Una página con poca relevancia no sube por volverse rápida. Entre dos páginas de fuerza similar, en cambio, la velocidad puede inclinar la balanza. Quien promete saltos en el posicionamiento vende más de lo que puede demostrarse.

El beneficio más fiable está en el visitante. Una página que se hace visible con rapidez, se mantiene estable y reacciona al tocarla pierde a menos personas antes del primer contacto. Esto afecta directamente a las solicitudes, las llamadas y las reservas de cita. El tamaño del efecto en una web concreta depende del sector, de la fuente de tráfico y del estado de partida, y no damos porcentajes al respecto.

La medición se haría así: en el informe de Core Web Vitals, la Search Console muestra si los grupos de URL pasan de «deficiente» o «necesita mejorar» a «bueno», con un retraso de algunas semanas. PageSpeed Insights aporta además valores de CrUX por URL. Desde el punto de vista del negocio cuenta la comparación del comportamiento de abandono y de las solicitudes de contacto antes y después de los cambios, a ser posible durante varias semanas, para que la temporada y las campañas no distorsionen la imagen.

No puede garantizarse que todos los indicadores se pongan en verde en cada página. Un servicio incrustado que la empresa necesita puede aportar una carga residual, y algunos públicos usan dispositivos poco potentes. Entonces importa dónde están las mayores fricciones y qué puede corregirse en ellas. Un balance intermedio honesto, con puntos abiertos, vale más que una nota global maquillada.

El retroceso más frecuente llega después del proyecto. Alguien sube una nueva imagen de cabecera en formato bruto, marketing incorpora otro script, un editor añade una galería de cincuenta imágenes. Ninguna de estas acciones tiene mala intención y cada una puede empeorar los indicadores. Las mejoras sin protección son, por tanto, solo una instantánea.

Los presupuestos de rendimiento hacen visibles los límites. Un presupuesto fija el tamaño máximo de las imágenes, los scripts y el peso total de la página, o qué valores de laboratorio no deben empeorar. En una pipeline de compilación pueden automatizarse estas comprobaciones, de modo que un despliegue llame la atención antes de publicarse. Además, un procesamiento de imágenes al subirlas evita que los editores introduzcan archivos sobredimensionados en el sistema.

A ello se suma una rutina sencilla: una mirada mensual a la Search Console, una breve revisión tras cambios importantes y una lista de scripts de terceros permitidos con sus responsables. Esta disciplina es menos espectacular que una reforma, pero evita que al cabo de un año vuelvan los mismos problemas.

Quien quiera mejorar los Core Web Vitals necesita primero un inventario honesto y solo después medidas. El primer paso no cuesta nada: abrir la Search Console, ver el informe de Core Web Vitals y comprobar qué tipos de página destacan en dispositivos móviles. Después, una ejecución de PageSpeed por cada página señalada ofrece las primeras pistas.

En las webs corporativas con muchas imágenes, el orden suele estar claro: imagen de cabecera y entrega de imágenes, después scripts de terceros, luego tipografías y diseño, y por último el código. Cada paso puede verificarse por separado, y cada uno aporta algo aunque el siguiente no llegue a ser necesario. El objetivo no es la mejor nota en la herramienta de pruebas, sino una página que los visitantes puedan usar sin fricciones.

Si desea saber en qué punto está su web, revisamos juntos sus datos de campo y señalamos las tres palancas con mejor relación entre efecto y esfuerzo. También forma parte del trabajo el resultado de que no haya nada urgente que hacer.