WordPress guarda varias copias de cada imagen y no optimiza ninguna

Sube una foto a WordPress y no obtienes un archivo. Obtienes una miniatura, una mediana, una mediana-grande, una grande, el tamaño completo y todos los tamaños extra que registraron tu tema y tu maquetador de páginas. Seis u ocho archivos de una sola subida es lo normal. Cada uno se recodifica con la calidad JPEG por defecto de WordPress y después no se vuelve a tocar.

Multiplica eso por unos cuantos años de publicaciones y la carpeta de subidas suele ser lo más pesado de tu copia de seguridad, y la parte más lenta de tus páginas. La mayor parte de ese peso es evitable.

Dónde está el peso en realidad

Son los JPEG. Las fotos dominan una biblioteca típica, y WordPress las codifica con una calidad fija (82 por defecto) con un codificador antiguo. Es un valor por defecto prudente y razonable, no un archivo pequeño. Las capturas de pantalla y los logos guardados como PNG añaden más, porque el PNG es el contenedor equivocado para muchos de ellos.

Hay dos maneras honestas de reducir esto, y sus compromisos son distintos.

1. Recodificar en el sitio

Toma cada tamaño generado y recodifícalo a una versión más ligera del mismo formato: el JPEG sigue siendo JPEG, el WebP sigue siendo WebP. Un codificador moderno quita aproximadamente entre un quinto y un cuarto de un JPEG por defecto de WordPress sin cambio visible.

Lo atractivo es que nada más en tu sitio se entera. El nombre de archivo, las dimensiones y la extensión son idénticos, así que cada URL sigue funcionando, en cada tema, en cada página en caché, en cada <img> escrito a mano. Es la opción aburrida y segura, y para muchos sitios es la correcta.

Lo que no hará: cambiar de formato. Un JPEG sigue siendo un JPEG, así que no obtienes las ganancias mayores que te daría un formato más nuevo.

2. Servir formatos de nueva generación

Genera un AVIF (y un WebP) junto a cada original y sírvelo mediante una etiqueta <picture>, manteniendo el JPEG o el PNG original como alternativa para los navegadores antiguos. Aquí es donde están los ahorros de verdad: a igual calidad, el AVIF necesita muchos menos bytes que el JPEG, y por fin cubre también tus PNG. Medimos la diferencia en unas 1.900 fotos si quieres los números.

Las advertencias honestas, porque las hay:

• Reescribe el HTML de la página, lo que la hace independiente del tema, pero solo toca las etiquetas <img>. Un background-image en CSS no se sustituirá.
• Un lazy-loader de JavaScript que reescribe src en tiempo de ejecución puede pasarlo por alto. El loading="lazy" nativo va bien.
• El GIF todavía no está cubierto.

Los originales se quedan exactamente donde están, así que no se pierde nada, y los navegadores que no pueden leer AVIF recurren al archivo que ya entendían.

Lo que de verdad preocupa a la gente

Ambos enfoques guardan una copia de cada original, así que cualquier imagen se restaura a sus bytes exactos con un clic. Un archivo solo se reemplaza cuando el nuevo es estrictamente más pequeño, así que nada crece. Y si una optimización falla, se omite, no es fatal: tu subida nunca se cuelga y una imagen nunca se queda a medio escribir.

Cómo hacerlo

Esto es lo que hace Patu Optimizer. Las subidas nuevas se optimizan automáticamente, una sola pasada masiva se ocupa de todo lo que ya hay en la biblioteca, y eliges en el sitio o nueva generación por cada sitio. Funciona sobre la API de Patu, así que la codificación ocurre fuera de tu servidor. Una clave gratuita basta para empezar.

Empieza con en el sitio si quieres cero sorpresas. Ve a por la nueva generación cuando quieras los bytes y tus páginas usen etiquetas <img> normales. En cualquier caso, el objetivo es el mismo: dejar de servir una biblioteca de medios dos o tres veces más pesada de lo necesario.