La evolución de Ladybird durante agosto no se mide únicamente en nuevas funciones visibles. El navegador también ha cambiado por dentro: ahora reproduce más formatos de vídeo, permite depurar JavaScript, recupera sesiones completas y dedica una parte creciente de su desarrollo a reducir el trabajo del motor.

El proyecto mantiene su objetivo: comenzar la primera versión alpha en 2026. Para llegar hasta ahí todavía quedan piezas importantes, pero el boletín de agosto muestra un navegador cada vez más capaz y una arquitectura que empieza a comportarse como la de un producto preparado para crecer.

Ladybird ya puede reproducir vídeo en Twitch

El salto más visible está en la reproducción multimedia. La implementación de Media Source Extensions incorporó soporte para MP4 fragmentado y para los códecs AVC —H.264—, HEVC —H.265—, AV1 y AAC.

Con estos cambios, Ladybird puede reproducir vídeo con bitrate adaptativo en más sitios, incluidos Twitch y Plex. También mejora la compatibilidad con YouTube: aunque la plataforma ya funcionaba mediante VP9 y Opus en WebM, algunos vídeos antiguos o menos populares ofrecen sus distintos niveles de calidad únicamente en AVC. Las resoluciones más altas, especialmente 8K, suelen utilizar AV1.

El equipo también corrigió varios fallos de reproducción. Las previsualizaciones de vídeo de YouTube ya no provocan cierres al pasar el cursor sobre ellas, los reproductores con `preload="none"` no se quedan bloqueados y los reproductores basados en HLS.js empiezan a reproducir correctamente.

DevTools incorpora depuración de JavaScript

Ladybird ya permite establecer puntos de interrupción, avanzar por el código línea a línea y evaluar expresiones de inspección desde las herramientas de desarrollo.

El flujo básico de depuración funciona, aunque todavía faltan la depuración de WebAssembly y los puntos de interrupción para mutaciones del DOM. La interfaz utilizada sigue siendo, de forma provisional, la interfaz de Firefox DevTools. El proyecto prevé construir una propia más adelante.

Para quienes desarrollan sitios web, este cambio tiene un efecto práctico: Ladybird deja de ser un navegador que únicamente sirve para comprobar si una página carga y empieza a ofrecer herramientas para investigar por qué falla.

Pausar una descarga y recuperar una sesión completa

Las descargas ahora pueden pausarse y reanudarse, siempre que el servidor lo permita. También sobreviven al reinicio del navegador y utilizan hasta cuatro conexiones paralelas cuando es posible.

La recuperación de pestañas ha recibido una mejora igual de útil. El atajo `Ctrl+Shift+T` ya no restaura únicamente la URL de una pestaña cerrada: recupera su historial completo, incluidos los estados de navegación hacia atrás y hacia delante. Esa información se conserva incluso después de reiniciar Ladybird.

La opción “Duplicar pestaña” también copia el historial de sesión. El navegador, eso sí, todavía no guarda los datos introducidos en formularios enviados. El equipo ha preferido dejar esa parte pendiente para tratarla con más cuidado.

CSS scroll snap y animaciones más fluidas

El soporte para CSS scroll snap añade `scroll-snap-type`, `scroll-snap-align` y `scroll-snap-stop`. El ajuste funciona con la rueda del ratón, el teclado, el desplazamiento de la barra, los gestos del panel táctil y las llamadas programáticas a `scrollTo()`.

Los carruseles y los desplazadores a pantalla completa dependen de estas propiedades. El desplazamiento mediante `scrollIntoView()` aún no activa el ajuste.

Ladybird también ha trasladado determinadas animaciones CSS fuera del hilo principal. Las animaciones de opacidad y transformación que cumplen los requisitos se entregan al compositor, que las ejecuta siguiendo su propio ciclo de sincronización.

Antes, una animación CSS podía despertar el hilo principal 60 veces por segundo para recalcular estilos, reconstruir el estado de pintura y generar una nueva lista de dibujo. Ahora el hilo principal no interviene mientras la animación está en marcha. El resultado esperado es una reproducción más fluida cuando JavaScript está ocupado y un menor consumo en páginas con muchas animaciones.

El rendimiento deja de ser una tarea ocasional

El equipo de Ladybird dedicó agosto a medir de forma continua el navegador y a investigar operaciones concretas que resultaban mucho más lentas que en Chromium.

En Speedometer 2, la puntuación pasó aproximadamente de 47 a 64. En Speedometer 3 subió de alrededor de 2,5 a 3,9. StyleBench registró el cambio más pronunciado: de unas 3,5 unidades a cerca de 83.

Las cifras siguen por debajo de las de los motores consolidados, pero algunas operaciones concretas mejoraron de forma notable. El análisis de `canvas fillStyle`, por ejemplo, redujo la diferencia frente a Chromium de unas 90 veces más lento a aproximadamente el doble. `replaceChildren()` pasó de 13 veces más lento a menos de cuatro, mientras que la inserción y eliminación de elementos de listas bajó de más de 120 veces a menos de 20.

El motor de JavaScript también incorporó rutas rápidas para el acceso a propiedades, el operador spread, los combinadores de promesas y `JSON.stringify`. En una de las pruebas, `JSON.stringify` quedó a aproximadamente un 15 % del rendimiento de V8. Otro ajuste permitió que Minecraft4k pasara de 10,2 a 14,5 fotogramas por segundo después de que los arrays que se volvían dispersos dejaran de permanecer indefinidamente en un almacenamiento lento basado en tablas hash.

Un nuevo motor de estilos para recalcular menos

Ladybird reemplazó su sistema de coincidencia de selectores, invalidación de estilos, cascada y almacenamiento de estilos calculados.

La idea es sencilla de describir y compleja de ejecutar: cuando cambia una parte del documento, el navegador debería trabajar sobre lo que realmente puede verse afectado, no sobre todo aquello que podría haber cambiado. El nuevo motor trata las mutaciones del DOM, los cambios de estado y las modificaciones del CSSOM como eventos tipados. Cada evento se dirige a los selectores relacionados y el proceso se detiene cuando el resultado no cambia.

Para comprobar que las optimizaciones no rompen la corrección, Ladybird mantiene una implementación de referencia sin cachés. Además, puede grabar la secuencia de eventos de una sesión real y reproducirla de forma determinista. Durante el desarrollo se han utilizado grabaciones de sitios reales con millones de eventos.

En StyleBench, el nuevo motor terminó agosto cerca de los motores principales. En un MacBook Pro con chip M3, la puntuación fue de 232,8 para Firefox, 129,5 para Safari, 116,3 para Ladybird y 103,8 para Chrome. Todavía quedan optimizaciones pendientes, pero la base técnica ya compite en una prueba centrada precisamente en el recálculo incremental de estilos.

Caché de layout para no rehacer páginas enteras

Hasta ahora, muchos cambios obligaban a volver a calcular el diseño completo del documento desde la ventana gráfica hacia abajo. Ladybird comenzó a reutilizar los resultados del layout mediante una caché basada en las restricciones de entrada.

Cada ejecución de un contexto de formato queda asociada al tipo de contexto, las restricciones de tamaño y el estado de su raíz. Si un subárbol no ha cambiado, el resultado completo puede reutilizarse, incluso en ejecuciones anidadas. Como las posiciones de los fragmentos son relativas a su bloque contenedor, ese subárbol puede reaparecer en una ubicación diferente sin repetir todo el cálculo.

El equipo también redujo las invalidaciones innecesarias en páginas con elementos flex anidados. Antes, una sola hoja podía medirse 29 veces durante un layout porque un ancestro resolvía su altura. Ahora Ladybird registra qué entradas observa realmente cada caja e ignora las que no influyen en ella.

Este trabajo, combinado con el nuevo motor de estilos, explica buena parte de la mejora de rendimiento registrada durante el mes.

Rust gana terreno en LibWeb

La migración de componentes de LibWeb a Rust avanzó en varias áreas. El análisis sintáctico de CSS pasó a Rust mediante un sistema de comparación entre los analizadores antiguo y nuevo. El código en C++ solo se eliminaba cuando ambos producían resultados idénticos en toda la batería de pruebas.

También se trasladaron a Rust el almacenamiento y el cálculo de estilos computados, así como la canalización de pintura, el registro de listas de dibujo y la comprobación de impactos. Las cadenas de texto comparten ahora una representación entre ambos lenguajes, lo que evita copias al cruzar esa frontera.

El cambio afecta a la arquitectura, pero también al rendimiento. El analizador CSS en Rust terminó siendo más rápido que el código C++ al que reemplazó.

Un servicio independiente para compilar WebAssembly

La compilación de WebAssembly se ejecutaba fuera del proceso de la página, pero cada proceso lanzaba su propio compilador. Esa estrategia chocaba con las restricciones del sandbox y podía provocar que Ladybird recurriera silenciosamente al intérprete.

El navegador ahora inicia un único servicio `WasmCompiler`, con su propio sandbox mínimo. Los procesos de las páginas se comunican con él mediante IPC y pierden el permiso para crear procesos de compilación por su cuenta.

La modificación endurece el aislamiento y acelera la carga en ciertos casos. El boletín la relaciona con la mejora observada en los mapas de Strava, que cargan aproximadamente en la mitad de tiempo durante una visita en frío.

Más límites frente a la corrupción de memoria

Ladybird amplió el sistema de protección de punteros en los valores JavaScript almacenados mediante NaN-boxing. El navegador ya había aplicado esta técnica a los contenidos de `ArrayBuffer` y a las memorias de WebAssembly; ahora también limita dónde pueden apuntar los punteros de celdas del recolector de basura.

Todos los bloques del heap gestionado se encuentran dentro de una región reservada. Los datos de las celdas se almacenan como desplazamientos dentro de esa región y se enmascaran al decodificarse. Un valor manipulado puede apuntar a una posición dentro del área permitida, pero no directamente a cualquier dirección de la memoria del proceso.

La protección no cubre por completo el heap de JavaScript. Sí reduce, en cambio, el alcance de un valor corrupto. El bytecode recién generado también se almacena en regiones de solo lectura, de modo que una corrupción del heap no puede reescribir directamente los flujos de instrucciones.

Compatibilidad con sitios reales y cambios en la interfaz

Ladybird incorporó reglas declarativas de compatibilidad para sitios que entregan contenido defectuoso al detectar su agente de usuario. Las reglas se cargan en tiempo de ejecución, están escritas en JSON y pueden consultarse sin que la política esté codificada directamente en el navegador.

Las primeras reglas se aplican a `nytimes.com` y `cnn.com`, que se muestran correctamente cuando Ladybird oculta su nombre en el agente de usuario.

También mejoró el funcionamiento de varios sitios:

- `chatgpt.com` dejó de sufrir un cierre en la página de sesión y recibió tres correcciones de layout.

- `vscode.dev` ya no se cerraba segundos después de abrir un archivo.

- `icloud.com` dejó de mostrar texto ilegible cuando la declaración de codificación aparecía más de 1 KB después del inicio del documento.

- `strava.com` recibió dos correcciones que redujeron aproximadamente a la mitad el tiempo de carga de los mapas.

- En Outlook se corrigió un cierre y Word permite iniciar sesión.

- Los enlaces de mapas de imagen de `milliondollarhomepage.com` y xkcd ya responden al clic.

La interfaz también suma pequeños cambios con impacto diario. Los enlaces `mailto:` abren el cliente de correo y otros esquemas externos solicitan confirmación. Los diálogos JavaScript de tipo `alert()`, `confirm()` y `prompt()` ya no bloquean todo el navegador: aparecen como superposiciones dentro de la página en la interfaz Qt.

Si una pestaña falla, Ladybird conserva la entrada real del historial en lugar de insertar una página falsa. Al recargar, intenta continuar desde el punto en el que se produjo el cierre. Además, las direcciones `localhost:8000` y `127.0.0.1` se abren mediante HTTP desde la barra de direcciones.

Más pruebas superadas y avances de plataforma

La puntuación en Web Platform Tests pasó de 2.079.020 a 2.088.677 subpruebas, con una ganancia de 9.657 durante agosto. El salto más importante procede de unas 2.500 pruebas sobre `referrer-policy`, relacionadas con la forma en que el referente se transmite entre navegaciones, iframes y documentos `srcdoc`. Ladybird supera ya el 99 % de esa suite.

WebGL funciona en Windows mediante el backend Direct3D 11 de ANGLE. La decodificación de JPEG XL cambió al decodificador jxl-rs. Las ventanas ocultas o cubiertas dejan de rasterizar, ejecutar ciclos de desplazamiento suave y presentar fotogramas, un ajuste que puede ayudar al consumo de batería junto con las animaciones fuera del hilo principal.

La historia de sesión y la navegación se trasladaron al proceso del navegador, un requisito previo para el aislamiento de sitios. El DOM se separó de sus envoltorios JavaScript, de modo que un nodo no mantiene estado de objeto JavaScript hasta que un script lo utiliza. Esa decisión reduce memoria y abre el camino a distintos envoltorios para diferentes “mundos”, un mecanismo necesario para las extensiones.

El alpha sigue previsto para 2026

El motor todavía no está terminado, y el propio proyecto lo presenta como una condición normal para una versión alpha. Antes de publicarla quedan tareas que no dependen tanto del motor como de la distribución y la experiencia de uso.

Ladybird necesita un sistema de informes de fallos que no obligue a iniciar el navegador desde un terminal, instaladores firmados para macOS y Linux, un mecanismo de actualización automática y una primera experiencia de configuración. También debe habilitar un lugar desde el que descargar el navegador.

Esa primera configuración incluirá listas de filtros opcionales para bloquear anuncios, como EasyList, con actualización automática.

El balance de agosto deja una imagen concreta: Ladybird no está intentando competir únicamente mediante una lista de funciones. Está acelerando el motor, endureciendo sus límites, reduciendo su dependencia de procesos inseguros y mejorando la compatibilidad con páginas que ya forman parte de la rutina diaria.

El alpha llegará con trabajo pendiente. Precisamente por eso será una prueba relevante: permitirá comprobar si todas estas piezas, desarrolladas a gran velocidad, pueden sostener un navegador que empiece a utilizarse fuera del entorno de pruebas.