Aplicación de una sola página
debido a que el SPA es una evolución alejada del modelo de redibujo de páginas sin estado para el que se diseñaron originalmente los navegadores, han surgido algunos nuevos desafíos. Las posibles soluciones (de complejidad variable, exhaustividad y control de autor) incluyen:
- bibliotecas JavaScript del lado del cliente.
- Marcos web del lado del servidor que se especializan en el modelo SPA.
- La evolución de los navegadores y la especificación HTML5, diseñada para el modelo SPA.,
Search-engine optimizationEdit
debido a la falta de ejecución de JavaScript en los rastreadores de algunos motores de búsqueda web populares, SEO (Search engine optimization) ha presentado históricamente un problema para los sitios web públicos que desean adoptar el modelo SPA.
entre 2009 y 2015, Google Webmaster Central propuso y luego recomendó un «esquema de rastreo AJAX» utilizando un signo de exclamación inicial en identificadores de fragmentos para páginas AJAX con estado (#!)., El sitio SPA debe implementar un comportamiento especial para permitir la extracción de metadatos relevantes por parte del rastreador del motor de búsqueda. Para los motores de búsqueda que no admiten este esquema de hash de URL, las URL con hash del SPA permanecen invisibles. Estos Uri «hash-bang» han sido considerados problemáticos por varios escritores, incluyendo Jeni Tennison en el W3C porque hacen que las páginas sean inaccesibles para aquellos que no tienen JavaScript activado en su navegador. También rompen los encabezados HTTP referer ya que los navegadores no pueden enviar el identificador de fragmento en el encabezado Referer., En 2015, Google desaprobó su propuesta de rastreo hash-bang AJAX.
alternativamente, las aplicaciones pueden representar la carga de la primera página en el servidor y las actualizaciones de página posteriores en el cliente. Esto es tradicionalmente difícil, porque el código de renderizado puede necesitar ser escrito en un lenguaje o marco diferente en el servidor y en el cliente. El uso de plantillas sin lógica, la compilación cruzada de un idioma a otro o el uso del mismo idioma en el servidor y el cliente puede ayudar a aumentar la cantidad de código que se puede compartir.,
en 2018, Google introdujo el renderizado dinámico como otra opción para los sitios que desean ofrecer a los rastreadores una versión pesada de una página que no sea JavaScript para fines de indexación. La representación dinámica Cambia entre una versión de una página que se representa en el lado del cliente y una versión preprocesada para agentes de usuario específicos. Este enfoque implica que su servidor web detecte rastreadores (a través del agente de usuario) y los enrute a un renderizador, desde el cual se les sirve una versión más simple del contenido HTML.,
debido a que la compatibilidad SEO no es trivial en los SPAs, vale la pena señalar que los SPAs no se usan comúnmente en un contexto donde la indexación de motores de búsqueda es un requisito o deseable. Los casos de uso incluyen aplicaciones que muestran datos privados ocultos detrás de un sistema de autenticación. En los casos en que estas aplicaciones son productos de consumo, a menudo se utiliza un modelo clásico de «redibujo de página» para la página de destino de las aplicaciones y el sitio de marketing, que proporciona suficientes metadatos para que la aplicación aparezca como un éxito en una consulta del motor de búsqueda., Blogs, Foros de soporte y otros artefactos tradicionales de redibujo de páginas a menudo se sientan alrededor del SPA que pueden sembrar motores de búsqueda con términos relevantes.
otro enfoque utilizado por los marcos web centrados en el servidor como el Itsnat basado en Java es renderizar cualquier hipertexto en el servidor utilizando el mismo lenguaje y tecnología de plantillas. En este enfoque, el servidor conoce con precisión el estado DOM en el cliente, Cualquier actualización de Página grande o pequeña requerida se genera en el servidor, y se transporta por Ajax, el código JavaScript exacto para llevar la página del cliente al nuevo estado ejecutando métodos DOM., Los desarrolladores pueden decidir qué estados de Página deben ser rastreables por las arañas web para SEO y ser capaces de generar el Estado requerido en el tiempo de carga generando HTML simple en lugar de JavaScript. En el caso del framework ItsNat, esto es automático porque ItsNat mantiene el árbol DOM del cliente en el servidor como un árbol DOM de Java W3C; el renderizado de este árbol DOM en el servidor genera HTML simple en tiempo de carga y acciones Dom de JavaScript para solicitudes Ajax., Esta dualidad es muy importante para SEO porque los desarrolladores pueden construir con el mismo código Java y plantillas basadas en HTML puro el estado DOM deseado en el servidor; en el tiempo de carga de la página, el HTML convencional es generado por ItsNat haciendo que este estado DOM sea compatible con SEO.
a partir de la versión 1.,3, ItsNat proporciona un nuevo modo sin estado, y el Dom del cliente no se mantiene en el servidor porque, con el cliente en modo sin estado, el estado del DOM se reconstruye parcial o totalmente en el servidor cuando se procesa cualquier solicitud Ajax basada en los datos requeridos enviados por el cliente que informan al servidor del estado actual del DOM; el modo sin estado también puede ser compatible con SEO porque la compatibilidad SEO ocurre en el momento de carga de la página inicial no afectada por los modos con estado o sin estado., Otra opción posible son frameworks como PreRender, Puppeteer, Rendertron que se pueden integrar fácilmente en cualquier sitio web como un middleware con una configuración de servidor web que permite que las solicitudes de bot (google bot y otros) sean servidas por el middleware mientras que las solicitudes que no son de bot se sirven como de costumbre. Estos frameworks almacenan en caché las páginas web relevantes periódicamente para permitir que las últimas versiones estén disponibles para los motores de búsqueda. Estos marcos han sido aprobados oficialmente por google.
hay un par de soluciones para que parezca que el sitio web es rastreable., Ambos implican la creación de páginas HTML separadas que reflejan el contenido del SPA. El servidor podría crear una versión basada en HTML del sitio y entregarla a los rastreadores, o es posible usar un navegador sin cabeza como PhantomJS para ejecutar la aplicación JavaScript y generar el HTML resultante.
ambos requieren un poco de esfuerzo, y pueden terminar dando un dolor de cabeza de mantenimiento para los sitios complejos grandes. También hay trampas potenciales de SEO. Si se considera que el HTML generado por el servidor es demasiado diferente del contenido de SPA, el sitio será penalizado., Ejecutar PhantomJS para generar el HTML puede ralentizar la velocidad de respuesta de las páginas, lo cual es algo para lo que los motores de búsqueda – Google en particular – degradan los rankings.
client/server code partitioningEdit
Una forma de aumentar la cantidad de código que se puede compartir entre servidores y clientes es utilizar un lenguaje de plantillas sin lógica como Mustache o Handlebars. Estas plantillas pueden ser renderizadas desde diferentes lenguajes de host, como Ruby en el servidor y JavaScript en el cliente., Sin embargo, el mero hecho de compartir plantillas suele requerir la duplicación de la lógica empresarial utilizada para elegir las plantillas correctas y rellenarlas con datos. La representación a partir de plantillas puede tener efectos negativos en el rendimiento cuando solo se actualiza una pequeña parte de la página, como el valor de una entrada de texto dentro de una plantilla grande. Reemplazar una plantilla completa también podría alterar la selección o la posición del cursor de un usuario, donde actualizar solo el valor modificado podría no., Para evitar estos problemas, las aplicaciones pueden usar enlaces de datos de interfaz de usuario o manipulación granular del DOM para actualizar solo las partes apropiadas de la página en lugar de volver a representar plantillas completas.
historial del Navegadoreditar
con un SPA siendo, por definición,» una sola página», el modelo rompe el diseño del navegador para la navegación del historial de páginas utilizando los botones «adelante» o «atrás»., Esto presenta un impedimento de usabilidad cuando un usuario presiona el botón Atrás, esperando el estado de la pantalla anterior dentro del SPA, pero en su lugar, se descarga la página única de la aplicación y se presenta la página anterior en el historial del navegador.
la solución tradicional para SPAs ha sido cambiar el identificador de fragmento de hash de la URL del navegador de acuerdo con el estado actual de la pantalla. Esto se puede lograr con JavaScript, y hace que los eventos del historial de URL se construyan dentro del navegador., Mientras el SPA sea capaz de resucitar el mismo estado de pantalla a partir de la información contenida en el hash de la URL, se conservará el comportamiento esperado del botón de retroceso.
para resolver aún más este problema, la especificación HTML5 ha introducido pushState y replaceState que proporcionan acceso programático a la URL real y al historial del navegador.
AnalyticsEdit
las herramientas de análisis como Google Analytics dependen en gran medida de la carga de páginas completamente nuevas en el navegador, iniciada por una nueva carga de página. Los SPAs no funcionan así.,
después de la carga de la primera página, todos los cambios de Página y contenido posteriores son manejados internamente por la aplicación, que simplemente debe llamar a una función para actualizar el paquete de analytics. Al no llamar a dicha función, el navegador nunca activa una nueva carga de página, nada se agrega al historial del navegador y el paquete de análisis no tiene idea de quién está haciendo qué en el sitio.
agregar cargas de página a un SPAEdit
es posible agregar eventos de carga de página a un SPA utilizando la API de historial HTML5; esto ayudará a integrar analytics., La dificultad viene en la gestión de esto y asegurar que todo está siendo rastreado con precisión – esto implica comprobar si faltan informes y entradas dobles.Algunos marcos proporcionan integraciones de análisis de código abierto que se dirigen a la mayoría de los principales proveedores de análisis. Los desarrolladores pueden integrarlos en la aplicación y asegurarse de que todo funciona correctamente, pero no hay necesidad de hacer todo desde cero.
velocidad de carga inicialEditar
Las aplicaciones de una sola página tienen una carga de primera página más lenta que las aplicaciones basadas en servidor., Esto se debe a que la primera carga tiene que derribar el marco y el código de la aplicación antes de representar la vista requerida como HTML en el navegador. Una aplicación basada en servidor solo tiene que enviar el HTML requerido al navegador, reduciendo la latencia y el tiempo de descarga.
acelerar la carga de la páginaeditar
hay algunas maneras de acelerar la carga inicial de un SPA, como un enfoque pesado para el almacenamiento en caché y módulos de carga lenta cuando sea necesario., Pero no es posible alejarse del hecho de que necesita descargar el marco, al menos parte del código de la aplicación, y lo más probable es que golpee una API para obtener datos antes de mostrar algo en el navegador. Este es un escenario de compensación de «Págame ahora o Págame más tarde». La cuestión del rendimiento y los tiempos de espera sigue siendo una decisión que el desarrollador debe tomar.