Lista para la nueva generación de contenido web
Soy Chris Harrelson, líder de ingeniería de Renderización (transformación HTML y CSS en píxeles) en Blink. He estado en el campo del rendimiento de la renderización en la Web durante más de ocho años, con el objetivo personal de hacer todo lo posible para que entregar una UX excelente en la Web sea más rápida, fácil y confiable. Nos entusiasma contarte sobre lo que hicimos en ese tiempo para crear una nueva arquitectura de vanguardia para el motor de renderización de Chromium. Lograr esto fue un trabajo enorme de amor, y espero que disfrutes escucharlo.
En 2021, completaremos en gran medida el proceso de diseño, construcción y envío de esta arquitectura. La llamaremos RenderingNG, ya que es una arquitectura de renderización de nueva generación que supera considerablemente a la anterior. RenderingNG lleva al menos ocho años en desarrollo y representa el trabajo colectivo de muchos desarrolladores dedicados de Chromium. Descubre un gran potencial para la nueva generación de contenido web rápido, fluido, confiable, responsivo e interactivo. También es un modelo de referencia que creo que define un nuevo estándar mínimo para todos los motores de renderización web en el que pueden confiar los desarrolladores.
Esta entrada de blog es la primera de una serie, en la que explicaremos lo que creamos, por qué lo hicimos y cómo funciona. En esta primera publicación, comenzaré con lo siguiente:
- Nuestro objetivo de la estrella polar.
- La pirámide del éxito: principios que guían nuestro trabajo y ejemplos de esos principios en la práctica.
- Las funciones y capacidades que hace RenderingNG.
- Una descripción general de alto nivel de los principales componentes del proyecto de RenderingNG.
Estrella del norte
El objetivo principal que motiva a RenderingNG es que la implementación del motor del navegador y la riqueza de sus APIs de renderización no deben ser un factor limitante de la UX en la Web.
No deberías preocuparte por los errores del navegador que hagan que las funciones no sean confiables o que interrumpan la renderización de tu sitio.
No debería haber acantilados misteriosos. Además, no deberías tener que evitar las funciones integradas que faltan.
Debería funcionar.
Creo que RenderingNG es un gran paso para lograr este objetivo. Antes de RenderingNG, podíamos (y lo hicimos) agregar funciones de renderización y mejorar el rendimiento, pero teníamos dificultades para que esas funciones fueran confiables para los desarrolladores y había muchos obstáculos de rendimiento. Ahora tenemos una arquitectura que elimina sistemáticamente muchos de esos problemas y también desbloquea funciones avanzadas que antes no se consideraban viables. Por ejemplo:
- Tiene funciones principales sólidas en distintas combinaciones de plataformas, dispositivos y sistemas operativos.
- Tiene un rendimiento predecible y confiable.
- Maximiza el uso de las capacidades de hardware (núcleos, GPU, resolución de pantalla, frecuencias de actualización, APIs de trama de bajo nivel).
- Solo realiza el trabajo necesario para mostrar contenido visible.
- Ofrece compatibilidad integrada con patrones comunes de diseño visual, animación e interacción.
- Proporciona APIs de desarrollador para administrar con facilidad los costos de renderización.
- Proporciona puntos de extensión de la canalización de renderización para los complementos de desarrollador.
- Optimiza todo el contenido: HTML, CSS, lienzo 2D, lienzo 3D, imágenes, video y fuentes.
Comparación con otros motores de renderización de navegadores
Gecko y Webkit también implementaron la mayoría de las funciones arquitectónicas descritas en estas entradas de blog y, en algunos casos, las agregaron antes de Chromium. lo que es genial. Si bien cualquier navegador que sea más rápido y confiable es un motivo de celebración y un impacto real, el objetivo final es mejorar el modelo de referencia para todos los navegadores, de modo que los desarrolladores puedan confiar en él.
La pirámide del éxito
Mi filosofía es que el éxito es el resultado de primero lograr la confiabilidad, luego el rendimiento escalable y, por último, la extensibilidad.
Al igual que ocurre con las pirámides de la vida real, cada nivel proporciona una base sólida para el nivel superior.
Confiabilidad
Si queremos que haya experiencias del usuario enriquecidas y complejas, lo primero que necesitamos es una plataforma sólida. Las funciones principales y los fundamentos deben funcionar correctamente y seguir funcionando con el tiempo. Además, es importante que esas funciones se compongan bien y no tengan un comportamiento extraño de casos extremos o errores.
Por esta razón, la confiabilidad es la parte más importante de RenderingNG. La confiabilidad es el resultado de buenas pruebas, ciclos de reacción de calidad, métricas y
Para dar una idea de lo importante que es la confiabilidad, estuvimos la mayor parte de los últimos ocho años Primero, desarrollamos un gran conocimiento del sistema, es decir, aprendimos de los informes de errores en los que se encontraban los puntos débiles y los corrigimos, iniciamos pruebas integrales y comprendimos las necesidades de rendimiento de los sitios y las limitaciones de rendimiento de Chromium. Luego, diseñamos e implementamos de forma gradual y cuidadosa los patrones clave de diseño y las estructuras de datos. Solo entonces estábamos listos para agregar primitivas de última generación para el diseño responsivo, la escalabilidad y la personalización de la renderización.
Esto no quiere decir que, en ese tiempo, no se mejoró nada en Chromium. De hecho, sucede lo contrario. En esos años, hubo un aumento sostenido y sostenido en la confiabilidad y el rendimiento a medida que refactorizamos y lanzamos cada mejora paso a paso.
Pruebas y métricas
En los últimos 8 años, agregamos decenas de miles de pruebas de integración, rendimiento y unidades. Además, desarrollamos métricas integrales que miden muchos aspectos del comportamiento de la renderización de Chromium en pruebas locales, en comparativas de rendimiento y de forma local en sitios reales, con usuarios y dispositivos reales.
Sin embargo, independientemente de lo excelente que sea RenderingNG (o el motor de renderización de otro navegador, en realidad), no será fácil de desarrollar para la Web si hay muchos errores o diferencias en el comportamiento entre los navegadores. Para abordar este problema, también maximizamos el uso de las Pruebas de plataforma web. Cada una de estas pruebas verifica un patrón de uso de la plataforma web que todos los navegadores deben aprobar. También supervisamos de cerca las métricas para aprobar más pruebas con el tiempo y aumentar la compatibilidad de los núcleos.
Las pruebas de plataforma web son un esfuerzo colaborativo. Por ejemplo, los ingenieros de Chromium solo agregaron alrededor del 10% del total de pruebas de WPT para las funciones de CSS; otros proveedores de navegadores, colaboradores independientes y autores de especificaciones contribuyen con el resto. Se necesita toda una comunidad para crear la Web interoperable.
Buenos patrones de diseño de software
La entrega confiable de software de calidad es, a su vez, mucho más fácil si el código es fácil de entender y está diseñado de modo que se minimice la probabilidad de errores. Tendremos mucho más que decir sobre el diseño de software de RenderingNG en las siguientes entradas de blog.
Rendimiento escalable
Lograr un gran rendimiento, en las dimensiones de velocidad, memoria y uso de energía, es el siguiente aspecto más importante de RenderingNG. Queremos que las interacciones con todos los sitios web sean fluidas y responsivos, pero no sacrifiquen la estabilidad del dispositivo.
Pero no solo queremos rendimiento, también queremos rendimiento escalable, una arquitectura que funcione de manera confiable bien en máquinas de gama baja y alta y en todas las plataformas de SO. A esto lo llamo escalar verticalmente (aprovechar todo lo que el dispositivo de hardware puede lograr y reducir la escala) para maximizar la eficiencia y reducir la demanda del sistema cuando sea necesario.
Para lograrlo, necesitábamos hacer el máximo uso del almacenamiento en caché, el aislamiento de rendimiento y la aceleración de hardware de la GPU. Analicemos cada una de ellas. Para ser concreto, pensemos en cómo cada una de ellas contribuye al rendimiento de una interacción extremadamente importante en las páginas web: el desplazamiento.
Almacenar en caché
En una plataforma de IU interactiva y dinámica, como la Web, el almacenamiento en caché es la forma más importante de mejorar el rendimiento de forma drástica. El tipo de almacenamiento en caché más conocido en un navegador es la caché HTTP, pero el procesamiento también tiene muchas cachés. La caché más importante para el desplazamiento son las texturas de GPU y las listas de visualización en caché, que permiten que el desplazamiento sea extremadamente rápido, a la vez que minimiza el agotamiento de la batería y funciona bien en una variedad de dispositivos.
El almacenamiento en caché ayuda a la duración de la batería y a la velocidad de fotogramas de animación para el desplazamiento, pero lo más importante es que desbloquea el aislamiento de rendimiento del subproceso principal.
Aislamiento de rendimiento
En las computadoras de escritorio modernas, nunca tendrás que preocuparte por que las aplicaciones en segundo plano disminuyan la velocidad en la que estás trabajando. Esto se debe a la multitarea preventiva, que, a su vez, es una forma de aislamiento del rendimiento, es decir, asegurarse de que las tareas independientes no se ralenticen entre sí.
En la Web, el mejor ejemplo del aislamiento de rendimiento es el desplazamiento. Incluso en sitios web con mucho código JavaScript lento, el desplazamiento puede ser muy fluido, ya que se ejecuta en un subproceso diferente que no tiene que depender de JavaScript ni del subproceso de diseño. Nos esforzamos mucho en RenderingNG para asegurarnos de que cada desplazamiento posible esté en un subproceso, a través del almacenamiento en caché, que va mucho más allá de una lista de visualización a situaciones más complejas. Los ejemplos incluyen código para representar elementos de posición fija y fija, objetos de escucha de eventos pasivos y renderización de texto de alta calidad.
Aceleración de GPU
Una GPU permite que la generación de píxeles y el dibujo en la pantalla sea mucho más rápido. En muchos casos, cada píxel se puede dibujar en paralelo con cada otro píxel, lo que produce un enorme aumento de velocidad. Un componente clave de RenderingNG es la trama de GPU y dibujar en todas partes. De esta manera, se usa la GPU en todas las plataformas y en todos los dispositivos para acelerar de manera hiperacelerada la renderización y la animación del contenido web. Esto es especialmente importante en dispositivos de gama baja o muy alta, que suelen tener una GPU mucho más capaz que otras partes del dispositivo.
Extensibilidad: Las herramientas adecuadas para el trabajo
Una vez que tengamos la confiabilidad y el rendimiento escalable, estamos listos para compilar sobre una serie de herramientas que ayudarán a los desarrolladores a extender las partes integradas de HTML, CSS y Canvas, y de maneras que no sacrifiquen nada de ese rendimiento y confiabilidad tan difícil.
Esto incluye APIs integradas y expuestas en JavaScript para casos de uso avanzados de diseño responsivo, renderización progresiva, fluidez y capacidad de respuesta, y renderización de subprocesos.
Las siguientes APIs web abiertas, impulsadas por Chromium, fueron posibles gracias a RenderingNG y, anteriormente, se consideraban inviables.
Todos se desarrollaron con especificaciones abiertas y colaboración con socios de la Web abierta, ingenieros de otros navegadores, expertos y desarrolladores web. En entradas de blog posteriores, profundizaremos en cada una de ellas y explicaremos cómo las hace posible RenderingNG.
- content-visibility: Permite que los sitios eviten fácilmente el trabajo de renderización del contenido fuera de pantalla y que el procesamiento de caché para las vistas de aplicaciones de una sola página que no se muestran actualmente.
- OffscreenCanvas: Permite que el procesamiento de lienzo (tanto la API de lienzo 2D como WebGL) se ejecute en su propio subproceso para obtener un rendimiento excelente de manera confiable. Este proyecto también es otro hito importante para la Web; es la primera API web que permite que JavaScript (o WebAssembly) renderice un solo documento de página web desde varios subprocesos.
- Consultas de contenedores: Permiten que un solo componente se diseñe de manera responsiva, lo que desbloquea un universo completo de componentes listos para usar (actualmente, una implementación experimental).
- Aislamiento de origen: Permite que los sitios opten por un mayor aislamiento de rendimiento entre los iframes.
- Trabajos de pintura del subproceso principal: Proporcionan a los desarrolladores una forma de extender la forma en que se pintan los elementos, con código que se ejecuta en el subproceso compositor.
Además de las APIs web explícitas, RenderingNG nos permitió ofrecer varias "funciones automáticas" muy importantes que benefician a todos los sitios:
- Aislamiento de sitios: Coloca iframes de origen cruzado en diferentes procesos de la CPU para mejorar la seguridad y el aislamiento del rendimiento.
- Vulkan, D3D12 y Metal: Aprovecha las APIs de nivel inferior que usan GPU de manera más eficiente que OpenGL.
- Más animaciones compuestas: SVG, color de fondo.
Entre las próximas funciones adicionales que desbloqueamos con RenderingNG, nos entusiasman incluir las siguientes:
- Animaciones vinculadas a desplazamientos.
- DOM oculto, pero accesible y fácil de buscar.
- Transiciones de elementos compartidos.
- Diseño personalizado
- Composición fuera del subproceso principal; separación de subprocesos y composición
Proyectos clave que componen RenderingNG
A continuación, se muestra una lista de los proyectos clave de RenderingNG. En las entradas de blog posteriores, se profundizará en cada una de ellas.
CompositeAfterPaint
Dispara la composición del estilo, el diseño y la pintura, lo que permite mejorar la confiabilidad y el rendimiento predecible, aumentar la capacidad de procesamiento y usar menos memoria sin sacrificar el rendimiento. Comenzó en 2014 y finalizará este año.
| Año | Progreso |
|---|---|
| 2015 | Enviar listas de visualización. |
| 2017 | Envía una nueva invalidación. |
| 2018 | Árboles de propiedad de barcos (parte 1). |
| 2019 | Árboles de propiedad de barcos (parte 2). |
| 2021 | Se completó el envío del proyecto. |
LayoutNG
Una reescritura desde cero de todos los algoritmos de diseño para mejorar en gran medida la confiabilidad y el rendimiento más predecible Comenzó en 2016 y planeamos terminar este año.
| Año | Progreso |
|---|---|
| 2019 | Flujo del bloque de la nave |
| 2020 | Nave flexible y edita. |
| 2021 | Envía todo lo demás. |
BlinkNG
Una limpieza y refactorización sistemáticas del motor de renderización de Blink en fases de canalización bien separadas. Esto permite un mejor almacenamiento en caché, mayor confiabilidad y funciones de reentrantes o de renderización retrasada, como la visibilidad del contenido y las consultas de contenedores. Comenzó en 2014 y mejoró progresivamente, y sigue siendo una práctica desde entonces. Se completará en 2021.
Aceleración de GPU en todas partes
Es un esfuerzo a largo plazo para implementar la rasterización, el dibujo y la animación de GPU en todas las plataformas, todo el tiempo. La aceleración de GPU proporciona una aceleración enorme para la mayor parte del contenido, ya que cada píxel se puede procesar en paralelo. También es un método eficaz para mejorar el rendimiento en dispositivos de gama baja, que tienden a tener una GPU. Comenzó en 2014 y se completó en 2020.
| Año | Progreso |
|---|---|
| 2014 | Compatibilidad con lienzos. Se envía en el contenido habilitado en Android. |
| 2016 | Enviar en Mac. |
| 2017 | GPU se usa en más del 60% de las vistas de página de Android. |
| 2018 | Realiza envíos en Windows, ChromeOS y Android Go. |
| 2019 | Rasterización de GPU por subprocesos. |
| 2020 | Envía el contenido restante de Android. |
Desplazamiento por subprocesos, animaciones y decodificación
Es un esfuerzo a largo plazo para quitar del subproceso principal todas las animaciones de desplazamiento que no generan diseño y la decodificación de imágenes. Comenzó en 2011 y sigue en curso.
| Año | Progreso |
|---|---|
| 2011 | Compatibilidad inicial para animación y desplazamiento en subprocesos. |
| 2015 | Reducción de capas |
| 2016 | Desplazamiento de desbordamiento universal. |
| 2017 | La imagen se decodifica en el subproceso del compositor. |
| 2018 | Animaciones de imágenes en el subproceso del compositor. |
| 2020 | Siempre compuesta de posición fija. |
| 2021 | Animaciones de transformación de porcentaje, animaciones SVG. |
Visualización
Es un proceso centralizado de dibujo y trama para Chromium que aumenta la capacidad de procesamiento, optimiza la memoria y permite un uso óptimo de las capacidades de hardware. También ofrece otros beneficios menos visibles para los desarrolladores web, pero muy visibles para los usuarios, como desbloquear el aislamiento de sitios y separar la canalización de renderización de la renderización de la IU del navegador. Comenzó en 2016 y se completará en 2021.
| Año | Progreso |
|---|---|
| 2018 | OOP-R se envía en Android, Mac y Windows. |
| 2019 | Se envió la OOP-D. Envío OOP-R a todas partes (excepto Canvas). SkiaRenderer se envió en Linux. |
| 2020 | SkiaRenderer para Windows y Android. Vulkan se envió en Android. |
| 2021 | SkiaRenderer se envió en Mac (y pronto en ChromeOS). |
Definiciones de los términos de la tabla anterior:
- OOP-D
- Compositor de pantallas fuera del proceso. La composición de pantallas es el mismo tipo de actividad que un compositor de SO. Fuera de proceso significa hacerlo en el proceso de Viz, en lugar del proceso de renderización de la página web o el proceso de la IU del navegador.
- OOP-R
- La trama está fuera del proceso. La trama está convirtiendo las listas de visualización en píxeles. La opción Fuera de proceso implica realizar el proceso de Viz en lugar del proceso de renderización de la página web.
- SkiaRenderer
- Es una nueva implementación del compositor de pantalla que puede admitir la ejecución en una variedad de APIs de GPU subyacentes, como Vulkan, D3D12 o Metal.
Renderización de lienzo de subprocesos y acelerada
Este es el proyecto que puso en marcha las piezas arquitectónicas que hicieron posible OffscreenCanvas. Comenzó en 2015 y finalizará en 2021.
| Año | Progreso |
|---|---|
| 2018 | Envía el lienzo fuera de la pantalla. |
| 2019 | Envía ImageBitmapRenderingContext. |
| 2021 | Envía OOP-R. |
VideoNG
Un esfuerzo a largo plazo para ofrecer una reproducción de video eficiente, confiable y de alta calidad en la Web.
| Año | Progreso |
|---|---|
| 2014 | Se introdujo un framework de renderización basado en Mojo. |
| 2015 | Se enviaron Project Butter y superposiciones de video para lograr una renderización de videos más fluida. |
| 2016 | Envío de canalizaciones unificadas de procesamiento y decodificación para computadoras de escritorio y Android. |
| 2017 | HDR incluido y renderización de video con color corregido. |
| 2018 | Canalización de decodificación de video basada en Mojo que se envió. |
| 2019 | Canalización de procesamiento de video basada en la superficie enviada. |
| 2021 | Se envió compatibilidad con la renderización de contenido protegido en 4K en ChromeOS. |
Definiciones de los términos de la tabla anterior:
- Mojo
- Un subsistema de IPC de nueva generación para Chromium.
- Superficie
- Un concepto que forma parte del diseño del proyecto Viz.
Conclusión
Me entusiasma la tasa de mejora del procesamiento en la Web y en Chromium. Creo que el ritmo seguirá acelerando en los próximos años, ya que podemos compilar sobre la base sólida de RenderingNG.
No te pierdas las próximas publicaciones que brindarán más detalles sobre la nueva arquitectura, cómo surgió y cómo funciona.
Foto de dispositivos de Eirik Solheim en Unsplash
Ilustraciones de Una Kravets.