Debaixo do capô: servidor, PHP e base de dados

Módulo 1: Como funciona o WordPress · Tempo de leitura: 8 minutos

Objetivo de aprendizagem: Após esta lição, saberá explicar passo a passo como um pedido de página no WordPress se transforma numa página HTML, e onde uma cache encurta esse caminho.

Conceitos-chave: servidor (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, query, index.php, hierarquia de modelos, dinâmico vs estático, TTFB

Uma página estática e uma página dinâmica

Num site estático, cada página existe como um ficheiro pronto a usar no servidor. O servidor pega no ficheiro e envia-o. Isso é rápido e simples, mas cada alteração significa um novo ficheiro.

O WordPress é dinâmico: a página só existe no momento em que alguém a pede. Não existe um ficheiro contact.html. Existe um texto na base de dados, um tema com modelos e um conjunto de código PHP que junta os dois. Isto dá comodidade (altera o texto e vê logo no seu navegador), mas exige trabalho de processamento em cada visita. Se compreender esse trabalho de processamento, compreenderá também mais tarde por que razão um site é lento, por que a cache faz tanta diferença e por que uma atualização do PHP pode quebrar alguma coisa.

A viagem de um pedido de página

Imagine que um visitante abre https://example.com/contact/. Eis o que acontece:

1. DNS: o navegador procura o endereço IP de example.com (veja o curso de DNS). Estabelece uma ligação segura com esse endereço.
2. Servidor: no servidor corre um servidor web, por exemplo LiteSpeed, Apache ou nginx. Este recebe o pedido. Se existir um ficheiro ou pasta real com esse nome (uma imagem, uma folha de estilos), envia-o diretamente. Caso contrário, aplica-se a regra do .htaccess (no LiteSpeed e no Apache) ou da configuração do nginx: "entregue tudo o que não existe ao index.php".
3. PHP: index.php é um ficheiro PHP. O servidor manda-o executar pelo PHP, a linguagem de programação em que o WordPress está escrito. O PHP carrega primeiro o wp-config.php (as configurações, incluindo os dados da base de dados), depois o resto do WordPress, depois todos os plugins ativos e o tema ativo.
4. Base de dados: o WordPress verifica que conteúdo corresponde a /contact/ e faz perguntas à base de dados (MariaDB ou MySQL): que página tem o slug contact, quais são as definições do site, que menu lhe corresponde? Uma pergunta destas chama-se uma query. Uma página simples facilmente custa dezenas de queries; com plugins podem chegar às centenas.
5. Tema: o WordPress escolhe que modelo do tema formata a página. Isto segue a hierarquia de modelos: para uma página com o slug contact, o WordPress procura primeiro um modelo page-contact, depois page-<id> (o número da página), depois page, depois singular e por fim index. O primeiro que existir ganha.
6. Regresso em HTML: o resultado é uma página HTML que o PHP entrega ao servidor, e o servidor entrega ao navegador.
7. O navegador lê o HTML e vai depois buscar as folhas de estilos, os scripts, os tipos de letra e as imagens. Estes são ficheiros normais, por isso vêm diretamente do servidor (ou de uma cache).

Entre o passo 2 e o passo 6 está o tempo que o servidor precisa para criar a página. Isto reflete-se no TTFB (time to first byte): o tempo entre o pedido e o primeiro byte da resposta. Num site bem configurado, este valor fica bem abaixo de um segundo. No módulo 6 vai medir isto você mesmo.

Por que razão cada plugin conta

No passo 3, todos os plugins ativos são carregados, em cada pedido. Mesmo que esse plugin não faça nada visível nesta página. Um plugin de galeria de fotos é assim carregado mesmo quando alguém abre a sua página de contactos. Cada plugin pode fazer queries adicionais, carregar código extra e acrescentar scripts extra à página.

Isto explica duas coisas que encontrará mais vezes neste curso:

• Menos plugins é geralmente mais rápido. Não porque o número em si conte, mas porque cada plugin pode realizar trabalho em cada pedido.
• Um único plugin avariado pode derrubar todo o site. Se algo correr mal no passo 3 (por exemplo, um plugin que não funciona com a nova versão do PHP), o PHP nunca chega ao passo 6. O visitante recebe uma página em branco ou a mensagem "Ocorreu um erro crítico neste site" (lição 5.4).

De onde vêm o PHP e a base de dados

O PHP e a base de dados correm no servidor da sua empresa de alojamento. Normalmente, escolhe você mesmo a versão do PHP no painel de controlo (no DirectAdmin isso chama-se Select PHP version, veja a lição 8.4). A base de dados é criada durante a instalação; o instalador costuma fazer isso por si (lição 2.2).

Algumas coisas a reter:

• Versão do PHP: cada nova versão do PHP é mais rápida e mais segura, mas código antigo pode falhar com ela. O wordpress.org recomenda atualmente PHP 8.3 ou superior (situação em novembro de 2026).
• Base de dados: o wordpress.org recomenda MariaDB 10.11 ou superior, ou MySQL 8.0 ou superior. O MariaDB é uma derivação do MySQL; para o WordPress não faz diferença.
• A base de dados está geralmente no mesmo servidor (DB_HOST é, nesse caso, localhost). Em alojamentos maiores, pode estar num servidor separado.

Cache: encurtar o caminho

Se cem visitantes pedirem a mesma página de contactos, o WordPress cria-a cem vezes sem cache. Sempre as mesmas queries, o mesmo modelo, o mesmo HTML. Uma cache de página guarda o HTML após a primeira vez. O visitante seguinte recebe a versão guardada: os passos 3 a 6 deixam de ser necessários.

Zonder cache:  browser > webserver > PHP > WordPress + plugins > database > thema > HTML
Met cache:     browser > webserver > opgeslagen HTML

É por isso que a cache traz o maior ganho de velocidade (lição 6.2). Também explica uma confusão frequente: "alterei o texto, mas continuo a ver a versão antiga." Nesse caso, está a receber uma versão guardada; após limpar a cache, verá a versão nova.

Nem tudo pode vir de uma cache. Um administrador com sessão iniciada, um carrinho de compras ou uma página de finalização de compra são diferentes para cada visitante. Um bom plugin de cache ignora essas situações.

Cabeçalhos: o que o servidor lhe diz

Cada resposta de um servidor começa com cabeçalhos (headers), antes do HTML. Não os vê na página, mas pode vê-los nas ferramentas de programador do seu navegador (F12, separador Rede, clique no primeiro pedido). Um exemplo:

HTTP/2 200
server: LiteSpeed
content-type: text/html; charset=UTF-8
link: <https://example.com/wp-json/>; rel="https://api.w.org/"
x-litespeed-cache: hit

• server indica que servidor está a responder.
• link com wp-json revela que se trata de WordPress.
• x-litespeed-cache: hit significa que esta página veio da cache do LiteSpeed. Outras caches usam outros nomes, como x-cache: HIT ou cf-cache-status: HIT no caso do Cloudflare.

Não precisa de decorar estas linhas. Mas quem as sabe ler consegue resolver muitos problemas sozinho.

Resumo

• O WordPress cria cada página no momento do pedido: servidor, PHP, plugins, base de dados, tema, HTML.
• Em cada pedido, todos os plugins ativos são carregados; um único plugin avariado pode parar todo o site.
• A hierarquia de modelos determina que modelo do tema formata uma página.
• Uma cache de página poupa o trabalho de processamento ao entregar HTML guardado. Utilizadores com sessão iniciada e carrinhos de compras não devem estar nessa cache.
• Os cabeçalhos de uma resposta indicam que servidor está a responder e se a página veio de uma cache.

Questionário

Exercício

Exercício A1.2: Leia os cabeçalhos do seu site. Abra o seu próprio site (ou wordpress.org) com as ferramentas de programador do seu navegador (F12, separador Rede, atualize a página, clique no primeiro pedido). Indique que servidor consta no cabeçalho server (ou "nenhum" se não existir) e se há um cabeçalho que indique que a página veio de uma cache (que nome e que valor). O programa pede a mesma página e compara.

Leitura adicional

Estes artigos descrevem os passos nos painéis da WebOké; noutros painéis funcionam de forma semelhante.

• Manual DirectAdmin 1.9: Conceitos explicados: domínio, sub-domínio, pointer, DNS, e-mail e banco de dados
• Manual DirectAdmin 14.1: Escolher a versão do PHP (Select PHP version)
• Curso gratuito de DNS 1.4: A viagem de um pedido DNS
• Hierarquia de modelos (developer.wordpress.org, Inglês): https://developer.wordpress.org/themes/basics/template-hierarchy/