wp-admin levando de 50 a 150 segundos por página: requisições externas que nunca voltam

Em um parágrafo: quando o site público está rápido mas cada página do wp-admin leva perto de um minuto ou mais, o WordPress geralmente está esperando requisições para servidores externos que nunca respondem. Nesta loja, o servidor não conseguia acessar api.wordpress.org de jeito nenhum, e um plugin chamava sem parar um servidor de atualização que não existia mais. Bloquear essas chamadas levou as páginas do painel de 47 a 151 segundos para cerca de um segundo, enquanto a hospedagem corrigia a rede.

Sintomas

Uma loja WooCommerce com o site público carregando normalmente.
Cada página do painel levava entre 47 e 151 segundos. Painel inicial, plugins e atualizações eram as piores.
Nada no log de erros do PHP explicava. As páginas não falhavam, só esperavam.

Por que o painel e não o site

WordPress, temas e plugins verificam atualizações, licenças e novidades a partir do painel. Essas verificações são requisições HTTP para outros servidores. Quando o outro lado responde, levam milissegundos e ficam em cache. Quando a conexão simplesmente trava, cada página espera o tempo limite, e alguns plugins repetem a verificação em toda página do painel.

Como diagnosticar

Teste a partir do próprio servidor. Por SSH:
```
curl -sS -m 10 -o /dev/null -w '%{http_code} %{time_total}s\n' https://api.wordpress.org/core/version-check/1.7/
```
Um servidor saudável responde 200 em bem menos de um segundo. O nosso estourava o tempo tanto em IPv4 quanto em IPv6.
Liste as chamadas externas. Se o painel abrir, o plugin Query Monitor mostra cada chamada da HTTP API com a duração. Procure chamadas de 5, 10 ou 20 segundos.
Quando não há ferramentas. Hospedagens compartilhadas muitas vezes não têm ss nem netstat. Conexões presas no estado SYN_SENT continuam aparecendo em /proc/net/tcp com o código de estado 02, e o endereço remoto vem em hexadecimal. Decodificar mostra qual servidor o PHP está esperando.

Nesta loja encontramos dois problemas ao mesmo tempo: api.wordpress.org inacessível a partir daquele servidor, e um plugin premium de importação e exportação chamando o próprio servidor de atualização em toda página do painel. Esse servidor não existia mais, e cada chamada esperava cerca de 20 segundos.

A correção temporária

Um pequeno plugin must-use que recusa requisições aos hosts que travam. O WordPress recebe um erro imediato em vez de esperar:

<?php
/* Plugin Name: Block hanging external hosts (temporary) */
add_filter( 'pre_http_request', function ( $pre, $args, $url ) {
	$blocked = array( 'api.wordpress.org', 'update.example-plugin.com' );
	$host    = wp_parse_url( $url, PHP_URL_HOST );
	if ( in_array( $host, $blocked, true ) ) {
		return new WP_Error( 'http_blocked', 'Temporarily blocked: ' . $host );
	}
	return $pre;
}, 10, 3 );

O WordPress também tem uma chave própria, WP_HTTP_BLOCK_EXTERNAL, combinada com WP_ACCESSIBLE_HOSTS para os hosts que você ainda libera. O filtro acima é mais preciso: bloqueia só o que está quebrado.

Com ele no lugar, as páginas do painel abriram em cerca de um segundo.

A correção de verdade

Bloquear api.wordpress.org também bloqueia avisos de atualização e atualizações de segurança, então não pode ficar assim. A correção é da hospedagem: o acesso de saída daquele servidor precisa ser restabelecido. Até lá, atualizamos o núcleo do WordPress enviando o pacote manualmente. O bloqueio sai assim que o servidor voltar a acessar a internet. Para o servidor de atualização morto, o fabricante do plugin precisa corrigir, ou o plugin precisa ser substituído.

Checklist

Site rápido, painel lento: teste primeiro o HTTP de saída a partir do servidor.
Encontre exatamente os hosts que travam antes de bloquear qualquer coisa.
Bloqueie só esses hosts e anote o motivo.
Peça à hospedagem para corrigir o acesso de saída e remova o bloqueio depois.
Mantenha núcleo e plugins atualizados manualmente enquanto as atualizações não rodam.

Perguntas que recebemos sobre isso

É seguro bloquear api.wordpress.org?

Só por pouco tempo. Você deixa de receber avisos de atualização, inclusive de segurança, então o bloqueio precisa sair assim que a rede for corrigida.

Uma CDN ou plugin de cache resolve um painel lento?

Não. O painel não usa cache, e a demora está nas requisições que o seu servidor faz para outros servidores.

Por que piorou com o tempo?

Plugins que não conseguem concluir a verificação de atualização nunca guardam um resultado em cache, então tentam de novo na página seguinte, e na outra.