Ladybird, el navegador independiente, estrena JIT

Ladybird cierra octubre con 2.184.722 subtests superados en los Web Platform Tests

El navegador independiente Ladybird terminó octubre con 2.184.722 subtests aprobados en los Web Platform Tests (WPT), un avance de 75.650 en un solo mes. El dato importa porque el proyecto, financiado por empresas y personas que apuestan por la web abierta, ya dejó atrás a Safari Technology Preview en esa medición: el 26 de octubre cruzó ese umbral.

Para un founder, la señal no es solo técnica. Un motor de navegador construido desde cero que avanza a este ritmo es una demostración de cómo se hace producto hoy: foco quirúrgico, automatización agresiva y decisiones de arquitectura que se pagan a largo plazo.

¿Qué cambió en el motor de renderizado de Ladybird?

Hasta ahora, los navegadores ejecutan JavaScript, estilo y layout en un único hilo principal, uno por vez. Mientras corre un script, la página no se actualiza. Ladybird movió el estilo y el layout a su propio hilo y la grabación de pintado a otro, de modo que ahora corren al mismo tiempo que JavaScript.

El resultado se ve en dos casos concretos:

• Las animaciones CSS siguen corriendo mientras JavaScript está ocupado, incluidas las que cambian layout, como width y font-size.
• El estado :hover sigue funcionando durante un script largo: el hilo de renderizado encuentra el elemento bajo el mouse, aplica sus estilos, arranca transiciones, actualiza el cursor y dibuja un frame nuevo. Cuando el script termina, el hilo principal se pone al día y dispara los eventos de hover.

Según el propio proyecto, ningún otro navegador puede hacer esto hoy. Si un script pide información de layout —el tamaño de un elemento, por ejemplo— espera a que termine el trabajo pendiente, así que nunca recibe datos obsoletos.

El JIT de JavaScript y el nuevo motor WebAssembly

En Linux y macOS, LibJS ahora compila JavaScript caliente a código máquina, tanto en x86-64 como en AArch64. El equipo había descartado un JIT en el pasado y había apostado por optimizar el intérprete, pero concluyó que duplicar su velocidad solo convertiría un cuelgue de 300 ms en uno de 150 ms, igual de perceptible. La decisión fue construir un JIT optimizador.

El diseño es deliberadamente conservador: optimización especulativa basada en perfilado de tipos en tiempo de ejecución. Mientras el código se calienta, el motor registra qué tipos y formas de objeto ve, y el código compilado usa esos registros para hacer conjeturas —por ejemplo, "este valor siempre es un entero"— e inlinea funciones pequeñas. Para cazar errores durante el desarrollo usaron un fuzzer que ejecutaba el mismo código en el JIT y en el intérprete y comparaba los resultados.

En paralelo, reemplazaron el motor WebAssembly en C++ y Cranelift por uno nuevo con intérprete y JIT propios. Soporta partes más recientes del estándar, como manejo de excepciones y GC, y en las cargas Wasm de JetStream 3 que ambos motores pueden ejecutar puntúa unas 7 veces más.

El intérprete de Wasm está escrito en flap, el pequeño lenguaje y compilador que el equipo creó en julio para escribir el intérprete de LibJS. Una sola fuente lo construye para x86-64, AArch64 y Windows x64, y las funciones calientes pasan al JIT incluso en medio de un bucle en ejecución.

El avance en rendimiento ya se mide en casos reales: JSLinux, un emulador de PC x86, arranca Alpine Linux hasta una shell en 1,8 segundos, mientras que Chrome tarda 1,5.

Web Platform Tests: cómo se cerró la brecha con Safari

La mayor parte de la ganancia mensual llegó en cinco días: de unos 2,12 millones de subtests el 22 de octubre a unos 2,18 millones el 27. Los mayores aportes fueron unos 30.000 en /css y 10.000 en /editing.

El método es lo más relevante para cualquier equipo de producto: apuntaron agentes de IA de programación a los WPT y les pidieron completar funcionalidad faltante. Hicieron muchos arreglos pequeños y la suma fue decisiva. Es un caso de uso concreto de agentes de código sobre una suite de tests pública y objetiva, no sobre un backlog ambiguo.

Interfaz nueva, más sitios compatibles y accesibilidad

Por primera vez el equipo mapeó un diseño completo en lugar de ir parcheando sobre la marcha. La interfaz cubre pestañas, barras de herramientas, menús y páginas about: propias en macOS y Linux, con temas claro, oscuro y uno violeta oscuro para ventanas privadas.

Entre las funciones: fijar pestañas, buscar entre todas las pestañas abiertas, restaurar ventanas al iniciar, controles de formulario rediseñados, selectores de fecha y hora, scroll suave con rueda, sobredesplazamiento elástico en macOS, inercia de trackpad y barras de scroll que se ocultan hasta usarlas.

Sitios que ahora funcionan mejor:

• Google Slides abre presentaciones en lugar de mostrar un error.
• GitHub renderiza diagramas Mermaid.
• ChatGPT agranda el cuadro de texto mientras se escribe.
• nytimes.com y reuters.com superan sus verificaciones anti-bot.
• Instagram muestra el primer frame de los videos en lugar de quedar en blanco.
• Gmail deja de retener la página anterior en memoria al recargar.

En accesibilidad sumaron un primer soporte de VoiceOver en macOS y Orca en Linux, corrección ortográfica en campos de texto en macOS, Picture-in-Picture, enlaces a texto, permisos de ubicación y micrófono, e Inspector de elementos, autocompletado de consola y objetos expandibles en DevTools.

Seguridad: aislamiento de procesos y la migración a Rust

Las páginas corren en procesos de renderizado en sandbox, así que una página maliciosa que tome el control de su renderer debería quedar atrapada ahí. El equipo siguió cerrando vías de escape: antes, un renderer comprometido podía pedirle al proceso del navegador que abriera cualquier archivo del equipo; ahora solo un renderer que muestra archivos locales puede leerlos. También podían falsificar un clic de usuario para abrir popups o leer el portapapeles, y el proceso del navegador ya no confía en ellos para eso.

Además dividieron el navegador en más procesos: los iframes y popups de sitios cruzados tienen su propio renderer por defecto, cada sitio de nivel superior tiene su propio proceso de red con caché HTTP y cookies de terceros separadas, y cada renderer tiene su propio proceso de audio y decodificador de imágenes.

En el frente del lenguaje, el runtime de LibJS pasó de C++ a Rust justo antes de que aterrizara el JIT, así que el motor de JavaScript es ahora todo Rust salvo su intérprete en flap y el recolector de basura. El nuevo motor Wasm también es Rust, y WebGL, canvas 2D, IndexedDB, Streams y URL se movieron igual. El cálculo de estilo en C++ se eliminó: ahora se computa enteramente en Rust.

¿Qué significa esto para tu startup?

Un navegador nuevo no es solo un proyecto de infraestructura: es una superficie de mercado que se abre y una lección de ingeniería aplicable a cualquier producto web.

• Audita cuánto bloquea tu JavaScript el hilo principal. El problema que Ladybird resolvió moviendo estilo y layout a hilos separados es el mismo que congela tus animaciones y tu feedback de hover. Mide con el panel de rendimiento del navegador cuánto duran tus tareas largas y divide las que pasen de unos pocos cientos de milisegundos, o muévelas a Web Workers.
• Copia el método de los agentes de IA sobre una suite objetiva. El salto de 75.650 subtests en un mes no vino de un roadmap difuso, sino de apuntar agentes de código a los WPT y pedirles completar funcionalidad faltante. Si tienes tests automatizados, ese es el insumo que hace rendir a un agente; sin ellos, el agente adivina.
• Trata a Ladybird como target de testing y como canal temprano. Un motor con soporte nuevo de APIs como el HTML Sanitizer, Touch Events, COOP o WebDriver BiDi es una oportunidad para detectar bugs de compatibilidad antes que tu competencia, y para posicionarte frente a una comunidad técnica que hoy está mirando el proyecto de cerca.

La cuenta regresiva para el primer alpha

El primer alpha está previsto para lo que queda de este año. Este mes sumaron builds de release —archivos para macOS, tarballs de Linux, paquetes .deb y .rpm, y bundles Flatpak—, reportes de crash que el usuario puede revisar antes de enviar, una página de bienvenida para elegir layout de pestañas, buscador y bloqueo de anuncios, y la posibilidad de reportar sitios rotos desde dentro del navegador.

Conclusión

Ladybird pasó de ser un experimento de nicho a un motor que compite en métricas objetivas: superó a Safari Technology Preview en WPT, estrenó un JIT de JavaScript y un motor WebAssembly propio, y resolvió un problema de concurrencia que, según el propio proyecto, ningún otro navegador resuelve hoy. Para un founder, el valor está menos en el navegador en sí y más en el manual de ejecución que deja: decisiones de arquitectura tomadas a conciencia, migración de C++ a Rust sin frenar el roadmap, y agentes de IA usados contra una suite de tests real. Si tu producto vive en la web, ese manual es material de estudio.

Fuentes

• https://ladybird.org/newsletter/2026-10-31 (fuente original)

No se encontraron datos adicionales verificables en la búsqueda: los resultados devueltos no correspondían al proyecto Ladybird, por lo que este artículo se apoya exclusivamente en la fuente original.