Mi web va lenta: cómo encontrar el cuello de botella antes de cambiar de hosting

¿Qué significa realmente que una web vaya lenta?

«Tarda mucho» describe una sensación. Para investigar necesitamos convertirla en una escena: qué página estabas abriendo, qué intentabas hacer y en qué momento te quedaste esperando. No hace falta conocer el nombre de ninguna métrica para empezar.

Piensa en la visita a una tienda online. Primero abres un producto, después ves su foto y su precio y, finalmente, eliges una talla y lo añades al carrito. La espera puede aparecer en cualquiera de esos momentos.

1. La respuesta inicial tarda en llegar

Pulsas un enlace y el navegador parece quedarse esperando antes de mostrar la nueva página. Una posibilidad es que tarde en recibir el comienzo de la respuesta, pero la pantalla en blanco, por sí sola, no lo demuestra: también puede haber contenido recibido que todavía no se ha dibujado.

El TTFB, o tiempo hasta el primer byte, ayuda a investigar esa espera inicial. En la navegación incluye etapas como la conexión y el tiempo hasta empezar a recibir la respuesta. Un TTFB alto no demuestra, por sí solo, que el hosting sea lento. Hay que separar dónde se acumula la espera antes de atribuirla al servidor, a la aplicación o a la red.

Ejemplo: abres una categoría y no aparece nada durante varios segundos; después, todo se muestra bastante deprisa. Anota esa secuencia. Nos da una hipótesis que comprobar, no una causa confirmada.

2. El HTML llega pronto, pero el contenido tarda en aparecer

El navegador necesita hacer más cosas que recibir el documento de la página. Debe interpretar su estructura, aplicar estilos, obtener recursos y dibujar el resultado. Algunas webs también necesitan ejecutar JavaScript para construir parte del contenido.

Por eso puede llegar pronto el HTML y, aun así, tardar en aparecer la foto del producto o el texto principal. La investigación se desplaza hacia los recursos y el trabajo del navegador: qué necesita para mostrar ese contenido y qué se lo está impidiendo.

Ejemplo: ves el encabezado de la tienda enseguida, pero el espacio de la foto sigue vacío. Anota qué elemento falta. Decir «la imagen principal tarda en aparecer» resulta mucho más útil que decir «la ficha carga mal».

3. La página se ve, pero tarda en responder al tocarla

El menú está a la vista. Lo pulsas y no se abre. Vuelves a pulsar y, de repente, responde. La apariencia de una página terminada puede esconder trabajo pendiente o tareas que mantienen ocupado al navegador.

JavaScript puede retrasar esa reacción. En algunas aplicaciones también hay una fase que conecta los controles visibles con su comportamiento, conocida como hidratación. Son posibilidades que conviene investigar; no todas las webs utilizan esa técnica ni todos los botones lentos tienen la misma causa.

Aquí hay una distinción importante: que un botón reconozca tu pulsación y que termine la operación son dos tiempos diferentes. Si al añadir un producto aparece inmediatamente «Añadiendo…», pero el carrito tarda en actualizarse, la interfaz ha reaccionado; queda por investigar la operación que está esperando.

La métrica INP ayuda a evaluar la respuesta visual a las interacciones. No equivale al tiempo total que tarda en completarse una compra, una búsqueda o una petición remota.

4. Algunas páginas son rápidas y otras muy lentas

La portada abre bien, pero buscar un producto tarda. O navegar por el catálogo resulta cómodo, mientras el carrito se queda pensando cada vez que cambias una cantidad.

Esa diferencia acota la investigación. Cada ruta puede ejecutar un trabajo distinto, consultar otros datos, cargar recursos diferentes o disponer de una caché que otra página no utiliza. La aplicación y la base de datos son candidatas, pero también puede haber un recurso pesado o una dependencia externa exclusiva de esa pantalla.

Qué recoger: una dirección que vaya bien y otra que vaya mal, probadas desde el mismo dispositivo y conexión. Anota también si habías iniciado sesión. Comparar la portada como visitante con el carrito de un cliente identificado mezcla condiciones distintas.

5. La lentitud aparece solo algunas veces

A primera hora todo funciona. Más tarde, la misma operación tarda mucho más. Cuando alguien intenta comprobarlo, vuelve a ir bien.

La intermitencia también es información. Puede coincidir con más solicitudes, trabajos programados, diferencias de caché o respuestas variables de otros servicios. Ninguna de esas explicaciones queda demostrada porque ocurra a una determinada hora.

Qué recoger: hora y zona horaria, página, acción y duración aproximada. «Hoy a las 10:15, hora peninsular, buscar este producto tardó unos ocho segundos» permite investigar mucho mejor que «por las mañanas va fatal». Si desaparece al recargar, anótalo también: la segunda visita puede encontrar recursos ya descargados o contenido en caché.

6. Solo algunos usuarios la perciben lenta

En tu ordenador funciona bien, pero un cliente insiste en que desde el móvil no puede utilizarla con comodidad. Ambas experiencias pueden ser ciertas.

Influyen la conexión, la distancia a los sistemas que sirven el contenido y la capacidad del dispositivo para procesarlo. También pueden cambiar el contenido y el trabajo que recibe cada visitante: sesión iniciada, idioma, ubicación o personalización.

Qué comparar: la misma acción en condiciones conocidas. Si pruebas en un móvil y un ordenador conectados a redes diferentes, habrás cambiado dos variables a la vez. Empieza por una comparación sencilla —el mismo dispositivo en otra red, por ejemplo— y conserva el resto de las condiciones.

Convierte «va lenta» en una descripción que se pueda investigar

No necesitas resolver el problema para describirlo bien. Basta con dejar una observación que otra persona pueda intentar reproducir:

Ya sabemos qué acción estudiar, en qué condiciones y qué parte de la experiencia introduce la espera. Todavía no sabemos si la causa está en una consulta, un servicio externo o cualquier otro componente. Ese es el siguiente paso: medir el recorrido para comprobar dónde se consume el tiempo.

Referencias técnicas: qué mide el TTFB y qué mide la respuesta a las interacciones (INP), en web.dev.

Primero mide: ¿en qué parte del proceso se pierde el tiempo?

Imagina que una ficha de producto tarda cinco segundos en mostrar su imagen principal. Ese dato describe la espera, pero todavía no explica cómo reducirla. ¿La imagen tarda en descargarse o el navegador no empieza a pedirla hasta el cuarto segundo? El resultado parece parecido; la intervención sería diferente.

Medir sirve para repartir la espera entre etapas. Antes de instalar nada, vamos a observar qué solicita el navegador, cuándo lo solicita y qué ocurre mientras espera.

Empieza por una página y una acción concretas

Elige la operación que has identificado en la sección anterior: abrir un producto, desplegar un menú o aplicar un filtro. Anota la dirección, el dispositivo, la conexión y si has iniciado sesión. Mantén esas condiciones durante la primera serie de pruebas.

Para abrir la página interesa registrar su carga. Para investigar un carrito que tarda en actualizarse, interesa registrar la pulsación y lo que sucede después. Medir únicamente la portada no explica el tiempo que consume una operación dentro de la tienda.

Una primera lectura con Network, sin cambiar la web

En Chrome, abre las herramientas de desarrollador desde Inspeccionar y entra en Network o Red. Con el registro activo, recarga la página. Verás las solicitudes de documentos, imágenes, estilos y otros recursos.

1. Localiza el documento principal. Puedes filtrar por Doc. Abre su detalle y consulta Timing: muestra cómo se reparte el tiempo de esa solicitud.
2. Mira la columna Waterfall. Las barras sitúan cada petición en el tiempo. Observa cuáles empiezan tarde y cuáles permanecen abiertas mucho tiempo.
3. Reproduce la acción lenta. Si es un filtro o un carrito, utiliza Fetch/XHR para localizar peticiones que podrían corresponder a esa operación. Comprueba su dirección y el momento en que aparecen.
4. Revisa qué inicia la petición. Initiator ayuda a seguir su origen. No todas las solicitudes registradas después de un clic pertenecen a la acción: también puede haber medición u otra actividad de fondo.

Los nombres y la disposición pueden variar según el idioma y la versión del navegador. La guía de inspección de red de Chrome explica este recorrido con capturas.

Cómo leer una cascada de peticiones

Una waterfall, o cascada, representa cuándo empieza y termina cada solicitud. Se lee de izquierda a derecha. Varias peticiones pueden solaparse: sumar sus duraciones no da el tiempo de carga de la página.

En este ejemplo, la imagen tarda 1,5 segundos en obtenerse, pero su solicitud no empieza hasta los 2,5 segundos. Hay dos aspectos que estudiar: por qué se pide tan tarde y por qué tarda ese tiempo en llegar. Comprimirla podría mejorar el segundo, sin resolver el primero.

La cascada tampoco demuestra que JavaScript haya retrasado la imagen solo porque su descarga ocurra antes. Para comprobar esa relación hay que mirar qué inicia la solicitud y, si hace falta, registrar el trabajo del navegador.

Qué significa cada tramo de la espera

Al abrir el detalle de una petición encontrarás fases que conviene separar. No todas aparecen siempre: el navegador puede reutilizar una conexión, resolver un nombre desde caché o recuperar un recurso sin acudir a la red.

Ojo con comparar cifras que tienen distinto punto de partida. El tramo Waiting (TTFB) de una solicitud en Network no debe confundirse con el TTFB de navegación completo que incluye fases anteriores. Consulta el desglose de la herramienta antes de comparar resultados.

Después del HTML, observa CSS, JavaScript, imágenes y fuentes. También las peticiones a otros dominios: un mapa o un servicio externo pueden añadir esperas. Que una solicitud termine la última no significa que esté retrasando el contenido o la acción que te preocupa.

Cuando la red no explica toda la espera

Una descarga terminada no equivale a una interfaz lista. El navegador puede seguir ejecutando código, calculando estilos o dibujando contenido. Si los recursos llegan pronto pero el menú continúa bloqueado, registra la acción en el panel Performance para observar las tareas del navegador. La referencia del panel Performance describe cómo relacionar la actividad de red con la ejecución y la presentación.

En sentido contrario, el navegador tampoco ve el detalle de lo que ocurre dentro del servidor. Puede mostrar una espera larga sin distinguir entre una consulta SQL, una cola de ejecución o una llamada externa. Para separarlas necesitaremos registros o mediciones de la aplicación. Si esta expone tiempos mediante Server-Timing, pueden aportar contexto; su ausencia no demuestra que esas operaciones sean rápidas.

Repite las pruebas y distingue las cachés

Haz, como primera exploración, entre tres y cinco repeticiones por condición. Conserva los resultados, no solo el mejor. Esa pequeña serie ayuda a detectar variación, aunque no representa por sí sola la experiencia de todos los usuarios.

• Sin recursos en la caché del navegador: la opción Disable cache de DevTools permite investigar ese escenario mientras las herramientas están abiertas. No vacía automáticamente la caché del servidor ni de una CDN.
• Con recursos reutilizables: desactiva esa opción y repite la visita. Anota si mejora. La diferencia es una pista, no una prueba de que toda la mejora proceda de la caché local.
• Con y sin sesión: registra por separado ambos casos. Pueden recibir contenido diferente y utilizar políticas de caché distintas.

No borres las cachés de producción solo para hacer una primera medición. Una «caché fría» siempre debe indicar qué caché está fría. Además, un service worker puede gestionar respuestas de forma independiente y merece una comprobación específica si la web lo utiliza.

PageSpeed bajo y web lenta no son exactamente el mismo problema

PageSpeed Insights combina una prueba de laboratorio con información de usuarios reales cuando hay datos disponibles. La puntuación de rendimiento procede del análisis de laboratorio: no es un cronómetro universal de tu negocio ni identifica por sí sola la causa de un retraso.

Los datos reales reflejan otras visitas, dispositivos y conexiones. Comprueba si el informe corresponde a esa URL o al conjunto del origen. Una mejora recién publicada tampoco se refleja de inmediato en todo el histórico. Google explica estas diferencias en su documentación de PageSpeed Insights.

Una portada puede obtener una buena puntuación mientras el buscador tarda demasiado después de iniciar sesión. Y una prueba simulada exigente puede detectar problemas que tu ordenador apenas deja notar. Utiliza el informe para orientar la investigación y contrástalo con la operación concreta que quieres mejorar.

Con esa evidencia podemos seguir el recorrido completo de la petición y buscar en la capa adecuada. Ese mapa es el siguiente paso.

Dónde puede estar el cuello de botella: el recorrido de una petición web

La cascada nos permite ver cuándo llega cada recurso. Ahora necesitamos un mapa para interpretar lo que no se ve desde el navegador. Cuando una petición pasa dos segundos esperando respuesta, ¿quién está trabajando y quién está esperando a otro componente?

Seguiremos una ficha de producto generada por una aplicación. Es un recorrido habitual, no una arquitectura obligatoria: una página estática, una respuesta en caché o una aplicación que carga los datos después pueden tomar otros caminos.

Antes del código: llegar al sistema que va a responder

El navegador necesita alcanzar un destino. Resolver el dominio y establecer una conexión puede añadir tiempo antes de que la aplicación reciba nada. Si esa información o la conexión se reutilizan, una segunda visita puede ahorrarse parte del recorrido.

Además, el primer sistema que responde puede ser un intermediario. Una CDN distribuye contenido; un proxy inverso recibe solicitudes y las encamina hacia otros servidores; un WAF aplica reglas de protección al tráfico web. Un mismo proveedor puede reunir varias de estas funciones.

La pregunta útil aquí es: ¿la petición llegó al origen o recibió una respuesta antes? Si una CDN entrega una copia válida, ese acceso no sirve para medir cuánto tardaría la aplicación en generar la página desde cero. Si no puede reutilizarla, el viaje continúa. Las cabeceras de caché pueden ayudar a distinguirlo, aunque su interpretación depende del sistema utilizado.

En el origen: recibir la petición no significa empezar a ejecutarla

El servidor web puede entregar directamente un archivo o delegar la generación de la respuesta. En una instalación con PHP, por ejemplo, puede enviar el trabajo a PHP-FPM, que administra procesos capaces de ejecutar ese código.

Conviene separar dos momentos: esperar un proceso disponible y ejecutar la aplicación. Una petición puede tardar mucho aunque su código sea relativamente rápido si antes pasa tiempo en una cola. También puede empezar enseguida y consumir demasiado tiempo durante la ejecución.

Esto explica por qué «el servidor ha tardado dos segundos» todavía es una descripción incompleta. Necesitamos saber cuánto fue espera, cuánto fue trabajo y qué componente midió ese intervalo. Más adelante profundizaremos en recursos y procesos; por ahora basta con distinguir esas responsabilidades.

Dentro de la aplicación: el tiempo puede estar en una dependencia

Para mostrar un producto, la aplicación podría consultar el catálogo, recuperar una tarifa y preparar la plantilla. Algunas operaciones leen datos locales; otras podrían consultar una caché o pedir información a un servicio remoto.

La base de datos no envía después la petición a una API como si fueran estaciones consecutivas. Es la aplicación la que coordina las operaciones que necesita. Puede ejecutarlas una detrás de otra o hacer parte de ellas en paralelo. También puede repetir innecesariamente una misma consulta.

Si espera una respuesta externa, la petición sigue abierta aunque el procesador tenga poco trabajo que hacer en ese instante. Por eso una CPU tranquila no demuestra que la aplicación esté respondiendo bien. Y una duración alta atribuida a la aplicación puede incluir tiempo que esta pasa esperando a otro sistema.

Un ejemplo: dos segundos que no se arreglan por igual

Supongamos que hemos instrumentado una petición y obtenido este reparto. Las cifras son ficticias y los intervalos del ejemplo son consecutivos, sin solapamientos.

El total es de dos segundos en el origen. La consulta de datos representa el 75 % de ese intervalo: es una candidata clara para investigar primero. Eso no demuestra todavía si le falta un índice, espera un bloqueo o procesa demasiado volumen.

El ejemplo también marca un límite: eliminar por completo los 0,15 segundos de código propio no haría desaparecer los 1,50 segundos de la consulta. Elegir qué mejorar exige mirar su contribución al retraso, además de la facilidad de cambiarlo.

En una medición real, cuidado con sumar duraciones incluidas unas dentro de otras. Si una herramienta llama «tiempo de aplicación» a todo el intervalo y dentro registra una consulta, sumar ambas cifras contaría esa consulta dos veces. Tampoco se suman sin más tareas ejecutadas en paralelo. Las trazas ayudan a reconstruir esas relaciones.

De vuelta al navegador: recibir HTML no termina el recorrido

La respuesta vuelve hacia el visitante y el navegador empieza a procesarla. Al encontrar referencias a otros recursos puede iniciar nuevas solicitudes, algunas al mismo dominio y otras a proveedores externos. No tiene que esperar necesariamente a descargarlo todo para mostrar algo.

Ahí aparece otro posible límite: disponer pronto del HTML no garantiza que la imagen principal llegue pronto ni que el dispositivo pueda ejecutar con fluidez el código recibido. Esta parte del recorrido se observa desde el navegador; una medición del servidor no basta para explicarla.

Y el viaje puede repetirse después de cargar la página. Al cambiar una talla o aplicar un filtro, JavaScript puede solicitar datos y actualizar solo una parte de la pantalla. En esa petición, la respuesta podría ser JSON en lugar de HTML, pero vuelven a existir conexión, intermediarios, ejecución y presentación del resultado.

Utiliza el mapa para decidir dónde mirar después

• La espera está antes de llegar al origen: contrasta conexión, intermediarios y comportamiento de caché.
• El origen recibe la petición, pero tarda en prepararla: separa cola, ejecución y dependencias con registros o trazas.
• La respuesta llega pronto, pero el contenido o la interacción tardan: estudia los recursos y el trabajo del navegador.

Para conectar esas observaciones, intenta seguir la misma petición mediante su identificador y registros asociados, cuando estén disponibles. Comparar una visita que pasó por caché con otra que ejecutó todo el backend puede producir una explicación equivocada.

Empezaremos por el principio del recorrido: qué puede retrasar la conexión antes de que la aplicación tenga ocasión de responder.

Referencias para ampliar: cómo trabaja el navegador, caché y tiempo hasta la primera respuesta y mediciones del backend con Server-Timing.

Cuando el problema ocurre antes de llegar a la aplicación

Abres la web desde la oficina y tarda una eternidad. Pruebas con el mismo portátil conectado al móvil y aparece enseguida. La tentación es dar por culpable al wifi. La comparación aporta una pista, pero al cambiar de red también pueden cambiar la resolución DNS, el recorrido hasta el servidor y el nodo de la CDN que te atiende.

Antes de tocar PHP o la base de datos, conviene comprobar si la espera está en ese viaje. La pregunta de esta sección es concreta: ¿qué sucede entre el visitante y el sistema que prepara la respuesta?

¿Es lenta la web o la conexión? Empieza por una comparación controlada

Utiliza la misma dirección, dispositivo, navegador y estado de sesión. Repite varias veces con una red y después con otra, anotando la hora. Si puedes, vuelve a la primera: una mejora puntual puede coincidir con una caché recién calentada o con el final de una incidencia.

Una prueba de velocidad de internet mide el acceso al servidor de esa prueba. Tener muchos megabits por segundo no garantiza una conexión de baja latencia con tu web. La capacidad para transferir datos y el tiempo que tarda en empezar una respuesta son aspectos diferentes.

DNS: encontrar la dirección también puede consumir tiempo

El DNS permite resolver un nombre como tienda.example en las direcciones necesarias para conectarse. Si esa resolución tarda o falla, la aplicación puede estar funcionando correctamente y aun así no recibir la visita a tiempo.

Busca el tramo DNS en el detalle de la petición del navegador. Si no aparece, puede haberse reutilizado información disponible: no significa que el dominio no utilice DNS. Observa también qué dominio tarda; a veces la página principal responde bien y la espera corresponde a una fuente, una imagen o un servicio alojado fuera.

Hay que distinguir resolución lenta de resolución incorrecta. Después de un cambio, un visitante podría seguir obteniendo una dirección anterior desde una caché. En ese caso interesa comparar las respuestas y su vigencia, además de la duración. Cambiar registros a ciegas puede introducir otra variable sin explicar la diferencia.

Si una comprobación desde terminal y otra desde el navegador no coinciden, revisa qué mecanismo de resolución utiliza cada una. El navegador puede tener DNS seguro configurado y no estar consultando por el mismo camino que la herramienta del sistema.

IPv4 e IPv6: el mismo nombre puede abrir caminos distintos

Un dominio puede publicar direcciones IPv4 e IPv6. Si uno de esos caminos presenta problemas, la experiencia puede variar entre redes y dispositivos. Eso no convierte a IPv6 en una causa general de lentitud: hay que comprobar el acceso concreto.

En una investigación técnica se pueden comparar solicitudes forzadas por cada familia, siempre que el dominio y la conexión las soporten. Un fallo de IPv6 en una red que no tiene conectividad IPv6 no demuestra un defecto del servidor. Lo útil es encontrar una diferencia repetible y situarla en el tramo adecuado.

Conexión, TLS y redirecciones: trabajo anterior al contenido

Una conexión nueva requiere comunicación entre los extremos. En HTTPS también hay una negociación segura. La distancia, el recorrido de red y los problemas de conectividad pueden afectar a esos intercambios. El protocolo utilizado y la reutilización de conexiones modifican el trabajo necesario.

Por eso conviene comparar primeras conexiones con otras ya establecidas, sin interpretar una segunda visita más rápida como prueba exclusiva de una caché de página. Son mecanismos distintos que pueden coincidir.

Revisa también las redirecciones. Si una dirección pasa por varias variantes antes de llegar a la definitiva, el visitante debe completar esos pasos. Una redirección necesaria hacia HTTPS o hacia la URL canónica puede ser correcta; lo que interesa detectar son rodeos evitables o destinos erróneos. Un error de certificado, por su parte, necesita corregirse: desactivar su validación no es una optimización.

CDN, proxy y WAF: separa los dos lados del intermediario

Cuando hay una CDN o un proxy inverso, existen al menos dos tramos relevantes: visitante → intermediario e intermediario → origen. Una respuesta lenta observada desde fuera no dice en cuál se ha consumido el tiempo.

Comprueba si la respuesta procede de caché, si el intermediario tuvo que contactar con el origen y si hubo una redirección o una comprobación de seguridad. Las cabeceras y los registros del proveedor pueden aportar esa información, aunque sus nombres y significado varían entre plataformas.

Una copia servida cerca del visitante puede reducir viajes al origen. Pero una respuesta personalizada que no se pueda reutilizar seguirá necesitando el trabajo correspondiente. Añadir una CDN no garantiza que mejore un carrito lento, y una respuesta rápida desde caché no demuestra que el origen sea rápido.

Si usas Cloudflare u otro servicio similar, compara sus observaciones con los registros del origen. La ausencia de una petición en un registro concreto solo es útil si sabes que ese registro está completo y corresponde al servidor y periodo correctos. No desactives globalmente el proxy o el WAF para «ver si mejora»: perderías condiciones de comparación y podrías retirar protecciones innecesariamente.

Latencia, pérdidas y geografía: cuándo investigar el recorrido

Si el problema se repite desde una ubicación o un operador, mientras otras conexiones funcionan bien, conserva esa diferencia como evidencia. Anota horas, destinos y resultados comparables para que el proveedor pueda investigar la ruta.

Herramientas como ping, traceroute o mtr pueden ayudar, pero sus resultados no equivalen al tiempo de una petición HTTPS. Algunos equipos limitan o ignoran sus respuestas de diagnóstico. Un salto intermedio con asteriscos o aparente pérdida no prueba que esté descartando el tráfico que continúa hasta el destino.

La comprobación importante es si la anomalía se sostiene hasta el destino y coincide con retrasos o fallos en las solicitudes reales. Así evitamos atribuir al proveedor una avería basándonos únicamente en un salto que no responde a la herramienta.

Una comprobación técnica opcional con curl

Si tienes acceso a una terminal, esta consulta permite observar hitos de una petición HTTPS. Sustituye la dirección por una página pública de tu web que se pueda consultar sin ejecutar ninguna operación:

curl --http1.1 --connect-timeout 10 --max-time 30 \
  --output /dev/null --silent --show-error \
  --write-out 'HTTP: %{http_code}\nDNS: %{time_namelookup}s\nConexion: %{time_connect}s\nTLS: %{time_appconnect}s\nPrimer byte: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
  'https://tu-dominio.example/'

Ejemplo para Linux o macOS; fija HTTP/1.1 para simplificar la comparación y no sigue redirecciones. No ejecuta JavaScript ni reproduce la sesión del navegador. Los tiempos son acumulados desde el inicio: no los sumes. Si devuelve un código 3xx, has medido esa respuesta de redirección.

En una conexión HTTPS directa y nueva, la diferencia entre los hitos de conexión y TLS orienta sobre la negociación segura. El intervalo posterior hasta el primer byte incluye más que ejecución de código: no lo etiquetes automáticamente como «tiempo de PHP». Los proxies y otras condiciones pueden cambiar la interpretación. Consulta la documentación oficial de curl para el significado de cada variable.

Si la conexión se establece con normalidad y la espera aparece después, seguiremos hacia el origen. El siguiente paso será comprobar si el servidor carece realmente de recursos o si el retraso tiene otra explicación.

¿El servidor tiene realmente falta de recursos?

La web va lenta y el panel del hosting muestra la memoria casi llena. La propuesta parece inmediata: contratar más RAM. Pero ese gráfico no cuenta si la memoria está ocupada por datos reutilizables, si hay procesos esperando disco o si la aplicación ha alcanzado un límite propio mientras al servidor todavía le sobra capacidad.

Para justificar una ampliación necesitamos relacionar un recurso limitado con la espera de las peticiones. Revisaremos CPU, memoria, almacenamiento y concurrencia durante el mismo intervalo en que la web tarda. Una captura tomada después puede mostrar un servidor tranquilo y ocultar lo ocurrido.

CPU: mira los núcleos y la cola, además del porcentaje

Una CPU ocupada está haciendo trabajo. Eso no es un problema por sí mismo. La señal que interesa es si, de forma sostenida, el trabajo que necesita ejecutarse supera la capacidad disponible y coincide con el retraso de la web.

El promedio del servidor puede esconder un límite localizado. Ejemplo ficticio: en una máquina con cuatro CPU lógicas, una tarea que utiliza por completo una sola podría verse como aproximadamente un 25 % de uso total. Añadir más núcleos no garantiza acelerar esa operación si no puede repartir su trabajo entre ellos.

Comprueba qué procesos consumen CPU, durante cuánto tiempo y si pertenecen a las peticiones lentas. Una conversión de imágenes, una importación o una copia comprimida pueden competir con la web. La coincidencia merece investigarse; no autoriza a detener procesos sin conocer su función.

El load average tampoco es un porcentaje de CPU. En Linux incluye tareas ejecutables y tareas en espera ininterrumpible, frecuentemente relacionadas con entrada/salida. Una carga elevada puede exigir mirar el disco o una espera del sistema, no solo el procesador.

Memoria: poca RAM libre no equivale a falta de RAM

Linux aprovecha memoria para cachés que pueden recuperarse cuando hace falta. Por eso conviene observar la memoria disponible, además de la estrictamente libre, y comprobar si existe presión sostenida. El manual de free distingue ambas medidas.

La swap también requiere contexto. Tener espacio de intercambio ocupado no prueba que el sistema esté intercambiando memoria intensamente en este momento. Interesan la actividad de entrada y salida, los procesos afectados y su relación con las pausas.

Otra evidencia importante son las terminaciones por falta de memoria, conocidas como OOM. Revisa qué proceso terminó, cuándo y bajo qué límite: puede agotarse la memoria permitida a un contenedor aunque el host todavía tenga capacidad. No todos los reinicios son OOM; hay que verificar el motivo en los registros.

En una web con PHP y base de datos, aumentar simultáneamente el número de procesos puede agravar la situación: cada uno necesita memoria y los servicios comparten recursos. Más RAM puede ser adecuada si existe una necesidad sostenida, pero también interesa saber si el consumo crece por concurrencia, por una operación excepcional o por una fuga.

Disco: importa cuánto tarda cada operación, no solo cuánto espacio queda

Un disco puede tener muchos gigabytes libres y responder lentamente. Capacidad y rendimiento son cuestiones diferentes. Para estudiar rendimiento observamos latencia, operaciones por segundo —IOPS—, volumen transferido y trabajo pendiente.

Una base de datos puede necesitar muchas operaciones pequeñas; una copia de seguridad, transferencias grandes. Ambas compiten de maneras distintas. El almacenamiento contratado puede limitar las operaciones o el caudal, y ciertas modalidades permiten ráfagas que no se mantienen indefinidamente.

El porcentaje de utilización o la espera de entrada/salida aportan contexto, pero no bastan para declarar «disco saturado». La interpretación depende del dispositivo y de su paralelismo. Busca una relación entre el aumento de latencia, la cola y las operaciones que está realizando la web.

Comprueba también espacio e inodos disponibles: agotarlos puede provocar errores al escribir sesiones, temporales o registros. Es un problema distinto de disponer de almacenamiento lento. Antes de borrar archivos, identifica su función y aplica la política de retención correspondiente.

Concurrencia: pueden faltar plazas aunque sobren recursos

Imagina ocho procesos disponibles para atender solicitudes y ocho ocupados esperando una API. Una novena petición podría quedar en cola, aunque la CPU esté poco utilizada. El límite visible es la disponibilidad de procesos; la causa que los mantiene ocupados está en otra dependencia.

Algo parecido puede ocurrir con un grupo de conexiones a la base de datos. La petición espera poder entrar, en lugar de consumir CPU continuamente. Por eso interesa distinguir tiempo en cola de tiempo ejecutando o esperando dentro de la operación.

Aumentar el número de plazas puede reducir una cola y crear otra: más solicitudes simultáneas pueden presionar la base de datos o agotar memoria. La configuración concreta de los procesos web y de PHP merece su propio análisis, que abordaremos en el siguiente bloque.

Hosting, máquinas virtuales y contenedores: comprueba el límite efectivo

Los recursos anunciados no siempre coinciden con lo que puede utilizar un proceso en cada instante. Revisa las cuotas de CPU y memoria, las restricciones de almacenamiento y los límites del plan. En contenedores, contrasta las métricas del host con las del servicio afectado.

Una cuota de CPU puede hacer que un proceso sea limitado —throttling— aun cuando la máquina tenga capacidad libre. En entornos virtualizados, el tiempo de CPU no concedido por el hipervisor también puede aportar una pista. Ninguno de esos datos debe confundirse automáticamente con una aplicación ineficiente.

Compartir infraestructura con otras cargas puede influir, pero no demuestra la existencia de un «vecino ruidoso». Para trasladar una incidencia al proveedor, aporta franjas horarias, métricas, límites observados y solicitudes afectadas. Es una base mucho más útil que una captura aislada del panel.

Cómo observar sin convertir el diagnóstico en otra carga

En un servidor Linux con acceso autorizado puedes empezar por consultas ligeras. Estas herramientas pueden no estar instaladas o mostrar solo una parte del entorno si se ejecutan dentro de un contenedor:

free -h
vmstat 1 6

free ofrece una instantánea. vmstat permite observar varias muestras; su primera línea resume desde el arranque y las siguientes corresponden al intervalo indicado. Revisa, entre otros campos, tareas ejecutables, procesos bloqueados y actividad de swap. Las unidades y columnas deben interpretarse según la versión y las opciones utilizadas; consulta su manual.

Si el sistema lo ofrece, PSI —Pressure Stall Information— permite observar tiempo de espera por presión de CPU, memoria o entrada/salida. Complementa los porcentajes de uso: ayuda a detectar que el trabajo está siendo frenado por un recurso. La documentación del kernel explica sus métricas y su disponibilidad por grupos de procesos.

Para una incidencia intermitente, el histórico de monitorización suele ser más útil que conectarse después. Evita lanzar pruebas de carga o benchmarks sobre producción como primer paso: medir el comportamiento existente y provocar carga son acciones distintas.

Un caso práctico: el gráfico de memoria señala al lugar equivocado

Escenario ficticio: una tienda se vuelve lenta durante una copia de seguridad. El panel muestra poca memoria libre, pero la memoria disponible se mantiene estable y no aparece presión sostenida de memoria. En cambio, sube la latencia del almacenamiento y aumentan los tiempos de las consultas durante esa misma ventana.

La primera hipótesis sería competencia por entrada/salida, no falta de RAM. Para contrastarla podríamos comparar ejecuciones equivalentes y, en una ventana controlada, ajustar la planificación o limitar la carga de la copia, manteniendo su cobertura y verificando el resultado. La coincidencia temporal orienta; una comparación controlada aporta evidencia más fuerte.

Cuando hay una limitación real, ampliar capacidad puede estar justificado. Si además hay que dimensionar la infraestructura para sostener el crecimiento, entra en juego el rendimiento y la escalabilidad de servidores. Cuando las peticiones esperan por configuración o por una dependencia, el siguiente paso es entender esa espera. Empezaremos por el punto donde el servidor web entrega el trabajo a PHP.

Cuando el cuello está entre el servidor web y PHP

La CPU no parece agotada, queda memoria disponible y, aun así, abrir una página dinámica tarda varios segundos. Las imágenes se descargan bien. En esta situación conviene mirar cómo se entrega el trabajo a PHP: una petición puede estar esperando turno antes de ejecutar una sola línea de la aplicación.

Este bloque se aplica a instalaciones que utilizan PHP-FPM, habituales en WordPress, PrestaShop y aplicaciones PHP. Otras arquitecturas gestionan la ejecución de otra forma. Primero identifica qué atiende realmente tu web; no copies ajustes de un sistema que no coincide con el tuyo.

Apache o Nginx reciben la petición; PHP-FPM organiza la ejecución

El servidor web puede entregar archivos estáticos y pasar las solicitudes PHP a un servicio de ejecución. Nginx suele comunicarse con PHP-FPM mediante FastCGI. Apache también puede utilizar FPM, aunque existen otras configuraciones.

Por tanto, saber que una web usa Apache no demuestra que deba migrarse a Nginx para mejorar. Interesa conocer el recorrido efectivo y sus límites. Aumentar conexiones en el servidor web no crea automáticamente más capacidad para ejecutar PHP.

Qué limita realmente pm.max_children

PHP-FPM agrupa procesos en pools. La directiva pm.max_children establece el máximo de procesos hijos de un pool y limita cuántas solicitudes puede atender simultáneamente. No representa visitantes diarios ni conexiones totales de la web.

Ejemplo ficticio: un pool dispone de ocho procesos y los ocho están ocupados. Llega una novena solicitud. Puede esperar aunque utilice una página sencilla, porque todavía no ha conseguido un proceso que la ejecute. Si quienes ocupan los procesos están esperando una API, la CPU podría seguir relativamente tranquila.

Hay dos preguntas diferentes: ¿hemos alcanzado el límite del pool? y ¿por qué permanecen ocupados sus procesos? La primera localiza una restricción; la segunda orienta la solución. Duplicar el límite sin responder ambas puede trasladar la saturación a la memoria o a la base de datos.

Cómo reconocer una cola con evidencia

Cuando la página de estado de FPM está habilitada y restringida al entorno de administración, permite observar actividad y colas. No debe exponerse públicamente: puede revelar información operativa. Consulta el significado de sus campos en el manual de estado de PHP-FPM.

Observa varias muestras y relaciónalas con las peticiones afectadas. Una cola breve durante una ráfaga no equivale a una espera sostenida. Además, comprueba qué pool estás mirando: la tienda y el backoffice podrían compartirlo o tener pools separados.

Static, dynamic y ondemand: distintas formas de disponer de procesos

FPM puede mantener un número fijo de procesos con static, ajustar su cantidad con dynamic o crearlos según llegan solicitudes con ondemand. La elección modifica el equilibrio entre recursos reservados y disponibilidad para atender trabajo.

En un modo que crea procesos según la demanda, una ráfaga puede encontrar una situación diferente a la de un pool que ya mantiene procesos preparados. Pero reservar más procesos consume recursos incluso cuando la demanda es baja. No hay un modo ganador para todas las webs.

Antes de cambiarlo, comprueba la configuración efectiva, el patrón de llegadas y el coste de los procesos. El archivo que encuentras primero no siempre contiene los valores que utiliza el pool de producción. La documentación de configuración de FPM describe las directivas y sus relaciones.

Dimensionar el pool sin convertir la memoria en el siguiente problema

Un límite adecuado necesita dejar margen para el sistema operativo, la base de datos y otros servicios. También debe respetar las cuotas del contenedor o del hosting y la capacidad de las dependencias que recibirán más trabajo.

Dividir la RAM total entre el tamaño aparente de un proceso no produce por sí solo un valor fiable. Hay memoria compartida, solicitudes con consumos distintos y picos que una instantánea no representa. Mide procesos bajo carga representativa y distingue la memoria compartida de la privada cuando la herramienta lo permita.

Una ampliación controlada tiene sentido si hay peticiones en cola, margen real y dependencias capaces de absorber más concurrencia. Después hay que verificar si baja la espera sin aumentar errores, presión de memoria ni latencia de consultas.

Timeouts: esperar más no hace que el trabajo termine antes

En el recorrido puede haber límites del proxy, del servidor web, de PHP-FPM, de PHP y de las llamadas externas. No todos miden lo mismo: algunos se refieren a intervalos sin recibir datos y otros al tiempo permitido a una operación o solicitud.

Si aparece un timeout, identifica quién lo emite y qué estaba esperando. Ampliarlo puede permitir que una operación legítima finalice, pero también mantener procesos ocupados durante más tiempo. No es una corrección automática de rendimiento.

Ejemplo: si todos los procesos esperan a un proveedor que tarda demasiado, concederles otros treinta segundos no libera plazas. Primero hay que estudiar esa dependencia y qué comportamiento debería tener la aplicación cuando no responde a tiempo.

El slowlog ayuda a descubrir qué mantiene ocupado a PHP

El registro lento de FPM puede capturar una traza cuando una solicitud supera el umbral configurado mediante request_slowlog_timeout. Esa traza ayuda a localizar dónde estaba el código en ese instante: una consulta, una llamada remota o una función de la aplicación.

No es un perfil completo de toda la ejecución ni describe automáticamente la espera anterior a entrar en PHP. Una traza aislada ofrece una pista; varias observaciones de solicitudes comparables permiten comprobar si el patrón se repite.

Si se habilita para investigar, utiliza un umbral razonable, acceso restringido y retención controlada. Relaciona el registro con la URL y el momento de la incidencia. Los detalles de rutas y llamadas son útiles para el equipo técnico, no contenido que deba publicarse en la web.

OPcache y versión de PHP: comprobar antes de optimizar

OPcache guarda código PHP compilado para reutilizarlo. Reduce trabajo repetido de análisis y compilación; no guarda por sí mismo la página terminada ni convierte una consulta lenta en rápida. El manual de OPcache explica su función.

Comprueba que está activo en el entorno web que atiende la aplicación, no únicamente en la terminal. Revisa sus indicadores y la política de actualización del código durante los despliegues. Vaciarlo continuamente puede eliminar precisamente el trabajo que se pretende reutilizar.

La versión de PHP también forma parte del diagnóstico. Actualizar puede aportar mejoras, pero exige comprobar compatibilidad del código, módulos y extensiones, además de repetir la medición sobre operaciones equivalentes. La versión utilizada por el comando de terminal puede ser distinta de la que utiliza FPM.

Si las solicitudes entran enseguida y permanecen demasiado tiempo ejecutándose, toca mirar dentro de la aplicación. El siguiente bloque abordará cómo localizar el código que consume ese tiempo.

Cuando el código de la aplicación es el que tarda

Ya sabemos que la petición ha entrado en PHP y que no ha pasado la mayor parte del tiempo esperando una plaza en el pool. Dentro de la aplicación, una ficha de producto puede hacer mucho más que buscar un título y una foto: aplicar precios, consultar disponibilidad, preparar variantes, cargar recomendaciones y construir la respuesta. La pregunta ahora es qué operación ocupa el tiempo que percibe el visitante.

«El código es lento» todavía abarca demasiadas posibilidades. Un proceso puede estar calculando, leyendo archivos, consultando la base de datos o esperando una API. Si confundimos tiempo transcurrido con tiempo de CPU, optimizaremos una función que quizá pasó la mayor parte de su vida esperando.

Separa trabajo propio y espera de dependencias

Imagina una petición ficticia de 2,4 segundos: 0,2 se consumen antes de entrar en la aplicación, 0,15 en preparar el producto, 1,6 esperando una API de stock y 0,45 en el resto del trabajo. Solo el desglose permite ver que el componente prioritario es la consulta remota. Acelerar la plantilla un 50 % apenas modificaría la experiencia.

Ese ejemplo presenta intervalos consecutivos para que se entienda. En una aplicación real algunas tareas se solapan, otras contienen subtareas y una cifra puede incluir el tiempo de otra. El total de una petición no se obtiene sumando todas las duraciones que aparecen en un panel. Hace falta conocer su relación.

Son pistas, no diagnósticos automáticos. Una base de datos que trabaja en otro servidor puede tener la CPU alta mientras el servidor PHP espera con la suya baja. Hay que observar ambos lados cuando la evidencia lo exige.

El coste repetido: cien operaciones pequeñas también pueden formar un segundo

Una función que tarda 10 milisegundos puede parecer irrelevante. Si se ejecuta cien veces para una sola página, ya hemos ocupado aproximadamente un segundo, incluso antes de contar otros trabajos. A menudo sucede al recorrer productos, reglas de precio o bloques de contenido y repetir dentro de cada vuelta una consulta o una lectura de archivo.

No basta con preguntar cuál fue la llamada más lenta. Registra cuántas veces se ejecutó cada operación, cuánto tardó cada una y cuánto tiempo acumuló. Un perfil que muestra un único máximo y oculta la frecuencia puede dirigir la atención al lugar equivocado.

También importa el volumen. Procesar diez elementos y procesar diez mil puede seguir el mismo camino de código y producir tiempos muy distintos. Documenta el tamaño de los datos y el caso que reproduce la lentitud; una mejora probada con un catálogo diminuto no demuestra que funcione en producción.

Trabajo innecesario antes de mostrar la página

En algunos proyectos, la petición carga módulos, archivos, traducciones o servicios que esa pantalla no necesita. El autoload y el arranque de dependencias pueden añadir un coste fijo a cada solicitud. En otros, se serializan estructuras grandes para acabar mostrando un fragmento pequeño.

Hay código que consulta un servicio externo antes de generar una respuesta que no depende de él, o que convierte imágenes durante la visita en lugar de utilizar recursos preparados. Otro patrón es leer repetidamente del sistema de archivos en rutas de mucho tráfico.

La solución no es eliminar llamadas por su nombre. Hay que comprobar si el resultado se utiliza, cuándo se necesita y qué garantiza su ejecución. Cargar algo más tarde puede mejorar la primera vista, pero empeorar una interacción importante si simplemente desplazamos la espera.

Plugins, módulos y código heredado: localiza el comportamiento concreto

Una extensión puede añadir una consulta, registrar un gancho que se ejecuta en todas las páginas o contactar con una API. Un código heredado puede seguir funcionando correctamente y, sin embargo, hacer trabajo redundante que nadie había medido.

El nombre del plugin no demuestra que sea culpable. Lo útil es trazar qué parte ejecuta, en qué ruta, con qué datos y cuánto tarda. Si una función solo afecta al checkout, medir la portada no servirá. Si la lentitud aparece tras una actualización, registra versiones y momento del cambio, pero conserva otras hipótesis: también pudo cambiar el catálogo, el tráfico o un servicio remoto.

Desactivar módulos al azar en producción puede romper pagos, precios o integraciones. Una prueba controlada en un entorno representativo, o una instrumentación temporal de la ruta afectada, permite confirmar la relación con menos incertidumbre.

Cómo medir dentro de la aplicación

Empieza por los límites de una operación: inicio de la petición, carga de datos, llamadas externas, preparación de la vista y fin. Un registro estructurado con una duración y un identificador de petición permite relacionar esas etapas sin guardar información sensible del usuario.

Para intervalos dentro del mismo proceso PHP puede usarse un reloj monotónico como hrtime(). La idea es medir antes y después de la operación concreta, no añadir cronómetros indiscriminadamente a cada línea. Un ejemplo sencillo sería registrar «cálculo de precio: 18 ms» y «respuesta del proveedor de stock: 1.620 ms» para una petición identificada. La documentación de PHP describe esa función.

Cuando intervienen varios servicios, una traza permite seguir el recorrido de la misma solicitud y ver sus operaciones relacionadas; un sistema APM puede reunir trazas, errores y duraciones por ruta. Un perfilador ayuda a localizar dónde se emplea el tiempo de CPU dentro del código. Un slowlog muestra dónde estaba una petición al superar un umbral. Son instrumentos complementarios: el slowlog no demuestra por sí mismo cuánto tiempo pasó en cada función. OpenTelemetry documenta la diferencia entre trazas, métricas, registros y perfiles.

Recoge muestras de peticiones comparables, incluidas las lentas y las rápidas, para observar qué cambia. Las herramientas de diagnóstico también pueden añadir carga: ajusta su alcance, acceso y tiempo de uso. En producción registra errores de forma privada y evita mostrar trazas técnicas al visitante, como recomienda la documentación de PHP.

Una hipótesis debe poder fallar

Ejemplo ficticio: sospechamos que preparar recomendaciones retrasa las fichas de producto. Medimos la operación y vemos que tarda 30 ms en las visitas lentas, que consumen 1,8 segundos. La hipótesis pierde fuerza. En cambio, la llamada de stock tarda entre 1,4 y 1,7 segundos en esas mismas visitas y menos de 100 ms en las rápidas. Ya sabemos qué dependencia merece una investigación más precisa.

El paso siguiente no consiste necesariamente en eliminarla. Puede que el dato sea imprescindible antes de vender; quizá existe un timeout excesivo o una respuesta que se puede reutilizar durante un intervalo seguro. La decisión depende de la función del dato y del efecto sobre el usuario.

La base de datos: cuando encontrar la información tarda demasiado

La ficha de producto entra en la aplicación sin hacer cola, pero la respuesta sigue tardando. La traza señala varias consultas al catálogo. Antes de «poner más caché» o contratar un servidor de base de datos mayor, necesitamos averiguar qué consultas se ejecutan, cuántas veces y qué están esperando.

Una página dinámica puede consultar productos, precios, stock y preferencias. La base de datos suele responder con rapidez cuando la operación y los datos están bien acotados; también puede pasar tiempo examinando filas, esperando un bloqueo o aceptando conexiones. Esas situaciones tienen soluciones distintas.

Una consulta lenta y muchas consultas pequeñas dejan señales diferentes

Supongamos una ficha ficticia que tarda 1,8 segundos en consultas. Podría deberse a una sola búsqueda de 1,6 segundos. También a 120 consultas de unos 15 milisegundos cada una. El total se parece, pero en el primer caso investigaríamos el plan de una consulta concreta; en el segundo, por qué la aplicación repite el acceso a los datos.

Registra por ruta la duración total de consultas, su número, las más costosas y las más repetidas. Comprueba si el tiempo observado por PHP incluye espera para conseguir conexión o bloqueos; una cifra llamada «tiempo de base de datos» puede agrupar varias cosas según la herramienta.

El registro de consultas lentas ayuda a localizar operaciones individuales que superan un umbral, pero no cuenta por sí solo la historia completa: cien consultas breves pueden quedar por debajo de él. En MySQL, además, lo que se registra depende de su configuración. Consulta la documentación del slow query log antes de interpretar su ausencia como prueba de que todo va rápido.

Índices: encontrar una fila sin revisar una tabla entera

Un índice permite localizar o recorrer datos de acuerdo con determinados campos. Piensa en un catálogo de 300.000 productos: si una consulta filtra por referencia, un índice adecuado puede evitar examinar gran parte de la tabla. La mejora dependerá de los datos, del filtro, de la ordenación y de la consulta completa.

No toda lectura de muchas filas es un fallo. Un informe puede necesitar recorrerlas; un buscador puede pedir una combinación de filtros poco selectiva. Y tener índices en las columnas utilizadas tampoco garantiza que el motor elija el plan esperado. Añadir índices sin medir ocupa espacio y encarece algunas escrituras.

Para una consulta identificada, EXPLAIN muestra el plan que el motor prevé utilizar: tablas, orden de acceso, índices y estimaciones. Es un punto de partida para contrastar hipótesis. En MySQL, EXPLAIN ANALYZE ejecuta la consulta y muestra tiempos reales; por eso se debe valorar su coste y utilizar en condiciones controladas si la consulta puede ser pesada. La referencia oficial de EXPLAIN explica ambas modalidades.

N+1: una ficha que consulta de nuevo por cada elemento

Imagina una categoría con 50 productos. La aplicación obtiene la lista mediante una consulta y después pregunta por el stock de cada producto con otra consulta. Ha realizado 51 accesos antes de terminar esa parte del trabajo.

En una página con cinco productos quizá pase inadvertido. Con cincuenta, la duración acumulada y el tráfico entre aplicación y base de datos pueden hacerse visibles. La solución posible puede consistir en solicitar el stock del conjunto de productos de una vez; hay que comprobar la corrección del resultado y su comportamiento con un volumen realista.

El patrón N+1 no se limita a relaciones entre tablas. Puede aparecer al cargar precios, imágenes, permisos o traducciones dentro de un bucle. La pista es la repetición de consultas con la misma forma y distintos identificadores.

JOIN, ordenaciones y búsquedas: mira los datos que realmente se procesan

Un JOIN permite combinar información de varias tablas. No es malo por definición: puede evitar trabajo repetido de la aplicación. Lo problemático aparece cuando la combinación genera demasiadas filas intermedias, usa condiciones poco selectivas o requiere ordenar un volumen muy superior al que acabará mostrándose.

Un buscador que ofrece filtros por marca, precio y disponibilidad puede necesitar un plan distinto al de una ficha que se consulta por identificador. Si una tabla ha crecido mucho, un plan que funcionaba con pocos productos puede dejar de ser adecuado. La cantidad de filas examinadas frente a las devueltas aporta una pista, aunque no debe leerse aislada del coste de cada operación.

SELECT * puede transferir columnas que la página no necesita. En tablas con campos grandes, reducir lo solicitado puede ayudar, pero cambiarlo por una lista de columnas no sustituye el análisis del plan ni corrige una consulta que examina demasiadas filas. Del mismo modo, una búsqueda de texto con patrones que impiden aprovechar un índice ordinario requiere estudiar sus necesidades; para catálogos grandes puede tener sentido un sistema de búsqueda especializado.

Bloqueos: una consulta puede esperar sin estar procesando datos

Durante una compra, una operación puede necesitar modificar stock o pedido. Si otra transacción mantiene un bloqueo incompatible, la nueva tendrá que esperar. Desde PHP se percibe una consulta lenta, pero el problema puede estar en la transacción que conserva el bloqueo.

Busca la relación entre quién espera, qué recurso espera y qué transacción lo retiene. En MySQL con InnoDB, las vistas de bloqueos y esperas ayudan a reconstruirla; los datos cambian rápidamente y una captura posterior puede no mostrar el conflicto. La documentación de InnoDB describe estas relaciones.

Acortar una transacción o evitar trabajo ajeno a la base de datos mientras permanece abierta puede resolver más que añadir memoria. Antes de interrumpir una transacción hay que entender qué operación representa y sus efectos sobre pedidos o datos de negocio.

Conexiones: llegar al límite no revela por qué se ocupan

La aplicación puede esperar una conexión libre para consultar datos. También puede llegar al máximo permitido por el servidor y recibir un error. Comprueba el número de conexiones activas, las que están esperando y los límites efectivos del servidor, del usuario y de la aplicación. MySQL documenta max_connections como límite de conexiones simultáneas, pero puede haber otros límites en el recorrido.

Aumentar ese máximo puede permitir entrar a más solicitudes y, a la vez, incrementar la presión sobre CPU, memoria o bloqueos. Una conexión ocupada durante mucho tiempo podría ser consecuencia de una consulta costosa o de una transacción abierta, no de un límite demasiado pequeño.

Configuración y caché de datos: ajustes después de entender el patrón

La memoria disponible para datos e índices, el almacenamiento y la configuración del motor influyen en el rendimiento. Pero no existe un ajuste universal para «acelerar MySQL». Primero identifica la operación afectada y determina si examina demasiados datos, repite consultas, espera disco o está bloqueada.

Una caché de aplicación puede evitar lecturas repetidas cuando el dato admite reutilización. Su validez es parte de la solución: un precio o un stock desactualizados pueden ser más perjudiciales que la espera que intentamos eliminar. Antes de introducirla, define cuándo cambia el dato y cómo se invalida.

En este ejemplo los intervalos se han medido sin solapamiento y suman 1,9 segundos. Investigar primero la consulta de variantes promete más que afinar una de las consultas pequeñas. Después habría que verificar si corregir el patrón repetido mejora el tiempo total de la ficha; la prioridad podría cambiar en páginas con muchos más productos.

Con los accesos a datos localizados, podremos examinar otro origen frecuente de trabajo añadido: los plugins, módulos y temas de los CMS.

WordPress y PrestaShop lentos: cuándo intervienen plugins, módulos y temas

Una ficha de producto tarda en responder y la base de datos registra muchas consultas. El código que las provoca podría estar en el CMS, en un módulo de precios, en la plantilla o en una personalización. La lista de extensiones instaladas indica posibilidades; la ruta de la petición y sus mediciones indican qué se ejecutó realmente.

WordPress y PrestaShop permiten ampliar funciones sin modificar cada parte del núcleo. Ese diseño es útil para el negocio, pero una extensión puede participar en más páginas de las previstas. En esta sección identificaremos ese trabajo añadido. Cada plataforma merece después una guía propia de diagnóstico.

Una extensión instalada no equivale a una extensión ejecutándose

Los CMS ofrecen puntos donde el código ajeno puede intervenir. WordPress utiliza acciones y filtros; PrestaShop utiliza hooks para ejecutar lógica o incorporar contenido. Un plugin o módulo puede registrar funciones en esos puntos y activarse cuando una petición pasa por ellos. Las guías de WordPress y la documentación de PrestaShop explican esos mecanismos.

Por tanto, contar «treinta plugins» no cuantifica la lentitud. Un único módulo puede realizar una petición remota en cada ficha; varios más pueden limitarse a páginas de administración que el cliente nunca visita. También puede ocurrir que un tema ejecute una función costosa sin que aparezca en la lista de plugins.

Pregunta útil: para la página que tarda, ¿qué funciones del tema y qué extensiones se ejecutan, cuántas veces y durante cuánto tiempo? Registra además la versión del CMS, el tema y las extensiones implicadas: hace posible comparar una incidencia tras un cambio.

Qué trabajo pueden añadir sin resultar visibles

No mezcles estos síntomas. Si el HTML ya llega pronto y el retraso aparece al ejecutar un script, no obtendrás la explicación buscando solo consultas SQL. Si la espera ocurre antes del primer byte, descargar menos CSS puede mejorar la presentación, pero no esa espera inicial.

WordPress lento: observa la página y el tipo de visitante

En WordPress, un plugin puede intervenir en consultas, construcción del contenido, menús, formularios o llamadas HTTP. El tema y sus funciones también participan. Una portada cacheada puede ocultar el coste de generar la página, mientras que un usuario identificado recibe una respuesta preparada de otra forma. Si la corrección exige intervenir en el tema o en un plugin, puede requerir desarrollo WordPress a medida.

Ejemplo ficticio: la portada pública parece rápida; abrir el panel de un editor tarda cuatro segundos. Revisar solo PageSpeed de la portada no reproduce la operación. Instrumenta esa ruta y busca el tiempo invertido por las funciones, consultas y peticiones externas que ejecuta. Si la demora aparece tras abrir una entrada concreta, compara también una entrada sencilla con otra que tenga muchos bloques o metadatos.

Las tareas programadas merecen una observación aparte. WordPress puede activar eventos pendientes durante solicitudes normales cuando utiliza el mecanismo de WP-Cron; el efecto depende de cómo esté configurado el sitio y de qué trabajo haya pendiente. Correlaciona los picos con los eventos y la ruta, sin asumir que toda lentitud intermitente procede del cron.

PrestaShop lento: separa escaparate, compra y administración

En PrestaShop, un módulo puede ejecutar lógica en hooks de presentación o de acciones del sistema. El tema puede llamar a hooks para montar zonas de una página. Eso permite añadir fichas, mensajes, recomendaciones o integraciones, pero también puede hacer trabajo repetido. Las guías de hooks del tema muestran cómo se incorporan módulos al escaparate. Corregir un módulo o una regla comercial sin alterar su función puede requerir desarrollo PrestaShop a medida.

Ejemplo ficticio: una categoría con pocos productos abre bien; otra con muchos tarda. Un módulo de insignias consulta una condición comercial por cada producto. La pista es una consulta repetida en proporción al tamaño de la lista. Otra investigación distinta sería un checkout que espera la respuesta de un proveedor de pagos o envíos.

Separa asimismo el front office, lo que ve el comprador, del back office, el área de gestión. Crear un pedido, editar combinaciones o recalcular precios puede ejecutar operaciones que no están presentes al navegar como visitante. Decir «PrestaShop va lento» sin precisar pantalla y acción deja demasiadas causas abiertas.

Temas y personalizaciones: también pueden estar en la ruta crítica

Un tema decide qué contenido se muestra y qué recursos se envían al navegador. Puede pedir datos adicionales, cargar widgets o producir un HTML muy grande. Una personalización heredada puede alterar consultas o repetir transformaciones. Que el trabajo aparezca durante la carga del tema no implica necesariamente que el diseño visual sea la causa; hay que localizar la función responsable.

Compara una página que presenta el problema con otra parecida que no lo presenta. Anota qué cambia: plantilla, bloque, cantidad de productos, sesión o módulo activado para esa ruta. El contraste reduce mejor el campo de búsqueda que una lista general de extensiones.

Cómo confirmar una sospecha sin romper el sitio

1. Reproduce una operación concreta. Guarda URL, estado de sesión, datos utilizados y tiempos de varias visitas.
2. Localiza dónde se espera. Separa preparación de HTML, consultas, llamadas externas y trabajo del navegador.
3. Relaciona la operación con una extensión o función. Busca en una traza o perfil qué código se ejecuta y cuánto aporta al total; una coincidencia de nombres no basta.
4. Prueba un cambio aislado en un entorno representativo. Si desactivas o sustituyes una extensión para comprobar la hipótesis, verifica también precios, pagos, contenidos e integraciones que dependen de ella.
5. Repite la medición. Compara la misma ruta y acción antes y después. Una mejora en la portada no demuestra que el checkout haya mejorado.

En producción, desactivar extensiones de compra o seguridad al azar puede provocar una avería mayor que la lentitud. Para investigar un efecto específico, a menudo basta con instrumentar temporalmente su función, reproducir el caso en un entorno de pruebas o deshabilitarla allí. Lo importante es que la comparación conserve los datos y el comportamiento relevantes.

Una extensión puede trabajar correctamente y aun así no necesitar repetir siempre el mismo cálculo. En el siguiente bloque veremos cuándo una caché evita ese trabajo y cuándo simplemente oculta una aplicación lenta.

La caché ayuda cuando evita el trabajo que causa la espera

La portada pasa de tardar tres segundos a abrir casi al instante después de activar una caché de página. Parece resuelto. Sin embargo, una persona inicia sesión, abre el carrito y vuelve a esperar los mismos tres segundos. Las dos experiencias son compatibles: una respuesta reutilizada puede ser rápida mientras el camino que genera respuestas nuevas sigue siendo lento.

La caché guarda un resultado para volver a utilizarlo. Su utilidad depende de tres preguntas: qué se guarda, para quién es válido y cuándo deja de serlo. Si no sabemos responderlas, una mejora de velocidad puede ocultar el cuello de botella o entregar datos incorrectos.

No hay una sola caché: cada capa evita un trabajo distinto

Una caché de navegador puede acelerar la segunda visita sin cambiar el tiempo que tarda el servidor en preparar el HTML. Una caché de página puede evitar PHP y la base de datos para una URL pública. Una caché de objetos puede ahorrar una consulta, pero no sustituir la respuesta completa. En WordPress, la caché de objetos existe por petición y necesita una implementación persistente para conservar esos datos entre peticiones.

Redis puede actuar como almacén para ciertos datos reutilizables. Instalar Redis no significa que la web esté aprovechándolo: hay que comprobar qué aplicación escribe y lee, cuántas peticiones aciertan y cuánto cuesta mantener los datos actualizados. La lógica de cada caché la determina el sistema que la utiliza.

Hit y miss: la prueba que explica dos tiempos muy diferentes

Si existe una copia válida y se utiliza, tenemos un hit. Si falta, ha caducado o no corresponde a esa petición, hay un miss y alguien debe generar el resultado. Compara ambas situaciones sobre la misma ruta y con condiciones conocidas.

Las cifras no representan una web real. Lo importante es que los tres tiempos responden a rutas de ejecución diferentes. Una puntuación obtenida sobre una portada servida desde caché no explica el rendimiento del checkout ni el de la administración.

Para comprobarlo, inspecciona las cabeceras de respuesta y, si existe, el estado de caché que informa el proveedor. Su nombre puede variar. Contrasta con los registros del origen: una cabecera HIT solo informa de la capa que la emitió, y una respuesta puede haber atravesado más de una caché. Conserva URL, cookies relevantes, momento y repetición de la prueba.

Cuándo una página no puede compartir la misma copia

Un catálogo público puede mostrar el mismo contenido a muchas personas durante un intervalo. Un carrito, la cuenta de un cliente o una página con precios específicos pueden depender de la sesión, del grupo comercial o de datos que cambian entre visitantes. Reutilizar una respuesta sin distinguir esas condiciones puede mostrar información ajena.

Las reglas HTTP, como Cache-Control, ayudan a definir dónde puede guardarse una respuesta. Para contenido personalizado hay que evitar que una caché compartida entregue la copia a otra persona; private y no-store responden a necesidades distintas. La referencia de Cache-Control explica sus efectos. Las cookies por sí solas no garantizan que una respuesta sea privada.

Eso no significa que una operación personalizada deba ser lenta. Aunque no se guarde la página completa para todos, quizá puedan reutilizarse datos o cálculos que son válidos para esa sesión o durante un tiempo acotado. La clave es definir la identidad y vigencia del resultado.

Invalidación: que un dato sea rápido no basta si ya cambió

Imagina que la ficha muestra un producto agotado como disponible porque conserva un stock anterior. Una caché útil necesita una política para renovarse o invalidarse cuando cambia el dato original. La duración admisible no es igual para una imagen, una descripción editorial, un precio o una disponibilidad.

Para cada resultado cacheado anota qué hecho lo invalida, quién ejecuta la invalidación y cuál es el retraso máximo aceptable. Si el precio cambia en el ERP, importa cuándo llega ese cambio a la tienda y cuándo deja de servirse la copia anterior. Una política de tiempo de vida, por sí sola, puede permitir un periodo de datos obsoletos que el negocio no acepta.

También existe el problema contrario: vaciar todas las cachés a la vez después de cada cambio. Eso obliga al origen a reconstruir muchas páginas y puede producir un pico de lentitud. Una invalidación más precisa reduce ese trabajo, pero requiere conocer las dependencias entre los datos y las páginas.

El primer visitante también importa

Si una ficha tarda varios segundos cuando no existe copia, ese coste reaparecerá al caducar, tras una publicación o cuando llegue una combinación de parámetros que no se había pedido antes. A veces varias peticiones simultáneas intentan regenerar lo mismo; el efecto se conoce como cache stampede.

No hace falta introducir otra capa de caché para cada pico. Primero confirma que el patrón coincide con misses, mide el coste de generación y comprueba si hay coordinación para evitar trabajo duplicado. Si el origen genera la página de forma eficiente, los misses dejan de ser una incidencia grave.

Una comprobación que no confunda la caché con la corrección

1. Define la operación que duele: ficha, búsqueda, carrito, checkout o backoffice.
2. Identifica la capa que responde: navegador, CDN, caché de página o aplicación.
3. Compara hit y miss cuando ambos sean válidos: misma URL, sesión y condiciones de datos.
4. Comprueba el origen: mide el trabajo que queda cuando no puede utilizarse la copia.
5. Verifica los datos: precio, stock y contenido después de cambios y con diferentes usuarios.

Evita interpretar «caché desactivada» como una única condición: podrías desactivar la del navegador mientras siguen activas la de CDN, la de página y la de objetos. Registra cuál has modificado en cada prueba. Tampoco conviene purgar la caché de producción repetidamente para obtener un número; altera la experiencia de otros visitantes.

Si el HTML llega pronto y la sensación de lentitud permanece, la siguiente parada será el navegador: imágenes, CSS, JavaScript y el trabajo necesario para mostrar e interactuar con la página.

El servidor responde rápido, pero la página sigue siendo lenta

El documento HTML empieza a llegar en unas décimas de segundo. Sin embargo, la foto principal aparece mucho más tarde y el menú tarda en reaccionar. El origen ya hizo su parte; el navegador todavía tiene que descubrir recursos, descargarlos, construir la página y atender las interacciones.

En este caso, cambiar de hosting puede reducir poco la espera percibida. Necesitamos identificar qué elemento tarda en verse o en poder utilizarse, y qué trabajo lo precede. No es lo mismo una imagen que se solicita tarde que una imagen que se descarga despacio; tampoco es lo mismo un botón que no acusa la pulsación que una operación remota que tarda en terminar.

JavaScript: descarga, ejecución y trabajo que bloquea

Un archivo JavaScript pequeño puede ejecutar una tarea costosa; uno grande puede descargarse rápido desde caché y seguir tardando en analizarse o ejecutarse en un móvil modesto. Por eso la cantidad de kilobytes no explica por sí sola la experiencia.

Busca en el panel Performance de DevTools si la actividad del hilo principal coincide con el retraso. Cuando una tarea larga mantiene ocupado al navegador, una pulsación puede quedarse esperando turno. Si el código del propio botón tarda en ejecutarse, el bloqueo ocurre durante la interacción. Si después se actualizan demasiados elementos, la demora puede aparecer al presentar el resultado. La referencia del panel Performance ayuda a relacionar tareas, renderizado e interacciones.

Una aplicación que construye su interfaz en el navegador puede mostrar primero un contenedor y tardar después en poblarlo. Otras envían HTML ya preparado y necesitan conectar los controles visibles con su comportamiento, proceso llamado hidratación. Antes de hablar de «JavaScript excesivo», observa cuál de esas etapas afecta a la pantalla concreta.

CSS y fuentes: el contenido puede estar descargado y seguir sin aparecer

El navegador necesita información de estilos para dibujar la página correctamente. Una hoja CSS necesaria que llega tarde puede retrasar la primera presentación. La investigación consiste en comprobar qué archivo se solicita, cuándo llega y si sus reglas son necesarias para el contenido inicial.

Las fuentes también influyen. Un texto puede esperar a una fuente web o aparecer primero con otra y cambiar después, según cómo se haya configurado. La guía de carga de fuentes de web.dev explica cómo se descubren y renderizan. No siempre conviene precargar todas: adelantar recursos que no hacen falta compite con los que sí importan.

Ejemplo ficticio: el HTML de una página de servicios llega a los 300 ms, pero el título permanece invisible hasta los 2,3 s porque espera una fuente. Comprimir una imagen situada al final de la página apenas cambiaría esa primera impresión.

Imágenes: distingue cuándo se piden, cuánto pesan y cuándo se dibujan

La foto principal de un producto puede estar optimizada y aun así descubrirse tarde si la aplicación la inserta después de ejecutar código. También puede solicitarse pronto pero descargar demasiados bytes para el tamaño al que se muestra. O puede terminar de descargarse y tardar en dibujarse porque el navegador está ocupado.

Mide por separado inicio de la petición, tiempo de transferencia y aparición en pantalla. El elemento visual principal suele reflejarse en LCP, una métrica de la presentación del contenido más grande visible al cargar. Su desglose ayuda a evitar un consejo genérico: si casi toda la demora ocurre antes de pedir la imagen, reducir su tamaño aborda solo una parte. La documentación de LCP describe sus fases.

La carga diferida es útil para imágenes alejadas del primer vistazo, pero aplicarla sin criterio a la imagen principal puede retrasar su descubrimiento. Y servir una imagen enorme para una tarjeta pequeña desperdicia transferencia, aunque dispongas de una CDN.

Un DOM grande y animaciones costosas también consumen tiempo

Una página con miles de nodos obliga al navegador a gestionar una estructura mayor. Si un filtro reemplaza toda la lista de productos tras cada tecla, el coste de actualizar la interfaz puede dominar aunque los datos lleguen deprisa.

Las animaciones no son culpables por existir. El problema aparece cuando el efecto exige recalcular continuamente la disposición o dibujar zonas grandes mientras el dispositivo ya tiene otras tareas. Registra la acción: ¿el movimiento se entrecorta?, ¿se retrasa la respuesta al pulsar?, ¿ocurre solo en móviles? Un cambio de propiedad o de alcance puede ayudar, pero hay que comprobar que conserve la experiencia y respete la preferencia de reducir movimiento.

Una línea temporal que impide culpar al componente equivocado

La imagen tardó 0,4 segundos en descargarse, pero se vio 2,8 segundos después de que comenzara a llegar el HTML. La primera investigación debería centrarse en el descubrimiento tardío y en el trabajo anterior a su presentación. Comprimirla puede ser útil, pero difícilmente eliminará esos 2,8 segundos.

La página se ve; ahora comprueba si responde

Una ficha puede mostrar precio y fotografía, pero bloquearse al elegir una variante. INP evalúa cuánto tarda la página en mostrar la siguiente respuesta visual después de determinadas interacciones. El retraso puede estar antes de que el controlador empiece, durante su ejecución o antes de pintar el resultado. La guía de INP de web.dev detalla esas etapas.

Ese dato no mide el tiempo completo de una operación remota. Si al pulsar «Añadir al carrito» aparece enseguida «Añadiendo…» y el carrito tarda dos segundos en actualizarse, la interfaz ha reconocido la acción; hay que medir también la solicitud posterior. Si ni siquiera aparece la señal inicial, investiga el trabajo del navegador alrededor de la pulsación.

El navegador no trabaja aislado: chats, mapas, vídeos, analítica y otros proveedores pueden añadir recursos o esperas. En el siguiente bloque examinaremos esas dependencias externas.

Cuando tu web espera a un servicio externo

La aplicación responde en medio segundo, pero el visitante sigue viendo un hueco donde debería estar el mapa. En otra pantalla, el checkout permanece abierto mientras calcula el envío. Ambas demoras pueden depender de terceros, aunque ocurren en lugares distintos: un recurso que carga el navegador y una API a la que llama tu servidor.

Chats, vídeos, mapas, fuentes, píxeles, captchas, reseñas, pasarelas de pago y sistemas de gestión pueden añadir valor a la web. Para investigar su efecto en la velocidad, necesitamos saber cuándo se solicitan, si la función depende de su respuesta y qué sucede cuando tardan o fallan.

Un recurso externo puede retrasar la página de varias formas

Un chat integrado puede descargar JavaScript, abrir más conexiones y ejecutar código en el dispositivo del visitante. Un vídeo embebido puede traer un reproductor completo. Un mapa puede necesitar scripts, estilos e imágenes de otro proveedor. Incluso un pequeño píxel puede originar nuevas peticiones.

El coste depende de cuándo carga el recurso y qué trabajo provoca. Un script síncrono situado en un punto crítico puede retrasar el procesamiento del documento. Otro que se descarga en segundo plano puede ocupar el hilo principal al ejecutarse o competir por la red con la imagen importante de la página. La guía de web.dev sobre JavaScript de terceros describe estas formas de interferencia.

Que una petición externa sea la última de la lista no demuestra que el visitante haya tenido que esperarla. Puede tratarse de medición enviada después de mostrar el contenido. Investiga si afecta al elemento o a la acción que has señalado, no solo si aparece en la cascada.

Cómo descubrir quién cargó un script, un mapa o una fuente

Abre Network en las herramientas del navegador y reproduce la página lenta. El filtro de solicitudes de terceros permite localizar dominios ajenos al origen; la columna Initiator muestra qué desencadenó cada petición. La referencia de Chrome DevTools explica ambos controles.

Una petición puede aparecer por un módulo, por el tema o por un gestor de etiquetas. En este último caso, el archivo inicial del gestor puede ser pequeño, pero activar varias herramientas después. Sigue la cadena de iniciadores y anota las funciones que realmente se cargan. Las herramientas de medición, el chat y las pruebas de variantes pueden cambiar sin que cambie el código del sitio, por lo que conviene guardar la fecha y el entorno de la prueba.

Después registra una interacción en Performance. La cascada de red muestra transferencias; el registro de rendimiento revela si el código externo ocupa el navegador cuando debería mostrar contenido o atender una pulsación.

El servidor también puede quedar esperando fuera

Una aplicación puede consultar un ERP para conocer stock, pedir una tarifa de envío, validar una dirección o recuperar reseñas antes de generar el HTML. Desde fuera se verá una respuesta lenta del servidor; la CPU local puede seguir casi desocupada mientras aguarda la respuesta. La documentación de WordPress sobre peticiones HTTP señala el coste de esperar a servicios externos.

Separa en la traza inicio de la llamada, tiempo hasta respuesta, reintentos y procesamiento posterior. Si una llamada de 200 ms se ejecuta diez veces en serie, el problema puede ser la repetición. Si una sola llamada tarda dos segundos solo algunas veces, interesa estudiar la variación y los límites de espera acordados con el proveedor.

La solución depende de la función del dato. Una reseña agregada quizá pueda actualizarse periódicamente; el resultado de un pago no puede sustituirse por una copia antigua. Tampoco conviene posponer un dato indispensable para vender con seguridad solo para mejorar una cifra de carga.

Un mismo síntoma puede requerir decisiones opuestas

Los dos últimos casos exigen especial cuidado: una confirmación tardía no se arregla repitiendo indiscriminadamente la operación. El visitante necesita una respuesta clara y el sistema debe mantener la integridad de pedidos y pagos.

Prueba el efecto sin eliminar una función necesaria

Si sospechas de un recurso de navegador, puedes bloquearlo temporalmente en DevTools o en una prueba controlada y comparar la misma página. Si mejora, has encontrado una relación que merece estudiar. Una prueba que bloquea el recurso no demuestra que sea seguro retirarlo: comprueba si desaparece un mapa útil, deja de funcionar el captcha o se rompe la medición necesaria para tomar decisiones.

Para llamadas desde el servidor, instrumenta la operación y utiliza un entorno de pruebas con respuestas lentas o fallos simulados. No provoques indisponibilidad de una pasarela en producción para obtener una captura. Cuando el servicio falla, la aplicación necesita un comportamiento definido: informar, reintentar de forma controlada, mostrar datos válidos o impedir la acción, según el caso.

También es fácil confundir un problema externo con uno local: un script alojado en otro dominio puede descargar rápido y tardar mucho en ejecutarse en el móvil. La ubicación del archivo no explica por sí sola dónde se pierde el tiempo.

Reduce dependencias en el momento crítico

Una vez identificado el coste, decide qué necesita suceder antes de mostrar o completar la operación. Un vídeo situado al final de un artículo puede esperar a que se acerque a la pantalla. Un chat puede iniciarse después del contenido principal si el servicio y la experiencia lo permiten. Una tarifa de envío necesaria para cerrar una compra debe estar disponible o producir un estado de error comprensible.

Revisa las etiquetas duplicadas y las integraciones que siguen activas aunque ya no se utilicen. Configura tiempos máximos y reintentos de acuerdo con el impacto de cada operación. Si se reutilizan respuestas, define su vigencia, como vimos en la sección de caché. Después mide la misma acción para comprobar el efecto real.

El siguiente paso será comparar rutas: una portada rápida y un checkout lento pueden ofrecer una pista más precisa que una media de velocidad de toda la web.

Home rápida, producto lento, checkout lento: qué nos está diciendo

«La web va lenta» parece describir el sitio entero. Pero la portada abre en medio segundo, las categorías funcionan bien y solo una ficha tarda cuatro segundos. Esa diferencia es valiosa: las tres páginas pueden compartir servidor, dominio y CMS, mientras cambian los datos y el trabajo necesarios para responder.

Comparar rutas no da el diagnóstico final, pero reduce el espacio de búsqueda. Nos ayuda a decidir si conviene investigar una operación específica, un tipo de contenido, una condición de sesión o una dependencia que interviene solo en esa pantalla.

Elige una página rápida que se parezca a la lenta

La primera comparación no debería ser siempre portada frente a checkout: además de la ruta, cambian sesión, datos, caché y función. Una referencia más útil para una ficha lenta puede ser otra ficha que funcione bien, abierta desde el mismo móvil, con la misma sesión y en un intervalo próximo.

Si una ficha rápida y otra lenta comparten plantilla, la diferencia puede estar en el número de variantes, reglas de precio, imágenes o módulos condicionados por esos datos. Si todas las fichas son lentas y la portada no, investigaremos el trabajo común a las fichas. Son hipótesis para medir, no explicaciones confirmadas.

Qué pista aporta cada tipo de página

Una tabla como esta orienta el primer vistazo. No convierte «checkout lento» en «pasarela lenta»: hay que comprobar el paso y la dependencia que introducen la espera.

Ejemplo: una ficha concreta tarda cuatro segundos

Escenario ficticio: dos fichas se consultan con la misma sesión y conexión. La primera tiene una variante; la segunda, 180 combinaciones. La primera responde en 0,6 segundos y la segunda en 4,1. Su HTML empieza a llegar tarde en la segunda, mientras las imágenes tardan una cantidad parecida.

La hipótesis inicial se desplaza hacia la preparación de los datos del producto. Una traza muestra que un módulo vuelve a consultar una regla para cada combinación y acumula 2,8 segundos. Ya tenemos una explicación comprobable: no basta con decir que «las fichas de PrestaShop son lentas», ni ayudaría empezar comprimiendo fotografías que se descargan después.

Si, por el contrario, ambas fichas recibieran HTML igual de rápido y solo la segunda mostrara tarde su fotografía, investigaríamos su descubrimiento, tamaño y presentación en el navegador. El contraste entre rutas se combina con la etapa donde se pierde el tiempo, como vimos en las secciones anteriores.

Ejemplo: la portada es rápida porque usa otro camino

Una portada pública puede servirse desde caché. El carrito de una persona identificada necesita datos particulares y no puede reutilizar esa misma copia completa. Comparar sus tiempos sin anotar el estado de caché puede hacer parecer que el carrito tiene una avería cuando lo que hemos medido son dos caminos de ejecución distintos.

La diferencia sigue importando al visitante. El objetivo es buscar una comparación justa: una ficha pública con caché y sin copia válida, o dos operaciones de carrito equivalentes. Para saber si el HTML y sus recursos se solicitaron de nuevo, consulta la información de Network. Las mediciones de navegación y recursos observan aspectos distintos de la carga, como explica web.dev.

Cuando la lentitud empieza después de pulsar un control

Buscar, aplicar un filtro o actualizar el carrito puede no cargar una página nueva. Si solo medimos el tiempo de navegación inicial, esa operación desaparece del informe aunque sea lo que más molesta.

Activa el registro de Network, reproduce una sola acción y observa qué solicitud comienza. Preserve log permite conservar las peticiones al navegar entre pantallas, según la guía de Chrome DevTools. Relaciona el comienzo y el final de la solicitud con la reacción visible: quizá la red termina pronto y el navegador tarda en actualizar los resultados, o quizá la aplicación aún no ha respondido.

Con un checkout evita provocar pagos o pedidos duplicados para repetir la prueba. Un entorno de pruebas, pedidos de ensayo o registros existentes permiten investigar el flujo con más control.

Una comparación útil mantiene pequeñas las diferencias

1. Escribe el síntoma: «buscar este término tarda» o «abrir este producto tarda».
2. Elige una referencia cercana: otra búsqueda o producto que responda bien.
3. Mantén las condiciones: dispositivo, red, sesión y ventana temporal. Anota cualquier diferencia de caché.
4. Mide la misma etapa: respuesta inicial, aparición del contenido o duración de la interacción.
5. Formula una hipótesis comprobable: «el coste crece con las variantes» o «solo tarda cuando se consulta el proveedor de envíos».

Si cambian a la vez producto, red, usuario, dispositivo y hora, el contraste pierde fuerza. Tampoco hay que sacar una conclusión de una sola prueba: repite las operaciones equivalentes para comprobar que la diferencia se mantiene.

Si esa misma ruta unas veces funciona bien y otras tarda mucho, la comparación entre páginas no basta. Entonces importará el momento en que se produjo cada visita, asunto del siguiente bloque.

La lentitud intermitente es una pista: busca qué coincide en el tiempo

A las diez, una ficha abre con normalidad. A las diez y siete minutos, la misma ficha tarda varios segundos. Cuando alguien del equipo intenta verlo media hora después, ya funciona. La incidencia no ha dejado de existir por ser difícil de reproducir: su horario y su variación forman parte de la evidencia.

La investigación cambia de pregunta. Ya no basta con saber qué ruta tarda; necesitamos comparar una petición lenta con otra rápida de la misma operación y averiguar qué sucedía en el sistema durante esos minutos.

Guarda una muestra que se pueda relacionar con los registros

Para cada episodio anota hora y zona horaria, URL, acción, duración aproximada, dispositivo, red y estado de sesión. Si la aplicación dispone de un identificador de petición, consérvalo. Así se puede seguir el mismo intento entre servidor web, aplicación, base de datos y llamadas externas.

La hora importa especialmente: un navegador puede mostrar hora local mientras los registros del servidor están en UTC. Comparar 10:17 con 10:17 en dos zonas diferentes crea una correlación falsa. Comprueba también si los relojes están sincronizados; una desviación pequeña puede desordenar eventos de un flujo breve.

La descripción «ayer iba mal» sirve para comunicar que existe una incidencia. «El 24 de septiembre, a las 10:17 hora peninsular, añadir este producto al carrito tardó unos seis segundos; a las 10:25 tardó menos de uno» ofrece una ventana que se puede investigar.

Superpone respuesta, tráfico y trabajo del sistema

Una gráfica aislada puede engañar. Pon en la misma línea temporal el tiempo de respuesta de la ruta, las solicitudes que llegan, los errores y el uso o la presión de CPU, memoria y disco. Añade los registros de trabajos programados, copias de seguridad e integraciones que se ejecuten en ese periodo.

Este ejemplo es ficticio y solo muestra una correlación. Para atribuir la causa habría que repetir la observación, comprobar que la copia utiliza el almacenamiento relevante y, en una ventana controlada, medir qué ocurre al cambiar su horario o limitar su consumo sin perder cobertura.

Las medias de cinco minutos pueden ocultar pausas de pocos segundos. Si el problema dura treinta segundos, revisa muestras con suficiente resolución para verlo. La información de presión de recursos del kernel Linux, cuando está disponible, ofrece ventanas de 10, 60 y 300 segundos para CPU, memoria y entrada/salida; su documentación explica qué significa que las tareas hayan tenido que esperar.

Picos de visitas y procesos que compiten por la misma capacidad

Una campaña, una noticia o una oleada de tráfico automatizado pueden llenar las plazas disponibles para atender solicitudes. En ese caso interesa ver peticiones por segundo, rutas solicitadas, procesos ocupados y tiempo en cola. El número de visitas diarias no revela una ráfaga concentrada en dos minutos.

Pero más tráfico no siempre es la causa. Puede que una ruta se haga más costosa por una consulta y, como tarda más, mantenga ocupados los procesos durante más tiempo. La cola crece incluso si el número de visitantes no ha cambiado demasiado. Necesitamos relacionar demanda y duración por petición.

Importaciones, generación de informes, envío de correos y sincronizaciones con un ERP también pueden competir por CPU, disco o conexiones. Anota su comienzo y fin. Si una tarea se ejecuta a intervalos, comprueba si cada episodio lento acompaña a una ejecución y si existen ejecuciones sin lentitud.

Cron y copias de seguridad: coincidencia no significa causa

En WordPress, WP-Cron comprueba tareas pendientes al cargar páginas cuando se utiliza esa modalidad. Una tarea puede comenzar con una visita y consumir recursos en el mismo periodo; en instalaciones configuradas de otra forma el mecanismo cambia. En cualquier caso, es necesario identificar la tarea concreta y medir su efecto.

Una copia de seguridad puede leer mucho, comprimir archivos, exportar la base de datos o transferir datos. Cada fase presiona recursos diferentes. Si la web se ralentiza durante la copia, observa qué recurso presenta espera y qué solicitudes resultan afectadas. Mover la copia a otra hora puede evitar el choque con el tráfico, pero no corrige necesariamente un almacenamiento incapaz de sostener ambas cargas.

La caché que caduca puede producir picos visibles

Durante minutos, la mayoría de las visitas recibe una copia rápida. La copia caduca y varias peticiones necesitan reconstruirla casi a la vez. Puede surgir un pico breve de consultas o de procesos ocupados. Después vuelve la normalidad.

Relaciona aciertos y fallos de caché, tiempo de generación y hora de caducidad o invalidación. Si el pico aparece tras publicar contenido, también mira qué se purgó: invalidar todo el sitio por un cambio pequeño obliga a rehacer mucho trabajo.

Una respuesta rápida desde caché y una respuesta lenta sin copia no describen el mismo camino. Conserva esa diferencia en las muestras; de otro modo, el patrón intermitente parecerá aleatorio.

Servicios externos que varían y tareas del navegador

Una API de stock puede responder en 100 ms casi siempre y tardar varios segundos durante una incidencia del proveedor. Si ocurre dentro de la generación de HTML, los registros deben mostrar el inicio, fin y resultado de esa llamada. Si se trata de un script externo, una traza del navegador puede revelar cuándo su descarga o ejecución afecta a la página.

En el móvil, una tarea larga del navegador puede coincidir con la pulsación unas veces sí y otras no. Por eso compara tanto la duración de la red como el momento en que se produjo la interacción. Una espera intermitente no tiene por qué estar en el servidor.

Un método para pasar de coincidencia a explicación

1. Delimita el episodio: ruta, acción, hora, duración y condiciones de una petición lenta.
2. Consigue una referencia: misma operación rápida con datos y condiciones parecidos.
3. Localiza la espera: conexión, cola, código, base de datos, API o navegador.
4. Busca lo que cambió en ese tramo: tráfico, tarea, caché, recurso o respuesta externa.
5. Comprueba una predicción: si la hipótesis es correcta, ¿debería repetirse el retraso en la siguiente ejecución o desaparecer al cambiar una condición controlada?

Ejemplo: si sospechas de una importación, espera que los próximos episodios coincidan con sus ejecuciones y muestren presión del recurso que utiliza. Si hay importaciones rápidas y episodios lentos sin importación, la hipótesis necesita revisarse. Coincidir una vez es una pista; sostener una explicación requiere más evidencia.

Parte del tráfico que desencadena estas ráfagas puede venir de bots y rastreadores. El siguiente bloque mostrará cómo reconocerlo sin confundirlo con visitas de clientes.

Cuando los bots ocupan recursos que necesitan tus visitantes

La tienda se ralentiza a ratos, aunque las ventas no indican una oleada de compradores. En los registros aparecen miles de solicitudes a búsquedas y filtros. El servidor atiende esas peticiones igual que atiende las páginas que piden las personas: pueden ejecutar PHP, consultar productos y ocupar procesos.

No todo tráfico automatizado es un problema. Hay rastreadores de buscadores, servicios que comprueban disponibilidad, herramientas comerciales, scrapers y escáneres que buscan fallos. El diagnóstico consiste en averiguar qué solicitudes coinciden con la espera y cuánto trabajo le cuestan a la web.

Primero mide la carga; después identifica quién la genera

Consulta los registros de acceso de la misma ventana en que aumentó el tiempo de respuesta. Agrupa solicitudes por minuto, ruta, tipo de respuesta y origen aparente. Compara con la carga de CPU, los procesos ocupados, la cola de PHP y las consultas de base de datos.

Una imagen servida por una CDN no cuesta lo mismo que una búsqueda dinámica que atraviesa aplicación y base de datos. Por eso un pico de peticiones es menos informativo que un pico de trabajo en rutas concretas. Si hay proxy o CDN, comprueba en qué capa se registraron las solicitudes: el origen puede no haber visto las que el intermediario resolvió.

Un catálogo puede crear muchísimas URL sin crear más productos

Supongamos una categoría con filtros de talla, color, marca, precio y ordenación. Las combinaciones pueden producir muchas direcciones distintas. Un rastreador que siga cada variación obliga a generar páginas parecidas una y otra vez, quizá con consultas costosas y pocos aciertos de caché.

Ejemplo ficticio: en diez minutos se solicitan 5.000 combinaciones de filtros; solo 80 corresponden a categorías principales. Durante esa ventana sube el tiempo de respuesta de las fichas de producto y se ocupan los procesos PHP. La relación temporal justifica mirar las peticiones filtradas y su coste. Todavía falta confirmar qué parte de la carga provocaron y qué otro trabajo había en el servidor.

Google documenta que la navegación por filtros puede generar espacios de URL muy grandes y consumir recursos al rastrearlos. La primera medida aquí es conocer qué filtros crean páginas útiles y cuáles multiplican variaciones sin aportar valor; las decisiones sobre rastreo deben respetar las páginas que sí necesitan aparecer en buscadores.

Un nombre de Googlebot en el registro no verifica su identidad

El campo User-Agent es una declaración del cliente y puede imitarse. Antes de aplicar una regla específica a Googlebot, verifica las solicitudes mediante los métodos que publica Google, como sus rangos de IP o la comprobación DNS indicada en su guía oficial.

La IP observada también requiere contexto. Si el sitio está detrás de una CDN o proxy, el registro del origen puede mostrar la IP del intermediario. Solo utiliza la dirección del cliente que aporta ese intermediario cuando esté configurado como origen de confianza. Un encabezado enviado directamente por cualquiera no basta para identificar a un visitante.

Otros rastreadores pueden tener documentación y mecanismos propios; si no puedes verificar su identidad, describe su comportamiento sin atribuirlo a una empresa concreta. «Solicitudes automatizadas a búsquedas internas» es más preciso que culpar a un buscador por el texto de una cabecera.

Escáneres, scrapers y búsquedas internas: distingue los patrones

Un escáner puede probar muchas direcciones inexistentes, rutas de administración o archivos conocidos. Un scraper puede recorrer sistemáticamente fichas y descargar imágenes. Una herramienta comercial puede comprobar repetidamente precios o stock. También hay automatizaciones legítimas de tu empresa o de proveedores.

Observa frecuencia, rutas, secuencia y resultado. ¿Se piden miles de búsquedas diferentes? ¿Un solo origen genera la mayoría de las solicitudes costosas? ¿Las peticiones llegan en ráfagas sincronizadas? Evita guardar o difundir datos personales que no hagan falta para entender el patrón.

Un bot que solicita páginas ya cacheadas puede tener poco impacto en el origen. Otro que insiste en búsquedas no cacheables puede ocupar procesos con menos peticiones. De nuevo, hay que relacionar tráfico con tiempo de respuesta y recursos, no bloquear por volumen sin conocer el coste.

Qué hacer cuando las peticiones automatizadas sí explican la lentitud

1. Reduce trabajo evitable: corrige rutas de filtros que generan combinaciones sin sentido y asegúrate de que las respuestas reutilizables se sirvan sin ejecutar toda la aplicación.
2. Protege los puntos caros: considera límites de frecuencia adecuados para búsquedas y endpoints abusados, con excepciones bien justificadas.
3. Distingue actores: verifica los rastreadores legítimos antes de aplicar reglas que puedan afectar a la visibilidad o a otros servicios.
4. Mide el resultado: compara tiempos de respuesta, colas y errores de las rutas que sufren el problema.

robots.txt sirve para comunicar reglas de rastreo a bots que las respetan. Google advierte que no es un control de seguridad ni obliga a seguir sus instrucciones a scrapers o escáneres. Tampoco conviene devolver errores a Googlebot como ajuste permanente de velocidad: las respuestas de sobrecarga están previstas para emergencias breves y pueden afectar al rastreo si se prolongan, según la guía de Google.

Si un endpoint es demasiado caro incluso con tráfico razonable, limitar bots solo aliviará una parte. Vuelve a medir la operación: puede necesitar una consulta mejor diseñada, una respuesta reutilizable o una forma distinta de ofrecer la búsqueda.

Ya conocemos las capas, las rutas y los patrones temporales. En el siguiente bloque los reuniremos en un método de diagnóstico que pueda repetirse ante una web lenta.

Un método completo para diagnosticar una web lenta

Ya hemos recorrido servidor, código, base de datos, navegador y servicios externos. El reto ahora es usar ese conocimiento en el orden correcto. Una incidencia puede ofrecer muchas pistas a la vez: una imagen grande, la CPU al 70 %, varios plugins y una puntuación discreta en PageSpeed. Ninguno de esos datos decide por sí solo qué está haciendo esperar al usuario.

Este procedimiento empieza con la operación afectada y termina cuando una corrección demuestra mejorarla. Puedes aplicarlo a una ficha de producto, una búsqueda o un panel interno, adaptando las mediciones a la acción.

1. Describe una operación que alguien pueda repetir

«Mi tienda va lenta» no basta para elegir una prueba. Sí sirve: «en móvil, como visitante, la ficha de este producto tarda en mostrar el precio» o «al aplicar este filtro con la sesión iniciada, los resultados tardan cinco segundos».

Guarda URL, acción, dispositivo, red, hora, sesión, versión desplegada y estado de caché conocido. Indica qué momento afecta al usuario: inicio de la respuesta, aparición del contenido o reacción al pulsar. Si solo ocurre a veces, conserva también una petición rápida comparable.

La reproducción debe ser representativa. Una tienda con miles de productos no se diagnostica únicamente con una copia que contiene cinco. Una cuenta administrativa puede seguir un camino distinto al del comprador. Si la incidencia no se reproduce todavía, el siguiente paso es registrar sus episodios, no declarar que desapareció.

2. Establece una línea de base

Antes de tocar nada, mide varias veces la misma acción. Conserva el conjunto de resultados y señala la variación; el número más rápido de una serie no describe necesariamente lo que vive el cliente.

Incluye, según el problema, tiempo total, tiempo hasta la primera respuesta, aparición del contenido importante y duración de la interacción. Para una operación de carrito añade el tiempo de la petición que actualiza el carrito. Para una ficha registra si la respuesta llegó desde caché.

Si dispones de tráfico real, mira la distribución por ruta: una media puede mantenerse estable aunque una parte de las visitas tarde mucho. Los percentiles ayudan a ver esas esperas menos frecuentes. Google SRE explica por qué las medias pueden ocultar la latencia de las solicitudes más lentas.

3. Decide en qué tramo se pierde el tiempo

Esta tabla orienta el siguiente instrumento, no identifica una causa automáticamente. Un TTFB alto mezcla etapas; una CPU libre no descarta que PHP espere una API; una imagen que termina la última puede no retrasar la parte importante. Usa la cascada, registros, trazas y métricas de recursos para reducir la incertidumbre.

4. Escribe una hipótesis que pueda fallar

«La web necesita más potencia» es difícil de comprobar tal como está escrita. «Durante la importación, las consultas de producto esperan disco y la ficha tarda más» permite buscar un patrón y también refutarlo.

Para cada hipótesis apunta qué dato esperas encontrar si es cierta y qué dato la debilitaría. Ejemplo: si el problema es una consulta de stock repetida, el número de consultas debería crecer con el número de productos mostrados; si permanece igual y el tiempo se concentra en una sola llamada externa, hay que cambiar de explicación.

Empieza por las hipótesis que encajan mejor con la evidencia y se pueden comprobar con menor riesgo. La metodología de resolución de problemas de Google SRE también recomienda contrastar hipótesis con observaciones y cambios controlados, y advierte de las correlaciones engañosas.

5. Cambia una causa identificada, con una comparación válida

Una prueba puede consistir en medir una consulta, desactivar una función en un entorno representativo o ajustar la hora de una tarea programada. Si exige tocar producción, delimita el alcance, registra el estado previo y prepara la reversión. No cambies a la vez el hosting, la caché, la versión de PHP y los plugins: si mejora o empeora, será difícil saber qué produjo el resultado.

El objetivo de la prueba es responder una pregunta concreta. Por ejemplo: «Si evitamos esta consulta por cada variante, ¿disminuye el tiempo de las fichas con muchas combinaciones sin alterar precios ni stock?». Una mejora que rompe el cálculo de precios no valida la solución.

6. Verifica la experiencia y vigila los efectos secundarios

Repite la misma acción, con datos y condiciones comparables. Mide varias veces antes y después, y comprueba también el comportamiento funcional: carrito correcto, imágenes visibles, datos actuales y procesos internos disponibles.

Observa qué pasó con CPU, memoria, disco, colas y errores. Aumentar los procesos PHP puede reducir una cola y trasladar la presión a MySQL. Una caché puede acelerar la ficha anónima y dejar inalterado el checkout. Una corrección real mejora la operación objetivo sin introducir una espera o un fallo más grave en otro punto.

Si el resultado no coincide con la predicción, anota lo aprendido y vuelve al paso 4. No hace falta ocultar una hipótesis descartada: saber que el retraso no estaba en la imagen evita repetir esa prueba en el próximo incidente.

Un ejemplo de principio a fin

Caso ficticio: una categoría de tienda tarda entre cuatro y cinco segundos cuando contiene más de treinta productos. Otras categorías pequeñas tardan menos de uno. Las pruebas se hacen con la misma sesión y sin copia de página válida.

1. Medición: el HTML empieza a llegar tarde; imágenes y scripts no explican la mayor parte de la espera.
2. Localización: PHP ejecuta una consulta de disponibilidad por cada producto de la lista.
3. Hipótesis: el número de consultas crece con el tamaño de la categoría y concentra la demora.
4. Prueba: un entorno con datos equivalentes obtiene las disponibilidades del conjunto en una operación controlada.
5. Verificación: se comparan tiempos de categorías grandes y pequeñas, exactitud de stock y carga de la base de datos.

Hasta el último paso, «la base de datos es lenta» habría sido una conclusión demasiado amplia. Al terminar podemos describir la operación responsable, el cambio realizado y el resultado observado. Una auditoría técnica web y de rendimiento aplica este enfoque cuando hace falta examinar el conjunto y ordenar las correcciones con evidencias.

Con una causa localizada ya podemos responder una pregunta habitual: cuándo tiene sentido cambiar de hosting y cuándo trasladaría el mismo cuello de botella a otra máquina.

¿Cuándo conviene cambiar de hosting si una web va lenta?

Cambiar de servidor puede ser la decisión correcta. También puede trasladar intacto el problema y añadir el coste de una migración. La pregunta útil no es «¿qué proveedor es más rápido?», sino «¿qué recurso o límite está haciendo esperar a esta operación y puede corregirse aquí?».

La respuesta requiere unir tres observaciones: dónde se produce la espera, qué ocurre en el servidor en ese mismo momento y qué margen ofrece el plan actual. Una puntuación baja de PageSpeed, una CPU alta en una captura aislada o el nombre de un proveedor no bastan para decidir.

Señales de que la capacidad del alojamiento sí limita la web

Una señal es una CPU limitada de forma repetida durante las operaciones afectadas: el trabajo espera turno y el tiempo mejora cuando hay capacidad disponible. En algunas instancias con CPU ampliable por créditos, agotarlos puede reducir el rendimiento sostenido; conviene mirar el tipo de instancia y sus métricas, no aplicar esa explicación a cualquier servidor. AWS documenta cómo funcionan los créditos de sus instancias ampliables.

Otra es presión real de memoria: intercambio a disco, procesos terminados por falta de memoria o límites del contenedor alcanzados a la vez que aparecen errores y esperas. La cifra de «memoria libre» por sí sola puede engañar, porque el sistema utiliza RAM como caché. Hay que observar el comportamiento y los límites del entorno.

También puede haber un techo de almacenamiento. Si las solicitudes lentas coinciden con latencia de lectura o escritura, cola de disco o límites de IOPS y transferencia, aumentar CPU no arreglará ese tramo. En infraestructura como EBS intervienen las prestaciones del volumen y de la instancia que lo utiliza; AWS explica esa relación entre operaciones, transferencia y latencia.

Por último, revisa la concurrencia disponible. Una cola de PHP-FPM que crece y un máximo de procesos alcanzado pueden explicar por qué algunas peticiones esperan antes de ejecutarse; el estado de PHP-FPM expone ambas señales. Pero si esos procesos permanecen ocupados esperando una consulta o un servicio externo, contratar más procesos puede multiplicar la presión sin resolver la causa. Hay que medir qué hacen durante esa espera.

Ampliar el plan, ajustar la arquitectura o cambiar de proveedor

Si el límite está demostrado, primero determina si el alojamiento actual permite resolverlo con un cambio proporcionado: más capacidad sostenida, almacenamiento adecuado, procesos bien dimensionados o separación de tareas pesadas. Una prueba controlada con margen suficiente ayuda a estimar el beneficio y el coste. Si el proveedor permite ese ajuste y responde a la necesidad, no hace falta cambiar de proveedor solo por cambiar de máquina.

La migración cobra sentido cuando el plan no puede ofrecer el recurso necesario, la escalabilidad requerida o acceso suficiente a métricas y configuración para operar con seguridad; también cuando las incidencias se repiten y el proveedor no puede explicar ni corregir límites que afectan a la actividad. En un alojamiento compartido puede sospecharse interferencia entre vecinos, pero conviene confirmarla mediante patrones y datos del soporte antes de atribuirle cada pico.

En cambio, una consulta que recorre todo el catálogo, un plugin que llama a una API lenta, imágenes excesivas o JavaScript que bloquea el navegador viajan con la aplicación. Una máquina mayor puede ocultar temporalmente la consulta, pero no corrige su crecimiento. Si el cuello está fuera del origen, cambiar de hosting quizá ni siquiera altere el tiempo que percibe el visitante.

Los dos casos son ficticios. Ilustran por qué «web lenta» no equivale automáticamente a «hosting lento» y por qué migrar una aplicación ineficiente a un servidor más potente puede convertir un problema técnico en una factura más alta.

Si decides migrar, conserva la evidencia y una vía de vuelta

Una migración de servidores planificada empieza por registrar tiempos de las operaciones críticas, carga, errores y configuración relevante. Prepara copia verificable, prueba restauración, define cómo volver atrás y comprueba en el nuevo entorno las rutas que importan: navegación, búsquedas, formularios, compras y tareas internas. Después compara las mismas operaciones y vigila durante la carga real; un benchmark sintético no sustituye esa comprobación.

Si la web mantiene sus URL, verifica que sigan funcionando y que sus etiquetas canónicas, redirecciones y certificados sean correctos. Si el traslado afecta a DNS o correo, inclúyelos en la comprobación. El objetivo es cambiar la infraestructura sin perder funcionamiento ni visibilidad por un error evitable.

Cambia de hosting cuando hayas identificado un límite del alojamiento que afecta a tus usuarios y el entorno actual no pueda corregirlo de forma viable. Si aún no sabes dónde se pierde el tiempo, el siguiente paso es medir. Si ya conoces el cuello, la prioridad es elegir el cambio que lo elimina con menor riesgo.

No optimices todo: corrige primero lo que limita la web

Tras diagnosticar la lentitud suelen aparecer varios problemas verdaderos a la vez. Una consulta tarda demasiado, la imagen principal pesa más de lo necesario y el chat añade trabajo al navegador. Que los tres existan no significa que tengan la misma prioridad. Primero mejora la operación que hace esperar a las personas y comprueba qué causa domina esa espera.

La prioridad no sale de ordenar recomendaciones por color en una herramienta. Depende de qué rutas se usan, con qué frecuencia aparece el problema, cuánto tiempo añade, qué función dificulta y cuánto riesgo introduce la corrección. Los datos de campo y de laboratorio de PageSpeed Insights sirven para preguntas distintas: los primeros describen experiencias reales agregadas; los segundos ayudan a investigar bajo condiciones controladas. Ninguno sustituye el seguimiento de un checkout o un panel interno propio.

Ordena las mejoras con cinco preguntas

Las preguntas sirven para discutir prioridades, no para fabricar una puntuación universal. Si aún no hay evidencia suficiente, la siguiente tarea quizá sea medir mejor. Y si una operación crítica falla, su urgencia puede imponerse aunque corregirla cueste más.

Un ejemplo: la mejora que parece pequeña puede ir primero

Ejemplo ficticio. En una tienda se detectan tres problemas. El equipo registra el tiempo de cada tramo y su relación con la acción afectada; los números de la tabla ilustran una decisión, no un estándar de rendimiento.

Que la imagen quede para después no significa que sea irrelevante para siempre. Si la misma imagen fuese el elemento principal de miles de páginas móviles y retrasase su aparición, cambiaría su impacto y, por tanto, la prioridad. La prioridad pertenece al contexto medido, no al tipo de recurso.

Calcula el coste completo del cambio, incluida la reversión

Una modificación rápida de desplegar puede salir cara si invalida la caché del carrito, devuelve precios antiguos o rompe una integración. Antes de decidir, anota la conducta que debe permanecer correcta y cómo la comprobarás. En cambios delicados, prepara una prueba representativa, una salida gradual si es posible y una forma de volver al estado anterior.

Da preferencia a mejoras que eliminan una causa demostrada y pueden verificarse con claridad. Ese es también el criterio de una optimización de velocidad y rendimiento web: medir, intervenir en el cuello de botella y contrastar el resultado. Por ejemplo, reducir consultas repetidas en una categoría puede ser más valioso que añadir una nueva capa de caché que acelera solo a visitantes anónimos. Si la caché es la solución apropiada, define antes qué contenido puede almacenarse y durante cuánto tiempo.

Conviene separar las correcciones de incidente de las mejoras de mantenimiento. Si el checkout falla bajo carga, atiéndelo primero. Después puedes programar mejoras como comprimir recursos secundarios o limpiar código. Mezclarlas en una única lista sin contexto hace que lo fácil desplace a lo importante.

Comprueba que la prioridad elegida produjo la mejora esperada

Para cada tarea deja escrita una predicción concreta: «al eliminar estas consultas repetidas, la ficha con muchas variantes empezará a responder antes sin cambiar precio ni disponibilidad». Conserva la medición previa y repite la misma operación después, varias veces y bajo condiciones comparables. Mira también errores, uso de recursos y rutas relacionadas.

Si el cambio apenas mueve el tiempo total, puede que la causa fuese menor de lo previsto o que otro cuello de botella haya quedado expuesto. Actualiza la lista con lo aprendido. La metodología de diagnóstico de Google SRE insiste en probar hipótesis frente a evidencia; esa disciplina también evita dar por buena una optimización solo porque se desplegó.

Este criterio también ayuda a reconocer los errores más comunes al intentar acelerar una web: acciones fáciles de aplicar que se convierten en problemas cuando se ejecutan sin diagnóstico.

Errores habituales al intentar acelerar una web

Cuando una página tarda en responder, cualquier botón que promete «optimizar» resulta tentador. Algunos cambios sí ayudan, pero aplicarlos sin saber dónde está la espera puede crear una web más difícil de mantener y dejar intacta la operación lenta. La regla práctica es sencilla: cada intervención debe tener una hipótesis, una prueba y una forma de comprobar que no ha roto nada.

Apilar plugins, cachés y reglas sin conocer el recorrido

Un plugin de rendimiento no es intrínsecamente malo. El error es añadirlo como respuesta genérica, sin medir su coste ni saber si ya existe una función equivalente en el tema, el servidor o la CDN. Dos herramientas pueden modificar el mismo HTML o JavaScript y hacer difícil atribuir un fallo a una de ellas. La documentación de WordPress contempla conflictos entre plugins y recomienda aislar el causante durante el diagnóstico.

Con la caché sucede algo parecido. Varias capas pueden cooperar, pero cada una necesita reglas claras. Una página de producto pública, un carrito personalizado y un panel autenticado no tienen las mismas condiciones. Una configuración incorrecta puede mostrar datos antiguos o de otro contexto, ocultar la lentitud de las peticiones sin caché y complicar la invalidación. Antes de activar una capa nueva, identifica qué respuesta almacenará, cómo se distinguirá por usuario o estado y cómo comprobarás una modificación de precio o stock.

Ampliar recursos o migrar sin localizar la espera

Más RAM puede ayudar si el sistema está intercambiando memoria a disco o termina procesos por falta de ella. Si la ficha espera una API externa, añadir RAM no acorta esa llamada. Aumentar el número de procesos PHP puede aliviar una cola, pero también enviar más consultas simultáneas a una base de datos ya saturada. Cambiar de hosting plantea la misma pregunta a mayor escala: ¿qué límite concreto desaparecerá con el cambio?

Evita conclusiones basadas en una sola captura de CPU o en la lentitud de una única prueba. Relaciona las métricas de recursos con las solicitudes afectadas, comprueba si el límite se repite y compara una operación rápida con otra lenta. Si la causa es una consulta defectuosa o un proceso que se ejecuta innecesariamente, corrígelo o acótalo antes de decidir cuánta infraestructura necesitas.

Actualizar PHP, minificar o quitar scripts sin una prueba funcional

Actualizar PHP puede aportar mejoras y es necesario mantener un entorno compatible y soportado; el error es usar el cambio como experimento en producción sin revisar la aplicación, sus extensiones y la posibilidad de volver atrás. Algo similar ocurre al combinar archivos, diferir JavaScript o quitar un script de terceros: una métrica de carga puede mejorar mientras deja de funcionar un menú, un formulario, la analítica necesaria o el pago.

Prueba el cambio con las rutas y estados afectados. Un visitante anónimo no descubre errores de un usuario conectado; la portada no detecta un checkout roto. Si se retrasa un recurso, comprueba que se carga antes del momento en que la persona lo necesita. Si se elimina un script, determina qué función cumplía y verifica que esa función sigue disponible.

Cambiar muchas variables y después atribuirse la mejora

Instalar un plugin, modificar PHP, activar una CDN y comprimir imágenes en el mismo despliegue impide saber qué causó el resultado. También dificulta revertir: quizá una mejora compense un fallo introducido por otro cambio y el promedio parezca bueno. Separa las intervenciones cuando sea viable, registra estado anterior y posterior y conserva un criterio de reversión.

Hay una excepción razonable: un incidente grave puede exigir varias medidas de contención para recuperar el servicio. En ese caso distingue claramente la respuesta urgente del diagnóstico posterior. Que el sitio vuelva a funcionar no demuestra cuál era la causa ni cuál de las medidas debe quedarse.

Optimizar la portada y dar el trabajo por terminado

La home suele ser fácil de probar y mostrar. Una tienda puede tener una portada rápida y perder tiempo en filtros, fichas, carrito o pago. Una aplicación interna puede responder bien al cargar y volverse lenta al guardar datos. Selecciona las rutas según uso e importancia funcional; prueba sesiones, dispositivos y estados representativos.

Una puntuación de laboratorio puede orientar la investigación, pero es una observación bajo condiciones definidas. PageSpeed Insights distingue datos de laboratorio y de usuarios reales. No conviertas el número global en objetivo único: comprueba qué parte de la experiencia cambió y si la mejora se observa en la operación que motivó el trabajo.

La siguiente pregunta es por qué merece la pena hacerlo: la lentitud no afecta igual a todas las rutas ni a todos los momentos del negocio.

Una web rápida no es el objetivo: el objetivo es que funcione bien

Reducir un tiempo de carga tiene valor cuando ayuda a una persona a completar lo que vino a hacer: entender un servicio, encontrar un producto, pagar, enviar una consulta o terminar una tarea de trabajo. Por eso dos demoras de la misma duración pueden merecer prioridades distintas. El rendimiento se evalúa dentro de una acción, no solo en la portada o en un informe.

Esto tampoco significa que cada milisegundo ganado produzca automáticamente más ventas. Las decisiones de compra, la calidad de la oferta y la facilidad de uso intervienen a la vez. Podemos medir mejor la espera y observar el resultado de una acción; atribuirle un cambio comercial exige una comparación más cuidadosa.

Conversión: sigue el recorrido, no una cifra aislada

En una tienda online, conviene observar conjuntamente el tiempo de las fichas, los filtros, el carrito y el pago. Si el pago tarda, importa distinguir «se quedó esperando», «falló» y «terminó, pero el usuario no vio confirmación». Son problemas distintos y no se arreglan con la misma intervención.

Relaciona las mediciones técnicas con eventos funcionales: producto visto, búsqueda realizada, carrito actualizado, pago iniciado y compra completada, siempre con una instrumentación coherente. Google Analytics documenta eventos de comercio electrónico para seguir ese recorrido. Revisa también diferencias por dispositivo, ruta y momento. Una tasa agregada puede ocultar que solo el móvil o una pasarela concreta sufre la demora.

Si después de una mejora aumentan las ventas, todavía hay que preguntarse qué más cambió: campañas, precios, stock, temporada o diseño. La evidencia más sólida compara situaciones equivalentes y verifica primero que la propia operación se aceleró sin introducir errores.

SEO y publicidad: la velocidad ayuda a la experiencia, pero no compra posiciones

Una página que muestra pronto el contenido y responde bien facilita la lectura y el uso. También puede mejorar señales de experiencia de página. Google indica que utiliza Core Web Vitals en sus sistemas de clasificación, pero advierte de que obtener buenos resultados en esas métricas no garantiza los primeros puestos: la relevancia del contenido sigue siendo fundamental.

En tráfico de pago, la pregunta inmediata es más concreta: ¿la página de destino permite entender la propuesta y realizar la acción antes de que la persona abandone? Compara las rutas y dispositivos que reciben campañas. Evita atribuir un coste por adquisición mejor o peor únicamente a la velocidad sin revisar segmentación, creatividad, oferta y medición.

Productividad, estabilidad y coste de infraestructura

La lentitud de un backoffice puede no figurar en PageSpeed ni afectar a una URL pública. Aun así, si una tarea de diez pasos se repite muchas veces al día, pequeñas esperas se acumulan. Mide el flujo completo: abrir un pedido, buscarlo, editarlo y guardarlo. La mejora relevante es que el equipo pueda terminar la operación correctamente y con menos espera.

El rendimiento también afecta a la estabilidad. Una consulta que retiene conexiones puede crear colas y errores durante una campaña o una importación. Optimizarla puede reducir la presión sobre el servidor; comprar capacidad adicional puede ser necesario si la demanda real crece. Para comparar costes, incluye infraestructura, desarrollo, mantenimiento e incidencia potencial. Lo barato en una factura mensual puede ser caro si el sistema falla en momentos críticos.

Define el resultado antes de elegir la métrica

Una forma útil de plantear el trabajo es escribir una frase por recorrido: «queremos que quien filtra el catálogo vea resultados utilizables sin esperar innecesariamente» o «queremos que cada pago termine con una confirmación clara». A partir de ahí selecciona una medida técnica y una medida funcional: duración del filtro y uso de resultados; tiempo del pago y tasa de errores o reintentos.

No conviertas la relación en una ecuación universal. Una web puede mejorar su LCP y seguir teniendo un checkout lento; puede acelerar el pago y no vender más por una oferta poco clara. El éxito técnico se demuestra en la operación medida; el efecto comercial se evalúa con sus propios datos y contexto.

Una vez identificadas las operaciones importantes, la siguiente tarea es vigilarlas para detectar cuándo vuelven a degradarse.

Cómo vigilar el rendimiento para detectar una web lenta a tiempo

Una web puede estar disponible y, sin embargo, tardar tanto en responder que una búsqueda o un pago resulten difíciles de completar. Una comprobación que solo espera un HTTP 200 no detecta ese problema. Para descubrirlo antes de que se convierta en una queja, hay que observar la duración y el resultado de las operaciones importantes, además de la salud de la infraestructura.

La monitorización no tiene que empezar con una plataforma compleja. Si el cuello está en la infraestructura, la monitorización de servidores y alertas debe observar los recursos y procesos que pueden limitar esas operaciones. Empieza con una lista corta de rutas y acciones críticas, una línea de base y señales que indiquen cuándo se apartan de su comportamiento normal. Más datos solo ayudan si permiten responder «qué se ralentizó, cuándo y por qué».

Disponibilidad y rendimiento son preguntas diferentes

Una prueba externa puede avisar de que la portada no responde, devuelve un error o tarda demasiado desde una ubicación concreta. Es útil, pero una portada con caché puede estar sana mientras el carrito, el backoffice o una búsqueda fallan. Incluye, cuando sea viable, comprobaciones de flujos representativos y verifica el resultado esperado, no solo el código HTTP.

La experiencia real añade el contexto que una prueba programada no reproduce siempre: móviles lentos, redes variables, usuarios autenticados y rutas concretas. Los datos de campo ayudan a ver cómo se carga y responde la página para quienes la utilizan; web.dev explica la diferencia entre mediciones reales y pruebas de laboratorio. Respeta la privacidad y evita que el propio código de medición perjudique la página.

Cuatro señales para saber si el problema está creciendo

Para cada operación importante registra latencia, tráfico, errores y saturación. Es el conjunto de señales que propone Google SRE para sistemas orientados a usuarios. La latencia indica cuánto se espera; el tráfico, cuánta demanda hay; los errores, cuántas operaciones fallan; y la saturación, cuánto margen queda en los recursos que pueden limitar el servicio.

Una media estable no garantiza que todos esperen lo mismo. Observa también percentiles o distribuciones y conserva la diferencia entre respuestas correctas y fallidas. Para diagnosticar un pico, correlaciona las cuatro señales en la misma franja horaria.

De la alarma a la causa: registros, consultas y trazas

Si el tiempo del checkout sube, una alerta debe llevar a la siguiente pregunta, no limitarse a avisar «servidor lento». Registra duración y estado por endpoint, las consultas lentas, el tiempo de las dependencias externas y las colas de ejecución. En PHP-FPM, por ejemplo, el estado del pool permite observar la cola y si se alcanzó el máximo de procesos.

Cuando una solicitud atraviesa varios componentes, una traza puede mostrar dónde se consume el tiempo; los registros explican acontecimientos concretos y las métricas muestran tendencias. OpenTelemetry describe cómo se complementan estas señales. Añade identificadores de petición cuando sea posible para relacionar un error visible con su recorrido interno, sin guardar datos personales innecesarios.

Alertas que pidan una acción, no ruido constante

Define umbrales a partir de la línea de base y de la tolerancia de cada operación. Una alerta útil nombra la ruta, el síntoma, su duración y un enlace a la evidencia. Evita alarmar por un pico aislado de CPU si los usuarios completan las tareas con normalidad; sí atiende un aumento sostenido de errores o latencia en el pago aunque la portada siga disponible.

Después de cada cambio importante compara la nueva versión con la línea de base y vigila posibles regresiones. Conserva el historial de despliegues, importaciones y tareas programadas junto a las métricas: a menudo explica por qué el problema comenzó a una hora concreta. Revisa las alertas que nunca llevan a una intervención; si nadie sabe qué hacer con una de ellas, hay que redefinirla.

Con estas señales preparadas, podemos condensar todo el diagnóstico en una lista breve que sirva cuando la próxima persona diga: «mi web va lenta».

Checklist para diagnosticar una web lenta

Usa esta lista cuando aparezca una incidencia, antes de instalar un plugin o contratar otro servidor. No es una colección de soluciones automáticas: cada casilla identifica una pregunta cuya respuesta ayuda a decidir dónde medir después. Puedes marcarla al comprobarla; las marcas se pierden al cerrar la página. Guarda las evidencias en tu registro de incidencia.

1. Describe qué va lento y para quién

Resultado de esta fase: una frase reproducible, por ejemplo: «al filtrar productos en móvil, la petición de resultados tarda varias veces más que la misma categoría sin filtro». Si aún no puedes escribirla, captura horarios, rutas y ejemplos antes de optimizar.

2. Averigua en qué tramo se pierde el tiempo

Resultado de esta fase: una capa candidata, no una conclusión definitiva. Un TTFB alto señala una espera antes del primer byte; por sí solo no distingue aplicación, base de datos, cola o servicio externo.

3. Comprueba la hipótesis en la capa afectada

Resultado de esta fase: una hipótesis que pueda fallar, como «estas consultas crecen con el número de variantes». Anota qué dato la confirmaría y cuál la debilitaría. Google SRE describe este contraste de hipótesis con observaciones como parte del diagnóstico.

4. Corrige y demuestra que mejoró

Quedan algunas dudas frecuentes que merecen una respuesta directa: hosting, WordPress, PrestaShop, CDN, SEO y tiempos de carga.

Preguntas frecuentes sobre una web lenta

Estas respuestas sirven para orientar la primera comprobación. Abre la pregunta que se parezca a tu caso y sigue el enlace a la parte del artículo donde se explica el diagnóstico con más detalle.

Si ninguna respuesta encaja del todo, vuelve a la checklist: una descripción precisa de la operación lenta suele ser más útil que empezar por el nombre de una tecnología.

Antes de acelerar una web, descubre qué la frena

«Mi web va lenta» es el principio de una investigación, no un diagnóstico. La espera puede estar en la conexión, el servidor, una consulta, una dependencia externa o el navegador; también puede aparecer solo en una ruta, una sesión o una hora concreta. Cada caso pide una intervención distinta.

El recorrido útil es medir → localizar → demostrar → corregir → verificar. Reproduce la operación que importa, identifica dónde se consume el tiempo, contrasta una causa posible y cambia una variable. Después comprueba la misma operación, su resultado funcional y las rutas relacionadas. Si el dato contradice la hipótesis, vuelve a investigar: también es un avance.

Una mejora real permite a las personas encontrar, decidir, comprar o trabajar con menos espera y sin nuevos errores. Cuando intervienen servidor, aplicación, base de datos, CMS, frontend y servicios externos, diagnosticar primero evita acumular cambios sin saber cuál ha funcionado. La checklist de diagnóstico queda aquí para la próxima vez que aparezca el síntoma.