Optimización moderna de imágenes para WordPress en 2026

AVIF es aceptado por el 96,35% del uso de navegadores que mide caniuse (dato a 12 de octubre de 2026). El capítulo de medios del Web Almanac de 2024 lo encontró en el 1,0% de las imágenes en móvil. Esa distancia de más de 95 puntos no la explican los navegadores: la explican la ruta de subida, el marcado que elige el candidato y el momento en que el navegador se entera de que la imagen existe.

Por eso esta guía no empieza por la tabla de formatos. Empieza por el diagnóstico, sigue por la subida y termina por la entrega, que es el orden en el que se rompen las cosas en un sitio que ya está en producción.

Las tres capas donde se pierde el trabajo, en el orden en que se atraviesan:

• Subida: qué formato y qué ancho máximo llega a producir el servidor.
• Marcado: qué candidato del srcset acaba eligiendo el navegador.
• Descubrimiento: en qué momento se entera el navegador de que la imagen existe.

#Cómo identificar el elemento LCP en WordPress

Antes de convertir nada, confirma qué elemento es el Largest Contentful Paint de cada plantilla, con datos de campo y no con una suposición. El Web Almanac de 2024 midió que en el 68% de las páginas móviles ese elemento es una imagen, con una mediana de 135 KB para la imagen más grande. Leído al revés: en el 32% restante el LCP es texto, y ahí una pasada de conversión a AVIF no mueve la métrica ni un milisegundo.

Hay dos casos en los que el núcleo de WordPress no puede ayudarte aunque el LCP sí sea una imagen:

1. El elemento LCP no es una etiqueta img que haya renderizado el núcleo. Un fondo CSS, el póster de un video, o un maquetador que escribe el marcado fuera de wp_filter_content_tags(). El núcleo no prioriza lo que no ve, así que el hero llega después de la hoja de estilos que lo referencia.
2. El elemento LCP cambia según el breakpoint. La foto de cabecera en escritorio y la tarjeta en móvil son elementos distintos. Una suposición estática acierta en uno de los dos.

Para esos dos casos existe Image Prioritizer, que depende de Optimization Detective. Optimization Detective recoge URL Metrics de visitantes reales por breakpoint, de modo que sabe qué elemento fue el LCP en lugar de deducirlo del orden del documento. Con esos datos Image Prioritizer añade una precarga de alta prioridad para la imagen LCP, como elemento LINK en el HTML y como cabecera HTTP Link, y la precarga cubre también fondos CSS (en línea o de hoja de estilos) y pósteres de vídeo. Pone fetchpriority=high en un img solo cuando ese elemento es el LCP en todos los breakpoints, pone fetchpriority=low en las imágenes que están dentro del viewport inicial pero ocultas (las diapositivas dos y tres de un carrusel, el caso de siempre) y difiere la carga de los fondos declarados en atributos style en línea. No tiene pantalla de ajustes y solo actúa cuando ya hay métricas de visitantes recogidas.

Ambos plugins salen del equipo de rendimiento del núcleo, el mismo que publica en make.wordpress.org/performance. No son utilidades de terceros: son el laboratorio de lo que acaba entrando en WordPress, así que lo que hoy instalas como plugin es la dirección oficial del proyecto.

#Cómo activar AVIF en WordPress

WordPress 6.5 añadió soporte para AVIF en febrero de 2024, en un trabajo que anunció Adam Silverstein. Desde entonces puedes subir y servir .avif igual que un JPEG, sin plugins, siempre que la compilación de Imagick o LibGD del servidor sepa codificarlo. Esa condición tiene su propia pantalla en el administrador: Herramientas > Salud del sitio > Información > Gestión de medios.

Ese es el punto donde conviene bajar de la teoría al alojamiento real. En España y en Latinoamérica una parte grande del parque WordPress vive en planes compartidos de proveedores como Webempresa, Raiola Networks, Dinahosting, SiteGround, DonWeb u Hostinger, y en compartido tú no eliges la compilación de ImageMagick: la heredas. La versión de PHP del panel no te dice nada sobre los delegados de Imagick, y una migración entre planes del mismo proveedor puede cambiarlos. Abre Salud del sitio después de cada mudanza y después de cada actualización mayor del servidor, y trata el resultado como un dato del proyecto, no como una comprobación puntual. Un tema que da AVIF por hecho en un servidor sin soporte no produce nada y tampoco avisa.

Lo segundo que hay que interiorizar es que el núcleo no convierte nada por su cuenta. Un JPEG subido sigue siendo un JPEG, y sus subtamaños siguen siendo JPEG. El gancho que cambia eso es image_editor_output_format, disponible desde WordPress 5.8, que asocia un tipo mime de origen a un tipo mime de salida:

add_filter( 'image_editor_output_format', function ( $formats ) {
    $formats['image/jpeg'] = 'image/avif';
    return $formats;
} );

Tres consecuencias antes de desplegar ese filtro:

• El archivo original se conserva intacto. Solo los subtamaños generados adoptan el formato nuevo, que es lo que mantiene la biblioteca de medios reeditable.
• Se aplica solo a subidas futuras. Los medios existentes necesitan una pasada de regeneración.
• Su valor por defecto ya no está vacío. Desde WordPress 6.7 el núcleo incluye en ese filtro las asignaciones de HEIC y HEIF a JPEG, así que devuelve el array que recibiste en lugar de construir uno nuevo. Quien escribió return array( 'image/jpeg' => 'image/avif' ); en 2023 está desactivando hoy, sin saberlo, la conversión de las fotos que llegan desde un iPhone.

El otro ajuste del núcleo que condiciona cada subida es big_image_size_threshold, 2560 píxeles desde WordPress 5.3. Cualquier imagen más ancha o más alta se reduce, y la copia reducida pasa a ser el tamaño mayor disponible. Las subidas PNG quedan fuera de ese escalado. Si tu hueco de cabecera es realmente más ancho que 2560, ya estás sirviendo una imagen ampliada, y ningún trabajo de formato arregla esa falta de nitidez.

#Cuánto tarda codificar imágenes AVIF

La documentación de transformaciones de Cloudflare dice que codificar AVIF puede ser un orden de magnitud más lento que codificar a otros formatos, y que si una imagen es demasiado grande para codificarse rápido, Cloudflare recurre a WebP o JPEG. La misma aritmética se aplica en tu origen, y con más motivo en un plan compartido con límite de procesos. Convertir en bloque una biblioteca de 40.000 elementos es un trabajo por lotes con cola y con ventana horaria, no un clic en una pantalla de ajustes.

#Cómo regenerar miniaturas con WP-CLI

El filtro solo alcanza a las subidas nuevas, así que una biblioteca existente necesita una pasada explícita. wp media regenerate recorre los adjuntos y vuelve a crear los subtamaños con la configuración vigente, incluido el formato de salida que acabas de fijar. Dos banderas evitan buena parte de los disgustos: --only-missing, para no repetir lo ya hecho en una ejecución anterior que se cortó, y --image_size, para acotar la pasada a un tamaño concreto cuando solo cambió uno.

wp media regenerate --only-missing --yes

Acota la ejecución además de la orden. En compartido, una regeneración sobre decenas de miles de adjuntos compite por la misma CPU que atiende el tráfico real, y AVIF es justo el formato que más pide. Trocea la biblioteca por rangos de identificador, ejecuta fuera de hora punta y guarda el registro: el listado de adjuntos que fallan es el inventario de originales corruptos que llevaba años sin ver nadie.

Si el resultado no convence, la salida es repetir la pasada con otro ajuste de calidad, no restaurar una copia de seguridad. El original nunca se tocó.

#Qué calidad de compresión usar en WordPress

WP_Image_Editor::$default_quality vale 82, obsoleto desde WordPress 5.8.1 en favor de get_default_quality(), que devuelve 86 para WebP y ese mismo 82 para JPEG y para todo lo demás. JPEG pasa después por el filtro jpeg_quality, que se ejecuta detrás de wp_editor_set_quality y por tanto tiene la última palabra.

Los dos filtros reciben argumentos distintos, y confundirlos es la forma habitual de que una regla pensada para un formato acabe aplicándose a todos. wp_editor_set_quality recibe la calidad por defecto, el tipo mime y, desde WordPress 6.8, las dimensiones, así que permite variar la calidad por formato y por tamaño. jpeg_quality recibe solo la calidad y una cadena de contexto como image_resize. Un portafolio de fotografía y una biblioteca de capturas de interfaz no quieren el mismo número.

Conviene además saber cómo se rompe cada formato cuando el número es demasiado bajo. JPEG falla de forma visible, con bloques y halos que se detectan hasta en una miniatura. AVIF a calidad baja suaviza la textura fina: grano, tejido, follaje y pelo pierden detalle mientras los bordes siguen limpios. Ese modo de fallo es mucho más difícil de ver a tamaño pequeño, así que la revisión tiene que hacerse a resolución completa y sobre la plantilla real, no sobre la cuadrícula de la biblioteca de medios.

Y aquí va el aviso sobre las cifras. La idea de que un codificador detecta una cara, comprime el cielo con agresividad y entrega un ahorro concreto del 70% circula sin fuente que la sostenga. Trata cualquier número de ese tipo como no verificado hasta que lo hayas medido sobre tu propia biblioteca. Un panel de plugin que informa de un porcentaje ahorrado está informando sobre archivos en disco, no sobre lo que descargó el navegador después de que el edge negociara el formato. Solo cuentan dos medidas: los bytes entregados del recurso LCP y el resultado visual en la plantilla en la que se publica.

La comprobación práctica cabe en veinte minutos. Fija un conjunto pequeño de imágenes representativas de tu biblioteca real (una cara, un producto sobre fondo blanco, una captura con texto pequeño y un paisaje apaisado), codifícalo con cada ajuste candidato y mira el resultado a tamaño completo. Eso evita publicar un valor global que destroce la fotografía de producto.

#Cómo usar srcset y sizes en WordPress

Un formato eficiente con unas dimensiones equivocadas sigue arruinando el LCP. Si el hero en móvil ocupa 390 px de ancho CSS y el src apunta a un archivo de 2000 px, el navegador descarga megabytes de más, aunque sea AVIF.

WordPress registra los tamaños con add_image_size() y, al renderizar, wp_get_attachment_image_srcset() construye la lista de candidatos. El atributo sizes le dice al navegador qué ancho CSS se espera en cada breakpoint. Sin un sizes realista (por ejemplo (max-width: 768px) 100vw, 720px), el navegador puede elegir un candidato demasiado grande. Qué tamaños crea WordPress por defecto y cómo registrar los tuyos lo repasamos en la guía sobre TimThumb y el manejo nativo de imágenes.

Lista de comprobación breve:

• Registra solo los tamaños que usa el tema (evita decenas de recortes muertos).
• Regenera las miniaturas después de cada cambio (wp media regenerate, véase más arriba).
• En el hero, confirma en la pestaña Network de DevTools el ancho del archivo elegido, no solo el Content-Type.
• En los bloques de Gutenberg, mantén las imágenes alineadas con el ancho de contenido del tema; las subidas de 5000 px “porque ya recortaremos después” inflan el almacenamiento y el tiempo de generación.

Documentación útil: la referencia de wp_get_attachment_image_srcset en el Developer Handbook y el material sobre imágenes de web.dev explican la misma idea desde dos lados (el CMS y el navegador).

#Fetchpriority y sizes auto en WordPress 6.3 y 6.7

El consejo de añadir loading="eager" y fetchpriority="high" a mano lleva tres años desfasado para las imágenes de contenido. WordPress 6.3 añadió wp_get_loading_optimization_attributes(), que calcula ambos atributos para las imágenes que pasan por la ruta de renderizado del núcleo:

• La primera imagen que cumple el umbral recibe fetchpriority="high". Cumplir significa un área mínima de 50.000 píxeles, ancho por alto, ajustable con el filtro wp_min_priority_img_pixels.
• loading="lazy" se omite en las imágenes cercanas al principio del documento. El filtro del umbral es wp_omit_loading_attr_threshold, cuyo valor por defecto subió de 1 a 3 en la 6.3.
• La función nunca emite fetchpriority="high" y loading="lazy" juntos, porque son instrucciones contradictorias.

WordPress 6.7 añadió después sizes="auto" para imágenes con carga diferida, mediante wp_img_tag_add_auto_sizes(). Es la corrección del error de srcset más antiguo de WordPress: el atributo sizes generado daba por supuesto que la imagen ocupaba todo el viewport, así que una miniatura de barra lateral de 300 píxeles podía arrastrar en móvil un candidato de 1024. Como una imagen diferida no se carga hasta que el diseño está resuelto, el navegador ya puede usar el ancho real. El núcleo antepone auto solo cuando la imagen ya lleva loading="lazy", y encola una pequeña regla CSS (wp_enqueue_img_auto_sizes_contain_css_fix()) para evitar un efecto lateral de diseño.

La lectura útil de las dos versiones juntas: la prioridad y el ancho ya no son decisiones del tema. Si tu plantilla sigue forzando esos atributos a mano, lo más probable es que esté peleando contra el núcleo en lugar de con el navegador.

#Cómo servir AVIF con respaldo JPEG

El núcleo escribe un único src y un srcset. No escribe <picture>, lo que significa que por sí solo no puede servir AVIF a los navegadores que lo aceptan y JPEG a los que no desde el mismo marcado. Obtienes un formato por cada tamaño generado. Hay dos respuestas viables, y son excluyentes en la práctica.

Negociación de contenido en el edge o en el servidor. El CDN lee la cabecera Accept y sirve AVIF, WebP o JPEG desde una sola URL. Mantiene el HTML simple. El coste es que el cacheado pasa a depender de cabeceras de petición, así que las claves de caché tienen que tenerlo en cuenta, y una configuración descuidada sirve AVIF a un cliente que no lo acepta.

Respaldo a nivel de marcado. El plugin Modern Image Formats, parte del programa Performance Lab, genera subtamaños en formatos modernos al subir y, desde la versión 2.0.0, puede emitir elementos <picture> con respaldos. Su elección por defecto es AVIF cuando el servidor lo soporta y WebP en caso contrario, que es el valor correcto para un plugin que no puede conocer tu infraestructura. Sus ajustes viven en Ajustes > Medios, incluido si conservar los originales de respaldo. Igual que con el filtro del núcleo, se aplica a subidas nuevas.

Y conserva el JPEG. Fuera del navegador sigue siendo el formato seguro para clientes de correo, imágenes de Open Graph, tarjetas sociales, lectores de RSS y cualquier feed que consuma un socio. Modern Image Formats conserva el archivo original subido, pero por defecto genera los subtamaños de JPEG y PNG solo en el formato moderno. Si un feed o una tarjeta social necesita subtamaños JPEG, activa la casilla Output fallback images en Ajustes > Medios: el plugin generará el formato original junto al moderno en cada subtamaño, a cambio de más disco y más tiempo por subida.

#Redimensionar imágenes con Cloudflare en WordPress

La transformación en el edge saca el redimensionado y la negociación de formato del origen PHP, que es un argumento de peso cuando el origen es un plan compartido. En Cloudflare eso significa una URL con la forma https://<ZONA>/cdn-cgi/image/<OPCIONES>/<IMAGEN-ORIGEN>, donde el origen es una ruta absoluta en el servidor o una URL absoluta, y las opciones van separadas por comas. La que importa aquí es format=auto, que sirve el formato más eficiente que acepte quien pide.

Tres cosas que dice la documentación y que cambian la planificación:

• Hay que activarlo por zona en el panel antes de que ninguna URL de transformación resuelva en ese host. Es el motivo más frecuente de que una URL bien escrita devuelva el original sin redimensionar.
• Las imágenes de origen están restringidas a la misma zona por defecto. Los orígenes aceptados parten de una lista de permitidos que Cloudflare documenta aparte del formato de URL: un subdominio de medios separado o un bucket S3 hay que añadirlo a esa lista, o abrir la zona a cualquier origen.
• format=auto puede rechazar AVIF. Por el coste de codificación ya citado, Cloudflare recurre a WebP o JPEG cuando la imagen es demasiado grande para codificarse rápido. Su cabecera puede ser AVIF en pruebas y WebP en producción según las dimensiones del origen, y esa diferencia no aparece en ningún informe de plugin.

Lo que el edge no elimina es la necesidad de un srcset y un sizes correctos (cómo los construye WordPress a partir de add_image_size() lo explicamos en la guía sobre TimThumb y el manejo nativo de imágenes). El navegador elige el candidato antes de hacer la petición, así que un marcado equivocado pide un ancho equivocado y el edge genera con toda obediencia exactamente ese ancho equivocado. El edge sustituye el juego fijo de tamaños de WordPress por anchos arbitrarios; no sustituye la lógica de selección.

#Qué navegadores soportan JPEG XL en 2026

Aquí es donde se equivocan la mayoría de las guías de 2026. JPEG XL apenas empieza a llegar a la entrega.

El primer cambio real llegó el 6 de octubre de 2026. El anuncio de Google dice: “Chrome incorpora la compatibilidad de decodificación del formato de imagen JPEG XL (.jxl) a partir de Chrome 155” (Chrome for Developers, traducción propia). Los usuarios de Chrome de escritorio lo reciben a medida que el navegador se actualiza en las semanas siguientes. Edge, que usa el mismo motor, todavía no lo ha seguido.

Una semana después, el 13 de octubre de 2026, salió Firefox 158. Sus notas de versión en MDN dicen: “La compatibilidad con el formato de imagen JPEG XL (image/jxl) ahora está activada por defecto” (MDN, traducción propia). La cabecera Accept por defecto para las peticiones de imágenes es ahora image/avif,image/jxl,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5, así que una CDN que elige el formato según esa cabecera verá JXL también en los usuarios de Firefox.

caniuse sitúa JPEG XL en el 60,19% de soporte global a 20 de octubre de 2026, frente al 16,95% del 12 de octubre y al 15,02% cuando se escribió esta sección. De esa cifra, el 43,26% es soporte completo y el 16,93% parcial: Safari solo decodifica imágenes estáticas, sin decodificación progresiva. El estado real, navegador por navegador:

El Web Almanac ni siquiera midió el uso de JPEG XL en 2024, y explicó el motivo: los navegadores basados en Chromium no soportaban el formato. Es una señal más honesta que cualquier gráfico de adopción, porque el conjunto de datos que mide la web entera no lo consideró un formato de entrega. Chrome 155 cambia los datos de la próxima edición, no la conclusión para un sitio que publique este mes. Edge, Samsung Internet y el núcleo de WordPress siguen sin soportar JPEG XL, el soporte de Safari es parcial y AVIF ya llega al 96,35% del uso de navegadores, así que JXL todavía aporta poco como formato de entrega y de momento se queda fuera del srcset.

El tamaño de archivo tampoco favorece a JPEG XL. La comparativa de Jake Archibald (15 de octubre de 2026) encontró que AVIF genera archivos más pequeños en la mayoría de los usos web: en fotos con pérdida, el mejor archivo JPEG XL suele ser un 15-25% más grande que el AVIF equivalente con el esfuerzo predeterminado del codificador, y en capturas de pantalla e ilustraciones un 30-90% más grande. El núcleo de WordPress sigue rechazando las subidas de archivos .jxl. El pull request #12006 de wordpress-develop, que añade soporte en el servidor dentro del ticket de Trac #52788, seguía abierto el 23 de octubre de 2026. Incluso ese cambio hace que el navegador suba una versión JPEG o PNG para el sitio y deja el archivo .jxl solo como original guardado.

Qué significa en la práctica:

• Como formato de archivo o de máster es genuinamente bueno. La transcodificación sin pérdida desde y hacia JPEG es una función real y una razón real para guardar másteres en JXL. Jake Archibald midió que los JPEG existentes quedan entre un 9% y un 20% más pequeños al convertirlos a JPEG XL sin pérdida adicional. Eso es una decisión de almacenamiento, no de entrega, y no toca tu srcset.
• Si decides servirlo, tiene que ir como primer <source type="image/jxl"> dentro de un <picture> con una fuente AVIF y un JPEG de respaldo detrás. Quienes usan Edge, Samsung Internet o navegadores antiguos tomarán uno de los respaldos, así que la rama JXL no te ahorra construir el resto.
• No lo uses como argumento para posponer AVIF. AVIF es el formato con un 96,35% de soporte hoy.

Actualización del 23 de octubre de 2026. John Mueller, de Google, escribió el 15 de octubre: “Por si sirve: si esperas que tus imágenes aparezcan en Google Imágenes y como vistas previas en Discover, etc., JPEG-XL no está admitido por ahora” (traducción propia, John Mueller, Bluesky). La documentación de Google sobre imágenes enumera los formatos que la Búsqueda admite en el atributo src de img: BMP, GIF, JPEG, PNG, WebP, SVG y AVIF (Google Search Central). En un <picture> con una fuente JXL, el <img> de respaldo debe apuntar por tanto a un archivo AVIF, WebP o JPEG, y una imagen que quieras ver en Google Imágenes o como vista previa en Discover nunca debería existir solo como .jxl. Lo mismo vale para cualquier CMS, plataforma de tienda o sitio estático. La elección de formato forma parte de nuestra optimización de velocidad de WordPress.

Y si tu alojamiento no puede codificar AVIF, la respuesta no es esperar a JPEG XL: es WebP, mediante image_editor_output_format o el ajuste de Modern Image Formats. El soporte de WebP está mucho más disponible en compilaciones antiguas de Imagick y LibGD, y la distancia entre JPEG y WebP es bastante mayor que la que hay entre WebP y AVIF.

#Cómo optimizar imágenes en WordPress paso a paso

Un flujo que escala sin caos operativo:

1. Subida: foto maestra en sRGB, con un ancho máximo acorde al breakpoint más grande del tema (por ejemplo 1920 o 2560 px, no los 8000 px que salen de la cámara; de todos modos el núcleo reduce cualquier cosa por encima de 2560 px).
2. Generación: el núcleo crea los tamaños intermedios en el formato de la subida; image_editor_output_format, Modern Image Formats o el CDN aportan AVIF o WebP.
3. Renderizado: wp_get_attachment_image() (o el bloque Imagen) con srcset/sizes correctos.
4. Hero: deja que el núcleo ponga fetchpriority="high" y quite el lazy; precarga solo cuando el hero es un fondo o queda fuera del marcado del núcleo.
5. El resto: lazy, sin precarga.
6. Seguimiento: PageSpeed/CrUX sobre la URL real, filtrando por “LCP element” y por peso de imagen.

En un alojamiento compartido sin AVIF en Imagick, convertir en el edge del CDN suele salir más barato que cambiar de servidor por un solo códec.

#Errores habituales al optimizar imágenes en WordPress

• PNG para fotografías. PNG es para interfaz y transparencias. Una foto en PNG infla el disco y la transferencia.
• Calidad 100 en JPEG/AVIF. La diferencia frente a un nivel moderado rara vez se ve, pero sí se nota en el peso.
• Recortes 1:1 y 16:9 “por si acaso” que nunca se usan. Cada subida multiplica la E/S y las copias de seguridad.
• Lazy en el logo y en el hero. Retrasa el LCP, y también el CLS si faltan las dimensiones en el marcado.
• Dos plugins de optimización a la vez. Uno reescribe las URL y el otro sirve WebP; el resultado es un 404 o un procesamiento doble.
• Ignorar width y height. Sin dimensiones intrínsecas, el diseño salta cuando llega la imagen.

#Accesibilidad de imágenes en WordPress según la normativa

Esta parte suele quedar fuera de las guías de rendimiento y en España es exigible. El Real Decreto 1112/2018 traspuso la directiva europea de accesibilidad de los sitios web del sector público y remite a la norma UNE-EN 301 549, que a su vez recoge los criterios de WCAG 2.1 en nivel AA. La Ley 11/2023 extendió requisitos equivalentes al comercio electrónico, con aplicación desde el 28 de junio de 2025. Si tu proyecto es una sede electrónica, una universidad, un ayuntamiento o una tienda, el trabajo de imágenes tiene dos criterios que cumplir además de pesar poco.

El primero es la alternativa textual. Un alt vacío es correcto y deseable para una imagen decorativa, y es un defecto para una imagen que aporta información. WordPress guarda ese campo en la biblioteca de medios, por lo que una auditoría es una consulta a postmeta sobre _wp_attachment_image_alt, no una revisión plantilla por plantilla.

El segundo muerde directamente en este tema: las imágenes de texto. Un banner promocional que lleva el titular quemado dentro del píxel incumple el criterio, no se traduce, no se puede seleccionar y además es el peor candidato posible para AVIF, porque la pérdida de textura fina que este formato aplica se ceba con la tipografía pequeña. Texto en HTML sobre la imagen resuelve el problema legal y el de compresión a la vez. Lo mismo vale para las capturas de interfaz con letra diminuta: si son ilustrativas, conviene recortarlas y ampliarlas antes de codificar, en lugar de subir la pantalla entera y confiar en el codificador.

Un apunte relacionado, por si aparece en la misma revisión: SVG sigue siendo la respuesta correcta para iconos, porque es independiente de la resolución y un solo archivo cubre cualquier densidad de pantalla sin srcset. El núcleo no permite subirlo por defecto porque un SVG puede transportar script. Si lo habilitas, sanea en la subida en lugar de confiar en quien sube.

#Lista de comprobación de imágenes antes de publicar

• ¿Cuánto pesa el hero en la variante móvil típica, comparado con la mediana de 135 KB para la imagen más grande del Web Almanac 2024?
• ¿Muestra Network AVIF o WebP en el propio documento, y no solo en la página de prueba del plugin?
• ¿Coincide sizes con el ancho CSS real del contenido o del hero?
• ¿Solo una imagen tiene fetchpriority="high"?
• ¿Responde el CDN (si lo hay) con 200 y cache-hit a partir de la segunda petición?
• ¿Es estable el CLS del hero (dimensiones o aspect-ratio en CSS)?
• ¿Tienen texto alternativo las imágenes informativas, y el texto de los banners está en HTML y no en píxeles?

Si un punto falla, corrige ese punto antes de comprar más herramientas.

#Por dónde empezar a optimizar imágenes en WordPress

Los formatos están decididos y no requieren más investigación. AVIF tiene un 96,35% de soporte de navegador y soporte nativo en WordPress desde la 6.5. JPEG XL no tiene ninguna de las dos cosas: Chrome 155 empezó a decodificarlo el 6 de octubre de 2026 y Firefox 158 el 13 de octubre, pero Edge, Samsung Internet y el núcleo de WordPress no, así que de momento se queda fuera del srcset. WebP es el respaldo que sigue funcionando en todas partes.

Lo que sí está sin resolver en casi cualquier sitio es todo lo que ocurre entre la subida y el pintado. La secuencia, en este orden y con una medición en cada paso: confirmar el elemento LCP por plantilla con datos de campo, leer en Salud del sitio qué puede codificar el servidor, activar la conversión de subtamaños y regenerar lo existente por lotes, comprobar que sizes describe el diseño real, revisar si el edge está sirviendo WebP en silencio porque el origen era demasiado grande, y cerrar con la pasada de alternativas textuales e imágenes de texto. El 1% de adopción que registra el Web Almanac es lo que ocurre cuando un proyecto se detiene en el segundo paso porque ya instaló un plugin de imágenes.

Si las imágenes están hundiendo tus Core Web Vitals, el primer artefacto útil es un inventario corto: las plantillas afectadas, de dónde sale cada imagen, y el elemento LCP actual y su tiempo en cada plantilla. Recorremos exactamente esa lista dentro de la optimización de velocidad WordPress.