AVIF es aceptado por el 94,67% del uso de navegadores que mide caniuse. El capítulo de medios del Web Almanac de 2024 lo encontró en el 1,0% de las peticiones de imagen en móvil. Esa distancia de 94 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
srcsetacaba eligiendo el navegador. - Descubrimiento: en qué momento se entera el navegador de que la imagen existe.
Empiece por el elemento LCP, no por el formato
Antes de convertir nada, confirme 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 ayudarle aunque el LCP sí sea una imagen:
- El elemento LCP no es una etiqueta
imgque haya renderizado el núcleo. Un fondo CSS, el póster de unvideo, o un maquetador que escribe el marcado fuera dewp_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. - 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 emite una precarga con fetchpriority=high para la URL de la imagen LCP, como elemento LINK en el HTML y como cabecera HTTP Link, aplica el atributo solo en los breakpoints donde ese elemento es realmente el LCP, pone fetchpriority=low en las imágenes que están dentro del viewport pero ocultas (las diapositivas dos y tres de un carrusel, el caso de siempre) y difiere la carga de fondos CSS declarados en hojas de estilo de orígenes permitidos.
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 instala como plugin es la dirección oficial del proyecto.
La ruta de subida decide el formato antes que usted
WordPress 6.5 añadió soporte para AVIF en febrero de 2024, en un trabajo que anunció Adam Silverstein. Desde entonces puede 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 usted no elige la compilación de ImageMagick: la hereda. La versión de PHP del panel no le dice nada sobre los delegados de Imagick, y una migración entre planes del mismo proveedor puede cambiarlos. Abra Salud del sitio después de cada mudanza y después de cada actualización mayor del servidor, y trate 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 devuelva el array que recibió 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 su hueco de cabecera es realmente más ancho que 2560, ya está sirviendo una imagen ampliada, y ningún trabajo de formato arregla esa falta de nitidez.
Codificar AVIF cuesta tiempo de CPU
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 su 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.
Regenerar lo que ya está subido
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 acaba 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 --yesAcote 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. Trocee la biblioteca por rangos de identificador, ejecute fuera de hora punta y guarde 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ó.
Un número de calidad para toda la biblioteca es un compromiso, no un ajuste
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. Trate cualquier número de ese tipo como no verificado hasta que lo haya medido sobre su 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. Fije un conjunto pequeño de imágenes representativas de su biblioteca real (una cara, un producto sobre fondo blanco, una captura con texto pequeño y un paisaje apaisado), codifíquelo con cada ajuste candidato y mire el resultado a tamaño completo. Eso evita publicar un valor global que destroce la fotografía de producto.
Lo que el núcleo escribe en el marcado desde la 6.3 y la 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 filtrowp_min_priority_img_pixels. loading="lazy"se omite en las imágenes cercanas al principio del documento. El filtro del umbral eswp_omit_loading_attr_threshold, cuyo valor por defecto subió de 1 a 3 en la 6.3.- La función nunca emite
fetchpriority="high"yloading="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 su 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.
Picture, negociación de contenido y el hueco que deja el núcleo
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. Obtiene 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, traducido al español como Formatos de imagen modernos y 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 su 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 conserve 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 genera subtamaños adicionales en lugar de sustituir el original, así que mantener el respaldo no cuesta más que disco.
Llevar el redimensionado al edge sin perder el srcset
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=autopuede 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. 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.
JPEG XL sigue siendo un formato de archivo
Aquí es donde se equivocan la mayoría de las guías de 2026, incluida la versión anterior de esta. JPEG XL no ha llegado a la entrega.
caniuse sitúa JPEG XL en el 15,02% de soporte global, y esa cifra es generosa porque cuenta el soporte parcial. El estado real, navegador por navegador:
| Navegador | Estado de JPEG XL |
|---|---|
| Safari (macOS, iOS) | Soporte parcial, versión 17 y posteriores |
| Chrome, Edge | Desactivado por defecto. Chromium lo activó, lo retiró y lo reintrodujo desactivado por defecto en Chrome 145 |
| Firefox | Desactivado por defecto |
| Chrome para Android, Samsung Internet | Sin soporte |
El Web Almanac ni siquiera midió el uso de JPEG XL en 2024, y explicó el motivo: los navegadores basados en Chromium no soportan 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. La última fila de la tabla es la que decide el caso en mercados donde el acceso es mayoritariamente Android: ni Chrome para Android ni Samsung Internet lo soportan.
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. Eso es una decisión de almacenamiento, no de entrega, y no toca su
srcset. - Si decide 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. La gran mayoría de sus visitantes tomará uno de los respaldos, así que la rama JXL no le ahorra construir el resto. - No lo use como argumento para posponer AVIF. AVIF es el formato con 94,67% de soporte hoy.
Y si su 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.
La imagen también responde ante la norma de accesibilidad
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 su 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 habilita, sanee en la subida en lugar de confiar en quien sube.
El orden de trabajo que funciona
Los formatos están decididos y no requieren más investigación. AVIF tiene un 94,67% de soporte de navegador y soporte nativo en WordPress desde la 6.5, JPEG XL no tiene ninguna de las dos cosas y no las tendrá este año, y 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 sus 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.
