Skip to content

Lightning Experience con Lightning Speed (¿Ya llegamos?) ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

Experiencia relámpago con la velocidad del rayo (¿Ya llegamos?) | Blog de desarrolladores de Salesforce

Cuando el rendimiento del sitio web es excelente, es invisible y todo se siente sin fricciones. Pero cuando el rendimiento se ve afectado, afecta duramente a la experiencia general. Con eso en mente, todos sabemos que Lightning Experience ha tenido algunas áreas de oportunidad para mejorar. Extendemos un gran GRACIAS a todos los que compartieron sus pensamientos y sentimientos sobre el rendimiento de Lightning Experience en IdeaExchange. Hemos leído cada uno de sus comentarios y nos ha motivado a probar algo nuevo.

En esta publicación, nos gustaría brindarle una mirada más detallada al estado actual del rendimiento de Lightning Experience. Compartiremos datos concretos, discutiremos nuestras áreas actuales de inversión y describiremos los próximos pasos en este viaje. ¡Después de todo, queremos que Lightning Experience tenga la velocidad del rayo tanto como usted!

¿Qué sucede detrás de Lightning Experience?

Entonces, ¿qué sucede después de que un usuario escribe una URL en la barra de navegación del navegador y presiona "Enter"? Vamos a ver.

Comenzaremos describiendo los pasos clave que se deben realizar para producir una página de Lightning Experience . (Por cierto, esta es una descripción general opcional de Lightning Experience 101. Si cree que no aprenderá nada nuevo, no dude en omitir esta sección y pasar a la siguiente).

Al desglosar el flujo general, es importante tener en cuenta que Lightning Experience es una SPA (aplicación web de una sola página). Utiliza la representación del lado del cliente de los componentes Aura y LWC, a diferencia de Salesforce Classic, que utiliza la representación del lado del servidor y los componentes de Visualforce.

Teniendo eso en cuenta, esto es lo que hace el navegador del cliente cuando un usuario inicia la navegación:

Y aquí hay más detalles sobre los pasos necesarios para producir la página de Lightning Experience como se presenta en el diagrama anterior:

  1. Establecer conexión inicial a un centro de datos de Salesforce
  2. Descargue HTML, CSS y JavaScript iniciales con el marco central y los componentes Aura y LWC más comunes
  3. Use la representación del lado del cliente para crear el cromo de la aplicación (diseño inicial) y eliminar la pantalla de carga
  4. Descargar código adicional y componentes específicos de la página
  5. Solicite datos para mostrar en los componentes mientras aplica el acceso y la seguridad
  6. Comience a renderizar progresivamente la página de la aplicación a medida que lleguen más datos y espere más información del usuario.

Después de la navegación inicial, lo más probable es que ocurra una de las siguientes situaciones.

Como se indica en el diagrama anterior, es probable que el usuario pueda hacer una de las siguientes cosas:

  • Realice una acción que requiera una navegación completa (repita los pasos 2 a 6 anteriores), por ejemplo, cambie de aplicación en el Iniciador de aplicaciones
  • Haga clic en algún lugar de la página de la aplicación para iniciar la navegación suave (repita los pasos 3 a 6 anteriores), por ejemplo, navegue a un registro
  • Abandone la aplicación, por ejemplo, cierre la pestaña

Y eso es.

Medición del rendimiento de Lightning Experience

Como sabrá, Salesforce utiliza una métrica llamada Tiempo de página experimentado (EPT), que mide el tiempo que tarda una página en cargarse por completo.

Este gráfico da una idea de lo que mide la EPT:

Para realizar un seguimiento del rendimiento de Lightning Experience en Salesforce, utilizamos un tablero para agregar métricas de producción de todas las vistas de página de Lightning Experience. A partir de la última versión disponible públicamente , nuestro EPT P50 (mediano) medido globalmente se informa como 1,0 segundo.

Según HTTP Archive, las métricas promedio de carga de páginas se encuentran en el rango de dos a siete segundos. Si Lightning Experience carga páginas en un segundo, varias veces más rápido que el promedio , ¿por qué necesita ser aún más rápido?

Cuando comenzamos a cuestionar nuestras suposiciones, nos dimos cuenta de que necesitábamos adoptar un punto de vista centrado en el usuario y comenzar a observar los datos que reflejaban mejor la percepción del usuario sobre el tiempo de carga de la página .

Para hacer eso, analizamos los datos que no se informaron anteriormente como parte de EPT:

  • Todo el trabajo requerido para navegaciones completas; básicamente, el tiempo de carga de la página percibido por el usuario final cuando inicia Lightning Experience
  • Datos de carga de la página provenientes de navegaciones problemáticas que demoraron más de cierto umbral que se excluyó anteriormente

Además, hemos analizado más detalladamente la segmentación para centrarnos en los segmentos más problemáticos, no solo en los promedios:

  • Usuarios de escritorio vs móviles
  • Cantidad de personalización y "complejidad de implementación"

Por último, pero no menos importante, estamos mejorando los datos en sí:

  • Además de analizar los datos de P50 (al menos el 50 % de las navegaciones serían más lentas que ese valor), ahora estamos rastreando los datos de P75 (al menos el 25 % de las navegaciones serían más lentas que ese valor) para reflejar mejor las peores experiencias .

Una vez que se implementaron esos cambios en los tableros de rendimiento, vimos que la duración de carga de la página de Lightning Experience para navegaciones completas sería un P50 de aproximadamente cuatro segundos y un P75 de aproximadamente siete segundos. Esto empeora aún más para organizaciones con implementaciones complejas que alcanzan P75 de más de 10 segundos en algunos casos. Ay.

Toda solución comienza con la comprensión y la internalización del problema. Este ejercicio de descubrimiento de datos confirmó la urgencia de mejorar el rendimiento de carga de páginas de Lightning Experience para nuestros usuarios.

Mejora del rendimiento de Lightning Experience

Al ver el problema con claridad y gracias a sus comentarios, hemos elaborado un plan concreto de mejora para las próximas versiones.

Para ser claros, estamos enfocados en investigaciones de ingeniería profundas, perfiles y prototipos de múltiples opciones en este momento. A medida que descubrimos nueva información, podemos cambiar algunos planes para alcanzar nuestros objetivos generales de manera más eficiente. La lista a continuación representa nuestro pensamiento y enfoque actual, no necesariamente el trabajo comprometido y detallado.

Consideramos vital que estas mejoras sean lo más generalizadas posible. Como tal, estamos priorizando soluciones que elevarán la plataforma para la mayoría de nuestros clientes . Los casos de uso más específicos pueden ver mejoras adicionales más adelante. Por ahora, apuntamos a mejoras que deberían tener un impacto significativo en la mayoría de los usuarios.

Nuestro actual plan de mejora cubre las siguientes inversiones clave:

  1. Mejore la conectividad con una mejor utilización de CDN para los recursos del marco central y habilite CDN para más usuarios (vea más detalles en nuestra publicación de blog ).
  2. Reduzca el tamaño de la carga útil del marco, los componentes y los estilos básicos iniciales. Además de reducir la cantidad de datos transferidos, esto debería tener un impacto positivo en los dispositivos cliente si hay menos código para compilar y menos estilos para conectar en cascada.
  3. Habilite la priorización de las recuperaciones de recursos para obtener contenido inicialmente visible más rápido.
  4. Mejorar la capacidad de almacenamiento en caché del código.
  5. Reduzca la "conversación" cliente-servidor para cargas de página e interacciones más rápidas.
  6. Continuar nuestra inversión en componentes:
    1. Admite formularios dinámicos en entidades adicionales
    2. Hacer que Dynamic Forms sea el predeterminado para nuevas organizaciones
    3. Convierta las cinco entidades Aura más utilizadas en LWC

Así es como las mejoras de la lista anterior beneficiarían los pasos de construcción de páginas de Lightning Experience:

Conclusión

Estamos emocionados de embarcarnos en este viaje junto con usted, y la publicación de hoy es el comienzo de una serie centrada en el rendimiento de Lightning Experience, donde profundizaremos en temas y mejoras individuales. Además de mantenerlo informado sobre nuestro progreso, compartiremos consejos y trucos sobre las mejoras que puede lograr hoy, por ejemplo, actualizar a las últimas mejoras de componentes como Dynamic Forms que pueden mejorar el tiempo de carga de la página hasta en un 10%. ¡Por favor manténgase al tanto!

Mientras tanto, ¡no dude en contactarnos con sus pensamientos y comentarios!

Sobre los autores

Bogdan Brinza (él/él) es un director sénior de productos que administra el equipo de Lightning Platform. Dirige los equipos de la plataforma web que habilitan Lightning Experience y le apasiona ajustar las experiencias web para que sean más rápidas. Síguelo en GitHub @boggydigital.

Pierre-Marie Dartus (él/él) trabaja como arquitecto de ingeniería de software en Salesforce como parte del equipo principal de LWC. Se enfoca principalmente en el marco de JavaScript y el rendimiento de la interfaz de usuario. Sígalo en Twitter @pmdartus y en Github @pmdartus.

Obtenga las últimas publicaciones de blog de desarrolladores de Salesforce y episodios de podcast a través de Slack o RSS.

Agregar a Slack Suscríbete a RSS

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2023/03/lightning-experience-with-lightning-speed-are-we-there-yet.html

Entradas recomendadas