Entendiendo el rendimiento

1

Todo lo que aprender谩s sobre optimizaci贸n web

2

驴Vale el esfuerzo optimizar un sitio web?

3

驴Cu谩ndo realmente un sitio es r谩pido o lento?

Antes de optimizar...

4

Aprendiendo a medir

5

User Performance Metrics

6

Nuestro proyecto

Cr铆tical Rendering Path

7

Etapas de render del navegador

8

Network waterfall y recursos que bloquean el navegador

9

Priorizaci贸n de recursos

10

Preloading y prefetching de recursos

11

Fases Paint y Layout del Critical Render Path

CSS

12

Detectando Paints costosos y optimizando animaciones

13

Bloqueos y complejidad en selectores

WebFonts

14

WebFonts y su impacto en rendimiento

Im谩genes, Iconos y SVG

15

Im谩genes, formato y compresi贸n

16

Im谩genes y compresi贸n

17

驴WebFont, Imagen o SVG?

18

T茅cnicas avanzadas con Lazy Loading

19

T茅cnicas avanzadas con Responsive Loading

Aplicaciones JavaScript

20

JavaScript y aplicaciones modernas y Utilizando un servidor de producci贸n

21

Analizando el bundle de la aplicaci贸n

22

Reduciendo el tama帽o del bundle

23

Code Splitting

24

Lazy Module Loading

25

Llevando los listeners a otro nivel

26

Instalando Modal video

27

Lazy loading del modal

28

Moviendo la carga de rendering hacia el servidor: Server Side Rendering

29

Aplicando SSR

30

Pre-renderizando el contenido: Static Generation

Cach茅

31

C贸mo funciona el Cach茅 de recursos y CDN

32

Deploy en Netlify y automatizaci贸n de contenido en GitHub Actions

33

Aplicando Github Actions

34

Interceptando los requests del navegador con Service Workers

Performance Budget

35

Performance budget y auditorias automatizadas

36

Automatizando una auditor铆a con Lighthouse CI

37

Medidas reales y monitoreo constante

Conclusiones

38

Conclusiones

Crea una cuenta o inicia sesi贸n

隆Contin煤a aprendiendo sin ning煤n costo! 脷nete y comienza a potenciar tu carrera

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Reg铆strate

Comienza en:

1D
4H
59M
37S

Aprendiendo a medir

4/38
Recursos

Aportes 13

Preguntas 0

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

馃搹 Aprendiendo a medir

<h4>Apuntes</h4>

lo que no mide, no se mejora

  • Rail Model:
    • Centrado en el usuario
    • M茅tricas de rendimiento basadas en la experiencia de usuario

Entregar el contenido y ser interactiva en menos de 5 segundos

  • Esta frase parcialmente es cierta por que debemos recordar que no todos los usuarios tendr谩n la misma velocidad de internet

Cumplir las m茅tricas para los usuarios del percentil 75%

  • No basta concentrarse en un numero concreto si no que consiste en dar un buen recorrido por todas la pagina

RESUMEN: Lo importante es dar una experiencia de usuario en TODO el sitio web.

Excelente, con esto he podido ver que recursos hace que se demore en cargar m谩s la p谩gina pero tambi茅n quiero que vaya cargando desde antes como mostr贸 en el ejemplo 馃

El curso de devtools es realmente una joya que deben tomar antes de este curso. Es mi opini贸n, espero les ayude (:

Usando DuckDuckGo鈥 Nada mal 馃槈

Lo que no se mide no se mejora

Herramientas principales para medir

  • Chrome DevTools
    • Pesta帽a de Network
    • Lighthouse

RAIL Model

  • Centrada en el usuario
  • M茅tricas de rendimiento basadas en la experiencia de usuario.

" Entregar el contenido y ser interactiva en menos de 5 segundos "

" Performance is about user experience "

En resumen, el performance es sobre la experiencia que le damos a nuestros usuarios en nuestros sitios web.

驴Qu茅 medimos?

.
El modelo RAIL est谩 centrado en el usuario, y por eso todas las m茅tricas que este modelo nos invita a tomar son m茅tricas que nos ayudan a medir la experiencia de usuario.
.
RECUERDEN: el 鈥減erformance鈥 es algo totalmente subjetivo, y por eso mismo es muy dif铆cil pornerle una medida a cada uno de ellos.
.
Seg煤n el modelo RAIL, hay que cumplir las m茅tricas para la mayor铆a de los usuarios, espec铆ficamente deber铆amos estar en el percentil en el n煤mero 75.
驴Qu茅 significa esto?
Significa que cuando tengamos todas las gr谩ficas de nuestros datos, y est茅n ordenados de menor a mayor, y al dividir entre cuatro partes esas gr谩ficas, al menos tres de esas cuatro partes deber铆an ser satisfactorias para la medida que estamos buscando.
.
驴Es suficiente medir el tiempo de carga?
Para esto hay que ver 鈥渓a experiencia de usuario鈥. El 鈥減erformance鈥 es sobre la experiencia de usuario. No basta solo con que nos enfoquemos unicamente en un n煤mero al finalizar; lo que m谩s importa es la experiencia que le estamos brindando a los usuarios en todo el tiempo de carga

.

Nosotros tenemos que garantizar que las optimizaciones y que las medidas que ofrecemos a todos nuestros usuarios sean igual de buenas.

Antes de optimizar, debemos MEDIR.
Sino medimos nuestros c贸digos, sino medimos nuestras p谩ginas, nunca vamos a saber si est谩 mejorando.
.

Lo que no se mide, no se mejora

.
Herramientas para medir
Chrome DevTools
Las dos pesta帽as que m谩s vamos a usar son:

  • Pesta帽a 鈥淣etwork鈥: esta pesta帽a es una de las m谩s importantes porque esta pesta帽a graba TODO lo que pasa entre tu computador e Internet. Podemos ver todos los 鈥渞equest鈥 que est谩 haciendo una p谩gina. Nos permite ver el peso de cada uno de los archivos, su prioridad y el 鈥渨aterfall鈥 (que es c贸mo cargan cada uno de los recursos)
  • Pesta帽a 鈥淟ighthouse鈥: es la que va a generar los reportes de c贸mo se est谩 comportando nuestro sitio en t茅rminos de 鈥減erformance鈥 (desempe帽o).

Creo que son muchas variables a considerar para hacer esta medici贸n; internet, tipo de internet, tel茅fono, tipo de tel茅fono, clima, zona (cobertura), tipo de usuario, etc.

Algo que nos ayuda mucho para que nuestros usuarios tengan una mejor experiencia y sepan que est谩 pasando algo tras bambalinas mientras por ejemplo cargan los recursos de una API son los loading skeletons. Dejo recurso por si le quieren echar una miradita.
https://platzi.com/blog/tutorial-como-crear-una-animacion-de-carga-de-contenido-tipo-facebook/

Baldra la Pena eston?馃檳

viendo la pesta帽a network me acabo de fijar que tengo 68 request y todos finalizan al tiempo, me motiva saber que se puede mejorar!!!

馃槉