¿Construir un clon de Facebook o Airbnb en menos de un día? Eso habría sido impensable cuando se fundaron estas plataformas multimillonarias. Hoy lo es, gracias a las herramientas sin código. Con Bubble, Flutteflow, WeWeb y otras similares, cualquiera con un ordenador y una conexión a Internet puede desarrollar su propia aplicación.
Proyectos de la comunidad VisualMakers como GuestGoods, CircleHand o DreamyTales demuestran que es posible. Los editores frontales modernos y las plantillas ya preparadas facilitan enormemente la creación de aplicaciones atractivas. Sin embargo, una aplicación destinada a albergar a varios miles de usuarios requiere algo más que colores bonitos y tablas ordenadas.
Aunque no se note desde el principio, el rendimiento -principalmente expresado en tiempos de carga- es algo que a menudo no se tiene en cuenta cuando se hacen los primeros diseños de aplicaciones. Por desgracia, muchos desarrolladores ciudadanos no suelen aprender (o aprenden demasiado tarde) a optimizar el rendimiento de una aplicación. Por ello, en esta entrada del blog vamos a ver algunas de las mejores prácticas que te ayudarán a optimizar el tiempo de carga de tu app.
El contenido de este artículo no se refiere explícitamente al desarrollo sin código, sino que procede del desarrollo clásico. Desde luego, esta lista no es exhaustiva. Así que estaremos encantados si tienes tus propios consejos que puedas compartir con nosotros. Sólo tienes que unirte a nuestra comunidad de Slack.
En primer lugar, se trata del front-end. Esto afecta a todo lo que es visible, como imágenes, textos o tablas, pero también a elementos frontales invisibles como contenedores o bloques div.
Reduce el número de elementos de una página a un mínimo suficiente. Cuantos más elementos haya que cargar, mayor será el tiempo de carga y más lenta la aplicación. Todos los elementos requieren capacidad de carga, pero incluso los elementos no visibles, como los bloques div, pueden reducir el rendimiento. Así que piensa detenidamente si necesitas incluir otros elementos como texto o imágenes en sus propios bloques div o contenedores.
Si el diseño de tu aplicación ya es de naturaleza minimalista, entonces esto jugará a tu favor. Si no es así, tendrá que encontrar el equilibrio adecuado entre apariencia y rendimiento. En caso de duda, hay que dar prioridad al rendimiento. Fiel al lema "¿Es esto arte, o puede ir?".
En última instancia, lo que quieres es crear una aplicación potente que tenga buen aspecto, no una obra de arte inútil. La apariencia no lo es todo.
No se trata de los coches, sino de los ajustes automáticos de los elementos, por ejemplo, la altura o anchura automáticas de un contenedor. Esta configuración le cuesta rendimiento, porque calcularla requiere capacidad. Puedes aliviar a tu navegador de este trabajo trabajando con dimensiones absolutas, por ejemplo, height: 150px en lugar de height: auto. Lo mismo se aplica a un número fijo de filas o columnas en una tabla, por ejemplo. Los números fijos requerirán menos capacidad que un número relativo que aún hay que calcular. Por supuesto, esta no es siempre la mejor solución. Pero si es una opción que funciona, hay que favorecerla. Siempre teniendo en cuenta la capacidad de respuesta de la aplicación, por supuesto.
Sigamos con el diseño. Las animaciones son una parte importante del aspecto de un sitio web o una aplicación. A veces tienen un factor de frescura decisivo. Pero, como ya te habrás imaginado, esta frescura tiene un precio: comprometer el rendimiento.
¿Qué es absolutamente necesario y qué es sólo un detalle? Cualquier efecto de bamboleo en un botón reducirá su rendimiento. Y seamos sinceros: a nadie le gustan los botones que se tambalean.
Como acabas de aprender, la apariencia no lo es todo. Los valores internos también son importantes. Y cuando se trata de estos valores internos, realmente importa si son 3,5 megabytes o 40 kilobytes, por ejemplo (recuerda: 1000 kilobytes es 1 megabyte).
Hablamos del tamaño de los archivos. Esto se aplica a todos los tipos de archivos multimedia que cargue. Suelen ser imágenes, logotipos, vídeos, GIF o archivos descargables, por ejemplo, en formato PDF.
Comprime siempre estos archivos antes de subirlos. Hay muchos servicios gratuitos en línea para ello, como compresspng.com. Para imágenes y logotipos, también es recomendable utilizar formatos de archivo pequeños, como SVG o WebP, desarrollado por Google.
Hay elementos en los que se desea que la visibilidad dependa de diversos factores. Sin embargo, para mejorar el rendimiento de tu aplicación, deberías pensar en términos de presencia más que de visibilidad. Esto significa que no deberías cargar primero ciertos elementos que tienen visibilidad condicional y establecerlos como no visibles, sino no renderizarlos en absoluto.
Si, por ejemplo, tienes diferentes vistas de un elemento para diferentes grupos de usuarios (vista de administrador, vista de visitante, etc.), puedes evitar que se carguen todas las vistas pero que sean invisibles vinculando el renderizado a la condición de usuario. Entonces no cargue ciertos elementos en absoluto.
Lo mismo se aplica a los datos, por supuesto. Si necesitas acceder a datos, asegúrate de cargar sólo los que necesites en lugar de cargar todos los datos y filtrarlos después. Esto no sólo tiene la ventaja de mejorar el rendimiento, sino también la protección de los datos. Porque incluso si ciertos datos no son visibles en el frontend, puede ser posible encontrarlos en el código fuente si se han cargado y no se han tomado precauciones de seguridad.
Por ejemplo, puede utilizar las condiciones "Sólo cuando" antes de recuperar los datos del back-end. La alternativa más lenta sería recuperar todos los datos y luego filtrarlos.
Ya que estamos en el tema.
La carga de datos es lo que suele consumir más potencia de cálculo. Por lo tanto, las mejoras aplicadas a la carga de datos tendrán el mayor impacto en el rendimiento de tu aplicación. En pocas palabras, tienes que asegurarte de que solo cargas los datos que necesitas en ese momento concreto de la página.
Los datos se almacenan en el back-end y por eso puedes hacer ajustes relevantes para el rendimiento allí para aumentar el rendimiento de tu aplicación. En primer lugar, está el factor de la base de datos que elijas y cómo estructures tu base de datos. Pero eso es un tema en sí mismo.
Si ya lo ha hecho, puede, por ejemplo, asegurarse de optimizar el punto final de la API que recupera los datos de su back-end. El objetivo principal es reducir al mínimo el volumen de datos que se envían al front-end. Envíe únicamente las columnas o campos que necesite para la operación en cuestión.
Con una herramienta como Bubble, que no requiere necesariamente un back-end externo en comparación con WeWeb, las cosas pueden ser un poco diferentes. Allí no necesitas una API, sino que puedes comunicarte directamente con la propia base de datos de Bubble a través del editor. En este caso, sin embargo, la forma en que expresas tus comandos es relevante. Por ejemplo, si selecciona "Hacer una búsqueda de" o "Lista de", hay una diferencia. He aquí una versión abreviada:
"Lista de" es útil para listas cortas. Por ejemplo, si desea mostrar los colores favoritos de los usuarios, utilice "Lista de". En este caso, la expresión podría ser "Lista de colores favoritos del usuario actual". Las listas con pocas entradas (1-30) pueden cargarse más rápidamente.
"Hacer una búsqueda de" es útil para listas largas. Por ejemplo, si desea mostrar el historial de compras de un usuario, utilice "Hacer una búsqueda de". La expresión podría ser entonces: "Hacer una búsqueda de compras" + la condición de que el comprador = usuario actual.
Las operaciones de unión recuperan datos de dos o más tablas basándose en un campo común. El resultado es una tabla de resultados que combina datos de varias tablas. Hacer esto cuesta rendimiento. Puede que no importe con 3 tablas y 1.000 registros, pero si desea escalar, podría marcar la diferencia.
Así que evite estos asesinos del rendimiento siempre que pueda. Si puede mostrar la información en una sola tabla o recuperar los datos necesarios por separado, hágalo. Utilice las operaciones de unión sólo cuando sea absolutamente necesario.
Por ejemplo, si rellena un grupo repetitivo con datos en Bubble o desea mostrar una colección en WeWeb, los datos se cargan por defecto aunque lo configure como "display-none".
Por ello, para las páginas en las que el rendimiento es especialmente crítico, por ejemplo, cuando se trata de tablas de gran tamaño, es aconsejable vincular el proceso de carga de las colecciones de datos a la interacción del usuario. En este caso, los datos sólo se cargan cuando es necesario y no automáticamente. Por ejemplo, una tabla sólo se carga cuando el usuario se desplaza hasta ella o hace clic en un botón "Ver datos". En WeWeb tiene la opción de renderizado condicional para esto.
Si tienes varias páginas en tu aplicación o, por ejemplo, una tabla en la que puedes cambiar de una página a otra, se plantea la cuestión de cuál es la mejor forma de cargar los datos para ello. Existen las siguientes opciones:
En este caso, todos los datos se cargan en el navegador y se muestran en las páginas correspondientes, incluso lo que no se ve. Esto es ideal para pequeñas cantidades de datos. Si hay muchos datos, el rendimiento se ralentiza enormemente o incluso se bloquea el navegador.
Desde una perspectiva UI/UX, puede seguir teniendo sentido crear una tabla larga en lugar de utilizar diferentes páginas, por ejemplo. Sin embargo, esto debe hacerse siempre teniendo en cuenta la reducción del rendimiento.
Una buena forma de reducir el tiempo de carga es utilizar un lazy load. Con un lazy load, sólo se cargan los datos que están en la parte del navegador visible para el usuario. Si éste se desplaza hacia abajo, se cargan más datos. Las cargas perezosas son especialmente adecuadas para imágenes o tablas de carga intensiva que no son visibles inmediatamente.
En este caso, todos los datos necesarios se cargan en el navegador, pero sólo se muestra lo que debe ser visible. Esto ralentiza la carga inicial de la página, pero cuando los usuarios cambian a otra subpágina o página de tabla, los datos son rápidamente visibles porque ya se han cargado.
Aquí sólo se cargan los datos que se van a mostrar. Esto acelera la carga inicial, pero ralentiza la carga entre páginas. No obstante, suele ser la mejor opción para minimizar la percepción de los tiempos de carga.
Los cargadores esqueleto son marcadores visuales que los usuarios ven mientras se cargan los datos reales. El objetivo no es aumentar el rendimiento, sino mejorar la experiencia del usuario.
Puede que la aplicación móvil de LinkedIn te resulte familiar. Si la abres, al principio solo verás "caparazones" grises de lo que se muestra en cuanto se dispone de los datos necesarios.
A menudo se animan discretamente con un efecto pulsante o similar. El esqueleto, incluida la animación, permite al usuario saber que algo está ocurriendo y, en nuestra opinión, causa mejor impresión que los clásicos iconos de carga.
Eneste tuit, Gregory John de Buildcamp explica cómo puedes incorporar cargadores de esqueletos en tu propia app de burbujas.
Como ya hemos dicho, esta lista no es exhaustiva y, desde luego, no es la guía 100% correcta para todas las aplicaciones. Así que nuestro último consejo es: pruébalo. Todo lo que necesitas son dos versiones de una aplicación o página que quieras probar y un buen cronómetro. A continuación, pruébalas en distintos navegadores y dispositivos. O bien saldrá un claro ganador, o bien aprenderás algo sobre cómo se comportan ciertas personalizaciones con diferentes intervenciones (navegadores, dispositivos).
Esperamos que estos consejos te ayuden a convertir tu proyecto paralelo sin código en una aplicación potente que pueda competir con Airbnb, Facebook y similares, en términos de rendimiento e incluso de ingresos.
Así que si tienes alguna pregunta sobre tu proyecto, ¡no dudes en escribirnos! Únete a nuestra comunidad Slack. Más de 750 entusiastas del no-código te esperan a ti y a tus preguntas.
O reserve una llamada con nosotros. Quizá podamos ayudarle a realizar y ampliar su próximo proyecto.
