0
114
VisualizaçõesMejorar el rendimiento del sitio web que tiene muchas animaciones.
Hice un sitio web para reproducir música, usa muchas animaciones cuando presionas notas o reproduces una canción. Tengo problemas con el rendimiento, especialmente en dispositivos móviles, así que quería averiguar qué lo estaba causando. Pasé por la creación de perfiles usando Google Chrome y me dice que está sucediendo mucho Recalculate Style , y que 30 elementos se ven afectados cada vez. Intenté hacer que las animaciones tuvieran el mejor rendimiento posible, utilicé animaciones de escala de transformación y color de fondo, además agregué el accesorio will-change al elemento que tiene la mayoría de los cambios, con la esperanza de resolver problemas, pero no lo he hecho. No he podido ganar mucho.
Estaba pensando que tal vez el mayor problema podría ser con la animación del color de fondo, ya que eso causará un repintado a lo largo de la animación, pero aún no entiendo por qué causaría un Recalculate Style . Aquí está el enlace para la versión beta del sitio web . Si alguien pudiera ayudarme a localizar el problema.
PD: para probar y hacer una prueba de estrés de la aplicación, descargue e importe esta canción aquí
Aquí hay algunos gráficos:
1 Respostas
Responde à pergunta0
Mirando el sitio web y las discusiones en los comentarios. Parece que la mayor parte de su problema de rendimiento se debe a la composición SVG cada vez que cambia la nota. La representación SVG en los navegadores en estos días es bastante rápida, pero aún no tan rápida como, por ejemplo, una representación PNG.
Se me ocurrieron dos opciones.
Cree todas las notas con los estilos establecidos y luego establezca la visibilidad. El único problema aquí es que no estoy seguro de si el navegador volverá a renderizar el SVG cuando entre o no esté visible. Tal vez una opacidad muy baja también podría ayudar aquí. Básicamente, tenga todos los estados de las notas con una posición absoluta una encima de la otra, el estado activo tendría una opacidad total, los demás una muy baja.
Cree dinámicamente los SVG en PNG para cada estado, luego podría simplemente voltear los PNG, lo que debería ser mucho más rápido que el SVG haciendo un redibujado cada vez.
Personalmente, me gusta la opción 1., pero solo necesitaré hacer algunas pruebas. Hacer transiciones de opacidad es ciertamente rápido y fluido en el navegador, por lo que es de esperar que el SVG no requiera volver a renderizarse. Digo opacidad muy baja, en caso de que el navegador vea una opacidad como 0, como equivalente a la visibilidad oculta, y decidió perder el lienzo de renderizado y hacer otro dibujo SVG cuando vuelva a ser visible. Una vez más, algunas pruebas aquí confirmarían.