Selektives Lesen von Formaten: Ein besserer Standard für die Async Clipboard API

Prashant Singh
Prashant Singh
LinkedIn

Veröffentlicht am 3. Juli 2026

Wenn Sie schon einmal einen Texteditor, eine Tabellenkalkulations-App oder eine andere App verwendet haben, bei der das Einfügen von Inhalten aus der Zwischenablage eine primäre Interaktion ist, wissen Sie, was Nutzer erwarten: Das Einfügen sollte sofort erfolgen.

In vielen Fällen lesen Web-Apps jedoch mehr Daten aus der Zwischenablage als nötig. Dadurch kann das Einfügen von Inhalten langsamer als erwartet sein, es werden CPU-Zyklen verschwendet und Speicher für Daten verwendet, die die App nie benötigt.

Mit Selective format read wird dieses Leistungsproblem behoben, indem die Async Clipboard API so geändert wird, dass sie die Erwartungen der Nutzer besser erfüllt und Entwicklern das bietet, was sie brauchen: nur die Formate zu lesen, die die App tatsächlich benötigt.

Das Problem: Alle Datenformate im Voraus lesen

Wenn ein Nutzer Inhalte aus einer beliebigen App kopiert, z. B. aus Excel, Google Docs oder Photoshop, schreibt die App in der Regel mehrere Darstellungen derselben Daten in die Systemzwischenablage: Nur-Text, HTML, Bild und manchmal benutzerdefinierte Formate. Die Web-App, die die Daten liest (wenn der Nutzer Inhalte aus der Zwischenablage einfügt), benötigt selten alle diese Darstellungen. Ein Tabellenkalkulationseditor benötigt möglicherweise HTML. Ein Texteditor möchte möglicherweise den Befehl „Als Nur-Text einfügen“ anbieten. Ein Code-Editor benötigt möglicherweise nur den Text.

Bisher hat navigator.clipboard.read() jede verfügbare Darstellung der Daten aus der System zwischenablage abgerufen, eine Bereinigung durchgeführt (was Zeit in Anspruch nehmen kann, insbesondere bei großen HTML- oder Bild-Nutzlasten) und die Byte im Arbeitsspeicher gespeichert, auch für die Formate, die die App nie verwenden würde. Je größer die ungenutzte Nutzlast, desto länger mussten die Nutzer warten und desto mehr Arbeitsspeicher wurde vom Tab belegt – genau dann, wenn die Reaktionsfähigkeit beim Einfügen am wichtigsten ist.

Die Lösung: Nur aufzählen und dann bei Bedarf lesen

Ab Chrome und Edge 149 beschreiben ClipboardItem Objekte, die von der navigator.clipboard.read() Methode zurückgegeben werden, nur was sich in der Zwischenablage befindet, anstatt sofort Zugriff auf die Daten zu gewähren. Die tatsächlichen Byte für ein bestimmtes Format werden erst aus der Zwischenablage gelesen, wenn Sie ClipboardItem.getType(mimeType) aufrufen. Die API-Oberfläche bleibt unverändert. Derselbe Code, den Sie gestern geschrieben haben, funktioniert auch heute noch und bietet Ihnen sofortige Leistungsverbesserungen:

// Enumerate the available MIME types.
// No payload is fetched yet.
const items = await navigator.clipboard.read();

for (const item of items) {
  if (item.types.includes('text/html')) {
    // Only read the HTML data.
    // The data is fetched (and sanitized) here only.
     const blob = await item.getType('text/html');
     useThePastedHtml(await blob.text());
     break;
   }

   // text/plain, image/png, or any other custom formats
   // stored in the clipboard are never read.
}

Ein weiterer Leistungsvorteil ist, dass das Caching automatisch erfolgt. Wenn Sie getType('text/html') zweimal für dasselbe ClipboardItem aufrufen, wird nur einmal aus der System zwischenablage gelesen und beim zweiten Aufruf wird das im Cache gespeicherte Blob zurückgegeben.

Vorteile

Latenz : Die Arbeit, die bei Aufruf von navigator.clipboard.read() erforderlich war, z. B. das Kopieren von Byte zwischen Prozessen, das Bereinigen von HTML oder das Decodieren von Bildern, erfolgt jetzt nur noch für die Formate, die Ihre App tatsächlich benötigt. Apps, die nur ein einzelnes Format lesen, profitieren am meisten von der Einsparung. Je größer die Formate, die Sie überspringen, desto größer der Gewinn. HTML profitiert am meisten, da die HTML-Bereinigung aufwendig ist.

Arbeitsspeicher : Bisher bedeutete der Aufruf von navigator.clipboard.read(), wenn sich in der Zwischenablage ein 50 MB großes Bild befand, dass 50 MB im Renderer-Arbeitsspeicher der Webseite verwendet werden mussten, bis das ClipboardItem freigegeben wurde. Das galt auch dann, wenn die App nur die text/plain-Darstellung der Daten benötigte. Jetzt wird nur für die Formate, die Ihre App beim Aufruf von ClipboardItem.getType() liest, Arbeitsspeicher im Renderer-Prozess verwendet. Bei Apps, bei denen das Einfügen häufig vorkommt, z. B. Texteditoren, E-Mail-Editoren oder Designtools, wird dadurch die Arbeitsspeichernutzung beim Einfügen deutlich reduziert, insbesondere bei Sitzungen mit mehreren Tabs, bei denen mehrere Editoren parallel auf die Zwischenablage zugreifen.

Keine Anmeldung erforderlich : Jede Website im Web profitiert automatisch von diesen Vorteilen. Sie müssen keinen Code migrieren oder Code hinter der Logik zur Funktionserkennung sperren.

Eine Verhaltensänderung, die Sie kennen sollten

Wenn die Daten später gelesen werden, ändert sich das Verhalten leicht: Ein ClipboardItem-Objekt ist nicht mehr ein eingefrorener Snapshot der Zwischenablage zum Zeitpunkt, als der Aufruf von navigator.clipboard.read() aufgelöst wurde.

Wenn read() aufgerufen wird und ein ClipboardItem zurückgibt, ist dieses Element nur ein Lazy Handle für die Daten in der Systemzwischenablage. Wenn sich der Inhalt der Zwischenablage zwischen dem Aufruf von read() und einem späteren Aufruf von getType() ändert, wird der Aufruf mit einem InvalidStateError abgelehnt. Das gilt auch für ein Format, das Sie zuvor erfolgreich mit demselben ClipboardItem gelesen haben.

// Read from the clipboard.
const items = await navigator.clipboard.read();
// Get the first ClipboardItem.
const item = items[0];

// Actually fetch the data now, which works fine.
const text = await item.getType('text/plain');

// The user writes something new to the clipboard
// by copying from another app, or your own code writes to
// the clipboard again.
await navigator.clipboard.writeText('something new');

// Fetching the data from the earlier ClipboardItem
// rejects with InvalidStateError, because the contents
// of the clipboard changed.
const html = await item.getType('text/html');

Das liegt daran, dass die Rückgabe von Daten, die nicht mehr der Zwischenablage entsprechen, verwirrend wäre und sonst zu schwer zu debuggenden Problemen führen würde.

In der Praxis ist die Änderung für den meisten Code unsichtbar, da Apps in der Regel read() und getType() direkt nacheinander im selben Einfüge-Handler aufrufen. Sie sollten jedoch auf Fälle achten, in denen Sie Code haben, der ein ClipboardItem über asynchrone Grenzen hinweg beibehält.

Hier ein Beispiel, bei dem diese Änderung zu einem Problem werden kann: Caching von ClipboardItem-Objekten in window, Anzeige in einer UI für den Zwischenablageverlauf oder Warten auf die Nutzerinteraktion vor dem Aufruf von getType(). So vermeiden Sie Probleme in einem solchen Szenario:

  • Umschließen Sie getType()-Aufrufe mit try / catch-Blöcken und behandeln Sie InvalidStateError als Signal dafür, dass die Zwischenablage geändert wurde und der Code noch einmal gelesen werden sollte.
  • Wenn Sie Daten aus der Zwischenablage beibehalten müssen, kopieren Sie das Blob in Ihre eigene Struktur, sobald Sie es mit getType() abrufen. Behandeln Sie das ClipboardItem nicht als langfristigen Speicher.
  • Verwenden Sie das clipboardChange Ereignis, um veraltete Handles proaktiv zu ungültig zu machen.

Standards und Browserunterstützung

Selective format read ist eine Änderung der Clipboard APIs-Spezifikation , die von der Web Editing Working Group und dem Microsoft Edge-Webplattformteam vorangetrieben wird.

Safari unterstützt dieses Verhalten ebenfalls und Firefox hat eine positive Haltung zu den Standards und die Absicht zur Angleichung signalisiert.

Eine unauffällige, aber bedeutende Verbesserung der Leistung und Interoperabilität der Clipboard API, wobei Chromium jetzt auf dasselbe Modell umgestellt wird.