Corrección de errores de dimensiones de imagen y CLS en WordPress (guía 2026)

Los errores de dimensiones de imagen y el Cumulative Layout Shift (CLS) están entre los avisos más frecuentes que los administradores de sitios ven en Google Search Console y en PageSpeed Insights. Esta guía muestra cómo encontrar las causas en WordPress, corregir las plantillas y el flujo de medios y medir el CLS de forma reproducible, en lugar de dejar una sola URL en “verde” como un retoque cosmético.

El CLS mide la estabilidad visual: si algo salta en el viewport mientras la página carga, la puntuación sube. Los sospechosos habituales son la falta de width/height en <img>, las imágenes hero que cargan tarde y los banners de cookies y espacios publicitarios sin altura reservada. Documentación oficial para profundizar: web.dev sobre el CLS, web.dev sobre la optimización del CLS, MDN aspect-ratio y wp_get_attachment_image().

En tiendas y temas de revista aparece una y otra vez el mismo patrón: el tema a medida imprime las imágenes con marcado fijo, la redacción sube originales de 5000 píxeles y un plugin de optimización comprime los archivos sin escribir nunca las dimensiones en el HTML. PageSpeed se pone en “verde” en una URL de demostración y CrUX sigue en rojo, porque las plantillas de categoría y de producto usan otras rutas de imagen.

#Qué significan los errores de dimensiones de imagen en PageSpeed Insights

Durante años, Lighthouse avisaba de que los elementos de imagen no tenían width y height explícitos cuando el HTML no incluía dimensiones. En ese caso, el navegador solo conoce la relación de aspecto después de la descarga y empuja hacia abajo el texto y los botones. En fichas de producto con muchas miniaturas, todo eso se suma hasta dar un CLS en rojo.

Desde Lighthouse 13 estas comprobaciones tienen otro nombre. Según Chrome for Developers, las auditorías unsized-images y layout-shifts se integraron en el insight cls-culprits-insight, y prioritize-lcp-image y lcp-lazy-loaded en lcp-discovery-insight. Quien busque en el informe actual el nombre antiguo de la auditoría, sacado de un ticket o de un informe de agencia, ya no lo encontrará. La causa sigue siendo la misma.

En WordPress, los errores suelen surgir así:

• Plantillas a medida que usan <img src="..."> fijo, sin atributos
• Constructores de páginas que guardan el HTML de la imagen sin dimensiones en los metadatos de la entrada
• Iconos SVG sin viewBox y sin tamaño en CSS
• Imágenes de fondo en CSS, que no pueden llevar width/height en el marcado (el espacio debe reservarse en el contenedor)
• Shortcodes de galería de plugins antiguos que renderizan <img> sin la API de adjuntos
• URLs de CDN que solo replican el archivo y pierden los metadatos de la biblioteca de medios

Otro caso especial son las imágenes externas (hotlinking a recursos del fabricante o a CDN de redes sociales). WordPress no conoce sus dimensiones. O se alojan en local y se tratan como adjuntos, o se protege el contenedor que las rodea con una relación de aspecto fija y min-height.

#Cómo calcula Google el CLS

Cada desplazamiento individual recibe una puntuación a partir de dos factores: puntuación de desplazamiento = fracción de impacto × fracción de distancia. La fracción de impacto es la parte del viewport que ocupa el elemento inestable sumando ambos fotogramas. La fracción de distancia es el mayor trayecto que recorre, en relación con la dimensión mayor del viewport. Un elemento que, junto con su nueva posición, cubre la mitad del viewport y se desplaza un 15 % de la altura del viewport da 0,5 × 0,15 = 0,075.

El CLS ya no suma estos valores durante toda la vida de la página. web.dev define el CLS como la mayor ráfaga de desplazamientos: los desplazamientos separados por menos de un segundo forman una ventana de sesión, y una ventana dura como máximo cinco segundos. Cuenta la ventana con la suma más alta. Por eso, una página larga con muchos desplazamientos pequeños y separados en el tiempo no se pone en rojo automáticamente.

Para quien desarrolla temas hay dos excepciones importantes. Los desplazamientos que ocurren en los 500 ms siguientes a una entrada discreta (toque, clic, tecla) llevan la marca hadRecentInput y no cuentan para el CLS. Desplazar la página, arrastrar y hacer zoom con dos dedos no cuentan como esa entrada. Y las animaciones con transform no desplazan otros elementos, así que según web.dev no cuentan para el CLS.

Google evalúa los datos de campo (CrUX) con más rigor que una sola ejecución de Lighthouse en laboratorio. Lo que decide es el percentil 75 de las cargas de página, separado por móvil y escritorio. Por eso, después de una corrección, mida tipos de página reales (inicio, entrada, categoría, producto, carrito), no solo la URL que por casualidad se puso en verde.

El CLS de laboratorio y el de campo pueden divergir. En el laboratorio suelen faltar los banners de consentimiento, las pruebas A/B y los scripts lentos de terceros. Si Search Console indica “deficiente” y Lighthouse indica “bueno”, confíe en los datos de campo y active Layout Shift Regions en un móvil real o en una emulación realista.

#Cómo deriva el navegador la relación de aspecto a partir de width y height

Según MDN, los atributos width y height son números enteros sin unidad que indican el tamaño intrínseco en píxeles. No determinan el tamaño con el que se mostrará finalmente la imagen. Su utilidad: el navegador calcula con ellos la relación de aspecto antes de que la imagen se haya cargado. Los navegadores actuales aplican internamente un valor como aspect-ratio: auto 640 / 360 (web.dev).

El auto de ese valor tiene un significado preciso. MDN lo describe así: en un elemento reemplazado como <img>, se aplica la relación indicada hasta que el contenido se carga, y después la relación natural del archivo. Si los atributos y el archivo no coinciden, la imagen salta igualmente tras la carga. Es exactamente lo que ocurre cuando una plantilla escribe en los atributos las dimensiones del original pero sirve un tamaño con otro recorte.

De ahí salen tres reglas:

1. Todos los candidatos de un srcset necesitan la misma relación de aspecto; de lo contrario, los atributos solo son correctos para uno de ellos.
2. Con dirección de arte en <picture> y recortes distintos, cada <source> lleva sus propios width/height. Según web.dev, Chrome, Firefox y Safari ya lo admiten.
3. Las imágenes con carga diferida son las que más necesitan los atributos. MDN advierte que una imagen aún no cargada y sin dimensiones mide 0 × 0 píxeles y, por ello, puede que nunca entre en la zona visible que activaría su carga.

Una regla muy extendida pero ineficaz es aspect-ratio: attr(width) / attr(height). Sin indicación de tipo, attr() devuelve según MDN una cadena CSS, y una cadena no es una relación válida. La declaración se descarta. El navegador ya hace la derivación por sí mismo, así que la regla sobra.

#Cómo corregir el CLS de las imágenes en el marcado HTML

#1. Definir width y height

<img src="foto.jpg" width="800" height="600" alt="Descripción">

En WordPress, utilice preferentemente la función del núcleo que obtiene las dimensiones de los metadatos del adjunto:

echo wp_get_attachment_image( $attachment_id, 'large' );

wp_get_attachment_image() escribe width, height y, si existen tamaños intermedios, srcset/sizes. WordPress añade por sí mismo la clase attachment-large size-large y el atributo loading; no hace falta un 'loading' => 'lazy' propio, porque desde la 6.3 el núcleo decide qué imágenes pueden cargarse de forma diferida. Las etiquetas <img> fijas en temas heredados son el motivo más habitual por el que solo las entradas nuevas están “limpias” mientras el archivo antiguo sigue generando CLS.

Si usa campos de imagen de ACF, guarde el ID del adjunto, no solo la URL. Con el ID construye wp_get_attachment_image(). Con una URL suelta solo le queda adivinar o hacer una consulta adicional a la tabla de adjuntos.

#2. CSS aspect-ratio para contenedores y recortes

Para las imágenes de contenido con atributos correctos basta una regla responsive básica. Una relación fija en todas las imágenes de contenido obligaría a los formatos verticales y a las panorámicas a pasar a 4:3 y las deformaría:

.entry-content img {
  max-width: 100%;
  height: auto;
}

.hero-media img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

Un aspect-ratio fijo corresponde a componentes con un recorte deliberado: hero, cuadrículas de tarjetas, mosaicos de producto, vídeos incrustados y contenedores con imagen de fondo. Combínelo con valores de sizes razonables; de lo contrario, el navegador descarga variantes demasiado grandes y el LCP se resiente a la vez que el CLS.

Antes de aspect-ratio, los temas reservaban espacio con el truco del padding-bottom: un contenedor con height: 0 y padding-bottom: 56.25% (9 dividido entre 16) y dentro una imagen con posición absoluta. Sigue funcionando, pero requiere marcado adicional. Si hereda temas antiguos, compensa pasar a aspect-ratio en la próxima refactorización de plantillas, no como un proyecto aparte.

#3. Usar bien el lazy loading

El lazy loading corresponde a lo que queda por debajo del pliegue. El elemento LCP (a menudo la imagen hero) no debe llevar loading="lazy". De lo contrario, el navegador retrasa la descarga hasta que el diseño está resuelto. En nuestra guía de Core Web Vitals encontrará el resto de fases del LCP.

En la plantilla, la vía más directa es marcar explícitamente la imagen hero como importante:

echo wp_get_attachment_image(
	$hero_id,
	'full',
	false,
	array(
		'class'         => 'hero-media__img',
		'fetchpriority' => 'high',
	)
);

Con fetchpriority="high", wp_get_loading_optimization_attributes() trata la imagen como visible y omite loading="lazy". El método antes habitual, el filtro wp_get_attachment_image_attributes que cambia loading a eager a posteriori, tiene una pega desde WordPress 6.7: en ese momento el núcleo ya ha antepuesto auto a sizes en las imágenes diferidas. Según la nota de desarrollo de la 6.7, los navegadores rechazan sizes="auto, ..." en una imagen que no se carga de forma diferida y recurren a 100vw. La imagen hero se descarga entonces en su variante más grande. Si tiene que mantener el filtro, elimine el prefijo:

add_filter( 'wp_get_attachment_image_attributes', function ( $attr ) {
	if ( ! empty( $attr['class'] ) && false !== strpos( $attr['class'], 'skip-lazy' ) ) {
		$attr['loading']       = 'eager';
		$attr['fetchpriority'] = 'high';
		if ( isset( $attr['sizes'] ) ) {
			$attr['sizes'] = preg_replace( '/^\s*auto\s*,\s*/i', '', $attr['sizes'] );
		}
	}
	return $attr;
} );

Según MDN, fetchpriority es solo una indicación para el navegador, con los valores high, low y auto. Ponga high en una sola imagen por página; si no, varias descargas compiten por la misma prioridad.

En los temas de tienda es frecuente que la primera imagen de producto se cargue de forma diferida porque un filtro genérico marca todas las img. Una excepción para lo que está por encima del pliegue ahorra CLS y LCP. Revise también los sliders: si las diapositivas 2 y 3 son diferidas pero la 1 no tiene dimensiones, todo el marco del carrusel salta igualmente.

#Qué hace WordPress automáticamente desde 5.5, 6.3 y 6.7

Muchos tutoriales recomiendan código para cosas de las que el núcleo se encarga desde hace tiempo. El estado según las notas de desarrollo oficiales:

El completado de dimensiones se ejecuta en wp_filter_content_tags(), que default-filters.php engancha a the_content con prioridad 12, es decir, después de los shortcodes. El lazy loading omite las tres primeras imágenes del contenido; el número lo controla el filtro wp_omit_loading_attr_threshold. Para recibir fetchpriority="high", según la nota de la 6.3 una imagen debe tener una superficie de al menos 50.000 píxeles, ajustable con wp_min_priority_img_pixels. Por eso un logotipo pequeño no recibe la prioridad.

La consecuencia práctica: las imágenes insertadas desde el editor de bloques con referencia a la biblioteca de medios rara vez son el problema en las versiones actuales. Los errores están en las plantillas del tema, la salida de los constructores, el HTML fijo y las imágenes sin la clase wp-image-{ID}.

#Qué tamaños de imagen crea WordPress al subir un archivo

Según el código fuente de WordPress, una instalación nueva crea estos tamaños: thumbnail 150 px, medium 300 px, medium_large 768 px y large 1024 px (ancho en cada caso, modificable en los ajustes). Desde la 5.3 se suman 1536x1536 y 2048x2048. También desde la 5.3, WordPress reduce los originales cuyo lado más largo supera 2560 px hasta ese límite y los guarda con el sufijo -scaled; el filtro big_image_size_threshold cambia o desactiva ese valor.

Para el srcset, wp_calculate_image_srcset() solo incluye variantes con la misma relación de aspecto y, por defecto, corta en 2048 px de ancho (filtro max_srcset_image_width). Los tamaños propios del tema registrados con add_image_size() y recorte fijo (crop = true) tienen una relación distinta a la del original y por eso no entran en el srcset del original. Una cuadrícula de tarjetas con recorte 4:3 necesita, por tanto, varios tamaños propios en la misma relación 4:3; si no, solo hay un archivo para todas las pantallas.

#Cómo usar imágenes responsive y srcset en WordPress

El núcleo genera srcset cuando se usan las APIs de adjuntos. Los constructores de páginas y los campos de imagen de ACF con URL manual se lo saltan. Entonces faltan las dimensiones y las variantes adecuadas.

Cómo elige el navegador: con descriptores w en el srcset ignora src y usa sizes para determinar el ancho de visualización previsto. Si falta sizes, según MDN se aplica 100vw. Por eso WordPress define desde la 4.4 un valor por defecto que sigue el patrón (max-width: {ancho}px) 100vw, {ancho}px; se espera que los temas lo ajusten al diseño real con el filtro wp_calculate_image_sizes. Desde la 6.7, el núcleo antepone auto en las imágenes con carga diferida para que el navegador use el ancho realmente renderizado.

Lista de comprobación para redacción y desarrollo:

1. Biblioteca de medios: no subir originales de 6000 px de ancho sin necesidad
2. El tema registra variantes razonables con add_image_size en la misma relación de aspecto
3. Las plantillas nunca llaman solo a wp_get_attachment_url() para imágenes de contenido visibles
4. Tras un cambio de tema, regenerar los tamaños intermedios (por ejemplo, wp media regenerate); si no, faltan candidatos en el srcset
5. Ajustar el atributo sizes al ancho real del diseño (barra lateral frente a ancho completo)

Un caso típico de revista: el contenido mide 720 px de ancho en escritorio y 100 vw en móvil. Si sizes es 100vw, el navegador de escritorio suele descargar la variante de 2048 píxeles para una columna de 720 píxeles. No es un fallo de CLS, pero alarga el LCP y la página se percibe pesada. Conviene pensar en el CLS y el LCP a la vez, no uno detrás de otro.

#Imagen más pequeña de lo recomendado: requisitos de Discover y del marcado de artículos

El aviso de Search Console sobre una imagen más pequeña de lo recomendado no tiene nada que ver con el CLS. Afecta a la imagen que Google usa para las vistas previas, es decir, la imagen destacada, og:image y el campo image de los datos estructurados de artículo. Este aviso procede de la época de AMP (vea si Google AMP ha muerto en 2026 y qué usar en su lugar); los requisitos actuales figuran en dos documentos de Google.

Para Google Discover, las imágenes grandes deben tener al menos 1200 px de ancho, superar los 300.000 píxeles de superficie y tener una relación de 16:9. Las vistas previas grandes solo aparecen si la página permite max-image-preview:large o usa AMP. No le dé a Google el logotipo del sitio como og:image ni como imagen de vista previa en el marcado de schema.

La documentación del marcado de artículo recomienda varias imágenes de alta resolución con al menos 50.000 píxeles (ancho por alto) en las relaciones 16:9, 4:3 y 1:1. Las URLs de las imágenes deben poder rastrearse e indexarse.

Un script de control para la redacción que registra en el log las imágenes destacadas demasiado estrechas al publicar:

add_action( 'publish_post', function ( int $post_id ) {
	$thumbnail_id = get_post_thumbnail_id( $post_id );
	if ( ! $thumbnail_id ) {
		return;
	}
	$meta  = wp_get_attachment_metadata( $thumbnail_id );
	$width = (int) ( $meta['width'] ?? 0 );
	if ( $width < 1200 ) {
		error_log( sprintf( 'Entrada %d: imagen destacada de solo %d px de ancho.', $post_id, $width ) );
	}
} );

En las subidas escaladas, wp_get_attachment_metadata() devuelve las dimensiones del archivo -scaled, es decir, 2560 px como máximo. Para Discover es suficiente.

#Cómo evitar el CLS en WooCommerce y en diseños de cuadrícula

Las cuadrículas de productos son puntos calientes de CLS. Cada mosaico necesita el mismo marco de imagen. Si un producto no tiene imagen destacada y el recurso alternativo es un PNG de marcador más estrecho, la tarjeta salta. Defina en el tema un contenedor uniforme con relación de aspecto y object-fit: cover para las imágenes de producto.

Variaciones y galerías: WooCommerce cambia las miniaturas con JavaScript. Reserve la altura de la galería antes de que se ejecuten los scripts de variaciones. Si no, alguien hace clic en “talla M”, la imagen grande carga tarde y el botón de añadir al carrito se mueve. Los desplazamientos en los 500 ms siguientes al clic no cuentan para el CLS, pero una carga posterior sí, y el botón se escapa bajo el dedo en cualquier caso.

#Cómo causan CLS las fuentes web, los banners y los scripts de terceros

No todo CLS es un problema de imágenes. Los banners de cookies que pasan de 0 a 120 px tras el consentimiento, las fuentes sin una estrategia de font-display adecuada y los widgets de afiliación tardíos generan las mismas regiones de desplazamiento en DevTools. Reserve alturas mínimas para las barras de consentimiento y los espacios publicitarios antes de que carguen los scripts. web.dev aconseja además no colapsar el espacio reservado cuando no se sirve ningún anuncio, sino mostrar un marcador de posición.

En Chrome: DevTools, luego Rendering y luego Layout Shift Regions. Recargue y las zonas azules señalan a los culpables. Fíjese en la emulación móvil; el CLS de escritorio puede estar en “verde” mientras el CrUX móvil sigue en rojo.

Otras fuentes además de las imágenes:

• Fuentes web que pasan de la alternativa a la personalizada (según web.dev, font-display: optional solo usa la fuente si ya está disponible en el primer diseño)
• Vídeos e iframes incrustados sin caja con relación de aspecto
• Cabeceras fijas que crecen según la posición de desplazamiento
• Burbujas de chat en vivo que aparecen solo cuando la página queda inactiva
• Animaciones con top, left o height en lugar de transform

#Cómo reparar entradas antiguas mediante código

Para las imágenes con la clase wp-image-{ID} no hace falta código propio: desde la 5.5, wp_filter_content_tags() añade por sí mismo los width/height que faltan, con las dimensiones del tamaño realmente insertado. Un filtro que inserte en su lugar las dimensiones de full escribe atributos incorrectos en una miniatura de 300 px.

El código propio solo compensa para etiquetas sin esa clase, por ejemplo de contenido importado o de HTML antiguo de constructores. El siguiente filtro se ejecuta después del núcleo, busca el ID del adjunto a partir de la URL y toma las dimensiones del tamaño correspondiente:

add_filter( 'the_content', function ( $content ) {
	if ( false === strpos( $content, '<img' ) ) {
		return $content;
	}

	return preg_replace_callback(
		'/<img\b[^>]*>/i',
		function ( $matches ) {
			$img = $matches[0];
			if ( preg_match( '/\swidth=/i', $img ) || ! preg_match( '/\ssrc="([^"]+)"/i', $img, $src ) ) {
				return $img;
			}
			// attachment_url_to_postid() solo conoce la URL original, así que se quita el sufijo de tamaño.
			$original = preg_replace( '/-\d+x\d+(?=\.\w+$)/', '', strtok( $src[1], '?' ) );
			$id       = attachment_url_to_postid( $original );
			if ( ! $id ) {
				return $img;
			}
			$size = wp_image_src_get_dimensions( $src[1], wp_get_attachment_metadata( $id ), $id );
			if ( ! $size ) {
				return $img;
			}
			return str_replace( '<img', sprintf( '<img width="%d" height="%d"', $size[0], $size[1] ), $img );
		},
		$content
	);
}, 13 );

Es una red de seguridad, no un sustituto de unas plantillas limpias. attachment_url_to_postid() lanza una consulta a la base de datos por imagen; en archivos grandes compensa una ejecución única con WP-CLI que escriba los atributos en post_content, en lugar de filtrar en cada petición. Las imágenes de dominios externos se dejan como están: consultarlas en tiempo de ejecución con getimagesize() descarga el archivo del servidor externo en cada fallo de caché.

#Cómo medir y comprobar el CLS después de las correcciones

Después de cada corrección no basta con volver a ejecutar Lighthouse. Un proceso que funciona en proyectos de agencia:

1. Abrir el informe de Core Web Vitals en Search Console y anotar los grupos de URLs afectados
2. Revisar una URL por tipo de plantilla con Layout Shift Regions
3. Emular un Android de gama media (no solo un escritorio)
4. Esperar 28 días de datos de campo tras el despliegue antes de dar el trabajo por terminado, porque CrUX evalúa una ventana móvil de 28 días
5. Regresión: un nuevo bloque hero o una nueva CMP de cookies necesita la misma comprobación

Para obtener datos de campo propios sirve la biblioteca web-vitals de Google. Informa del CLS con la misma lógica de ventanas de sesión que CrUX:

import { onCLS } from 'web-vitals';

onCLS( ( metric ) => {
	navigator.sendBeacon( '/vitals', JSON.stringify( {
		name: metric.name,
		value: metric.value,
		id: metric.id,
	} ) );
} );

Documente qué tipos de página ha medido. Si solo la página de inicio está en verde y la entrada individual sigue en rojo, el trabajo no está terminado. Redacción y desarrollo necesitan una definición común de “terminado”.

#Lista de comprobación de errores de dimensiones de imagen y CLS en WordPress

• Todas las imágenes de contenido visibles pasan por las APIs de adjuntos
• Hero sin loading="lazy", con fetchpriority="high" en una sola imagen
• Ningún sizes="auto, ..." en imágenes que no se cargan de forma diferida
• Los add_image_size del tema cubren cuadrícula, entrada individual y OG, cada uno en la misma relación
• Imágenes destacadas de al menos 1200 px de ancho, max-image-preview:large definido
• Los banners de consentimiento y los espacios publicitarios tienen altura reservada
• CrUX y Search Console revisados de nuevo tras el despliegue
• Ningún hero de fondo sin contenedor con relación de aspecto
• Los recursos alternativos de la cuadrícula de productos mantienen la misma altura de mosaico

#Errores típicos de CLS por imágenes en proyectos WordPress

• Plugin de optimización activado, pero el tema sigue renderizando etiquetas <img> fijas
• Una bifurcación AMP o un “tema móvil” con un marcado distinto al de escritorio
• La conversión a WebP reemplaza archivos, pero deja candidatos antiguos en el srcset
• La redacción inserta capturas de pantalla de la ventana completa del navegador (3000×2000) sin recortar
• El constructor de páginas guarda anchos absolutos en píxeles que se rompen en móvil y luego se corrigen con JavaScript

#Preguntas frecuentes sobre tamaños de imagen y CLS en WordPress

#Qué causa el CLS de las imágenes en WordPress

Lo habitual es que falten dimensiones fijas, variantes responsive o espacio reservado en la plantilla. Por eso el diseño salta en cuanto las imágenes terminan de cargarse.

#Cómo corregir bien los errores de tamaño de imagen

Revise a la vez las plantillas, los tamaños de imagen, la salida de srcset y las reglas CSS. Después, vuelva a medir el CLS en tipos de página reales, no solo en una URL suelta.

#Con qué frecuencia revisar el CLS

Después de cambios en el tema, nuevos componentes, subidas grandes de medios y avisos de Core Web Vitals en Search Console.

#Si width y height rompen el diseño responsive

No. Los atributos HTML aportan la relación de aspecto. Con CSS max-width: 100% y height: auto, la imagen se escala y el espacio reservado se mantiene.

#Conclusión

Los errores de dimensiones de imagen rara vez son un problema de un solo plugin. Aparecen donde las plantillas se saltan la API de adjuntos, donde el hero y el lazy loading chocan y donde se ignoran los datos de campo. Si fija las dimensiones, la relación de aspecto y unas mediciones reproducibles, obtendrá diseños más estables y menos avisos en Search Console, sin retoques cosméticos de PageSpeed en una URL de demostración.

Más contexto sobre el trabajo de rendimiento: optimización de velocidad de WordPress. Si además le interesa la visibilidad en buscadores, vea nuestros servicios de SEO para WordPress y el desarrollo WordPress de WPPoland.