Otimização moderna de media WordPress, WebP e AVIF

#Otimização moderna de media WordPress: velocidade e escala

Conheça os nossos serviços de otimização de velocidade WordPress para melhorar as métricas de performance do seu site.

Aplicar estas estratégias exige um método que equilibre a otimização técnica com a qualidade do conteúdo. Segue-se a forma de executar cada uma.

#1. Suporte WebP e AVIF no WordPress com Imagick ou GD

Os formatos de imagem tradicionais (JPEG e PNG) são pouco eficientes quando comparados com as alternativas modernas.

• WebP: suportado no WordPress desde a versão 5.8, oferece compressão com e sem perdas. A documentação WebP da Google indica que o WebP com perdas fica 25 a 34% mais pequeno do que ficheiros JPEG comparáveis e que o WebP sem perdas fica 26% mais pequeno do que o PNG.
• AVIF (AV1 Image File Format): suportado desde o WordPress 6.5, usa codificação intra-frame derivada do codec de vídeo AV1. Costuma superar o WebP com a mesma qualidade visual, mas a margem depende da imagem, por isso meça na sua própria biblioteca. O guia de AVIF e JPEG XL trata do custo de codificação e do suporte nos browsers.

#Verificar se o PHP suporta WebP e AVIF

Para gerar estes formatos, o PHP tem de usar a biblioteca Imagick ou GD compilada com suporte AVIF/WebP. Pode verificar as bibliotecas de processamento de imagem disponíveis no servidor pela linha de comandos:

# Verificar o suporte WebP e AVIF nos módulos PHP
php -r "print_r(gd_info());"
php -r "if (class_exists('Imagick')) { print_r(Imagick::getConfigureOptions()); }"

No array do GD, procure WebP Support => 1 e AVIF Support => 1. Se estes indicadores faltarem, terá de compilar os pacotes PHP do servidor com libwebp e libavif.

[!TIP] Verifique a Saúde do site: vá a Ferramentas > Saúde do site para confirmar se a sua instalação PHP suporta a geração de AVIF.

#Imagick ou GD para processar imagens no WordPress

No desenvolvimento WordPress, há duas bibliotecas principais para transformar imagens no backend: GD e Imagick. A escolha tem impacto direto no consumo de recursos e na qualidade do resultado:

• Imagick (ImageMagick): o motor preferido em ambientes empresariais. Dá uma reprodução de cor superior, mantém perfis de metadados (como os valores de rotação EXIF) e suporta operações avançadas, como pré-visualizações de PDF com várias páginas. No entanto, consome bastante memória, porque o buffer de píxeis descodificado cresce com o número de píxeis e não com o tamanho do ficheiro: um JPEG de 12 megapíxeis com 3 MB em disco ocupa dezenas de megabytes de RAM.
• GD (Graphics Library): um motor leve, com pouca pegada. O GD é o mais leve dos dois nas operações de redimensionamento típicas. Os benchmarks publicados não concordam quanto ao tamanho da diferença, e alguns nem quanto ao sentido dela, por isso meça na sua própria stack em vez de confiar numa percentagem de título. Falta-lhe, porém, a conversão avançada de espaços de cor (as cores ficam muitas vezes ligeiramente desbotadas depois da conversão) e descarta os perfis EXIF.
• Ao gerar WebP e AVIF, o codificador do Imagick trabalha com várias threads, enquanto o GD corre de forma síncrona num único núcleo de CPU. Em plataformas com muito tráfego, dê prioridade ao Imagick e aplique políticas de recursos rigorosas para controlar o consumo de memória.

#Definir limites de memória do Imagick no policy.xml

Gerar ficheiros AVIF exige muito CPU e memória. Se várias imagens de alta resolução forem carregadas em simultâneo, o processo PHP pode ficar sem memória (OOM) ou atingir o tempo limite do script. Para o evitar, altere as políticas de limites de recursos do Imagick no servidor. Edite /etc/ImageMagick-6/policy.xml ou /etc/ImageMagick-7/policy.xml para definir limites de memória adequados:

<policymap>
  <!-- Limitar o uso de memória por processo a 512MiB -->
  <policy domain="resource" name="memory" value="512MiB"/>
  <policy domain="resource" name="map" value="1GiB"/>
  <!-- Limitar as threads de processamento para não esgotar o CPU -->
  <policy domain="resource" name="thread" value="2"/>
  <!-- Bloquear programas delegados externos -->
  <policy domain="delegate" rights="none" pattern="*"/>
</policymap>

Com estes limites, o processamento de imagens corre de forma estável no seu alojamento, mesmo durante a regeneração em massa da biblioteca de media.

#2. Como alterar a qualidade de compressão de imagens no WordPress

Por defeito, o WordPress comprime os carregamentos JPEG com qualidade 82%. Para thumbnails e elementos de fundo, este nível é desnecessariamente alto e resulta em ficheiros pesados.

#Definir a qualidade de compressão por formato de imagem

Adicione estes filtros ao functions.php do tema para ajustar a qualidade de compressão por tipo mime:

declare(strict_types=1);

namespace WPPoland\Performance\Media;

/**
 * Personaliza a qualidade de compressão por formato de imagem.
 */
function set_media_compression_quality( int $quality, string $mime_type ): int {
    switch ( $mime_type ) {
        case 'image/jpeg':
            return 75; // Poupa ~20% de espaço face aos 82% por defeito
        case 'image/webp':
            return 80;
        case 'image/avif':
            return 65; // O AVIF mantém boa qualidade mesmo com compressão mais forte
        default:
            return $quality;
    }
}
add_filter( 'wp_editor_set_quality', __NAMESPACE__ . '\\set_media_compression_quality', 10, 2 );
add_filter( 'jpeg_quality', function() { return 75; } );

#3. Como desativar tamanhos de imagem não usados no WordPress

Quando um utilizador carrega uma imagem, o WordPress gera um ficheiro para cada sub-tamanho registado. Só o core regista seis (thumbnail, medium, medium_large, large, 1536x1536 e 2048x2048), e cada tema ou plugin que chama add_image_size() acrescenta mais. Um único carregamento pode assim deixar uma dúzia de ficheiros em disco. Isto desperdiça limites de inodes e espaço em disco, e custa tempo de CPU nas migrações de media.

#Remover tamanhos de imagem não usados no functions.php

Remova os tamanhos de thumbnail que não usa para poupar disco e reduzir o processamento de cada carregamento:

declare(strict_types=1);

namespace WPPoland\Performance\Thumbnails;

/**
 * Remove dimensões de thumbnail não usadas.
 */
function unregister_bloated_thumbnail_sizes( array $sizes ): array {
    // Retirar os tamanhos que o layout do tema não usa
    unset( $sizes['medium_large'] ); // 768px de largura
    unset( $sizes['1536x1536'] );     // Extra grande
    unset( $sizes['2048x2048'] );     // 2K grande
    return $sizes;
}
add_filter( 'intermediate_image_sizes_advanced', __NAMESPACE__ . '\\unregister_bloated_thumbnail_sizes' );

/**
 * Regista os tamanhos personalizados usados pelos layouts ativos.
 */
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' );

Dica profissional: vá a Definições > Multimédia e defina as dimensões como 0 em qualquer tamanho padrão (como o médio) que não use.

#4. Desativar o lazy loading na imagem LCP do WordPress

Desde a versão 5.5, o WordPress acrescenta automaticamente loading="lazy" às imagens dos artigos. Embora isto ajude a velocidade da página em geral, aplicar lazy loading a recursos acima da dobra bloqueia os pré-carregadores do browser e piora o LCP (Largest Contentful Paint). Desde o WordPress 6.3, o core já não aplica lazy loading à primeira imagem grande e atribui-lhe fetchpriority="high", como explica o guia de gestão de imagens. Os filtros abaixo continuam a funcionar (o core mantém wp_img_tag_add_loading_attr por compatibilidade) e fazem diferença em templates personalizados e listagens onde o core adivinha mal.

#Carregar imagens acima da dobra de imediato com fetchpriority

Configure os templates para carregar de imediato a primeira imagem das listagens de artigos e dar prioridade alta às imagens hero:

declare(strict_types=1);

namespace WPPoland\Performance\LCP;

/**
 * Desativa o lazy loading na primeira imagem do artigo.
 */
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; // Impede a inserção de loading="lazy"
    }

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

/**
 * Acrescenta fetchpriority="high" às imagens carregadas de imediato.
 */
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. Configurar o atributo sizes das imagens responsivas

Para que o browser peça o tamanho de imagem ideal a partir do atributo srcset, tem de personalizar as definições de sizes. O atributo sizes por defeito recorre muitas vezes a 100vw e acaba por pedir imagens demasiado grandes em ecrãs de computador.

#Atributo sizes personalizado para os breakpoints do srcset

declare(strict_types=1);

namespace WPPoland\Performance\Responsive;

/**
 * Substitui o atributo sizes por defeito para coincidir com os breakpoints do tema.
 */
function filter_responsive_image_sizes_attribute( string $sizes, array $size_array ): string {
    $width = $size_array[0];

    // Verificar se a imagem cabe nos limites do layout dos artigos
    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 );

Também pode ajudar o browser definindo o atributo sizes manualmente ao renderizar imagens em loops personalizados:

echo wp_get_attachment_image(
    $image_id,
    'large',
    false,
    ['sizes' => '(max-width: 600px) 100vw, 800px']
);

Isto indica ao browser que, num ecrã com menos de 600px, a imagem ocupa a largura total; caso contrário, tem 800px de largura.

#6. Servir AVIF em vez de JPEG com .htaccess

Se o seu site guarda JPEG antigos mas quer servir versões WebP ou AVIF aos browsers modernos sem mudar o código HTML, pode usar regras de negociação de conteúdo no servidor.

#Servir AVIF com regras de rewrite do Apache

Adicione estas regras ao ficheiro .htaccess para servir automaticamente ficheiros AVIF quando o browser aceita o formato e o ficheiro existe no servidor:

<IfModule mod_rewrite.c>
  RewriteEngine On
  
  # Verificar se o browser suporta AVIF
  RewriteCond %{HTTP_ACCEPT} image/avif
  
  # Verificar se a versão AVIF existe em disco
  RewriteCond %{DOCUMENT_ROOT}/$1.avif -f
  
  # Redirecionar pedidos de JPEG/PNG para a versão AVIF
  RewriteRule ^(wp-content/uploads/.*)\.(jpe?g|png)$ $1.avif [T=image/avif,E=accept:1]
</IfModule>

Estas regras de rewrite ao nível do servidor permitem entregar ficheiros modernos e bem otimizados aos browsers compatíveis, mantendo alternativas para sistemas antigos.

#7. Descarregar a media do WordPress para S3 com CDN

Em sites com bibliotecas de media grandes, manter os ficheiros em volumes locais do servidor limita a escala e complica as cópias de segurança. Descarregar a media para um serviço de Object Storage (por exemplo AWS S3, DigitalOcean Spaces ou Google Cloud Storage) e servi-la através de uma Content Delivery Network (CDN) é a solução habitual para sites com muito tráfego. Plugins como WP Offload Media ou Media Cloud são a escolha comum aqui.

#O que muda quando a media do WordPress é descarregada

Quando a media é descarregada:

1. Servidores web stateless: cada servidor web deixa de precisar de sincronizar volumes persistentes. Pode aumentar e reduzir os contentores web de forma dinâmica com grupos de autoscaling.
2. Poupança de armazenamento local: configurar a integração para apagar os ficheiros locais logo após o envio bem-sucedido evita que os discos locais fiquem sem espaço e contém os custos dos servidores da aplicação.
3. Cache na CDN e distribuição geográfica: os pedidos passam do servidor principal para caches na periferia (como Cloudflare, Amazon CloudFront ou KeyCDN), o que reduz o consumo de largura de banda e a latência para utilizadores em todo o mundo.

#Definições do WP Offload Media para S3 no wp-config.php

As constantes de definições do WP Offload Media documentam AS3CF_SETTINGS como um array serializado. Os fornecedores de armazenamento são aws, do e gcp; um domínio CDN personalizado define-se nas chaves de entrega, não nas chaves de armazenamento:

// Definir as credenciais S3 e os dados do bucket de forma segura no 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, // Poupa espaço em disco no servidor principal da aplicação
    'object-versioning' => true, // Caminhos com data, para que ficheiros alterados recebam novos URL
    'delivery-provider' => 'cloudflare',
    'enable-delivery-domain' => true,
    'delivery-domain' => 'media.wppoland.com' // Subdomínio CDN personalizado
] ) );

#Cabeçalhos CORS e cache-control para um bucket S3 ou R2

Para que gráficos vetoriais (SVG) e webfonts personalizadas carregados do bucket de media apareçam corretamente em domínios headless separados (por exemplo, frontends Astro a correr noutros domínios), tem de aplicar uma configuração Cross-Origin Resource Sharing (CORS) ao bucket.

Aplique esta política CORS em JSON nas definições do bucket S3 ou R2:

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

Garanta também que os ficheiros servidos a partir do bucket têm cabeçalhos de cache estáticos. Configure a integração de descarga ou a CDN para definir: Cache-Control: public, max-age=31536000, immutable

Isto indica aos browsers e aos servidores na periferia que guardem os ficheiros de media em cache de forma permanente, reduzindo os pedidos de ida e volta e acelerando o carregamento. A diretiva immutable só é segura porque object-versioning coloca um ficheiro alterado num caminho novo; sem isso, uma imagem editada mantém o URL antigo e fica em cache durante um ano.

#8. Como limitar o tamanho de carregamento de imagens no WordPress

Para impedir que os autores de conteúdo carreguem fotografias de câmara de 10MB sem compressão diretamente nos blocos do editor (o que desperdiça largura de banda e armazenamento), implemente um filtro de validação automática no servidor.

#Porque validar o tamanho do carregamento no servidor

Verificar o tamanho dos ficheiros no servidor evita que o PHP atinja o tempo limite. Se um editor carregar uma imagem de 10MB:

1. O servidor tem de escrever o ficheiro temporário em /tmp/.
2. O processo PHP tenta carregar a imagem em memória para a redimensionar. Se os limites do GD ou do Imagick forem atingidos, o script falha e deixa ficheiros parciais em disco.
3. Um filtro em wp_handle_upload_prefilter interceta o ficheiro logo que é recebido e valida o tamanho antes de qualquer transformação de imagem. A secção sobre upload_max_filesize mais abaixo mostra como fazer o carregador do browser aplicar o mesmo limite antes de o ficheiro ser enviado.

Segue-se a implementação do filtro em PHP:

declare(strict_types=1);

namespace WPPoland\Performance\Limits;

/**
 * Aplica limites de tamanho por tipo de imagem durante o carregamento.
 */
function restrict_large_uploads( array $file ): array {
    $size_kb = $file['size'] / 1024;
    $type    = $file['type'];

    // Limitar as imagens raster comuns a 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. O que o WordPress guarda para cada imagem carregada

Cada ficheiro da biblioteca de media é um post do tipo attachment. O ficheiro em si é referenciado por duas linhas de post meta, e a maior parte dos problemas de media (thumbnails partidas depois de uma migração, um plugin de descarga a servir o tamanho errado, uma regeneração que nunca termina) resume-se a estas duas linhas não coincidirem com o que está em disco.

• _wp_attached_file guarda o caminho relativo à pasta de uploads, por exemplo 2026/10/workshop-floor.jpg. Quando o original era maior do que o limiar de imagem grande, aponta para a cópia -scaled e não para o original.
• _wp_attachment_metadata guarda um array serializado criado por wp_generate_attachment_metadata(): width, height, file, filesize (guardado desde o WordPress 6.0), sizes com uma entrada por cada sub-tamanho gerado (nome do ficheiro, largura, altura, tipo mime), image_meta com os dados EXIF e IPTC que o core lê, e original_image quando o carregamento foi reduzido.

Leia o array antes de confiar em qualquer relatório de plugin sobre ele:

# Mostrar os metadados do anexo 1874 em JSON
wp post meta get 1874 _wp_attachment_metadata --format=json

# Mostrar o caminho relativo guardado
wp post meta get 1874 _wp_attached_file

Desde o WordPress 5.3, o core escreve estes metadados depois de cada sub-tamanho que cria, e não uma única vez no fim. Se o PHP morrer a meio de um carregamento grande, os tamanhos já terminados ficam registados e wp_update_image_subsizes() cria apenas os que faltam na tentativa seguinte. É também por isso que a REST API tem uma rota post-process (/wp/v2/media/<id>/post-process com a ação create-image-subsizes): depois de um erro do servidor, o carregador pode pedir os tamanhos em falta em vez de enviar o ficheiro de novo.

O filtro big_image_size_threshold (2560 píxeis por defeito) decide quando é criada a cópia -scaled; o guia de gestão de imagens explica como alterá-lo ou desativá-lo, e o mesmo guia percorre o comando wp media regenerate.

#Como listar os tamanhos de imagem registados com WP-CLI

Antes de remover o registo de qualquer tamanho na secção 3, liste o que está de facto registado. O comando wp media image-size mostra cada tamanho com a largura, a altura, a indicação de recorte e a proporção, incluindo tamanhos acrescentados por plugins de que já se esqueceu:

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

Compare essa lista com os ficheiros de uma pasta mensal recente. Um tamanho que aparece em disco mas não na lista pertence a um tema ou plugin que já não está ativo, e wp media regenerate não o vai recriar. Os valores por defeito em Definições > Multimédia vêm do esquema de instalação: thumbnail 150 x 150 com recorte, medium 300 x 300, medium_large com 768 de largura e sem limite de altura, e large 1024 x 1024. Definir a largura e a altura como 0 nesse ecrã impede o core de gerar esse tamanho para os novos carregamentos.

#10. Como alterar a estrutura de pastas de uploads do WordPress

Por defeito, o WordPress guarda os carregamentos em pastas por ano e mês (wp-content/uploads/2026/10/). A caixa de verificação em Definições > Multimédia que organiza os carregamentos em pastas por ano e mês controla a opção uploads_use_yearmonth_folders, que vale 1 numa instalação nova. Desligá-la afeta apenas os novos carregamentos: os ficheiros existentes mantêm os caminhos, porque o caminho fica guardado por anexo em _wp_attached_file.

O filtro upload_dir muda o destino dos novos ficheiros. Recebe um array com path, url, subdir, basedir, baseurl e error, e deve alterar subdir em conjunto com path e url:

declare(strict_types=1);

namespace WPPoland\Performance\Uploads;

/**
 * Guarda os PDF carregados em /uploads/documents/ em vez das pastas por data.
 */
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' );

O core não tem pastas no ecrã da biblioteca de media. A vista de pastas que alguns plugins acrescentam é uma taxonomia registada no tipo de post attachment, por isso vive na base de dados e não move ficheiros em disco. Se criar uma por conta própria com register_taxonomy( 'media_folder', 'attachment', ... ), use _update_generic_term_count como callback de contagem: o contador por defeito só conta um anexo através de um post pai publicado, por isso os ficheiros sem post associado nunca aparecem na contagem do termo.

#11. Como gerir o texto alternativo na biblioteca de media do WordPress

O campo de texto alternativo da biblioteca de media fica guardado na post meta _wp_attachment_image_alt. A função wp_get_attachment_image() lê-o sempre que renderiza, depois de trim() e strip_tags(), por isso as imagens de destaque e os templates do tema que usam essa função apanham de imediato um valor editado.

O bloco Imagem comporta-se de outra forma. O seu atributo alt vem do atributo alt do <img> no conteúdo guardado do artigo, por isso o bloco copia o valor da biblioteca no momento da inserção e mantém depois a sua própria cópia. Corrigir o texto alternativo na biblioteca de media não atualiza os artigos que já contêm a imagem; esses precisam de ser editados no próprio bloco.

Uma consulta de auditoria encontra as imagens sem texto alternativo (ajuste o prefixo wp_ à sua instalação):

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 = '')"

# Definir o texto alternativo de um anexo
wp post meta update 1874 _wp_attachment_image_alt "Two developers reviewing a staging site on a laptop"

Um resultado vazio não é automaticamente o objetivo. A árvore de decisão do W3C para texto alternativo indica que uma imagem puramente decorativa, ou uma cujo texto já aparece como texto real por perto, deve ter um atributo alt vazio. Escreva texto alternativo para as imagens que transmitem informação e descreva a função das imagens que servem de ligação ou botão.

#12. Como aumentar o upload_max_filesize no WordPress

O limite de tamanho máximo de carregamento que o carregador mostra vem de wp_max_upload_size(). A função lê duas definições do PHP, upload_max_filesize e post_max_size, fica com a menor e passa-a pelo filtro upload_size_limit. O mesmo valor é entregue ao carregador do browser como max_file_size, por isso um ficheiro acima do limite é rejeitado antes de ser enviado.

O manual do PHP indica como valores por defeito 2M para upload_max_filesize e 8M para post_max_size, e marca ambos como INI_PERDIR. Isto tem uma consequência prática: ini_set() no wp-config.php não os consegue aumentar. Defina-os no php.ini, num ficheiro .user.ini, na configuração do pool PHP-FPM ou (em Apache com mod_php) no .htaccess, e mantenha post_max_size acima de upload_max_filesize, porque o manual o exige.

; .user.ini na raiz do WordPress (PHP-FPM / CGI)
upload_max_filesize = 16M
post_max_size = 20M

Aumentar os limites do PHP é metade do trabalho. A outra metade é impedir que os editores usem a nova margem para originais de câmara de 12 megapíxeis. Na prática, o filtro upload_size_limit só consegue baixar o limite efetivo (o PHP descarta tudo o que passe da sua própria definição antes de o WordPress correr), e é um sítio melhor para a política de 1,5 MB da secção 8, porque o carregador passa a mostrar o limite real:

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

Em multisite existe um terceiro limite. A definição de rede do tamanho máximo de carregamento fica guardada na opção de site fileupload_maxk, 1500 KB se não for alterada, e o core aplica-a através do mesmo filtro, em conjunto com a quota de carregamento que resta ao site.

#13. Plano de 90 dias para otimizar imagens no WordPress

Siga este calendário para otimizar e monitorizar os ficheiros de media do seu site:

• Dias 1-30 (configuração imediata): audite os módulos PHP do servidor quanto ao suporte nativo de AVIF/WebP. Configure os filtros de qualidade no functions.php para definir a compressão por formato. Crie exclusões que desativem o lazy loading nos elementos hero acima da dobra e aplique os hooks de prioridade alta para melhorar o tempo de Largest Contentful Paint (LCP).
• Dias 31-60 (redução de tamanhos e regeneração): identifique e remova o registo das variantes de tamanho de imagem que o tema não usa com o hook intermediate_image_sizes_advanced, para poupar espaço no servidor. Escreva um filtro PHP que limite os carregamentos grandes no servidor e alinhe o upload_size_limit com ele. Corra a consulta de auditoria do texto alternativo e corrija as imagens que transmitem informação. Corra os comandos de regeneração do WP-CLI para reconstruir as thumbnails existentes com os novos perfis de qualidade.
• Dias 61-90 (escala e descarga para a cloud): migre a biblioteca de media para object storage S3 ou R2, com configurações que removam os ficheiros locais de origem. Crie um subdomínio CDN dedicado e sem cookies, com os cabeçalhos CORS e cache-control adequados, e verifique as melhorias de velocidade no Search Console.

Precisa de ajuda para montar um circuito de otimização de media à medida ou configurar a descarga para S3? A nossa equipa de otimização de velocidade WordPress pode auditar as suas bibliotecas de media, compilar pacotes do servidor e configurar CDN na periferia. Contacte-nos para falar sobre os requisitos do seu projeto.

Do lado da entrega mantemos este tema sob auditoria Core Web Vitals.