La respuesta es completamente circunstancial.
La transmisión real de datos (es decir, el proceso de envío ) es más eficaz de una manera no encriptada y comprimida. El cifrado (SSL / TLS) normalmente aumenta el tamaño de los datos, por lo que hay más para enviar. Cuanto más pequeño es el conjunto de datos, más rápido se envía. En la vida real, el envío de datos sin cifrar es a menudo una mala estrategia. Sin embargo; el cifrado / compresión agrega operaciones adicionales. El punto es que hay una diferencia entre entregar los datos y cuándo el usuario realmente los verá.
Incrustar datos en una página y recuperarlos en una llamada separada es donde la respuesta “depende” puede llevarlo en muchas direcciones. El rendimiento se trata de la asignación de recursos informáticos. Si su servidor no es terriblemente poderoso y recibe muchas solicitudes simultáneas que todos necesitan para procesar páginas, podría convertirse en un cuello de botella y ralentizar las cosas. Todo el procesamiento de datos inicial se realiza en un servidor (lo que conduce a la agrupación en múltiples servidores como solución). Tampoco puede aprovechar el almacenamiento en caché si los datos son dinámicos … lo que significa que no puede almacenar en caché el HTML y otros activos en la página. Entonces, aunque solo haya una solicitud de red, esta estrategia puede aumentar la latencia.
- ¿Por qué MeteorJS perdió su popularidad después de mediados de 2016?
- ¿Qué idioma de backend tiene más trabajos y utilidad?
- No estoy completamente seguro de cuál es la diferencia entre CMS y un lenguaje de fondo + base de datos.
- ¿Cuáles son algunos lenguajes de programación de back-end que se requieren para construir una aplicación híbrida?
- ¿Cuáles son las diferencias entre un rol de PM de front-end y un rol de PM de back-end?
Usar AJAX es un medio de distribuir la capacidad informática. En lugar de confiar en el servidor para procesar todo, la página ahora puede usar los recursos del dispositivo cliente. Esto se vuelve más complicado con las aplicaciones de IoT, pero las capacidades del navegador han hecho avances enormes (y a menudo inadvertidos) en este espacio.
Por ejemplo, preconnect atributos predns y preconnect para una etiqueta . Notará que estas etiquetas ayudan al navegador a controlar las solicitudes de red, aprovechando el almacenamiento en caché de los activos que no son de datos. En muchos casos, esto puede aumentar sustancialmente el rendimiento percibido, incluso si carga sus datos en una solicitud por separado.
También es importante pensar en cosas como localStorage , que puede almacenar en caché los datos para eliminar potencialmente las solicitudes de datos por completo (después de la primera carga). Los trabajadores de servicios (que se están volviendo cada vez más comunes) también permiten un mayor control sobre la red, haciendo que cosas como la carga de datos predictivos sean más accesibles para el desarrollador promedio.
Finalmente, los datos se pueden recuperar de diferentes fuentes simultáneamente. Si escala una aplicación para usar múltiples API, puede “canalizar” los datos. Incluso los navegadores web más antiguos pueden admitir hasta 6 solicitudes HTTP simultáneas (las más nuevas que ejecutan HTTP2 son mucho mayores) … es la forma en la web de hacer hyperthreading.
Hay un montón de factores en el rendimiento. Es toda una subsector dentro del desarrollo web.
Hay casos de uso para ambos escenarios. Recientemente incruste datos específicos del usuario en una página porque el servidor estaba usando autenticación basada en sesión. Los datos específicos del usuario se integraron en la página, pero la carga principal de datos se sirvió desde una API a través de AJAX. El punto es que las soluciones híbridas son posibles, y el truco es saber cómo equilibrar el rendimiento con la productividad y las capacidades de todo el sistema.