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

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Detectando Paints costosos y optimizando animaciones

12/38
Recursos

Aportes 17

Preguntas 5

Ordenar por:

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

.carousel-item:before {
  content: '';
  position: absolute;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
  border-radius: 20px;
  box-shadow: 0 2px 8px rgba(0, 0, 0, 1);
  opacity: 0.4;
  transition: 450ms opacity;
}

.carousel-item:hover:before {
  opacity: 1;
}

.carousel-item:hover + .carousel-item {
  transform: translateX(100px);
}

.carousel-item {
  will-change: transform;
  border-radius: 20px;
  position: relative;
  display: inline-block;
  width: 200px;
  height: 250px;
  margin-right: 10px;
  font-size: 20px;
  cursor: pointer;
  transition: 450ms all;
  transform-origin: center left;
}


Pueden usar el selector ~ para lograr que todos lo items que le siguen al item que esta en estado hover tengan el translateX y no solo el inmediatamente siguiente

👀 Detectando Paints costosos y optimizando animaciones

<h4>Recursos</h4>

opacity

transform

<h4>Apuntes</h4>
  • Este tipo de optimizaciones no es algo que se haga al inicio si no que, al momento de detectar el problema, procedemos con la optimización del lugar visto
  • Por lo general se trata de CSS y animaciones
  • Esto es bastante notable de percibir ya que nuestro sitio web va lento o las animaciones no van fluidas
  • Podemos medir los paints costosos con las dev tools en la sección en performance
  • Debemos tener siempre en mente que todas las propiedades que cambiarán serán costosas a excepción y el transform
  • Podemos preparar al navegador de futuros cambios con la propiedad will-change en CSS

RESUMEN: Podemos detectar paints costosos con las dev tools integradas de chrome. Tambien podemos reducirlas usando el concepto de Cualquier cambio en una propiedad que no sea opacity o transform genera un Paint y también usando la propiedad will-change de CSS

Si un sitio, ocupa en su código css propiedades con valores decimales. ejemplo= margin: 0.5rem 0.1rem 0.25rem 0;

Esta proporción decimal en el uso de medidas rem o em, influyen en el cargado de la página?, estoy pensando en como se comporta el calculo, para cada medida y cada elemento.
saludos!!=)

Y que pasa si mi JS tiene más ms que el paint y el render???

Si les aparece el error, es que al meterse a otra librería, tienen que descargar una versión de webpack:

npm i webpack@latest webpack-cli@latest webpack-dev-server@latest

Recomiendo esta extension de VSC css-triggers, es muy útil para identificar de manera visual el impacto de cada propiedad CSS en el render.

😊👍

realmente me impresiono lo que se optimizo con unos pocos cambios 😲

curso favorito y profesor favorita hehehe

<h4>Detectando Paints costosos y optimizando animaciones</h4>

will-change Sirve para decirle al navegador que algo cambiará y debe estar listo para optimizarlo.

Pagina para saber que tan costosa es la propiedad a animar
https://csstriggers.com/
Ejemplo:
Propiedad height
En cada uno de los motores de renderizado, podemos darnos cuenta por la imagen de abajo que requiere de los pasos de Layout, Paint y Composite, lo cual es bastante costoso.

Aquí está solo el código que el profesor hace en el navegador para seguirle el mismo ritmo 😃

.carousel-item:before {
  content: '';
  position: absolute;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
  /* background: #ff634770; */
  border-radius: 20px;
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.4);
}

👌

Waoo esto es sorprendente y es algo que no conocia ni de cerca

Según google traductor:
hover = flotar.

No lo sé si el ajuste del box-shadow le dé una mejor optimización a la página web, si se tuvo una reducción en el tiempo del painting en 2 ms pero al crear otro elemento y aplicarle estilos con css se aumento el rendering en 6 ms.

Eso da a entender que los elementos que se remplazaron, no se deberian de usar en el caso de hacerlo con un Hover. ?

Por que eso no lo comentan.