PHP y Nginx: por qué una web se siente rápida o lenta

Qué hace cada uno

Cuando abres una página, Nginx normalmente es quien recibe la visita primero. Entrega archivos estáticos, maneja conexiones y organiza el tráfico para que el servidor no se ahogue.

PHP hace otra parte del trabajo: arma contenido, procesa formularios, valida datos, consulta la base de datos y genera respuestas dinámicas.

La dupla típica es:

Visitante → Nginx → PHP-FPM → aplicación → base de datos

Si Nginx sirve una imagen, un CSS o un JavaScript, no tiene que molestar a PHP. Si la página necesita lógica, entonces Nginx pasa la petición a PHP-FPM.

Por qué esta combinación se usa tanto

Nginx es muy bueno atendiendo muchas conexiones al mismo tiempo. PHP-FPM mantiene procesos PHP listos para trabajar, sin arrancar desde cero en cada visita.

Bien configurado, esto ayuda a tener:

• menos tiempo de espera;
• mejor uso del servidor;
• más estabilidad cuando sube el tráfico;
• separación clara entre archivos estáticos y contenido dinámico.

Lo que de verdad vuelve lenta una web

Mucha gente culpa “al servidor” o “a PHP”, pero casi nunca es tan simple. Una web suele ponerse lenta por una mezcla de cosas:

• imágenes gigantes sin compresión;
• consultas lentas a la base de datos;
• plugins innecesarios;
• caché mal configurado;
• demasiadas tareas corriendo al mismo tiempo;
• PHP viejo o con pocos workers;
• Nginx pasando a PHP cosas que podía servir solo;
• base de datos sin índices o saturada.

Una página lenta casi siempre es una cadena de pequeñas decisiones malas haciendo coro.

Qué mejora el rendimiento de verdad

Empieza por lo básico:

• usa caché para no repetir el mismo trabajo en cada visita;
• comprime imágenes y archivos;
• deja que Nginx sirva archivos estáticos directamente;
• actualiza PHP a una versión moderna y soportada;
• mide tiempos de respuesta antes de adivinar;
• revisa consultas lentas en la base de datos;
• limita plugins que cargan scripts en todas las páginas;
• configura workers de PHP-FPM según memoria real, no por fe.

Ejemplo mínimo de Nginx + PHP-FPM

location / {
  try_files $uri $uri/ /index.php?$query_string;
}

location ~ \.php$ {
  include fastcgi_params;
  fastcgi_pass unix:/run/php/php-fpm.sock;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

location ~* \.(css|js|jpg|jpeg|png|webp|svg|ico)$ {
  expires 30d;
  access_log off;
}

Esto no es una receta universal, pero muestra la idea: Nginx resuelve lo simple y solo manda a PHP lo que requiere PHP.

Cómo saber dónde está el cuello de botella

Antes de cambiar medio servidor, mira señales:

• tiempo de respuesta del servidor;
• uso de CPU y memoria;
• logs de errores de Nginx y PHP;
• consultas lentas en MySQL/PostgreSQL;
• tamaño total de la página;
• número de requests en el navegador.

Herramientas simples como curl, Lighthouse, logs y métricas básicas suelen decir más que una discusión eterna en un grupo de WhatsApp técnico.

Idea final

Cuando Nginx organiza bien el tráfico y PHP hace solo lo necesario, la página se siente rápida y estable. No es magia ni “un servidor más grande”. Es buena organización, configuración correcta y menos carga inútil.

Más hierro ayuda a veces. Pero si la aplicación está haciendo diez vueltas para abrir una puerta, comprar una puerta más grande no resuelve el drama.