Bajo el capó: servidor web, PHP y base de datos

Módulo 1: Cómo funciona WordPress · Tiempo de lectura: 8 minutos

Objetivo de aprendizaje: tras esta lección podrá explicar paso a paso cómo una petición de página en WordPress se convierte en una página HTML, y dónde una caché acorta ese camino.

Conceptos clave: servidor web (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, consulta, index.php, jerarquía de plantillas, dinámico frente a estático, TTFB

Una página estática y una dinámica

En un sitio web estático, cada página existe como un archivo ya terminado en el servidor. El servidor web toma el archivo y lo envía. Eso es rápido y sencillo, pero cada cambio significa un nuevo archivo.

WordPress es dinámico: la página solo existe en el momento en que alguien la solicita. No hay ningún archivo contact.html. Hay un texto en la base de datos, un tema con plantillas y un conjunto de código PHP que une ambas cosas. Esto proporciona comodidad (puede modificar el texto desde su navegador), pero exige trabajo de cálculo en cada visita. Si entiende ese trabajo de cálculo, también entenderá más adelante por qué un sitio va lento, por qué la caché marca tanta diferencia y por qué una actualización de PHP puede romper algo.

El recorrido de una petición de página

Imagine que un visitante abre https://example.com/contact/. Esto es lo que ocurre:

1. DNS: el navegador busca la dirección IP de example.com (véase el curso de DNS). Establece una conexión segura con esa dirección.
2. Servidor web: en el servidor se ejecuta un servidor web, por ejemplo LiteSpeed, Apache o nginx. Este recibe la petición. Si existe un archivo o carpeta real con ese nombre (una imagen, una hoja de estilos), lo envía directamente. Si no, se aplica la regla de .htaccess (en LiteSpeed y Apache) o de la configuración de nginx: «entregue todo lo que no exista a index.php».
3. PHP: index.php es un archivo PHP. El servidor web deja que lo ejecute PHP, el lenguaje de programación en el que está escrito WordPress. PHP carga primero wp-config.php (la configuración, con los datos de la base de datos), luego el resto de WordPress, después todos los plugins activos y el tema activo.
4. Base de datos: WordPress comprueba qué contenido corresponde a /contact/ y hace preguntas a la base de datos (MariaDB o MySQL): qué página tiene el slug contact, cuáles son los ajustes del sitio, qué menú le corresponde. A esa pregunta se le llama consulta (query). Una página sencilla ya puede suponer decenas de consultas; con plugins pueden llegar a ser cientos.
5. Tema: WordPress elige qué plantilla del tema da formato a la página. Esto sigue la jerarquía de plantillas: para una página con slug contact, WordPress busca primero una plantilla page-contact, luego page-<id> (el número de la página), después page, a continuación singular y finalmente index. Gana la primera que exista.
6. Devolución del HTML: el resultado es una página HTML que PHP entrega al servidor web, y el servidor web al navegador.
7. El navegador lee el HTML y a continuación obtiene las hojas de estilos, scripts, tipografías e imágenes. Estos sí son archivos normales, así que llegan directamente del servidor web (o de una caché).

Entre el paso 2 y el paso 6 se encuentra el tiempo que necesita el servidor para generar la página. Esto se refleja en el TTFB (time to first byte): el tiempo entre la petición y el primer byte de la respuesta. En un sitio bien configurado, ese tiempo se sitúa muy por debajo de un segundo. En el módulo 6 lo medirá usted mismo.

Por qué cada plugin cuenta

En el paso 3 se cargan todos los plugins activos, en cada petición. Incluso si ese plugin no hace nada en esa página concreta. Así, un plugin para una galería de fotos también se carga cuando alguien abre su página de contacto. Cada plugin puede realizar consultas adicionales, cargar código adicional y añadir scripts adicionales a la página.

Esto explica dos cosas que encontrará a menudo en este curso:

• Tener menos plugins suele ser más rápido. No porque la cantidad en sí importe, sino porque cada plugin puede realizar trabajo en cada petición.
• Un solo plugin averiado puede dejar fuera de servicio todo el sitio. Si algo falla en el paso 3 (por ejemplo, un plugin que no funciona con la nueva versión de PHP), PHP nunca llega al paso 6. El visitante recibe una página en blanco o el mensaje «Se ha producido un error crítico en este sitio web» (lección 5.4).

De dónde vienen PHP y la base de datos

PHP y la base de datos se ejecutan en el servidor de su proveedor de alojamiento. Normalmente usted elige la versión de PHP en el panel de control (en DirectAdmin se llama Select PHP version, véase la lección 8.4). La base de datos se crea durante la instalación; el instalador suele hacerlo por usted (lección 2.2).

Algunas cosas que conviene recordar:

• Versión de PHP: cada nueva versión de PHP es más rápida y más segura, pero el código antiguo puede fallar con ella. wordpress.org recomienda actualmente PHP 8.3 o superior (datos de noviembre de 2026).
• Base de datos: wordpress.org recomienda MariaDB 10.11 o superior, o MySQL 8.0 o superior. MariaDB es una bifurcación de MySQL; para WordPress no supone ninguna diferencia.
• La base de datos suele estar en el mismo servidor (DB_HOST es entonces localhost). En alojamientos más grandes puede estar en un servidor independiente.

Caché: acortar el camino

Si cien visitantes solicitan la misma página de contacto, sin caché WordPress la genera cien veces. Cada vez las mismas consultas, la misma plantilla, el mismo HTML. Una caché de página guarda el HTML después de la primera vez. El siguiente visitante recibe la versión almacenada: los pasos 3 a 6 se eliminan.

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

Por eso la caché proporciona la mayor ganancia de velocidad (lección 6.2). También explica una confusión muy habitual: «he modificado el texto, pero veo la versión antigua». En ese caso está recibiendo una versión almacenada; tras vaciar la caché verá la nueva.

No todo puede venir de una caché. Un administrador con sesión iniciada, un carrito de la compra o una página de pago son distintos para cada visitante. Un buen plugin de caché los excluye.

Cabeceras: lo que el servidor le indica

Toda respuesta de un servidor web comienza con cabeceras (headers), antes del HTML. No las ve en la página, pero sí en las herramientas de desarrollo de su navegador (F12, pestaña Red, haga clic en la primera petición). Un ejemplo:

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 qué servidor web responde.
• link con wp-json delata que se trata de WordPress.
• x-litespeed-cache: hit significa que esta página procedía de la caché de LiteSpeed. Otras cachés usan otros nombres, como x-cache: HIT o cf-cache-status: HIT en Cloudflare.

No necesita memorizar estas líneas. Pero quien sepa leerlas podrá resolver muchos problemas por sí mismo.

Resumen

• WordPress genera cada página en el momento de la petición: servidor web, PHP, plugins, base de datos, tema, HTML.
• En cada petición se cargan todos los plugins activos; un solo plugin averiado puede detener todo el sitio.
• La jerarquía de plantillas determina qué plantilla del tema da formato a una página.
• Una caché de página evita el trabajo de cálculo entregando HTML ya almacenado. Los usuarios con sesión iniciada y los carritos de la compra no deben estar en esa caché.
• Las cabeceras de una respuesta indican qué servidor web responde y si la página procedía de una caché.

Cuestionario

Ejercicio

Ejercicio A1.2: Lea las cabeceras de su sitio. Abra su propio sitio (o wordpress.org) con las herramientas de desarrollo de su navegador (F12, pestaña Red, actualice la página, haga clic en la primera petición). Indique qué servidor web aparece en la cabecera server (o «ninguno» si no aparece) y si hay alguna cabecera que indique que la página procedía de una caché (qué nombre y qué valor). El programa solicita la misma página y compara los resultados.

Para saber más

Estos artículos describen los pasos en los paneles de WebOké; en otros paneles funcionan de forma similar.

• Manual de DirectAdmin 1.9: Conceptos explicados: dominio, subdominio, pointer, DNS, buzón y base de datos
• Manual de DirectAdmin 14.1: Elegir la versión de PHP (Select PHP version)
• Curso gratuito de DNS 1.4: El viaje de una consulta DNS
• Jerarquía de plantillas (developer.wordpress.org, en inglés): https://developer.wordpress.org/themes/basics/template-hierarchy/