Optimización de performance

por Ivo Mastrángelo

Introducción:

Este archivo contiene información que he investigado o es de mi

conocimiento acerca de la optimización de la performance en general, es
decir sin hacer demasiado hincapié en ningún framework o herramienta de
desarrollo.

Sin embargo yo no soy un profesional con demasiados años de experiencia

en el área de la programación, tampoco soy un tutor, ni escritor profesional, ni
creo que este archivo (que escribí en dos tardes en google docs) deba
usarse para dar enseñanza o ejemplo de nada.

Proceda con discreción.

1) ¿Que es performance?

El performance, hablando de desarrollo web, se refiere al grado de agilidad y

respuesta con que se desempeña un sitio web.

¿Por qué buscar una mejor performance en una App?

Cuando estás desarrollando proyectos personales para mostrar a una

empresa tus conocimientos, lo primero en lo que se piensa NO es en la
performance de la app, esto tiene sentido ya que la app esta diseñada para
ser un mostrador, no intenta escalar ni será demasiado compleja, eso está
bien ya que al mantener las apps simples vas a tener más tiempo para
estudiar nuevas tecnologías.

Entonces…
¿En qué momento se empieza a pensar en la performance de una App?

Todas las apps profesionales tienen como objetivo cubrir una necesidad,
resolver un problema y/o llamar la atención de los usuarios para que
permanezcan en ella el mayor tiempo posible, pero si una app tarda
demasiado tiempo en cargar el usuario se frustra y se va, todos tenemos
un límite de paciencia, pongamos un ejemplo para dar cuenta de ello:

Pensemos en la realidad un momento, comparemos a Facebook y a una

herramienta que puedas tener a mano, si estas en una computadora intenta
abrir la sección de volumen, esa del parlante, ¿Cuánto tarda en abrirse? Si es
la primera vez que la abrís desde que prendiste la computadora, seguro que
más o menos lo mismo que tarda toda tu página de Facebook en cargar
(o capaz más incluso). ¿Alguna vez te frustraste porque tardaba mucho en
abrir esa interfaz de volumen? Yo sí.

(Se habrá criticado mucho a la plataforma Facebook por su manejo de

información, pero lo que no se puede negar es su habilidad para resolver
problemas complejos y nunca antes vistos).

Esto es solo un ejemplo, no tiene que ser la interfaz del volumen, pensá en
los tiempos de carga de los juegos ¿Cuanto tiempo perdiste mirando la
pantalla de carga? , o pensá en Instagram, si su Feed o su apartado de
cámara, junto con las diversas opciones de photoshop, tardarían 10s en
cargar nadie usaría esa aplicación.

Conclusión:

Para los usuarios la performance de una app es importante, pero, lo

cierto es que estas tienen una tendencia a ser lentas, sobre todo cuando
escalan, es por eso que se deben seguir ciertas estrategias de mejora de
performance, de lo contrario una baja performance tendrá impacto
directo en la generación de clientes potenciales.

2) ¿Cómo mido la performance de una App?:

Para poder medir la performance se la divide en distintas “etapas” o “ciclos

de vida” (no confundirse con los ciclos de vida de Angular) y se aplica una
métrica de tiempo en milisegundos, si superan ese tiempo la app es lenta,
mientras menos milisegundos tarda en cargar mejor.

La razón por la que se hace esto es porque, la mayoría de Apps, últimamente

tienen una tendencia a renderizarse en forma de “waterfall” o “cascada”, es
decir se van cargando de a poco.

Para medir estos tiempos vas a necesitar usar herramientas de desarrollador

como Ir a “inspeccionar” y después a “Network”, existe una página llamada
WebPageTest.org que te puede ayudar con la medición, entre otras
herramientas necesarias, el mundo de la optimización es grande y vas a
necesitar varias para una correcta medición.

3) Ciclos de Vida:

TTFB o Time To First Byte:

El primer ciclo, cuando la aplicación comienza y está pidiendo datos al

backend o pintando su interfaz de usuario. Para medirlo podés elegir la
primera request de “Name” ( que está en “Network”, entras a su “Timing”.

En “Timing “ tendrás un apartado llamado “Waiting for server response”,

este es el tiempo que tarda el backend en enviar la data y cargarse la
página, si es menor a 600 ms la performance es “correcta” (aunque he
visto personas que afirman que más de medio segundo sin que la app no
muestre nada les parece “demasiado tiempo”). Normalmente esta métrica no
cambia tanto entre dispositivos.

NO TODAS LAS PETICIONES tienen que ser menores a 600 ms, solo la
primera, la que empezará mostrandolo todo.

FCP o First Contentful Paint:

(A partir de ahora las métricas cambiarán según el acceso al internet y el

rendimiento de los dispositivos.)
El tiempo que tarda en renderizar cualquier texto, imagen o video desde que
se hizo la petición de la página, debe durar menos de 1,8s y toma en cuenta
el tiempo pasado por el TTFB , es decir después del TTFB te quedarían 1.2s.
Un ejemplo de diferencia, entre esta etapa y la anterior, es Youtube, cuando
entras a Youtube ves que la interfaz está “pintada” pero los videos y el texto
no cargaron todavía, eso es porque no se completó el FCP.

Esta medición es sin dudas de las más importantes ya que al ser el inicio de
la App podría definir si la mayoría de usuarios deciden quedarse o no, si tarda
demasiado en cargar, los usuarios pensarán que está rota o se aburren de
esperar y se van, sin ver el contenido.

LCP o Largest Contentful Paint

Tiempo que tarda en renderizar la pieza de contenido “más grande” o pesada

del viewport, el cual suele tener un impacto visual importante en el usuario.
Tiene que ser menor a 2.5S

Usualmente es una imagen grande o un carrousel con diferentes imágenes o

videos.

Es uno de los 3 Web Vitals de Google.

SI o Speed Index:

Calcula cómo de rápido el contenido visual (solo el visual) se ha renderizado,

progresivamente, en el viewport. Para que exista este ciclo de vida, la página
tiene que seguir un efecto “waterfall”.

Menor a 2.5s.

FID o First Input Delay:

Mide el tiempo que tarda en responder la interfaz a la primera interacción del

usuario. El usuario tendrá una sensación positiva o negativa, dependiendo de
qué tan interactiva será la página.
Web Vital de interactividad de Google.

Menor a 100ms.

mFID o Max Potential First Input Delay:

Mide el máximo FID posible, es decir, de todas las posibilidades de su

primera interacción, ¿Cuál tarda más?.
Menor a 130 ms.

TBT o Total Blocking Time:

Es la suma de la duración de las tareas que superen los 50 ms, y que

obstruyan el hilo principal de la App, es decir, hasta que no carguen, no se
puede interactuar.

Menor a 200 ms.

TTI o Time To Interactive:

Tiempo en mostrar todo el contenido “útil”, donde la aplicación podrá

interactuar en su totalidad.

Menor a 3.8s.

CLS o Cumulative Layout Shift:

Mide los “saltos” que la página dio mientras cargaba. A veces cuando una
página es muy pesada carga en “waterfall” y su contenido cambia de lugar o
se agrega nuevo contenido.

Los “saltos” deben durar menos de 100 ms entre ellos.

4) Estrategias para mejorar la performance de una App:

Las estrategias son las siguientes:

a) Lazy Loading.
b) Three Shaking o Manejo de Bundles
c) Componentes dinámicos
d) Modo de producción.
e) Modo estricto.
f) Optimización de imágenes.
g) Buenas prácticas.

No tienen que ser todas, son las que yo conozco.

4 A) Lazy Loading:

Solo debe estar cargado aquello que se está viendo actualmente, no

solo imágenes o videos, también componentes, funcionalidades, etc.

En el caso de HTML5 se le agrega a la etiqueta: Loading=”lazy” a las

imágenes, los videos necesitan la etiqueta preload="none".

En cuanto a componentes hablo de eso en la sección de “componentes

dinámicos”.

No todo tiene que ser cargado de manera Lazy, abusar de esta estrategia
termina generando problemas de rendimiento ya que más cosas tendrán que
ser cargadas al mismo tiempo.

4B) Three Shaking o Manejo de Bundles:

Los Bundles son paquetes de código javascript, el three shaking es una

estrategia que trata sobre no importar toda una librería si no solo las
funciones que vas a necesitar, y también de no tener imports que al final no
están siendo utilizados (aunque algunos frameworks como Angular no los
cargan de ser así).

Al importar toda una librería la App puede hacerse muy pesada, para saber
cuánto pesa tu App en general y cada sección de ella en particular podés
hacer uso de source-map-explorer.

4C) Componentes Dinámicos:

Los componentes dinámicos, son componentes que no están definidos en el

tiempo de compilación de la aplicación , en el caso de Angular no usan un
template y no es necesario declararlos en el NGModule. Estos componentes se
instancian y se colocan en la aplicación en tiempo de ejecución.

Usualmente usas esta estrategia cuando el componente es considerado

“demasiado pesado”, o cuando es un componente que solo algunos usuarios, y no
todos, utilizan.

Unos ejemplos de cómo aplicarlo:

Para los componentes de Angular usas el siguiente formato en las rutas:

const routes: Routes = [

{
path: 'customers',
loadChildren: () =>
import('./customers/customers.module').then(m =>
m.CustomersModule)
},
];

React usa Lazy y Suspense, donde Suspense será el componente que se

mostrará en caso de que el “componente Lazy” no haya cargado.

(Existen muchas otras formas de hacer Lazy Loading)

Usar Lazy Loading también le dará a tu app una mayor seguridad, por
ejemplo si el primer componente de tu App es el Login o Register, hasta que
el usuario no se haya conectado no tendrá acceso al resto de los
componentes.
4D) Modo de producción con ng build:

El “modo de producción “ se activa con el comando ng Build, el cuál tendrá

los siguientes efectos:
- Three Shaking.
- Uglifying: Para evitar hackeos, todo el código se hace mas “feo” de
ver y analizar.
- Minification: Elimina espacios, intenta tirar todo el código a una sola
línea.
- Bundling: Genera un Bundle de la App, lo hace para poder medir el
peso y verificar que no pase un límite especificado.
- Modo de producción: Eliminará cualquier parte que tenga que ver
con chequeos o debugging de la aplicación, junto con todas las
demás aplicaciones que tengan como objetivo ayudar al
desarrollador.

4E) Modo estricto:

Se trata de una variante del lenguaje que es menos permisiva con

ciertos tipos de comportamientos en el código y que hace que éste se
comporte de un modo más estricto, como su propio nombre indica.

Al principio puede ser complicado desarrollar con el modo estricto, pero las
buenas prácticas del Ecmascript 6 ayudarán a la performance y a tu
conocimiento.

4G) Optimización de imágenes:

Además de ponerles la etiqueta Loading=”lazy”, otra buena práctica es la

compresión de imagen, pongamos por ejemplo que tenes una imagen de
2000 x 2000 pixeles, pero en tu App el ancho y la altura de la imagen serán
de 700 x 700 píxeles entonces podes usar un compresor de imagenes de
internet como TinyPng.com.
Estos son todos mis conocimientos en cuanto a performance al dia de la
fecha 20/1/2023

Este artículo fue escrito por Ivo Mastrángelo Desarrollador de software JR

LinkedIn: https://www.linkedin.com/in/ivo-valentin-mastrangelo-42270521b/.
GitHub: https://github.com/IvoVM.

¡Gracias por leer!