Optimización de medios WordPress con WebP y AVIF

#Optimización de medios en WordPress: velocidad y escalabilidad

Conoce más sobre la optimización de velocidad WordPress en WPPoland si quieres mejorar las métricas de rendimiento de tu sitio.

Aplicar estas estrategias exige un método sistemático que equilibre la optimización técnica con la calidad del contenido. A continuación se explica cómo ejecutar cada una.

#1. Soporte de WebP y AVIF en WordPress con Imagick o GD

Los formatos de imagen tradicionales (JPEG y PNG) son muy poco eficientes frente a las alternativas modernas.

• WebP: WordPress lo admite desde la versión 5.8 y ofrece compresión con y sin pérdida. La documentación de WebP de Google indica que WebP con pérdida genera archivos entre un 25 y un 34% más pequeños que un JPEG comparable, y WebP sin pérdida un 26% más pequeños que PNG.
• AVIF (AV1 Image File Format): WordPress lo admite desde la versión 6.5. AVIF usa codificación intra-frame derivada del códec de vídeo AV1. Suele superar a WebP con la misma calidad visual, pero la diferencia depende de cada imagen, así que mídela en tu propia biblioteca; la guía de AVIF y JPEG XL trata el coste de codificación y el soporte en navegadores.

#Comprobar si PHP admite WebP y AVIF

Para generar estos formatos, PHP debe usar la biblioteca Imagick o GD compilada con soporte para AVIF/WebP. Puedes consultar las bibliotecas de procesamiento de imágenes disponibles en tu servidor desde la línea de comandos:

# Comprobar el soporte de WebP y AVIF en los módulos de PHP
php -r "print_r(gd_info());"
php -r "if (class_exists('Imagick')) { print_r(Imagick::getConfigureOptions()); }"

Dentro del array de GD, busca WebP Support => 1 y AVIF Support => 1. Si faltan estos indicadores, tendrás que compilar los paquetes PHP del servidor con libwebp y libavif. También puedes verificarlo desde el escritorio en Herramientas > Salud del sitio.

#Imagick o GD para procesar imágenes en WordPress

En WordPress, dos bibliotecas se encargan de las transformaciones de imagen en el servidor: GD e Imagick. La elección influye directamente en el consumo de recursos y en la calidad del resultado:

• Imagick (ImageMagick): el motor preferido en entornos empresariales. Ofrece mejor reproducción del color, conserva los perfiles de metadatos (como los valores de rotación EXIF) y admite operaciones avanzadas como vistas previas de PDF de varias páginas. Sin embargo, consume mucha memoria, porque el búfer de píxeles decodificado crece con el número de píxeles y no con el tamaño del archivo: un JPEG de 12 megapíxeles que ocupa 3 MB en disco se convierte en decenas de megabytes en RAM.
• GD (Graphics Library): un motor ligero y con poca huella. GD es el más ligero de los dos en operaciones de escalado habituales. Las pruebas publicadas no coinciden en el tamaño de la diferencia, y algunas ni siquiera en su dirección, así que mide en tu propio entorno en lugar de fiarse de un porcentaje de titular. Por otro lado, carece de conversiones avanzadas de espacio de color (los colores suelen quedar algo apagados tras la conversión) y descarta los perfiles EXIF.
• Al generar WebP y AVIF, el codificador de Imagick trabaja con varios hilos, mientras que GD se ejecuta de forma síncrona en un solo núcleo de CPU. En plataformas con mucho tráfico conviene priorizar Imagick y aplicar políticas de recursos estrictas para controlar el consumo de memoria.

#Limitar la memoria de Imagick en policy.xml

Generar archivos AVIF consume mucha CPU y memoria. Si se suben a la vez varias imágenes de alta resolución, el proceso PHP puede quedarse sin memoria (OOM) o agotar el tiempo de ejecución del script.

Para evitarlo, modifica las políticas de límites de recursos de Imagick en el servidor. Edita /etc/ImageMagick-6/policy.xml o /etc/ImageMagick-7/policy.xml para asignar límites de memoria adecuados:

<policymap>
  <!-- Limit memory usage per process to 512MiB -->
  <policy domain="resource" name="memory" value="512MiB"/>
  <policy domain="resource" name="map" value="1GiB"/>
  <!-- Limit processing threads to prevent CPU starvation -->
  <policy domain="resource" name="thread" value="2"/>
  <!-- Block external delegate programs -->
  <policy domain="delegate" rights="none" pattern="*"/>
</policymap>

Con estos límites, el procesamiento de imágenes funciona de forma estable dentro de tu alojamiento, incluso durante regeneraciones masivas de la biblioteca de medios.

#2. Cómo cambiar la calidad de compresión de imágenes en WordPress

Por defecto, WordPress comprime las subidas JPEG con una calidad del 82%. Para miniaturas y elementos de fondo, ese nivel es innecesariamente alto y produce archivos más pesados de lo necesario.

#Fijar la calidad de compresión por formato de imagen

Añade estos filtros al archivo functions.php de tu tema para ajustar la calidad de compresión según el tipo MIME de la imagen:

declare(strict_types=1);

namespace WPPoland\Performance\Media;

/**
 * Personaliza la calidad de compresión según el formato de imagen.
 */
function set_media_compression_quality( int $quality, string $mime_type ): int {
    switch ( $mime_type ) {
        case 'image/jpeg':
            return 75; // Ahorra ~20% de espacio frente al 82% por defecto
        case 'image/webp':
            return 80;
        case 'image/avif':
            return 65; // AVIF mantiene buena calidad incluso con más compresión
        default:
            return $quality;
    }
}
add_filter( 'wp_editor_set_quality', __NAMESPACE__ . '\\set_media_compression_quality', 10, 2 );
add_filter( 'jpeg_quality', function() { return 75; } );

#3. Cómo desactivar los tamaños de imagen no usados en WordPress

Cuando un usuario sube una imagen, WordPress genera un archivo por cada subtamaño registrado. Solo el núcleo registra seis (thumbnail, medium, medium_large, large, 1536x1536 y 2048x2048), y cada tema o plugin que llama a add_image_size() añade más. Una sola subida puede dejar una docena de archivos en disco, lo que cuesta espacio, inodos y tiempo de CPU durante las migraciones de medios.

#Eliminar tamaños de imagen no usados en functions.php

Elimina los tamaños de miniatura que no utilizas para ahorrar espacio en disco y reducir el trabajo de procesamiento en cada subida:

declare(strict_types=1);

namespace WPPoland\Performance\Thumbnails;

/**
 * Elimina las dimensiones de miniatura no utilizadas.
 */
function unregister_bloated_thumbnail_sizes( array $sizes ): array {
    // Quitar los tamaños que el diseño del tema no usa
    unset( $sizes['medium_large'] ); // 768px de ancho
    unset( $sizes['1536x1536'] );     // Extra grande
    unset( $sizes['2048x2048'] );     // 2K grande
    return $sizes;
}
add_filter( 'intermediate_image_sizes_advanced', __NAMESPACE__ . '\\unregister_bloated_thumbnail_sizes' );

/**
 * Registra los tamaños personalizados que usan los diseños activos.
 */
function register_theme_image_sizes(): void {
    add_image_size( 'hero-lg', 1920, 800, true );
    add_image_size( 'blog-card', 600, 400, true );
}
add_action( 'after_setup_theme', __NAMESPACE__ . '\\register_theme_image_sizes' );

#4. Desactivar el lazy loading en la imagen LCP de WordPress

Desde la versión 5.5, WordPress añade automáticamente loading="lazy" a las imágenes de las entradas. Aunque en general beneficia a la velocidad, aplicar lazy loading a los recursos por encima del pliegue bloquea los precargadores del navegador y empeora el LCP (Largest Contentful Paint). Desde WordPress 6.3, el núcleo ya omite el lazy loading en la primera imagen grande y le asigna fetchpriority="high", como explica la guía sobre el manejo de imágenes. Los filtros siguientes siguen funcionando (el núcleo mantiene wp_img_tag_add_loading_attr por compatibilidad) y son útiles en plantillas y listados personalizados donde el núcleo se equivoca.

#Carga inmediata de imágenes por encima del pliegue con fetchpriority

Configura tus plantillas para cargar sin demora la primera imagen de los listados de entradas y aplicar prioridad alta de descarga a las imágenes hero:

declare(strict_types=1);

namespace WPPoland\Performance\LCP;

/**
 * Desactiva el lazy loading en la primera imagen de la entrada.
 */
function disable_lazy_load_on_first_image( string|bool $value, string $image_tag, string $context ): string|bool {
    static $first_image = true;

    if ( 'the_content' === $context && $first_image ) {
        $first_image = false;
        return false; // Evita que se inyecte loading="lazy"
    }

    return $value;
}
add_filter( 'wp_img_tag_add_loading_attr', __NAMESPACE__ . '\\disable_lazy_load_on_first_image', 10, 3 );

/**
 * Añade fetchpriority="high" a las imágenes con carga inmediata.
 */
function apply_fetchpriority_to_eager_images( array $attr, \WP_Post $attachment ): array {
    if ( isset( $attr['loading'] ) && 'eager' === $attr['loading'] ) {
        $attr['fetchpriority'] = 'high';
    }
    return $attr;
}
add_filter( 'wp_get_attachment_image_attributes', __NAMESPACE__ . '\\apply_fetchpriority_to_eager_images', 10, 2 );

#5. Configuración de tamaños de imagen responsive

Para que el navegador solicite el tamaño adecuado del atributo srcset, debes personalizar las definiciones del atributo sizes. El valor por defecto suele acabar en 100vw, lo que hace que en escritorio se pidan imágenes demasiado grandes.

#Atributo sizes personalizado para los puntos de corte de srcset

declare(strict_types=1);

namespace WPPoland\Performance\Responsive;

/**
 * Sustituye el atributo sizes por defecto para ajustarlo a los puntos de corte del tema.
 */
function filter_responsive_image_sizes_attribute( string $sizes, array $size_array ): string {
    $width = $size_array[0];

    // Comprobar si la imagen encaja en el ancho del diseño de entradas
    if ( $width >= 800 ) {
        return '(max-width: 840px) 100vw, 800px';
    }

    return $sizes;
}
add_filter( 'wp_calculate_image_sizes', __NAMESPACE__ . '\\filter_responsive_image_sizes_attribute', 10, 2 );

#Limitar las fuentes de srcset por ancho

WordPress genera automáticamente el atributo srcset, de modo que el navegador elige el tamaño más adecuado. Con el filtro wp_calculate_image_srcset puedes descartar las fuentes demasiado pequeñas o demasiado grandes para tu diseño, por ejemplo las de menos de 300 o más de 2400 píxeles:

// Personalizar los tamaños disponibles en srcset
add_filter('wp_calculate_image_srcset', function($sources, $size_array, $image_src) {
    // Filtrar fuentes demasiado pequeñas o demasiado grandes
    foreach ($sources as $width => $source) {
        if ($width < 300 || $width > 2400) {
            unset($sources[$width]);
        }
    }
    return $sources;
}, 10, 3);

#6. Servir AVIF en lugar de JPEG con .htaccess

Si tu sitio aloja JPEG antiguos pero quieres servir versiones WebP o AVIF a los navegadores modernos sin cambiar el HTML, puedes usar reglas de negociación de contenido en el servidor.

#Servir AVIF con reglas de reescritura de Apache

Añade estas reglas a tu archivo .htaccess para servir automáticamente el archivo AVIF cuando el navegador acepta el formato y el archivo existe en el servidor:

<IfModule mod_rewrite.c>
  RewriteEngine On
  
  # Check if browser supports AVIF
  RewriteCond %{HTTP_ACCEPT} image/avif
  
  # Check if the AVIF version exists on disk
  RewriteCond %{DOCUMENT_ROOT}/$1.avif -f
  
  # Redirect requests for JPEGs/PNGs to the AVIF version
  RewriteRule ^(wp-content/uploads/.*)\.(jpe?g|png)$ $1.avif [T=image/avif,E=accept:1]
</IfModule>

Estas reglas de reescritura en el servidor te permiten entregar archivos modernos y muy optimizados a los navegadores compatibles, manteniendo la versión original para los sistemas antiguos.

#7. Descargar los medios de WordPress a S3 con una CDN

En sitios con bibliotecas de medios grandes, mantener los archivos en los volúmenes locales del servidor limita la escalabilidad y complica las copias de seguridad. Descargar los medios a un servicio de Object Storage (por ejemplo AWS S3, DigitalOcean Spaces o Google Cloud Storage) y servirlos a través de una red de distribución de contenidos (CDN) es la solución habitual en sitios con mucho tráfico.

Para la integración puedes usar WP Offload Media (Delicious Brains), cuya configuración se muestra más abajo, o Media Cloud (Interfacelab) como alternativa.

#Qué cambia al descargar los medios de WordPress

Cuando los medios se descargan:

1. Nodos web sin estado: los servidores web ya no necesitan sincronizar volúmenes persistentes. Puedes escalar los contenedores web hacia arriba y hacia abajo de forma dinámica con grupos de autoescalado.
2. Ahorro de almacenamiento local: si configuras la integración para borrar los archivos locales justo después de subirlos con éxito, los discos locales no se quedan sin espacio y los costes de los servidores de aplicación se mantienen bajo control.
3. Caché en CDN y distribución geográfica: las peticiones pasan del servidor principal a las cachés perimetrales (como Cloudflare, Amazon CloudFront o KeyCDN), lo que reduce el consumo de ancho de banda y la latencia para usuarios de todo el mundo.

#Ajustes de WP Offload Media para S3 en wp-config.php

Las constantes de configuración de WP Offload Media documentan AS3CF_SETTINGS como un array serializado. Los proveedores de almacenamiento son aws, do y gcp; un dominio CDN propio se configura con las claves de entrega, no con las de almacenamiento:

// Definir de forma segura las credenciales de S3 y los datos del bucket en wp-config.php
define( 'AS3CF_SETTINGS', serialize( [
    'provider' => 'aws',
    'access-key-id' => getenv( 'AWS_ACCESS_KEY_ID' ),
    'secret-access-key' => getenv( 'AWS_SECRET_ACCESS_KEY' ),
    'bucket' => 'wppoland-media-bucket',
    'region' => 'eu-central-1',
    'copy-to-s3' => true,
    'serve-from-s3' => true,
    'remove-local-file' => true, // Ahorra disco en el servidor de aplicación principal
    'object-versioning' => true, // Rutas con marca de tiempo: un archivo modificado recibe una URL nueva
    'delivery-provider' => 'cloudflare',
    'enable-delivery-domain' => true,
    'delivery-domain' => 'media.wppoland.com' // Subdominio CDN propio
] ) );

#Cabeceras CORS y cache-control para un bucket S3 o R2

Para que los gráficos vectoriales (SVG) y las fuentes web cargados desde tu bucket de medios se muestren bien en dominios headless desacoplados (por ejemplo, un frontend en Astro que se ejecuta en otro dominio), debes aplicar al bucket una configuración de Cross-Origin Resource Sharing (CORS).

Aplica esta política CORS en JSON en los ajustes de tu bucket S3 o R2:

[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["GET", "HEAD"],
    "AllowedOrigins": ["https://wppoland.com", "https://www.wppoland.com"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3000
  }
]

Además, asegúrate de que los archivos servidos desde el bucket llevan cabeceras de caché estáticas. Configura tu integración de descarga o tu CDN para enviar: Cache-Control: public, max-age=31536000, immutable

Esto indica a los navegadores y a los servidores perimetrales que guarden los archivos en caché de forma permanente, lo que reduce las peticiones de ida y vuelta y acelera la carga. La directiva immutable solo es segura porque object-versioning coloca cada archivo modificado en una ruta nueva; sin ello, una imagen editada conserva su URL anterior y queda en caché durante un año.

#8. Cómo limitar el tamaño de subida de imágenes en WordPress

Para evitar que los redactores suban fotos de cámara de 10 MB sin comprimir directamente en los bloques del editor (lo que desperdicia ancho de banda y almacenamiento), aplica un filtro de validación automático en el servidor.

#Por qué validar el tamaño de subida en el servidor

Comprobar el tamaño de los archivos en el servidor evita que PHP agote el tiempo de procesamiento. Si un redactor sube una imagen de 10 MB:

1. El servidor tiene que escribir el archivo temporal en /tmp/.
2. El proceso PHP intenta cargar la imagen en memoria para redimensionarla. Si se alcanzan los límites de GD o Imagick, el script falla y deja archivos a medias en disco.
3. Un filtro en wp_handle_upload_prefilter intercepta el archivo en cuanto llega y valida su tamaño antes de cualquier transformación. La sección sobre upload_max_filesize más abajo muestra cómo hacer que el cargador del navegador aplique el mismo límite antes de enviar el archivo.

Esta es la implementación del filtro en PHP:

declare(strict_types=1);

namespace WPPoland\Performance\Limits;

/**
 * Enforces file size limits by image type during upload.
 */
function restrict_large_uploads( array $file ): array {
    $size_kb = $file['size'] / 1024;
    $type    = $file['type'];

    // Limit standard raster images to 1.5MB
    if ( strpos( $type, 'image/' ) !== false && 'image/gif' !== $type ) {
        if ( $size_kb > 1536 ) {
            $file['error'] = 'Image upload failed: File size exceeds the 1.5MB limit. Please compress your asset before uploading.';
        }
    }

    return $file;
}
add_filter( 'wp_handle_upload_prefilter', __NAMESPACE__ . '\\restrict_large_uploads' );

#9. Qué guarda WordPress de cada imagen subida

Cada archivo de la biblioteca de medios es una entrada de tipo attachment. El archivo se referencia mediante dos filas de metadatos de la entrada, y la mayoría de los problemas con medios (miniaturas rotas tras una migración, un plugin de descarga que sirve el tamaño equivocado, una regeneración que nunca termina) se reducen a que esas dos filas no coinciden con lo que hay en disco.

• _wp_attached_file guarda la ruta relativa al directorio de subidas, por ejemplo 2026/10/workshop-floor.jpg. Si el original superaba el umbral de imagen grande, apunta a la copia -scaled y no al original.
• _wp_attachment_metadata guarda un array serializado construido por wp_generate_attachment_metadata(): width, height, file, filesize (se guarda desde WordPress 6.0), sizes con una entrada por cada subtamaño generado (nombre de archivo, ancho, alto, tipo MIME), image_meta con los datos EXIF e IPTC que lee el núcleo, y original_image cuando la subida se redujo.

Lee el array antes de fiarse de cualquier informe de un plugin sobre él:

# Volcar en JSON los metadatos del adjunto 1874
wp post meta get 1874 _wp_attachment_metadata --format=json

# Mostrar la ruta relativa guardada
wp post meta get 1874 _wp_attached_file

Desde WordPress 5.3, el núcleo escribe estos metadatos después de cada subtamaño que crea, no una sola vez al final. Si PHP se detiene a mitad de una subida grande, los tamaños terminados ya quedan registrados y wp_update_image_subsizes() crea solo los que faltan en el siguiente intento. Por eso la REST API tiene una ruta post-process (/wp/v2/media/<id>/post-process con la acción create-image-subsizes): tras un error del servidor, el cargador puede pedir los tamaños que faltan en lugar de volver a enviar el archivo.

El filtro big_image_size_threshold (2560 píxeles por defecto) decide cuándo se crea la copia -scaled; la guía sobre el manejo de imágenes explica cómo cambiarlo o desactivarlo, y la misma guía repasa wp media regenerate. Después de cambiar tamaños de imagen o la calidad de compresión, regenera las miniaturas existentes:

# Regenerar todas las miniaturas
wp media regenerate --yes

# Solo un tamaño concreto
wp media regenerate --yes --image_size=thumbnail

# Solo las imágenes a las que les faltan miniaturas
wp media regenerate --only-missing --yes

#Cómo listar los tamaños de imagen registrados con WP-CLI

Antes de eliminar nada en la sección 3, comprueba qué está registrado de verdad. wp media image-size muestra cada tamaño con su ancho, alto, indicador de recorte y proporción, incluidos los tamaños que añaden plugins de los que quizá ya no te acuerdas:

wp media image-size --format=table
wp media image-size --fields=name,width,height,crop --format=csv

Compara esa lista con los archivos de una carpeta mensual reciente. Un tamaño que aparece en disco pero no en la lista pertenece a un tema o plugin que ya no está activo, y wp media regenerate no lo volverá a crear. Los valores por defecto de Ajustes > Medios proceden del esquema de instalación: thumbnail de 150 x 150 recortado, medium de 300 x 300, medium_large de 768 de ancho sin límite de alto y large de 1024 x 1024. Si pones ancho y alto a 0 en esa pantalla, el núcleo deja de generar ese tamaño para las subidas nuevas.

#Auditar el tamaño de la biblioteca de medios

Para ver cuánto ocupa la carpeta de subidas y cuántos JPEG superan 1 MB, bastan dos comandos:

# Ver el tamaño total de la biblioteca
du -sh wp-content/uploads/

# Contar los archivos grandes (>1MB)
find wp-content/uploads/ -type f -size +1M -name "*.jpg" | wc -l

#10. Cómo cambiar la estructura de carpetas de subidas en WordPress

Por defecto, WordPress guarda las subidas en carpetas de año y mes (wp-content/uploads/2026/10/). La casilla de Ajustes > Medios que organiza las subidas en carpetas por año y mes controla la opción uploads_use_yearmonth_folders, que vale 1 en una instalación nueva. Desactivarla solo afecta a las subidas nuevas: los archivos existentes conservan sus rutas, porque la ruta se guarda por adjunto en _wp_attached_file.

El filtro upload_dir cambia dónde se guardan los archivos nuevos. Recibe un array con path, url, subdir, basedir, baseurl y error, y hay que cambiar subdir junto con path y url:

declare(strict_types=1);

namespace WPPoland\Performance\Uploads;

/**
 * Guarda las subidas PDF en /uploads/documents/ en lugar de las carpetas por fecha.
 */
function route_pdf_uploads( array $uploads ): array {
    $name = $_FILES['async-upload']['name'] ?? '';

    if ( ! str_ends_with( strtolower( $name ), '.pdf' ) ) {
        return $uploads;
    }

    $uploads['subdir'] = '/documents';
    $uploads['path']   = $uploads['basedir'] . $uploads['subdir'];
    $uploads['url']    = $uploads['baseurl'] . $uploads['subdir'];

    return $uploads;
}
add_filter( 'upload_dir', __NAMESPACE__ . '\\route_pdf_uploads' );

El núcleo no tiene carpetas en la pantalla de la biblioteca de medios. La vista de carpetas que añaden algunos plugins es una taxonomía registrada sobre el tipo de entrada attachment, así que vive en la base de datos y no mueve archivos en disco. Si creas una tú mismo con register_taxonomy( 'media_folder', 'attachment', ... ), usa _update_generic_term_count como función de recuento: el contador por defecto solo cuenta un adjunto a través de una entrada padre publicada, de modo que los archivos sin adjuntar nunca aparecen en el recuento del término.

#11. Cómo gestionar el texto alternativo en la biblioteca de medios de WordPress

El campo de texto alternativo de la biblioteca de medios se guarda en el meta _wp_attachment_image_alt. wp_get_attachment_image() lo lee cada vez que renderiza, tras aplicar trim() y strip_tags(), así que las imágenes destacadas y las plantillas del tema que usan esa función recogen al instante el valor editado.

El bloque Imagen se comporta de otra manera. Su atributo alt se toma del atributo alt de la etiqueta <img> guardada en el contenido de la entrada, de modo que el bloque copia el valor de la biblioteca al insertarse y después conserva su propia copia. Corregir el texto alternativo en la biblioteca de medios no actualiza las entradas que ya contienen la imagen; en ellas hay que editar el propio bloque.

Una consulta de auditoría localiza las imágenes sin texto alternativo (ajusta el prefijo wp_ a tu instalación):

wp db query "SELECT p.ID, p.post_title FROM wp_posts p
  LEFT JOIN wp_postmeta m ON m.post_id = p.ID AND m.meta_key = '_wp_attachment_image_alt'
  WHERE p.post_type = 'attachment' AND p.post_mime_type LIKE 'image/%'
  AND (m.meta_value IS NULL OR m.meta_value = '')"

# Set the alt text of one attachment
wp post meta update 1874 _wp_attachment_image_alt "Two developers reviewing a staging site on a laptop"

Un resultado vacío no es automáticamente el objetivo. El árbol de decisión del W3C para el texto alternativo indica que una imagen puramente decorativa, o una cuyo texto ya aparece cerca como texto real, debe llevar un atributo alt vacío. Escribe texto alternativo para las imágenes que aportan información y describe la función de las imágenes que actúan como enlaces o botones.

#12. Cómo aumentar upload_max_filesize en WordPress

El límite de tamaño máximo de subida que muestra el cargador procede de wp_max_upload_size(). La función lee dos ajustes de PHP, upload_max_filesize y post_max_size, toma el menor y lo pasa por el filtro upload_size_limit. Ese mismo valor se entrega al cargador del navegador como su max_file_size, de modo que un archivo que supera el límite se rechaza antes de enviarse.

El manual de PHP indica como valores por defecto 2M para upload_max_filesize y 8M para post_max_size, y marca ambos como INI_PERDIR. Eso tiene una consecuencia práctica: ini_set() en wp-config.php no puede aumentarlos. Configúralos en php.ini, en un archivo .user.ini, en la configuración del pool de PHP-FPM o (en Apache con mod_php) en .htaccess, y mantén post_max_size por encima de upload_max_filesize, porque el manual lo exige.

; .user.ini en la raíz de WordPress (PHP-FPM / CGI)
upload_max_filesize = 16M
post_max_size = 20M

Subir los límites de PHP es la mitad del trabajo. La otra mitad es evitar que los redactores usen el nuevo margen para originales de cámara de 12 megapíxeles. En la práctica, el filtro upload_size_limit solo puede reducir el límite efectivo (PHP descarta todo lo que supera su propio ajuste antes de que se ejecute WordPress), y es mejor sitio para la política de 1,5 MB de la sección 8, porque así el cargador muestra el límite real:

add_filter( 'upload_size_limit', static fn ( int $size ): int => min( $size, 1536 * KB_IN_BYTES ) );

En multisitio hay un tercer límite. El ajuste de red del tamaño máximo de archivo subido se guarda en la opción de sitio fileupload_maxk, 1500 KB si no se cambia, y el núcleo lo aplica con el mismo filtro junto con la cuota de subida que le queda al sitio.

#13. Plan de 90 días para optimizar imágenes en WordPress

Sigue este calendario para optimizar y vigilar los archivos multimedia de tu sitio:

• Días 1-30 (configuración inmediata): revisa los módulos PHP del servidor para confirmar el soporte nativo de AVIF/WebP. Configura los filtros de calidad en functions.php para fijar la compresión por formato. Excluye del lazy loading los elementos hero por encima del pliegue y aplica los filtros de prioridad alta de descarga para mejorar el tiempo de Largest Contentful Paint (LCP).
• Días 31-60 (depuración de tamaños y regeneración): identifica y elimina las variantes de tamaño de imagen que el tema no usa con el filtro intermediate_image_sizes_advanced para ahorrar espacio en el servidor. Escribe un filtro PHP que limite las subidas grandes en el servidor y alinea upload_size_limit con él. Ejecuta la consulta de auditoría de texto alternativo y corrige las imágenes que aportan información. Ejecuta los comandos de regeneración de WP-CLI para reconstruir las miniaturas existentes con los nuevos perfiles de calidad.
• Días 61-90 (escalado y descarga a la nube): migra la biblioteca de medios a un almacenamiento de objetos S3 o R2, configurado para borrar los archivos locales. Configura un subdominio CDN dedicado y sin cookies con las cabeceras CORS y cache-control adecuadas, y verifica las mejoras de velocidad en Search Console.

#Proceso de trabajo con cada imagen

1. Antes de subir: redimensiona las imágenes a un máximo de 2400 px de ancho en tu editor de imágenes.
2. Durante la subida: WordPress comprime la imagen y genera los tamaños aplicando tus filtros personalizados.
3. En la salida: los atributos srcset, loading y fetchpriority controlan cómo carga el navegador cada imagen.
4. Seguimiento: revisa los Core Web Vitals con regularidad para detectar regresiones.

¿Necesitas ayuda para montar una gestión de medios a medida o configurar la descarga a S3? Nuestro equipo de optimización de velocidad WordPress puede auditar tus bibliotecas de medios, compilar paquetes del servidor y configurar CDN perimetrales. Contacta con nosotros para hablar de los requisitos de tu proyecto.

Conoce más sobre los servicios de desarrollo WordPress y el mantenimiento WordPress en WPPoland.