WebP por defecto en espera para 6.1 después de nuevas objeciones de los desarrolladores principales de WordPress

La semana pasada, los colaboradores del equipo de Performance estaban trabajando en el perfeccionamiento de sus parches de seguimiento para la función multi-mime/WebP, después de que el trabajo principal se fusionara con el núcleo de 6.1 a finales de julio. Esto incluye elementos relacionados más pequeños, como la corrección para navegadores que no son compatibles y la adición de compatibilidad con PDF, que se manejan en tickets separados.

La propuesta de generar imágenes WebP por defecto para las nuevas subidas de imágenes JPEG ha sido controvertida desde el principio. Si bien los colaboradores patrocinados por Google que impulsan el proyecto hicieron algunas revisiones después de una ronda inicial de comentarios críticos importantes, otros colaboradores continuaron expresando preocupaciones que dijeron que no se estaban considerando. Varios colaboradores informaron problemas con la función y sugirieron que debería comenzar por ser opcional, una idea que se descartó sumariamente antes de que se comprometiera el trabajo principal.

La semana pasada, el desarrollador líder de WordPress, Andrew Ozz, intervino en el boleto con nuevas objeciones:

Al igual que @MatthiasReinholz, @eatingrules y otros, creo que tal vez falte este enfoque. ¿Por qué habría el doble de archivos de imagen ocupando mucho espacio adicional cuando la mitad de ellos nunca se usarán en ninguna parte?

En mi humilde opinión, un mejor enfoque sería simplemente hacer que todos los subtamaños de imagen sean WEBP. Si realmente se necesitan archivos JPEG, estos se pueden generar sobre la marcha según sea necesario. No tiene sentido obstruir el almacenamiento de los servidores web con todos estos archivos inútiles.

Por otro lado, si los tamaños de los archivos WEBP son realmente mayores que los archivos JPEG, eso probablemente significaría que se necesitan mejores herramientas, y este parche es prematuro.

Hace seis semanas, en respuesta a una queja de que los "recursos para la conversión serían tremendos", el responsable principal patrocinado por Google, Adam Silverstein, confirmó que los recursos para generar las imágenes cargadas "aumentarían drásticamente".

“Sin embargo, se reducirán los recursos para servir una imagen”, dijo Silverstein. “Dado que la carga de imágenes es muy rara en comparación con el servicio de imágenes, el esfuerzo adicional para comprimir y almacenar imágenes debería valer la pena”.

Este es otro problema que Ozz citó en su objeción a este enfoque.

“En realidad, ese aumento dramático en el uso de recursos al cargar una imagen es un efecto secundario muy malo aquí”, dijo Ozz. “Significa que muchas cargas fallarán y dejarán a los usuarios varados. También aumentará drásticamente las solicitudes de soporte tanto para WordPress como para las empresas de alojamiento. No creas que esto es aceptable. Debido a esto, incluso si se necesita soporte de imagen multi-mime en WordPress, el enfoque actual no parece una buena solución”.

Aproximadamente 24 horas más tarde, el colaborador patrocinado por Google, Felix Arntz, comentó que el mecanismo de respaldo de WebP a JPEG para navegadores más antiguos estaba listo para confirmar y que planeaba confirmarlo en unos días.

"Por favor, no envíe más código aquí a menos que sea para abordar el aumento dramático de los recursos necesarios para crear subtamaños de imágenes después de la carga", dijo Ozz. “Como dije anteriormente, tal aumento es inaceptable.

“¿Hay algún dato sobre cuántos recursos más (memoria, tiempo de procesamiento, etc.) se necesitan al cargar diferentes tamaños de imagen? ¿Alguna estimación sobre cuántos sitios pueden verse afectados por eso? ¿Alguna sugerencia sobre cómo lidiar con eso? ¿Sabes lo que sucede cuando falla el posprocesamiento de una imagen cargada?

"Francamente, por ahora parece que este parche tendrá que revertirse y refactorizarse para solucionar esto".

Adam Silverstein respondió a sus inquietudes aclarando por qué eligieron el enfoque actual, anticipándose a ciertos casos extremos y, finalmente, agregando soporte para formatos como AVIF una vez que sea más ampliamente compatible:

Tiendo a estar de acuerdo con su evaluación de que todos los subtamaños deben generarse solo como WebP, esa era la forma de la propuesta original. Para la gran mayoría de casos de uso/usuarios, esto funcionará mejor. Estaría abierto a considerar esto por defecto (con algunas mitigaciones, ver más abajo).

La razón por la que decidimos generar ambos formatos fue por consideraciones de compatibilidad con versiones anteriores para los pocos casos extremos que identificamos en los que las imágenes WebP podrían no funcionar: a saber, imágenes enviadas por correo electrónico (algunos clientes de Outlook/Windows más antiguos), etiquetas Open Graph (algunos servicios no admiten WebP) y navegadores Safari más antiguos. Una posibilidad que consideramos sería mantener solo el JPEG de tamaño completo para que siempre esté disponible para esos casos extremos.

El soporte "multi-mime" aquí está diseñado para generar múltiples formatos para que sus sitios puedan proporcionar un formato primario y alternativo con algo como el elemento de picture . Esto es menos importante para WebP ya que es ampliamente compatible, pero sería útil para adoptar formatos más nuevos como AVIF por complementos o núcleo.

Silverstein también dijo que la opción de generar imágenes sobre la marcha era algo que debían resolver, pero que "se sentía fuera del alcance de este esfuerzo".

En respuesta a la queja sobre el aumento dramático de los recursos para cargar imágenes, Silverstein dijo que confían en el mecanismo de "reintento" para mitigar este problema.

“Este cambio también duplica la cantidad de veces que WordPress volverá a intentar la regeneración de la imagen, por lo que aunque el tiempo de procesamiento aumentará, no creo que veamos necesariamente un salto en las fallas”, dijo. "Sé que tuvimos problemas para agregar nuevos tamaños en el pasado, sin embargo, eso fue antes de que agregáramos el mecanismo de reintento".

El equipo detrás del proyecto WebP by default está más enfocado en servir tamaños de imagen más pequeños en la interfaz y considera que el uso de recursos adicionales en la carga es un sacrificio necesario para los usuarios de WordPress.

“Los recursos adicionales en el momento de la carga deben sopesarse con los recursos reducidos de servir la imagen WebP más pequeña, especialmente porque el servicio suele ocurrir varios órdenes de magnitud más frecuentemente que la carga”, dijo Silverstein.

“Si la carga falla después de todos los reintentos, el usuario tiene la misma experiencia que actualmente: se queda con una imagen rota e inutilizable. Probablemente se pueda arreglar, aunque no creo que este cambio aumente las tasas de falla”.

El desarrollador principal de WordPress, Dion Hulse, también comentó sobre el ticket para informar problemas con las conversiones de WebP en el directorio de fotos de WordPress:

Solo notando aquí, que estas conversiones webp adicionales parecen haber sido la principal causa de fallas de carga en el directorio de fotos de WordPress en las últimas semanas. Ver #meta6142 y tickets cerrados como duplicado del mismo.

Los errores generalmente estaban en la línea del Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (obviamente con valores de bytes) mientras intentaba realizar la conversión jpeg -> webp original de tamaño completo inicial.

No ha afectado todas las subidas , solo la de ciertas imágenes. Potencialmente relacionado con el $quality que se pasa para las solicitudes webp (IIRC, ¿el valor predeterminado de 82 se optimizó para jpeg?).

Hulse deshabilitó la conversión de JPEG a WebP como resultado de estos errores, ya que el directorio de fotos actualmente no usa WebP, pero señaló que "podría ser una señal de que podría valer la pena considerar generar solo webp para las imágenes redimensionadas, en lugar de para el archivo original también.”

Silverstein dijo que están investigando los problemas que informó Hulse, ya que puede haber expuesto un error.

Ozz volvió a recomendar que hacer subtamaños a pedido sería un mejor enfoque que tiene un procesamiento más rápido de las imágenes cargadas y requisitos de espacio reducidos, ya que las imágenes JPEG adicionales no se generarían a menos que se necesiten. También señaló que el "reintento" para el posprocesamiento de imágenes "no funciona tan bien como se esperaba".

“La mala noticia es que si falla el procesamiento posterior, es probable que se mantenga el archivo cargado originalmente”, dijo Ozz. “Entonces se usará en todas partes, ya que la mayor parte del código en WP se basa en los tamaños disponibles, y el único tamaño será el original. Eso significa que publicaremos imágenes enormes (promedio de 4 MB a 8 MB). Un serio inconveniente.”

Silverstein respondió a las sugerencias de Ozz, estuvo de acuerdo con muchas y propuso dos posibles caminos a seguir para el proyecto:

1. Mantenga la infraestructura multi-mime actual, pero cambie los valores predeterminados para que solo se generen archivos WebP, posiblemente hasta un tamaño de umbral más allá del cual solo se generarían archivos JPEG. La mayor parte del trabajo existente continuaría; el filtrado de contenido posiblemente podría eliminarse.
2. Revertir la infraestructura multi-mime y volver a un enfoque de mimo único, usando WebP para imágenes hasta un tamaño de umbral y ajustando la capa de compatibilidad para usar los archivos JPEG que mantenemos.

El equipo de rendimiento está investigando más y ha dejado de comprometerse temporalmente hasta que reciba comentarios sobre la próxima dirección del proyecto.