La rapidez con la que se carga inicialmente su sitio web o aplicación es la primera impresión que obtienen sus usuarios. En esta guía, enumeraremos técnicas comprobadas para reducir valiosos segundos desde la carga inicial de la página.
Tabla de contenido
Tiempo de carga inicial
El tiempo que transcurre desde que su usuario o cliente ingresa el nombre de dominio de su sitio web hasta que ve el contenido son los segundos más importantes que tiene para causar una buena primera impresión.
Amazon descubrió que cada 100 milisegundos de latencia les cuesta un 1 % en ventas.
Y, sin embargo, muchos desarrolladores web tratan esto como una ocurrencia tardía. Se agregan más y más bibliotecas para más y más funciones y, gradualmente, con el tiempo, comienzan a ver menos conversiones. Peor aún, estas pérdidas en la conversión son difíciles de detectar porque abandonan una página de carga lenta antes de que tenga tiempo de enviar métricas.
Algunas de estas son técnicas que se pueden implementar en el front-end y otras en el back-end. Independientemente, las aplicaciones web deben cargarse rápidamente.
Agrega las medidas correctas
Lo primero que tienes que hacer es añadir medidas. Hay muchas etapas del proceso de carga y no sabrá dónde está el cuello de botella sin medir los segmentos correctos.
Los siguientes son los hitos más importantes del proceso de carga:
Medidas | Diagrama creado en Terraestructura
Lo que esto significa es que debe realizar un seguimiento de las métricas para cada segmento de este diagrama.
Veamos cómo podrías hacerlo.
Solicitud del navegador a la respuesta servida:
Mida esto en su servidor. Desea obtener el momento en que su API recibe la solicitud cuando entrega una respuesta. Dependiendo de si se realizan llamadas externas a, por ejemplo, bases de datos, esto puede ser muy corto o un cuello de botella significativo.
Respuesta servida a la respuesta recibida:
Esto es más difícil de medir, pero una forma de hacerlo es agregar una marca de tiempo cuando su respuesta sale de su servidor y medirla con la hora actual del lado del usuario en el primer momento posible (una etiqueta de secuencia de comandos en el encabezado del HTML página).
Respuesta recibida a la primera pintura con contenido:
La primera pintura con contenido se refiere a cuándo se representa el primer elemento en el DOM. Eso puede ser algo tan simple como un texto, un fondo o una rueda de carga. Esto se puede medir ejecutando Lighthouse en las herramientas de desarrollo de Chrome.
Primera pintura con contenido a pintura con contenido más grande:
La pintura con contenido más grande se refiere a cuándo se representa el elemento más grande en la ventana gráfica del navegador del usuario. Esto generalmente indica el final de la parte de «representación» de la carga de la página y el usuario ve una pantalla completa. Esto también se mide ejecutando Lighthouse.
Pintura con contenido más grande a tiempo para interactivo:
Finalmente, el tiempo de interacción se refiere a cuándo el usuario puede realizar acciones como desplazarse, hacer clic y escribir. Puede ser especialmente frustrante si esta duración es larga porque verán una pantalla renderizada frente a ellos, ¡pero no podrán hacer nada cuando esperan poder hacerlo! Esta es otra métrica que Lighthouse nos ayuda a medir.
Reducir código
Ahora que tiene medidas, puede comenzar a realizar optimizaciones. Las optimizaciones tienen ventajas y desventajas, y las medidas le dirán cuáles valen la pena.
La página más rápida para cargar es una página en blanco, pero se puede agregar una gran cantidad de código a una aplicación antes de que alguien pueda notar la diferencia en la velocidad de carga entre esta y una página en blanco. Lo que sucede a menudo es que los incrementos son tan pequeños que no percibe la diferencia de una construcción a otra hasta que un día, simplemente comienza a sentirse lento. Te das cuenta de que tu aplicación está inflada y es en este punto que reducir el código marcará la diferencia.
Obtiene dos mejoras en la velocidad cuando reduce el código:
- Su aplicación se transfiere a través de la red más rápido.
- El navegador del usuario termina de analizar el código más rápido.
La primera aceleración es pequeña; dado que las solicitudes se comprimen por cable, si corta 1 MB de código fuente, podría representar solo 10 KB de ahorro en ancho de banda. Sin embargo, la aceleración de analizar menos es significativa. Es probable que sus usuarios ejecuten su aplicación en una amplia gama de navegadores y computadoras, muchos de los cuales no tienen la potencia de cómputo que podría analizar el código tan rápido como lo hace por su cuenta.
O podrían ejecutarse en dispositivos móviles, con incluso menos poder de cómputo. La diferencia puede estar en la magnitud de los segundos.
Entonces, cuanto menos código tenga, más rápido el navegador puede terminar de analizar y comenzar a ejecutar su aplicación. Incluso si desea mostrar una pantalla de carga que controla Javascript, ha precedido el análisis de ese código.
Pero no desea cortar funciones ni eliminar código. Afortunadamente, hay un par de prácticas estándar para reducir el código sin tener que hacerlo.
- Ejecute su código a través de minificadores. Los minificadores realizan optimizaciones como acortar nombres largos en nombres cortos (signUpDarkModeButton se convierte en ss), eliminar espacios en blanco y otros para que su código sea lo más compacto posible sin perder nada.
- Importar parciales. Las bibliotecas a menudo están llenas de cosas que no necesita, pero vienen empaquetadas bajo un paquete general. Tal vez solo desee una función específica de una biblioteca de utilidades, por lo que en lugar de importar toda la biblioteca, puede importar solo el código que necesita.
- Código muerto de sacudidas de árboles. A veces, deja el código para fines de depuración o no ha limpiado a fondo una función obsoleta y, aunque está en su código fuente, nunca se ejecuta. Hay herramientas en la cadena de herramientas de JavaScript, como Webpack, que pueden detectar código muerto o dependencias no utilizadas y eliminarlos de la compilación de producción automáticamente.
Dividir código en fragmentos
Después de reducir la mayor cantidad de código posible de su aplicación general, puede pensar en exprimir aún más esta idea y reducir el código necesario para la carga inicial.
Digamos que el 20 % de su código activa alguna característica de su aplicación a la que los usuarios solo pueden acceder después de unos pocos clics. Sería una pérdida de tiempo que el navegador analizara ese código antes de mostrar una pantalla de carga. Dividir su código en partes puede reducir significativamente el tiempo de interacción.
En lugar de tener un gráfico de dependencia entrelazado de importaciones para todos sus archivos Javascript, identifique las áreas que se cortan fácilmente. Por ejemplo, tal vez un componente cargue algunas bibliotecas pesadas. Puede aislar ese componente en su propio archivo y luego solo importarlo cuando el usuario esté listo para interactuar con ese componente.
Existen varias bibliotecas para diferir la carga, según el marco que esté utilizando. No hay necesidad de exagerar con esto y dividir cada componente porque entonces el usuario tiene una carga inicial rápida y tiene que esperar en cada interacción posterior. Encuentre las piezas más grandes que pueda segmentar y divida su código fuente allí.
renderizado del lado del servidor
Dado que los navegadores necesitan hacer todo ese análisis y compilación intensivos y tener usuarios en Chromebooks y dispositivos móviles, una técnica común para reducir los tiempos de carga es hacer que sus servidores tomen parte de esa carga. Lo que esto significa es que en lugar de dar una página en blanco y luego usar Javascript para completar todo el contenido, como lo hacen la mayoría de las aplicaciones de una sola página en estos días, puede ejecutar un motor Javascript en su servidor (generalmente Node.js) y completar la mayor cantidad de datos y contenido que pueda.
Sus servidores serán mucho más rápidos y predecibles que los navegadores de los usuarios. Inevitablemente, aún necesitarán analizar algún código Javascript para que la aplicación sea interactiva. Aún así, la representación del lado del servidor puede completar gran parte del contenido inicial para que cuando el usuario obtenga la página, ya muestre una pantalla de carga o una barra de progreso como mínimo.
Y si se necesitan datos para la vista inicial, el cliente no necesita realizar una solicitud por separado para obtenerlos; ya estará hidratado en la aplicación para que el cliente lo use.
Comprimir activos
Los activos hacen que una página cobre vida y una página no se siente completamente cargada hasta que esos activos terminan de renderizarse. Este puede ser su fondo, los íconos de la interfaz de usuario, una imagen de perfil de usuario, incluso la rueda giratoria de carga. A menudo, los activos también pueden cambiar el diseño, por lo que si un usuario comienza a intentar interactuar con algo, la página puede continuar saltando mientras se cargan los activos. A veces, estos activos son la pintura de contenido más grande.
Pero los activos también son una de las partes más pesadas de una aplicación. Una imagen puede entrar en varios megabytes, y la carga de muchos íconos puede exceder fácilmente el límite máximo de solicitudes de red concurrentes del navegador, lo que provoca una cola asombrosa de carga.
Casi nunca desea descargar una imagen de Internet y luego hacer referencia a ella en su aplicación. Las imágenes deben redimensionarse a sus dimensiones más pequeñas posibles en las que se mostrarán. Si tiene un perfil de usuario que se muestra en un elemento diminuto de 50 píxeles por 50 píxeles, sin cambiar el tamaño, su aplicación se tomará el tiempo para descargar la imagen completa que se ve nítida como fondo de escritorio y luego la redimensionará al tamaño pequeño.
En segundo lugar, las imágenes se pueden comprimir según su formato. En estos días, webm es el formato preferido, pero el campo de la compresión en la web se mejora constantemente y hay muchos formatos nuevos en el horizonte. ¡Debido a la naturaleza cambiante de los formatos, es posible que algunos navegadores no admitan los más nuevos! Afortunadamente, la tecnología del navegador puede permitir que el navegador del usuario cargue cualquier formato que admita.
Por lo tanto, comprima al último y mejor formato, pero también mantenga una versión menos moderna y use elementos de imagen y video que admitan formatos alternativos.
Conclusión
Estas son cinco de las técnicas más efectivas para brindarles a sus usuarios una primera carga ultrarrápida en su aplicación. Esto mejorará sus tasas de conversión, la felicidad del usuario e incluso las clasificaciones de búsqueda, ya que el SEO recompensa los tiempos de carga rápidos. A Terraestructuraempleamos estas técnicas y más para que los usuarios puedan crear y ver los diagramas que ve en este artículo lo más rápido posible.