Chrome Extension Manifest V3 erklärt

Wenn Sie kürzlich nach Tutorials zu Chrome-Erweiterungen gesucht haben, ist Ihnen vermutlich etwas Frustrierendes aufgefallen: Die Hälfte der gefundenen Anleitungen verweist auf eine Background-Page-Architektur, die nicht mehr funktioniert. Manifest V2 ist veraltet und in Chrome standardmäßig deaktiviert. Manifest V3 ist die aktuelle Plattform, und das Verständnis seiner Architektur ist der einzige praktikable Ausgangspunkt für die Entwicklung von Erweiterungen im Jahr 2026.

Dieser Artikel erklärt, was sich geändert hat, warum es sich geändert hat und wie die wichtigsten APIs zusammenspielen.

Warum Chrome sich von Manifest V2 abgewandt hat

Manifest-V2-Erweiterungen konnten eine persistente Background Page ausführen – ein vollständiges HTML-Dokument, das unbegrenzt im Speicher geladen blieb, selbst wenn die Erweiterung nichts tat. Das war für Entwickler bequem, aber für Nutzer teuer. Jede installierte Erweiterung mit einer Background Page verbrauchte kontinuierlich Speicher und CPU.

Über die Performance hinaus erlaubte MV2 Erweiterungen, JavaScript von Remote-URLs zu laden und auszuführen. Das bedeutete, dass eine Erweiterung mit harmlosem Code die Prüfung des Chrome Web Stores bestehen und später unbemerkt schädliche Logik von einem externen Server einschleusen konnte. Es gab keine praktikable Möglichkeit zu prüfen, was eine Erweiterung tatsächlich ausführte.

Diese beiden Probleme – Ressourcenverschwendung und nicht prüfbarer Remote-Code – sind die eigentlichen Treiber hinter Manifest V3.

Die zentralen architektonischen Änderungen in Chrome Extension Manifest V3

Extension Service Worker ersetzen Background Pages

In MV3 ist die persistente Background Page Geschichte. Ihr Ersatz ist ein Extension Service Worker – ein ereignisgesteuertes Skript, das Chrome bei Bedarf startet und im Leerlauf wieder beendet.

Das ist die Änderung, über die die meisten Entwickler, die von MV2 kommen, stolpern. Ein Service Worker hat keinen DOM-Zugriff und bleibt zwischen Ereignissen nicht am Leben. Sie können keinen Zustand in einer globalen Variable speichern und erwarten, dass er erhalten bleibt. Verwenden Sie stattdessen chrome.storage für alles, was Ereignisse überdauern muss, und nutzen Sie die chrome.alarms-API, um wiederkehrende Aufgaben zu planen, die zuvor in einem setInterval-Aufruf innerhalb einer Background Page gelebt hätten.

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

declarativeNetRequest ersetzt blockierendes webRequest

Die webRequest-API von MV2 erlaubte Erweiterungen, jede Netzwerkanfrage abzufangen und synchron zu entscheiden, ob sie blockiert oder modifiziert werden soll. Das gab Erweiterungen weitreichenden Einblick in den gesamten Browser-Traffic – eine erhebliche Datenschutzgefährdung – und führte zu Latenz, da jede Anfrage auf die Antwort der Erweiterung warten musste.

Die declarativeNetRequest-API (DNR) funktioniert anders. Sie definieren eine Reihe von Regeln in JSON, Chrome wertet sie nativ aus, und Erweiterungen müssen Anfragen nicht mehr synchron in JavaScript abfangen, um sie zu blockieren oder zu verändern. Das ist schneller und vom Design her datenschutzfreundlicher.

Seit Chrome 120 sind die Regellimits gegenüber den frühen MV3-Tagen erheblich erweitert worden. Content-Blocker wie uBlock Origin Lite haben MV3-kompatible Versionen veröffentlicht, sodass die Behauptung, MV3 habe „Ad-Blocker getötet”, nicht ganz zutreffend ist – auch wenn das Filtermodell tatsächlich restriktiver ist als die Ansätze aus der MV2-Ära und das ursprüngliche uBlock Origin nach Entscheidung seines Autors weiterhin nur unter MV2 verfügbar bleibt.

Kein remote gehosteter Code mehr

Sämtliches JavaScript, das von einer MV3-Erweiterung ausgeführt wird, muss innerhalb des Erweiterungspakets selbst gebündelt sein. Das Laden von ausführbarem Code von einem externen CDN oder einer API ist nicht erlaubt. Dadurch ist jede Erweiterung zum Zeitpunkt der Prüfung vollständig auditierbar.

chrome.action-API und die Offscreen-API

Die browserAction- und pageAction-APIs aus MV2 sind in MV3 zur einzigen chrome.action-API zusammengeführt. Sie verwaltet das Symbolleisten-Icon, den Badge-Text und das Popup in einer einheitlichen Schnittstelle.

Für Fälle, in denen Sie DOM-Zugriff oder Audiowiedergabe aus einem Hintergrundkontext benötigen – Dinge, die ein Service Worker nicht leisten kann – stellt MV3 die Offscreen-API bereit. Damit lässt sich ein minimales, verstecktes Dokument speziell für diese Aufgaben erzeugen, ohne den Overhead einer vollständig persistenten Background Page. Laut Can I Use werden verwandte Offscreen-APIs inzwischen in modernen Chromium-basierten Browsern weitgehend unterstützt.

So sieht ein minimales MV3-Manifest aus

{
  "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/*"]
}

Beachten Sie, dass Host-Berechtigungen nun getrennt von API-Berechtigungen deklariert werden – eine bewusste Änderung, die Nutzern klarer aufzeigt, auf welche Websites eine Erweiterung zugreifen kann.

Fazit

Manifest V3 ist eine stärker eingeschränkte Plattform als MV2, und einige dieser Einschränkungen erfordern echte architektonische Anpassungen. Doch die Einschränkungen existieren aus konkreten Gründen: weniger Speicherverbrauch, kein nicht prüfbarer Remote-Code und weniger Offenlegung des rohen Netzwerk-Traffics gegenüber Erweiterungsprozessen. Wenn Sie heute eine neue Erweiterung beginnen, ist MV3 der einzige praktikabel unterstützte Weg. Das Verständnis des Service-Worker-Lebenszyklus und des declarativeNetRequest-Modells ist der Ausgangspunkt dieser Arbeit.

FAQs

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.