Buenas
TrinityCore,
El concepto de que Ajax es más rápido... bueno depende de como lo has montado.
Cada vez que se refresca el navegador se hace una solicitud de todos lo elementos no cacheados en el navegador del usuario y lógicamente de todas las tareas que tengas asignada al backend.
Ajax lo que permite es solo refrescar ciertas partes de la web, una zona donde aparecen consultas, select dependientes, nuevos registros, ventanas modales etc...
Al no tener que cargar de nuevo todos los elementos no cacheados en el navegador se "debe reducir" la velocidad de respuesta.
Quiere decir, que si tenemos bien configurado el cacheo en el navegador del usuario tenemos parte del trabajo solucionado. Ahora bien, ¿que pasa con el backend?
Ahí está la respuesta del problema, si haces una consulta sobre datos en la DB, por ejemplo para llenar un select con categorías, que es un sector bastante estático, esto se debería cachear y evitar peticiones recurrentes e innecesarias a la DB.
Los elementos más dinámicos, igual, se cachean pero quizás con un ttl algo más reducido.
Un caso de ejemplo, tienes 50 usuarios haciendo peticiones por segundo.
Cada petición es una consulta a la base de datos, 50 peticiones cada segundo... uhm... incluso si hay cambios, cachear con un ttl de un segundo o de dos segundos, es casi imperceptible para cualquier persona (es lo que tardan muchas webs en cargar) y la respuesta de la base de datos sería una consulta cada 1s o 2s para 50 usuarios... (valores teóricos
) eso es algo más aceptable y más ágil para conseguir una mejor respuesta del servidor.
El ttl de cada elemento en cache es algo que tienes que evaluar para buscar un equilibrio entre eficiencia de la aplicación y experiencia del usuario.
Después tendrías la propia configuración del servidor, me consta que influye, pero ese tema se me escapa.
Hay temas interesantes en el foro sobre aumentar la velocidad de descarga de una web. Y el tema ajax, tiene más que ver con el desarrollo de la aplicación.
Saludos,