Motores de renderizado web explicados: Blink, Gecko y WebKit

Cuando alguien dice que «Edge y Chrome son lo mismo por dentro», o que «en el iPhone todos los navegadores son Safari», está hablando de motores de renderizado. Son la pieza que convierte el HTML, el CSS y el JavaScript de una página en los píxeles que ves, y hoy quedan tres que importen: Blink, Gecko y WebKit.

Saber cuál lleva tu navegador explica cosas muy concretas: por qué una web se ve distinta en dos programas que parecen iguales, por qué una extensión no se instala, o por qué un fallo de seguridad de uno obliga a parchear media docena de navegadores a la vez. Esta guía cuenta qué hace cada uno y quién lo usa, con la documentación de cada proyecto delante: chromium.org, mozilla.org y webkit.org.

---

Qué hace exactamente un motor de renderizado

Un motor es mucho más que «lo que dibuja». La documentación de Mozilla lo enumera cuando describe Gecko: análisis y dibujado del HTML, red, JavaScript, comunicación entre procesos, DOM y las abstracciones de los componentes visuales del sistema operativo. Es decir, casi todo lo que hace un navegador por debajo de los botones.

Por eso un motor no se cambia a la ligera, y por eso la parte visible de un navegador —pestañas, marcadores, ajustes— es, comparada con el motor, una capa fina. Dos navegadores con el mismo motor renderizan igual y se diferencian en lo de fuera; dos navegadores con motores distintos pueden discrepar en cómo colocan un elemento o en qué función del lenguaje admiten.

---

Blink: el motor de Chromium, nacido de WebKit en 2013

Blink es, en palabras del propio proyecto, «el nombre del motor de renderizado que usa Chromium», y su código vive bajo third_party/blink. Chromium, a su vez, se define como «un proyecto de navegador de código abierto» del que salen Chrome y muchos otros.

Su origen está fechado: el 3 de abril de 2013, el blog de Chromium anunció Blink como «un nuevo motor de renderizado de código abierto basado en WebKit». El motivo que dieron no fue rendimiento, sino arquitectura: «Chromium usa una arquitectura multiproceso distinta de la de otros navegadores basados en WebKit, y mantener varias arquitecturas durante años ha ido aumentando la complejidad de los dos proyectos». En la misma nota calcularon lo que iban a quitar de entrada: 7 sistemas de compilación y más de 7.000 ficheros, con más de 4,5 millones de líneas.

Esa arquitectura multiproceso es la otra gran aportación de Chromium, y su documento de diseño la explica sin adornos: «es casi imposible construir un motor de renderizado que no se cuelgue nunca» y «que sea perfectamente seguro», así que separan las pestañas en procesos distintos para que un fallo no se lleve por delante el navegador entero. Hoy eso es normal en todos, pero no lo era cuando Chromium lo planteó.

---

Gecko: el motor de Mozilla, y lo que lleva dentro

Gecko es «el motor de renderizado de Mozilla para la web», y la documentación de Firefox lo desglosa pieza a pieza: la red se llama necko y usa la biblioteca NSS para el cifrado; el motor de JavaScript es SpiderMonkey; y buena parte de la interfaz de Firefox está escrita, precisamente, en ese JavaScript que el motor ejecuta.

Es el único de los tres que no comparte árbol con WebKit, y también el que usan menos programas: Firefox de escritorio, Firefox para Android y el gestor de correo Thunderbird, según la propia documentación de Mozilla. A esa lista hay que sumarle los derivados de Firefox —LibreWolf, Waterfox o Zen—, que llevan el mismo motor.

Mozilla también recorrió el camino de los procesos, y su documentación lo fecha: la separación del contenido web en un proceso aparte —el proyecto Electrolysis, «e10s»— llegó en 2016, y en 2021, como parte de las mitigaciones de Spectre y Meltdown, el modelo cambió para que cada proceso de contenido cargue solo lo de un sitio.

---

WebKit: el motor de Apple, y el que mandó en el iPhone

WebKit se define como «un motor de contenido web de código abierto para navegadores y otras aplicaciones», y su propia web dice dónde está: «es el motor que usan Safari, Mail, App Store y muchas otras aplicaciones en macOS, iOS y Linux». Esa última palabra sorprende a mucha gente: hay una versión de WebKit para escritorios Linux.

Su lista de prioridades explica bastante de cómo se comporta: compatibilidad con el mundo real, cumplimiento de estándares, estabilidad, rendimiento, duración de la batería, seguridad y privacidad. Y son explícitos con el orden: dicen que se esfuerzan en mantener la compatibilidad con el contenido que ya existe «a veces incluso a costa de los estándares».

El dato que más se nota en el bolsillo es el del iPhone, y lo cuenta bien un tercero que no es Apple: Brave, en su propia web, explica que su navegador «para Android y escritorio es una bifurcación de Chromium», pero que «para iOS está construido sobre el WebKit de Apple». Un navegador distinto por fuera y el mismo motor por dentro.

En licencias también va por libre: WebKit usa licencias de estilo BSD y LGPL, con el objetivo declarado de ser compatible con la LGPL 2.1 o posterior, mientras que el código de Mozilla va bajo MPL 2.0.

---

Cada motor trae su motor de JavaScript

Dentro de cada uno hay otra pieza con nombre propio, y conviene no confundirlas con el motor de renderizado.

• V8, en Blink. Google lo describe como «su motor de JavaScript y WebAssembly de alto rendimiento y código abierto, escrito en C++», y añade el dato que explica su alcance: «se usa en Chrome y en Node.js, entre otros».
• SpiderMonkey, en Gecko. Ejecuta el JavaScript de las páginas y también el de la propia interfaz de Firefox.
• JavaScriptCore, en WebKit. Su documentación lo llama «el motor de JavaScript integrado de WebKit», y avisa de que se le conoce por varios nombres —SquirrelFish, o Nitro en la jerga comercial de Apple—, aunque el proyecto siempre se ha llamado igual.

---

Quién usa cada motor

Lo de Edge no es un rumor: la documentación de Microsoft para desarrolladores habla de «el proyecto Chromium, el motor de navegador en el que se basa Microsoft Edge». Y ese es justo el motivo de que Chrome y Edge se parezcan tanto por dentro y tan poco por fuera.

---

Por qué esto te importa aunque no programes

Tres consecuencias prácticas, sin tecnicismos.

• Un fallo del motor es un fallo de muchos navegadores. Cuando aparece un agujero en Blink, no es solo cosa de Chrome; por eso los fallos de navegador son material habitual de los kits de exploits y por eso el ritmo de parches importa tanto: Chrome pasó en 2026 a un ciclo de actualizaciones de dos semanas.
• Cambiar de navegador no siempre cambia de motor. Si saltas de Chrome a Edge o a Brave en el ordenador, la página se sigue dibujando con Blink. Si lo que quieres es otro motor, tienes que irte a Firefox o a alguno de sus derivados.
• En el iPhone, cambiar de navegador no suele cambiar de motor. Brave, por ejemplo, dice de su propia versión para iOS que está construida sobre WebKit. Cambia la interfaz y cambian las protecciones, pero no cambia quién dibuja la página.

---

En resumen

Tres motores y una historia entrelazada: WebKit, según contó el propio blog de Chromium, «salió de KHTML en 2001»; Blink salió de WebKit en 2013; y Gecko llegó por el camino de Mozilla. Lo que se ve como «la guerra de los navegadores» es, por debajo, una conversación entre estos tres.

Y la elección práctica es más sencilla de lo que parece: si quieres variedad de motor, la opción es Gecko; si quieres compatibilidad máxima con webs que solo se prueban contra Chrome, la opción es Blink; y si estás en un iPhone, lo más probable es que la opción venga tomada.

---

Te puede interesar

Tech Planet participa en el programa de afiliados de Amazon. Si compras a través de estos enlaces, recibimos una pequeña comisión sin coste extra para ti, lo que nos ayuda a seguir creando contenido como este.