La imagen .webp que el servidor entregaba mal · WordPin 017

El catálogo visual de aquella tienda de muebles era el corazón del negocio online. Sofás, mesas, estanterías y lámparas se mostraban con fotografías de alta calidad que el equipo actualizaba casi a diario. Durante meses el sitio había ido bien: las páginas de producto cargaban con normalidad, el tiempo de respuesta se mantenía aceptable y las visitas desde el móvil no se quejaban. Habían aplicado optimizaciones de peso en las imágenes y el cambio se notaba en las métricas internas de rendimiento. Todo parecía estable hasta que empezaron a llegar señales sueltas de que algunas fichas no se veían completas en determinados entornos.

La primera alerta llegó por un informe de rastreo externo y por una comprobación de un marketplace que enlazaba varias referencias. En el navegador moderno la imagen .webp se mostraba sin problema, nítida y ligera. Sin embargo, en esas revisiones externas el recurso no resolvía como se esperaba. Algunas miniaturas aparecían rotas o directamente no se recuperaban. El síntoma no era una caída general ni un error 500. El sitio respondía, las páginas se generaban y el resto de elementos cargaban. Solo fallaba de forma selectiva en ciertas imágenes y en ciertos contextos. Esto no encajaba del todo con un simple fallo de subida o de permisos.

Empecé a sospechar que la optimización reciente había dejado algún cabo suelto en la forma de servir esos archivos. No había quejas masivas de clientes finales, pero la inconsistencia entre lo que veía un usuario con Chrome actualizado y lo que recibían las comprobaciones externas me resultaba molesta. Había que aislar si el problema vivía en el marcado, en la entrega del servidor o en cómo se resolvía la ruta del medio dentro de WordPress.

Cuando la imagen .webp no se comporta igual en todos los contextos

Lo primero que hice fue reproducir el síntoma con calma. Abrí varias fichas de producto en un navegador actualizado y todo se veía correcto: las fotos principales y las galerías laterales cargaban, el peso por imagen había bajado de forma clara y no había iconos rotos. Luego repetí la misma revisión simulando un entorno más limitado y contrasté con herramientas de rastreo y peticiones directas al recurso. Ahí aparecía la diferencia. Algunas URLs de imagen .webp no devolvían el recurso esperado o lo devolvían de un modo que ciertas comprobaciones no aceptaban.

El patrón no era aleatorio. Afectaba sobre todo a imágenes que habían pasado por el proceso de optimización más reciente. Las antiguas en JPEG o PNG seguían resolviendo sin sobresaltos. Las nuevas, más ligeras, fallaban de forma intermitente según quién las pedía. El sitio no estaba caído. El sistema de medios de WordPress listaba los archivos en la biblioteca. Las rutas en el HTML apuntaban a ubicaciones que existían en el disco. Y sin embargo el resultado final no era homogéneo.

La primera hipótesis plausible apuntó a la caché. Tenía sentido: si una capa intermedia había guardado una versión incompleta o una respuesta errónea justo después del cambio de formato, podía explicar por qué el navegador a veces veía bien y otras revisiones no. Purgamos la caché de página, la de objeto y la del CDN asociado. Forzamos bypass con parámetros y cookies de prueba. El comportamiento irregular se mantenía. La caché no inventaba el problema; como mucho lo podía estar conservando, pero no era el origen. Descartada esa vía con pruebas concretas de purga y acceso limpio.

La segunda sospecha recayó en un conflicto de plugin de optimización o en una regla de servidor demasiado agresiva con los tipos MIME. El catálogo usaba un sistema de optimización de imágenes que generaba versiones en el nuevo formato y actualizaba referencias. Desactivamos de forma controlada el plugin en un entorno de staging idéntico y regeneramos algunas miniaturas a mano. El síntoma se atenuaba en parte, pero no desaparecía del todo cuando volvíamos a servir las versiones ya convertidas. Revisamos también las reglas del servidor por si había un bloqueo de extensión o un Content-Type genérico mal aplicado. En muchos casos el archivo existía y el servidor respondía, así que no era un simple “el MIME no está declarado en el hosting”. Demasiado evidente como única explicación, y los datos no lo cerraban.

Seguí adelante con inspección directa. Abrí las herramientas de desarrollo del navegador y me centré en la pestaña Network filtrando por Img. Seleccionaba una imagen .webp conflictiva y miraba la petición completa: estado, tamaño, tipo y cabeceras de respuesta. En el navegador moderno la petición terminaba en 200 y el renderizado era correcto. Cuando repetía la misma URL con un cliente que no anunciaba soporte explícito o desde un rastreador, la respuesta cambiaba de carácter. A veces el cuerpo no coincidía con lo esperado; otras el tipo devuelto no ayudaba a la herramienta externa a interpretarlo como imagen válida para ese contexto.

También contrasté el marcado HTML de las plantillas de producto. En varias galerías el src apuntaba directamente al archivo en el formato nuevo sin una estructura alternativa clara. Eso podía funcionar estupendamente para un usuario con soporte nativo y fallar o degradarse mal cuando el consumidor del recurso no era un navegador completo. El servidor podía estar intentando negociar el formato según la cabecera Accept, pero esa negociación no cubría todos los caminos por los que llegaba la petición: crawlers, validadores, ciertos previews de redes o de marketplaces, e incluso algunas peticiones internas de comprobación.

Una pista adicional salió al comparar el comportamiento entre la portada de categoría y la ficha individual. En listados con muchas miniaturas el fallo se multiplicaba de forma visible en los informes. En fichas con una sola imagen principal a veces pasaba más desapercibido. El volumen de recursos optimizados hacía que el problema se notara más en las páginas densas del catálogo. Revisé logs de acceso de forma puntual y vi peticiones a las mismas rutas con resultados distintos según el user-agent y las cabeceras enviadas. No había un error PHP ruidoso ni un fatal en el error.log. El sistema de medios respondía, pero la entrega del recurso concreto no era consistente.

En este punto tenía claro que la optimización había mejorado el peso de forma real y medible, pero había introducido una fragilidad en la forma de exponer la imagen .webp. Las hipótesis de caché pura y de plugin “roto del todo” ya no se sostenían tras las pruebas de purga, desactivación controlada y regeneración. Quedaba mirar con más detalle cómo se construía la respuesta HTTP y cómo estaba escrito el HTML que referenciaba esos archivos. El síntoma apuntaba a una cosa, pero los datos decían otra: no era que el archivo no existiera, sino que no siempre se entregaba de la manera que todos los consumidores necesitaban.

Señales cruzadas en la entrega de la imagen .webp

Para no quedarme solo con la vista del navegador, hice peticiones directas con cabeceras controladas. Observé diferencias claras en Content-Type y en la presencia o ausencia de negociación. En un caso representativo la respuesta desde un cliente con soporte mostraba el tipo esperado y el cuerpo correcto. Desde otro contexto la misma ruta no devolvía el recurso de forma útil para la herramienta que la pedía. Eso explicaba por qué el usuario final con navegador reciente no se quejaba y por qué los informes externos y algunas validaciones sí marcaban fallos.

También comprobé que no todas las imágenes del catálogo estaban en la misma situación. Las que se habían subido y procesado después del cambio de estrategia de optimización concentraban casi todos los problemas. Las legadas en formatos clásicos seguían siendo predecibles. El componente de WordPress implicado era claramente el sistema de medios unido a la capa de optimización: generación de versiones, posible reescritura de rutas o de referencias en el contenido, y entrega final desde el servidor o la CDN.

En este tramo del análisis aún no cerraba la causa exacta, pero el cerco se estrechaba. Había que mirar si el HTML confiaba en exceso en un único formato, si las cabeceras de respuesta eran incompletas para ciertos caminos y si faltaba un mecanismo de fallback robusto cuando el cliente no podía o no quería consumir el recurso en ese formato. La inconsistencia entre “se ve bien aquí” y “no se resuelve allí” era la señal más valiosa.

Lo que realmente fallaba en la entrega

El diagnóstico se asentó cuando crucé tres pruebas que ya no dejaban margen a las hipótesis anteriores. Primero, la inspección reiterada en DevTools (Network e Img) confirmó que el navegador moderno recibía y renderizaba la imagen sin fricción. Segundo, las cabeceras HTTP de las mismas URLs mostraban que la entrega no era uniforme: el Content-Type y la forma de servir el binario no cubrían bien todos los casos de uso. Tercero, el marcado HTML de muchas plantillas de producto carecía de una estructura de fallback clara; se confiaba en que el recurso en el formato nuevo bastaría siempre.

El diagnóstico apuntaba a que la implementación del formato nuevo no había contemplado bien el fallback, las cabeceras ni la entrega correcta del recurso en todas las situaciones. El plugin o el flujo de optimización generaba la imagen .webp, actualizaba referencias y, en algunos casos, se apoyaba en negociación por Accept o en servir directamente la versión nueva. Eso funcionaba para el visitante habitual con soporte nativo. Fallaba o se degradaba mal cuando la petición venía de un rastreador, de una herramienta de validación, de un preview externo o de cualquier cliente que no negociaba el formato de la misma manera. El archivo podía existir en disco, la biblioteca de medios lo listaba y el navegador moderno lo mostraba, pero ciertas comprobaciones externas no recibían el recurso esperado.

Por eso los falsos positivos habían parecido razonables al principio. La caché podía magnificar una respuesta incorrecta guardada, pero tras purgas y bypass el problema seguía, así que no era el origen. El conflicto de plugin o el MIME “mal declarado de forma global” también parecía plausible porque al desactivar se notaba un alivio parcial; sin embargo, las versiones ya convertidas y las rutas existentes seguían mostrando la misma fragilidad de entrega. El origen no era que el plugin estuviera completamente roto ni que el servidor rechazara la extensión de forma sistemática. Era una implementación incompleta de cómo se exponía y se servía el nuevo formato.

El impacto técnico y de SEO era silencioso pero real. Las páginas cargaban para la mayoría de usuarios, las Core Web Vitals internas mejoraban por el menor peso, y sin embargo los rastreos y las validaciones externas marcaban recursos rotos o no recuperables. En un catálogo visual eso se traduce en fichas incompletas en informes, posibles problemas de indexación de imágenes y una experiencia inconsistente cuando el contenido se reutiliza fuera del propio sitio. Un error parcial suele ser más peligroso que una caída total, porque deja demasiadas cosas funcionando y retrasa la detección.

La prueba definitiva fue comparar la misma URL de imagen .webp con distintos conjuntos de cabeceras y clientes, junto con la revisión del HTML generado. Donde faltaba un mecanismo de alternativa claro y donde la entrega no garantizaba el recurso de forma predecible, el fallo reaparecía. Donde el navegador moderno pedía con soporte completo, todo parecía perfecto. Esa asimetría cerraba el caso.

HTTP/1.1 200 OK
Content-Type: image/webp
Content-Length: 48210
Vary: Accept
Cache-Control: public, max-age=31536000

En contextos problemáticos la respuesta no siempre mantenía esa claridad. Un ejemplo de respuesta problemática detectada durante las pruebas, cuyo tipo MIME no identificaba específicamente el formato de imagen, era:

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 48210
Vary: Accept
Cache-Control: public, max-age=31536000

En otros casos de negociación incompleta, la misma ruta devolvía un cuerpo que el cliente externo no podía interpretar como la imagen esperada, o la respuesta no coincidía con un recurso de imagen usable para ese contexto. El marcado tampoco ayudaba lo suficiente:

<img src="https://ejemplo-muebles.test/wp-content/uploads/2024/11/sofa-lin-gris-800x600.webp" 
     alt="Sofá lino gris" width="800" height="600">

Sin una estructura <picture> con fuentes alternativas o un fallback explícito a un formato más universal, la dependencia del único recurso se volvía frágil fuera del camino feliz del navegador actual.

Cómo se corrigió la entrega sin perder el beneficio de peso

La corrección pasó por revisar cómo se servían realmente las imágenes, añadir fallback cuando hacía falta y validar el acceso real a los recursos tanto desde el HTML como desde el rastreo. No bastaba con “volver a generar .webp” ni con desactivar la optimización por completo. Había que mantener la ganancia de peso y eliminar la inconsistencia de entrega.

Primero inventariamos las plantillas y los puntos del catálogo donde las galerías y las imágenes destacadas se imprimían. Donde el tema o el constructor permitía control, se sustituyó la referencia directa única por un marcado con alternativas. El elemento <picture> con una fuente para el formato nuevo y un img de respaldo en JPEG o en el formato original permitía al navegador elegir una alternativa cuando no admitía .webp. Sin embargo, ese fallback no solucionaba los errores de entrega de una imagen .webp que el navegador sí había seleccionado. Para esos casos también era necesario corregir la respuesta del servidor y la negociación del formato. En los casos en los que el HTML se generaba desde el sistema de medios o desde un shortcode del optimizador, ajustamos la configuración para que no reescribiera de forma agresiva todas las referencias sin dejar salida de emergencia.

En paralelo revisamos las cabeceras que salían del servidor y de la CDN. Nos aseguramos de que el Content-Type fuera correcto cuando se servía el archivo en el formato nuevo y de que la negociación, si existía, no dejara a ciertos clientes sin respuesta útil. Donde la reescritura por Accept estaba activa, comprobamos que no rompiera rutas cuando el cliente no enviaba la cabecera esperada. La validación se hizo con peticiones controladas, con la pestaña Network de las herramientas de desarrollo y con comprobaciones externas que antes fallaban.

El ajuste que no podía limitarse a apagar el formato

Hubo un momento en el que la tentación de la solución rápida fue fuerte: desactivar la generación de imagen .webp, regenerar todo a JPEG y declarar el incidente cerrado. Ese camino parecía válido porque eliminaba de raíz la variable nueva. Sin embargo no convenía aplicarlo así. El catálogo vivía de la velocidad percibida y del menor peso en móvil; tirar por la borda meses de mejora de rendimiento por un fallo de entrega era un precio alto e innecesario. El riesgo de hacerlo mal en el otro extremo también existía: añadir fallback de cualquier manera, dejar reglas de servidor a medias o confiar solo en la CDN podía crear duplicidades, cachés raras o HTML más pesado sin resolver el acceso real.

La solución elegida fue más quirúrgica. Mantuvimos la generación del formato ligero, corregimos el marcado para incluir alternativas claras mediante <picture> y fallback manual donde el tema lo requería, y validamos que cada recurso crítico del catálogo respondiera de forma predecible tanto a un navegador moderno como a una petición de rastreo o de validación externa. Después de los cambios, volvimos a pasar las mismas comprobaciones que habían fallado al principio: las miniaturas conflictivas resolvían, los informes externos dejaron de marcar roturas selectivas y el peso por página se mantuvo en el rango mejorado. La prueba final fue cruzar de nuevo DevTools, cabeceras y un rastreo de control sobre un conjunto representativo de fichas de sofás, mesas y estanterías.

También dejamos documentado en el entorno de staging el antes y el después de una galería típica para que el equipo de la tienda pudiera ver la diferencia sin tocar producción a ciegas. El servidor seguía entregando la versión ligera cuando correspondía, pero ya no dependíamos de que todos los consumidores hablaran el mismo idioma de formatos. La imagen .webp volvía a ser una ventaja en lugar de una fuente de inconsistencias.