Explicación del Manifest V3 de las extensiones de Chrome

Si has buscado tutoriales sobre extensiones de Chrome recientemente, probablemente hayas notado algo frustrante: la mitad de las guías que encuentras hacen referencia a una arquitectura de background page que ya no funciona. Manifest V2 está obsoleto y deshabilitado por defecto en Chrome. Manifest V3 es la plataforma actual, y comprender su arquitectura es el único punto de partida práctico para el desarrollo de extensiones en 2026.

Este artículo explica qué cambió, por qué cambió y cómo encajan las APIs clave entre sí.

Por qué Chrome se alejó de Manifest V2

Las extensiones de Manifest V2 podían ejecutar una background page persistente — un documento HTML completo que permanecía cargado en memoria indefinidamente, incluso cuando la extensión no estaba haciendo nada. Esto era conveniente para los desarrolladores, pero costoso para los usuarios. Cada extensión instalada con una background page consumía memoria y CPU de forma continua.

Más allá del rendimiento, MV2 permitía a las extensiones cargar y ejecutar JavaScript desde URLs remotas. Esto significaba que una extensión podía pasar la revisión de la Chrome Web Store con código inofensivo y, posteriormente, intercambiarlo silenciosamente por lógica maliciosa desde un servidor externo. No había una forma práctica de auditar lo que una extensión estaba ejecutando realmente.

Estos dos problemas — el desperdicio de recursos y el código remoto no auditable — son los verdaderos motivos detrás de Manifest V3.

Los cambios arquitectónicos principales en el Manifest V3 de las extensiones de Chrome

Los service workers de extensión reemplazan a las background pages

En MV3, la background page persistente desaparece. Su reemplazo es un service worker de extensión — un script basado en eventos que Chrome inicia cuando es necesario y termina cuando está inactivo.

Este es el cambio que más desconcierta a los desarrolladores que vienen de MV2. Un service worker no tiene acceso al DOM y no permanece activo entre eventos. No puedes almacenar estado en una variable global y esperar que persista. En su lugar, usa chrome.storage para cualquier cosa que necesite sobrevivir entre eventos, y usa la API chrome.alarms para programar trabajo recurrente que anteriormente habría estado en una llamada a setInterval dentro de una background page.

{
  "background": {
    "service_worker": "background.js",
    "type": "module"
  }
}

declarativeNetRequest reemplaza al webRequest bloqueante

La API webRequest de MV2 permitía a las extensiones interceptar cada solicitud de red y decidir de forma síncrona si bloquearla o modificarla. Esto le daba a las extensiones una visibilidad amplia sobre todo el tráfico del navegador — una exposición significativa de privacidad — e introducía latencia porque cada solicitud tenía que esperar la respuesta de la extensión.

La API declarativeNetRequest (DNR) funciona de manera diferente. Defines un conjunto de reglas en JSON, Chrome las evalúa de forma nativa, y las extensiones ya no necesitan interceptar solicitudes de manera síncrona en JavaScript para bloquearlas o modificarlas. Esto es más rápido y, por diseño, más privado.

Desde Chrome 120, los límites de reglas se han ampliado considerablemente respecto a los primeros días de MV3. Bloqueadores de contenido como uBlock Origin Lite han lanzado versiones compatibles con MV3, por lo que la afirmación de que MV3 “mató a los bloqueadores de anuncios” no es del todo precisa — aunque el modelo de filtrado es genuinamente más restrictivo que los enfoques de la era MV2, y el uBlock Origin original sigue siendo exclusivo de MV2 por elección de su autor.

Se acabó el código alojado remotamente

Todo el JavaScript ejecutado por una extensión MV3 debe estar empaquetado dentro del propio paquete de la extensión. No se permite cargar código ejecutable desde un CDN o API externo. Esto hace que cada extensión sea totalmente auditable en el momento de la revisión.

La API chrome.action y la Offscreen API

Las APIs browserAction y pageAction de MV2 se unifican en una sola API chrome.action en MV3. Maneja el icono de la barra de herramientas, el texto del badge y el popup en una única interfaz coherente.

Para los casos en los que necesitas acceso al DOM o reproducción de audio desde un contexto de fondo — cosas que un service worker no puede hacer — MV3 proporciona la Offscreen API. Te permite crear un documento mínimo y oculto específicamente para esas tareas, sin la sobrecarga de una background page persistente completa. Según Can I Use, las APIs offscreen relacionadas ahora son ampliamente compatibles en los navegadores modernos basados en Chromium.

Cómo se ve un manifest MV3 mínimo

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0",
  "background": { "service_worker": "background.js" },
  "action": { "default_popup": "popup.html" },
  "permissions": ["storage", "activeTab"],
  "host_permissions": ["https://example.com/*"]
}

Observa que los permisos de host ahora se declaran por separado de los permisos de API — un cambio deliberado que ofrece a los usuarios una visibilidad más clara sobre a qué sitios puede acceder una extensión.

Conclusión

Manifest V3 es una plataforma más restringida que MV2, y algunas de esas restricciones requieren cambios arquitectónicos reales. Pero las restricciones existen por razones concretas: menor consumo de memoria, ausencia de código remoto no auditable y menor exposición del tráfico de red en bruto a los procesos de la extensión. Si estás comenzando una nueva extensión hoy, MV3 es la única vía soportada práctica. Comprender el ciclo de vida del service worker y el modelo de declarativeNetRequest es donde comienza ese trabajo.

Preguntas frecuentes

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.