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

Convierte tus certificados en títulos universitarios en USA

Antes: $249

Currency
$209

Paga en 4 cuotas sin intereses

Paga en 4 cuotas sin intereses
Suscríbete

Termina en:

16 Días
20 Hrs
7 Min
9 Seg

¿Cuándo realmente un sitio es rápido o lento?

3/38
Recursos

Aportes 37

Preguntas 2

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Response: Dicta los tiempos ideales de respuesta a las acciones en la página web.
Animation: La duración ideal de las animaciones del sitio web.
Idle: Aprovechamiento de los tiempos muertos en el navegador
Load: El tiempo que tarda en cargar la página por completo

🚗 ¿Cuándo realmente un sitio es rápido o lento?

<h4>Ideas/conceptos claves</h4>

RAIL es un modelo de rendimiento centrado en el usuario que proporciona una estructura para pensar en el rendimiento. El modelo desglosa la experiencia del usuario en acciones clave (por ejemplo, tocar, desplazarse, cargar) y le ayuda a definir objetivos de rendimiento para cada uno de ellos.

<h4>Apuntes</h4> <h3>Rail Model</h3>
  • Response ⇒ Tiempos ideales en las cuales las acciones de nuestras paginas web deberían responder
  • Animation ⇒ Animaciones que el sitio web realiza
  • Idle ⇒ Tiempos muertos del navegador como ser cargar recursos que no son necesarios al momento
  • Load ⇒ Cuando tarda un sitio en cargar, una vez que el usuario ingrese a la URL del sitio

<h3>Tiempos de carga recomendados</h3>
  • Entre 0 a 300 milisegundos son perfectos 😄
  • desde 1000 milisegundos son buenos 🙂
  • Cuando tarda mas de 1500 milisegundos ya el usuario percibe que esta pasando algo malo 😐
  • luego de los 2 segundos todo es malo 🤨

RESUMEN: Cuando tenemos un sitio web lo importante es tener un limite que no exceda los 3 segundos de carga

Lazy load, es muy útil para aprovechar los tiempos muertos

Rapido 1 segundo, lento 5 segundos

RAIL es un modelo de rendimiento centrado en el usuario que proporciona una estructura para pensar en el rendimiento. El modelo desglosa la experiencia del usuario en acciones clave (por ejemplo, tocar, desplazarse, cargar) y le ayuda a definir objetivos de rendimiento para cada uno de ellos.

Leer Más

Entiendo la importancia de optimizar el sitio web, pero, ¿Que tanto puede influir la capacidad del servidor en la experiencia de usuario? Es decir, puedo tener el sitio web super optimizado pero si tengo un servidor compartido afectará mucho?

Lento: + 1.5 segundos
Aceptable: >1 - 1.5< segundo
Rápido: - 1 segundo

1 segundo: rápido.
1.5 segundos o más: “Esta cosa ya no funcionó, tal vez si presiono el muchas veces rápidamente funcione.”

creo que si toma más de 7 segundos ya el cliente se empieza a impacientar 🐢 , a mi me pasa

rápido 2s, lento 5s

Para mi lento es más de 5 segundos
Rápido menor a un segundo
Aunque en lo que carga una página que quiero ver siempre puedo ver otra.

rápido 3 segundos, lento más de 5 segundos

para mí lento es 5 segundos y 2 segundos es rapido

Rápido <1.5 seg, lento 3.5seg>

Para mi lento es 2 segundos o mas y rapido es menos de 2 segundos 😄

Un sitio es rápido si carga en menos de 2 segundos, si carga en más es lento para mí.

rápido 2 segundos, 7 segundos lento
Debo aprender a medir

La carga lenta es a partir de 5s, y rápido serían unos 2s

Rápido: 1s

Lento: 5s

Velocidad lenta: mas de 30 segundos.
Velocidad rapida: hasta 15 segundos.

Lento: 5 segundos
Rápido: 1 segundo

Hay un tiempo estándar que los cuatro pilares de RAIL manejan:
.

  • Entre 0 y 300 ms todo está bien 😁.
    Nuestros usuarios están felices con la velocidad de respuesta de nuestra página web.
    .

  • Entre 350 y 1.500 ms, no es lo mejor pero para el usuario sigue estando bien y tal vez no perciban que algo va lento en nuestro sitio 🙂.
    .

  • Más de 1.500 ms ya las cosas no están bien, ya que los usuarios ya perciben el tiempo no tan rápido de respuesta 🙁.

RAIL es un modelo propuesto por Google.
Este modelo se rige en cuatro pilares:

  • Response
    Cuáles son los tiempos ideales en los que nuestra página web debería responder. Tiempo de respuesta entre acción del usuario y respuesta de la página.
  • Animation
    Tiempo de carga de posibles animaciones en nuestro sitio.
  • Idle
    ¿Mi página web aprovecha los tiempos muertos del navegador?
    En estos tiempos muertos se me puede aprovechar para ejecutar tareas secundarias para el usuario.
  • Load
    ¿Cuánto tarda mi sitio en cargar? ¿Cuánto tarda en que la página se vea por completa?

Rápido 1 segundo o menos, será lenta si tarda 5 segundos o mas

2 segundos rapido 4.5 segundos tarda hasta mas, esta cosa ya q se presiona demasiado rapido el teclado ya no funciona 👌…

< 1 s - lento
> 1 s - rapido

Rapido 1 segundo, lento 4 segundos en cargar un sitio web

Antes de ver la respuesta del desafío:

Diría que rápido sería máximo 1 segundo y medio, más de eso diría que el usuario lo percibiría como lento.

Sin haber terminado la clase. Yo creo que rápido seria 2 segundo y lento seria 10 segundos.

Hola mi estimado. Una pregunta, el tiempo de respuesta del servidor TTFB depende solo de el hardware de este y de como esta compuesto el mismo, o también depende de nosotros y como hayamos optimizado las bases de datos del sitio?

Para mí rápido es menor a 2.5s y lento es de 5 s a más
tres a más es lento
<h4>¿Cuándo realmente un sitio es rápido o lento?</h4>

RAIL Model

  • Response: Cuáles son los tiempos ideales en los que las acciones de nuestra página web deberían responder. Ejemplo, al presionar un botón, ¿cuánto debería la página tardar en mostrar la información?
  • Animation: Animaciones que hace tu sitio web
  • Idle: Los tiempos muertos que tiene el navegador. ¿Los estoy aprovechando?
  • Load: ¿Cuánto tarda mi sitio en cargar?

Tiempo estándar:

  • 0 y 300ms ✅
  • 350ms y 1200ms ✔
  • 1500ms y 2000ms 💢
  • mayor que 2000ms ⛔❌🚫🆘‼

Rápido: 100ms o menos
Lento: 300ms o más

😊

RAIL model

  • Response. Cuales son los tiempos ideales de respuesta cuando yo, por ejemplo, presiono un botón.
  • Animación. Animaciones que hace tu sitio, estas llevan un tiempo en específico.
  • Idle. Tiempos muertos que tiene el navegador y como se aprovechan.
  • Load. EL tiempo que tarda en cargar.