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 probadas para ahorrar valiosos segundos de la carga de la página inicial.
Tiempo de carga inicial
El tiempo que pasa 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 costaba 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 un 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.
Add the right measurements
Lo primero que debe hacer es agregar 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:
Lo que esto significa es que debería realizar un seguimiento de las métricas cada segmento de este diagrama.
Veamos cómo podrías hacer eso.
Solicitud de respuesta del navegador entregada:
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 atendida 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 salga de su servidor y medir eso con la hora actual del lado del usuario en el primer momento posible (una etiqueta de script en el encabezado del HTML página).
Respuesta recibida a la primera pintura con contenido:
La primera pintura con contenido es cuando el primer elemento se representa 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.
De la primera pintura con contenido a la pintura con contenido más grande:
La pintura con contenido más grande es cuando el elemento más grande se representa 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 interactuar:
Finalmente, el tiempo para interactuar 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.
Reduce code
Ahora que tiene las medidas, puede comenzar a realizar optimizaciones. Las optimizaciones tienen ventajas y desventajas y las mediciones 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 se percibe la diferencia de una construcción a otra hasta que un día comienza a sentirse lento. Te das cuenta de que tu aplicación está inflada y es en este punto cuando la reducción del 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 del análisis es importante. Es probable que sus usuarios estén ejecutando su aplicación en una amplia gama de navegadores y computadoras, muchos de los cuales no tienen la potencia informática necesaria para analizar el código tan rápido como lo hace usted mismo.
O podrían estar corriendo dispositivos móviles, con incluso menos potencia de cálculo. La diferencia puede estar en la magnitud de los segundos.
Por lo tanto, cuanto menos código tenga, más rápido podrá finalizar el análisis del navegador y comenzar a ejecutar su aplicación. Incluso si desea mostrar una pantalla de carga que controla Javascript, ha sido precedida por 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 nombres cortos y largos en nombres cortos (signUpDarkModeButton se convierte en ss), eliminan 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 tembloroso. A veces, deja el código con 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 el Cadena de herramientas de JavaScript, como Webpack, que puede detectar código muerto o dependencias no utilizadas y eliminarlas automáticamente de la compilación de producción.
Split code into chunks
Después de reducir tanto código como pueda 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 la 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 áreas de corte fácil. Por ejemplo, tal vez un componente cargue algunas bibliotecas pesadas. Puede aislar ese componente en su propio archivo y luego importarlo solo 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 a cada interacción posterior. Encuentre las piezas más grandes que pueda segmentar y divida su código fuente allí.
Server-side render
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 lo use el cliente.
Compress assets
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 iconos de la interfaz de usuario, una imagen de perfil de usuario, incluso la rueda de carga. A menudo, los recursos también pueden cambiar el diseño, por lo que si un usuario comienza a intentar interactuar con algo, es posible que la página continúe saltando mientras se cargan los recursos. A veces, estos recursos son la pintura con mayor contenido.
Pero los activos también son una de las partes más pesadas de una aplicación. Una imagen puede llegar a varios megabytes y cargar muchos iconos puede exceder fácilmente el límite máximo de solicitudes de red simultáneas del navegador, lo que genera una cola de carga asombrosa.
Casi nunca querrá descargar una imagen de Internet y luego hacer referencia a ella en su aplicación. Se debe cambiar el tamaño de las imágenes a las 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 dependiendo de su formato. 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 picture y video elementos que admiten formatos alternativos.
Conclusión
Estas son cinco de las técnicas más efectivas para brindar a sus usuarios una ultrarrápida primera carga en tu aplicación. Estos mejorarán sus tasas de conversión, la felicidad del usuario e incluso rankings de búsqueda, ya que el SEO recompensa los tiempos de carga rápidos. A Terraestructura, empleamos 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.
