El proceso de un navegador web que convierte HTML, CSS y JavaScript en una representación visual terminada es bastante complejo e implica un poco de magia. A continuación, se muestra un conjunto simplificado de pasos por los que pasa el navegador:
- El navegador crea DOM y CSSOM.
- El navegador crea el árbol de renderizado, donde se tienen en cuenta el DOM y los estilos del CSSOM (
display: noneelementos se evitan). - El navegador calcula la geometría del diseño y sus elementos basándose en el árbol de renderizado.
- El navegador pinta píxel a píxel para crear la representación visual que vemos en la pantalla.
En este artículo, me gustaría centrarme en la última parte: cuadro.
Todos esos pasos combinados son mucho trabajo para que un navegador lo haga en la carga … y en realidad, no solo en la carga, sino cada vez que se cambia el DOM (o CSSOM). Es por eso que muchos desarrolladores web tienden a resolver esto parcialmente mediante el uso de algún tipo de marco de interfaz, como React, que, además de muchas otras ventajas, puede ayudar a optimizar en gran medida los cambios en el DOM para evitar recalcular o renderizar innecesarios.
Es posible que haya escuchado términos como Expresar, renderizado de componentes, o inmutabilidad. Todos ellos tienen algo que ver con la optimización de los cambios de DOM, o en otras palabras, solo hacer cambios en el DOM cuando sea necesario.
Para dar un ejemplo, el estado de una aplicación web puede cambiar y eso daría lugar a un cambio en la interfaz de usuario. Sin embargo, algunos (o muchos) componentes no se ven afectados por este cambio. Lo que React ayuda a hacer es limitar la escritura en el DOM para los elementos que realmente se ven afectados por un cambio de estado y, en última instancia, limitar la representación a la parte más pequeña posible de la aplicación web:
DOM/CSSOM → render tree → layout → paintingSin embargo, la pintura del navegador es especial a su manera, ya que puede suceder incluso sin ningún cambio en el DOM y / o CSSOM.
Ejemplo de resumen de rendimiento de la página
El diagrama anterior se generó utilizando el panel de rendimiento de Chrome en DevTools (más sobre eso más adelante) y muestra cuánto tiempo tomó cada tarea en el navegador en el tiempo registrado (0-7.12s) después de volver a cargar una página. Como puede ver, la pintura tiene un papel importante, y eso no es automáticamente algo malo. En este ejemplo en particular, el aumento de la pintura se debe a una combinación de GIF animados en la página y el dibujo del lienzo (a 60 fps), donde ambos no causan ningún cambio en el DOM o sus estilos, mientras siguen activando la pintura.
Otro buen ejemplo de una característica que puede causar pintura sin ninguna intervención externa es el CSS animation propiedad, y en comparación con el GIF animado o el lienzo, probablemente sea más común en la web. Por lo general, una animación se activa mediante la entrada del usuario, como al pasar el mouse, pero gracias a animation y @keyframes reglas, incluso podemos crear animaciones bastante complejas que se ejecutan constantemente en la página sin mucho esfuerzo, lo cual es bastante sorprendente.
Lo que algunos tal vez no se den cuenta es que esas animaciones pueden salirse de control fácilmente y activar constantemente la pintura, y eso puede costarnos una gran cantidad de capacidad de procesamiento. Por supuesto, existen algunas reglas que se pueden utilizar para evitar pintar. Lo más obvio es limitar la manipulación de elementos a CSS transform y opacity properties, que de forma predeterminada no activan la pintura, a menos que existan circunstancias especiales, como la animación de una ruta SVG.
Pintura parpadeante
Probablemente sepa que Chrome tiene DevTools. Lo que quizás no conozca es un pequeño atajo (Shift + Cmd + P en Mac o Control + Shift + P en PC) que se puede usar dentro de DevTools para abrir una pequeña barra de búsqueda y un menú de comandos.
Menú de comando
Empecé a investigarlo y, además de muchas otras opciones útiles e increíblemente interesantes, un panel de renderizado llamó mi atención.
Panel de renderizado
A primera vista, puedes ver algunas opciones interesantes que pueden ser muy útiles a la hora de depurar animaciones en la web, como un medidor de FPS.
Medidor de FPS
Bordes de capa y pintura parpadeante también son herramientas interesantes. Bordes de capa se utilizan para mostrar los bordes de las capas a medida que el navegador los renderiza, de modo que cualquier transformación o cambio de tamaño sea fácilmente reconocible. Pintura parpadeante sirve para resaltar áreas de la página web donde el navegador se ve obligado a volver a pintar.
Pintura parpadeante
Después de descubrir el destello de pintura, lo primero que hice fue comprobarlo en un proyecto mío. En la mayoría de los lugares, no hubo problemas. Por ejemplo, cualquier movimiento provocado por el desplazamiento en el sitio web fue impulsado por CSS transform propiedad, que, como mencionamos, no causa pintura. La pintura estaba presente donde uno esperaría que estuviera, como cambios en el color del texto al pasar el mouse, pero eso no es algo que deba ser motivo de gran preocupación debido a su área y presencia solo al pasar el mouse por encima del elemento. En resumen, siempre puedes encontrar algo para mejorar, incluso si escribiste el código ayer …
Pero una cosa fue una bofetada en la cara.
No importa cuán experimentado o cuidadoso sea, puede, y probablemente lo hará, cometer un error. Somos solo personas y algunos dirían que corregir sus propios errores es la mayor parte del trabajo cuando se trata de desarrollo. Sin embargo, para que se pueda solucionar un error, debemos ser conscientes de ello … y ahí es exactamente donde ayuda el panel de renderizado.
Caso de estudio
Echemos un vistazo más de cerca al problema real. El diseño vino con la solicitud de un fondo ruidoso. Ese tipo de efecto que tenían los televisores viejos cuando no había señal.
Se sabe que los GIF tienen muchos problemas, donde el rendimiento es sin duda uno de ellos, por lo que definitivamente no podría usarlo para el fondo de una página completa. Si desea leer un poco más sobre por qué evitar los GIF, aquí hay un buen recurso con un montón de razones.
Usar JavaScript es definitivamente una opción en este caso. Mostrar u ocultar elementos con un fondo ligeramente movido fue lo primero que me vino a la mente, y el uso de lienzos también podría ayudar. Sin embargo, todo esto parecía un poco exagerado simplemente por tener un trasfondo. Decidí optar por un enfoque solo de CSS.
Mi solución fue tomar una pequeña imagen PNG “ruidosa” como un background-image, permitir background-repeat y tírelo sobre un fondo de un solo color. ¿Cómo logré el efecto de ruido? ¡Con animación CSS infinita! Al establecer el background-position a un valor diferente durante el período de 200 milisegundos. Así es como resultó eso:
Vea el Pen MXoddr de Georgy Marchuk (@gmrchk) en CodePen.
¿Puedes adivinar el problema? Me pareció una solución bastante elegante, y estaba emocionado por mi logro de hacerlo sin un GIF de mierda y ni siquiera una sola línea de JavaScript. Solo CSS simple que está optimizado en los navegadores en estos días.
Bueno, el destello de pintura mostró algo completamente diferente. La capa del tamaño de la ventana se estaba repintando constantemente, sin que el usuario hiciera nada. Puede ver la pintura parpadeando en la demostración anterior si la habilita en el panel de renderizado (tenga en cuenta que la pintura parpadeante no aparece en el lápiz incrustado).
Sin tapajuntas de pintura (izquierda) vs.con tapajuntas de pintura (derecha)
Eso ciertamente no juega bien con el rendimiento del sitio web y agota las baterías de las computadoras portátiles como si no hubiera un mañana.
Uso de CPU para la animación realizada con background-position (arriba) y transform (abajo)
Todo este uso de CPU podría haberse evitado reemplazando los cambios en background-position utilizando transform o opacity.
Vea el Pen XYOYGm de Georgy Marchuk (@gmrchk) en CodePen.
El problema
Llevo un tiempo haciendo desarrollo web y sabía muy bien que animar un fondo nunca es una buena idea. Esto se sintió como un error de novato. La gente comete errores … pero esa no es toda la historia. El sitio web era lento e incómodo de navegar. ¿Cómo me lo perdí?
Algo que ciertamente juega un papel importante es el hecho de que yo soy (y tú también puedes estarlo) un poco malcriado cuando se trata de equipos de desarrollo. Tengo una computadora potente y agradable para trabajar y acceso a Internet de alta velocidad. A menos que escribamos un código realmente malo, todo lo que escribimos funciona sin problemas en nuestros ojos. Pero ese no es siempre el caso de nuestros usuarios.
Un problema similar se aplica a muchas otras cosas, como el tamaño de la pantalla. Usando un poco de exageración, mientras desarrollamos en una pantalla de 27 ”con resolución 4K y obtenemos los diseños principalmente para 1920 × 1080, nuestros visitantes provienen principalmente de computadoras portátiles de 1366 × 768 y tienen un flujo de trabajo completamente diferente cuando se trata de usar una computadora.
Conclusión
Si bien este artículo comenzó como un artículo sobre pintura, su tema principal es mucho más sobre ser consciente del impacto que nuestro código tiene en el proceso de pintura o el rendimiento en general. Si bien la pintura sirve como un buen ejemplo de algo que puede ser problemático y que fácilmente se pasa por alto, el problema es más una desconexión entre el desarrollador y el usuario.
La web es un lugar de muchos entornos, donde el entorno del desarrollador es a menudo muy diferente al del usuario. Si bien no es necesario cambiar nuestras costumbres o cambiar a computadoras perezosas, definitivamente ayuda ver nuestro trabajo de la manera en que otros lo ven de vez en cuando. Mi sugerencia es: cuando llegues a casa del trabajo y tengas un poco de tiempo libre, intenta recoger tu vieja computadora y revisar allí tu trabajo, para acercarte un poco más a lo que experimentan tus usuarios.
Si no tiene este tipo de computadora, herramientas como el panel de renderizado pueden resultar muy útiles.