¿Qué es un servidor?

La palabra se usa para dos cosas a la vez. MDN distingue el lado del hardware, un ordenador conectado a internet que almacena los archivos del sitio, como el HTML, las imágenes, las hojas de estilo y el JavaScript, y el lado del software, que como mínimo es un servidor HTTP: el programa que entiende las direcciones web y el protocolo HTTP y entrega el contenido.

El servidor es la otra mitad de cada visita. El navegador es el cliente que pide una página, y el servidor es quien la tiene y la envía. Un mismo ordenador puede alojar muchos sitios, y un sitio grande puede repartirse entre muchos ordenadores.

Cuando un navegador necesita un archivo, lo pide por HTTP. El servidor recibe la petición, busca el documento y lo devuelve junto con un código de estado, por ejemplo 200 si todo ha ido bien o 404 si la página no existe.

MDN distingue dos tipos de servidor web. Uno estático envía los archivos tal como están guardados. Uno dinámico añade un servidor de aplicaciones y, por lo general, una base de datos, y construye la página en el momento de cada petición, por ejemplo rellenando una plantilla HTML con contenido de la base de datos. Un sitio con miles de páginas puede funcionar con unas pocas plantillas y una base de datos grande.

Entre el usuario y el servidor de origen suele haber otros servidores. Según MDN, una CDN es un grupo de servidores repartidos por muchos lugares que guardan copias de los datos y responden desde el más cercano al usuario. Las peticiones que atiende la CDN ya no llegan al servidor de origen.

La velocidad del servidor es lo primero que se mide en una visita. El TTFB, el tiempo hasta el primer byte, cuenta lo que tarda en llegar el inicio de la respuesta. web.dev lo da como orientación: 0,8 segundos o menos es un buen valor, y más de 1,8 segundos, uno malo. El TTFB no forma parte de las Core Web Vitals, pero va antes que ellas: si el servidor tarda, todo lo demás empieza tarde.

El servidor también decide cuánto rastrea Google. Según su documentación, los rastreadores de Google calculan un límite de capacidad de rastreo para no sobrecargar el servidor. Si el sitio responde de forma constante y sus tiempos de respuesta se mantienen o mejoran, el límite sube. Si se vuelve lento o responde con errores 5xx o con un 429, el límite baja y Google rastrea menos.

En zds.es lo medimos el 15 de octubre de 2026 con diez peticiones a una página del glosario y diez a un archivo JavaScript de la plantilla. Cloudflare marca las páginas HTML como DYNAMIC, así que las responde el servidor de origen: el primer byte llegó de media a los 0,17 segundos. El archivo JavaScript sale de la caché de Cloudflare y llegó a los 0,06 segundos. Los dos valores están muy por debajo de los 0,8 segundos de referencia.

• Medir el TTFB de las páginas importantes, no solo el de la portada.
• Servir los archivos estáticos desde una CDN o una caché, para que el servidor de origen atienda solo lo que cambia.
• Revisar en Search Console el informe «Estadísticas de rastreo», que muestra el tiempo medio de respuesta y el estado del host.
• Elegir un alojamiento con capacidad suficiente para los picos de tráfico y de rastreo.
• Mantener actualizado el software del servidor.

• Medir la velocidad solo con la caché del navegador llena y no ver lo que tarda el servidor.
• Confundir el servidor de origen con la CDN y buscar el problema en el sitio equivocado.
• Dejar que el servidor responda con errores 5xx durante días sin darse cuenta.
• Bloquear a los rastreadores con reglas de seguridad demasiado estrictas.
• Dar por hecho que un buen alojamiento compensa una página muy pesada.