Entonces, ¿por qué importa si presentamos a nuestros usuarios con barras de carga? Bueno, resulta que después de 6 segundos de espera, tendemos a perder algo así como el 40% de nuestra audiencia que simplemente se va, no está dispuesta a esperar a que se cargue la página.
Entonces, cuando comenzamos una investigación sobre el tiempo de carga, ¿qué tipo de herramientas tenemos disponibles que pueden ayudarnos a investigar la optimización de los tiempos de carga? Bueno, como dije, incorporado directamente en el navegador, tienes algunas herramientas bastante avanzadas. En Chrome DevTools, tienes un par de pestañas. Tienes la pestaña de Red, que te muestra qué recursos está cargando Mi Juego, y luego tienes la pestaña de Performance que muestra cómo Mi Juego está cargando esos recursos. Entonces, cuando comienzas tu investigación, normalmente buscas las frutas más bajas. Si miras en la parte inferior izquierda de la pestaña del navegador, verás el número de solicitudes realizadas por el navegador. Verás la cantidad de data que se transfiere, y verás el tiempo que tarda en cargar tu juego. Ahora, lo primero que querrás hacer es ordenar la lista de recursos según su tamaño, porque, obviamente, cuanto más grande sea el recurso, mayores serán las oportunidades de optimización. Puedes buscar duplicados o recursos redundantes que tu juego realmente no debería estar cargando en primer lugar. Y si miramos el archivo más grande que se está cargando aquí en nuestro juego, es un jpeg de 2.2 megabytes. Entonces podemos preguntarnos, oye, ¿podemos reducir el tamaño de estos recursos? ¿Podemos optimizarlos de alguna manera?
Ahora, resulta que en los juegos HTML5, normalmente la mayoría de los data tienden a ser data basada en texturas. Y en nuestro ejemplo en la diapositiva anterior, teníamos un jpeg de 2.2 megabytes. Ahora, si el navegador descarga este archivo, necesitamos descomprimirlo en memoria. Y eso son 48 megabytes de data. Luego tenemos que pasarlo a WebGL para ser utilizado como textura. Y se hace una copia de él, además, tenemos que generar mitmaps, que son otros 64 megabytes de data. Así que juntos, eso son como 112 megabytes de data solo para un único jpeg. Ahora, si intentas cargar unos 10 de estos en una pestaña del navegador en móvil, te garantizo que harás que la pestaña se bloquee. Así que necesitamos algún tipo de solución para esto. Además, cada vez que recargamos un jpeg, tenemos que pagar, como, un costo de decodificación. Lleva tiempo descomprimir realmente los data del jpeg a un formato sin comprimir. Y en este caso, esta textura de 2 megabytes tarda 160 milisegundos, lo cual es simplemente excesivo. Porque va a hacer que el marco principal se bloquee, y va a causar largos tiempos de carga. Afortunadamente, tenemos compresión de texturas de hardware que podemos usar para cargar data de textura más optimizada. Entonces, si tomamos nuestro jpeg original de 2.2 megabytes y lo reducimos a algunos formatos de textura de hardware nativamente soportados como DXT, PVR y ETC, encontramos que los tamaños son en realidad más grandes que el jpeg original. Entonces, como el formato de esta compresión de textura de hardware data es nativo para la GPU, podemos simplemente suministrarlo a la GPU sin costo de decodificación, lo cual es genial. Además, la cantidad de memoria de la GPU utilizada por los formatos de data comprimidos de textura de hardware está entre 1 5th y 1 10th del jpeg original. Así que al menos estamos seguros de que no vamos a hacer que la pestaña del navegador se bloquee. Pero estamos pagando los costos por tener que descargar imágenes grandes. Y eso es un problema.
Comments