Cuando tu aplicación Laravel ejecuta cientos de queries por página, el rendimiento se desploma. Vamos a reducir esas consultas usando eager loading y la barra de depuración de Laravel para visualizar el problema en tiempo real, pensado para desarrolladores que ya manejan Eloquent y quieren resolver el clásico problema N+1.

Por qué tu aplicación ejecuta 500 queries en una sola vista

Antes de optimizar necesitas ver el problema. Por eso lo primero es instalar Laravel Debugbar, una herramienta que te muestra exactamente cuántas consultas se ejecutan en cada request.

En una terminal nueva corres:

bash composer require barryvdh/laravel-debugbar --dev

Apenas lo instalas aparece la barra al pie de la página y revela algo incómodo: 500 queries ejecutándose en el index y 19 al visitar una pregunta individual. Eso es insostenible.

¿Qué es Laravel Debugbar? Es un paquete de desarrollo que muestra en pantalla las queries SQL, el tiempo de respuesta y la memoria usada por cada request. Lo instalas con la flag --dev porque solo lo necesitas en local.

Cómo reducir 500 queries a 5 con eager loading

El culpable casi siempre es el mismo: por cada pregunta, Eloquent dispara una consulta extra para traer el usuario y otra para la categoría. Si tienes 100 preguntas, son 200 queries adicionales.

La solución es decirle a la query principal que cargue esas relaciones de una sola vez. En el componente que lista las preguntas, actualizas la consulta para que también traiga el usuario creador y la categoría asociada.

Después del cambio el conteo baja a 5 queries:

• Una para los usuarios involucrados.
• Una para las categorías.
• Una para el listado de preguntas.
• Dos adicionales del contexto general (usuario logueado y datos base).

Puedes hacer click en la barra y ver el detalle exacto de cada query, lo que te confirma que ya no hay consultas duplicadas.

Qué pasa al crear una pregunta nueva

Al entrar al formulario de creación verás solo 2 queries: una para listar categorías disponibles y otra para identificar al usuario logueado. Eso es lo mínimo que necesitas y está bien así.

Cómo optimizar respuestas anidadas para mantener un número constante de queries

Aquí aparece el reto más interesante. Al visitar una pregunta el contador marca 5, pero apenas agregas una respuesta sube a 7. Otra respuesta y llega a 9. Si esa respuesta tiene una respuesta hija, sube a 11.

El número crece con cada nivel de anidación, y eso es exactamente el problema N+1 aplicado a estructuras jerárquicas.

¿Qué es el problema N+1? Es cuando ejecutas una query para traer N registros y luego una query adicional por cada uno para cargar sus relaciones. Termina costando N+1 consultas cuando podrían ser solo 2.

La corrección se hace en el componente de la pregunta. Le indicas dos cosas:

1. Que cargue directamente al usuario creador junto con la pregunta.
2. Que al traer las respuestas hijas, también traiga sus usuarios.
3. Que desde las respuestas hijas, cargue recursivamente sus propias respuestas hijas.

Con el primer ajuste el conteo baja de 19 a 13. Con el segundo, llega a 7. Y al cubrir el segundo nivel de anidación, se estabiliza.

El número mágico: nueve queries como techo

Después de aplicar el eager loading recursivo, el comportamiento cambia por completo. Pruebas desde cero con una pregunta sin respuestas y marca 5 queries. Agregas una respuesta y sube a 7. Esa respuesta recibe una respuesta hija y llega a 9.

Y ahí se queda.

Agregas más respuestas, más niveles, recargas la página varias veces: siempre 9. Ese es el indicador de que tu optimización funciona, porque el número de consultas ya no depende del volumen de datos sino de la estructura de relaciones que definiste.

¿Por qué nueve y no menos? Porque cada relación que cargas suma una query base: pregunta, categoría, usuario de la pregunta, respuestas, usuarios de respuestas, respuestas hijas, usuarios de respuestas hijas, más el contexto del request. Nueve es el mínimo viable para esa estructura.

Cómo verificar que tu optimización funciona en producción

La prueba final es navegar la aplicación recargando con frecuencia y mirar la barra. Tanto en el index como en el detalle de cada pregunta el conteo se mantiene estable. Si lo ves crecer, falta una relación por incluir en el eager loading.

Este patrón aplica a cualquier modelo con relaciones anidadas: comentarios, categorías jerárquicas, organigramas. La regla es simple: cada relación que vas a usar en la vista, cárgala desde la query principal.

¿Has medido cuántas queries ejecuta tu proyecto actual? Cuéntame en los comentarios qué número te aparece antes y después de aplicar este ajuste.