Zum Inhalt springen
Frontend-Optimierung

Weniger JavaScript: Dialog und Popover direkt in HTML

Dialog, Menü und Filter-Schublade ohne Skript: was command und commandfor seit Dezember 2025 leisten, welcher Rückfall nötig ist und was es für INP bringt.

17 Min. Lesezeit JavaScriptINPFrontend

Kurz und einfach erklärt

Viele Seiten haben kleine Fenster, die sich öffnen. Zum Beispiel ein Menü oder eine Frage vor dem Löschen. Bisher braucht so ein Fenster ein Skript.

Jetzt kann der Browser das selbst. Ein Knopf bekommt zwei neue Angaben. Die eine sagt, welches Fenster gemeint ist. Die andere sagt, was passieren soll.

Das spart Code. Die Seite muss weniger laden und weniger rechnen. Der Knopf geht schon, bevor alle Skripte da sind.

Ältere Browser kennen die neuen Angaben noch nicht. Für sie lädt ein kleines Skript nach.

Wir prüfen Ihre Seite. Dann bauen wir die Fenster um. Danach messen wir, ob die Seite schneller reagiert.

Viele Seiten haben sie: das Menü auf dem Smartphone, die Filter-Schublade im Shop-Listing, die Rückfrage vor dem Löschen, den Hinweis zu den Versandkosten. Meist hängt an jedem dieser Bauteile ein Stück JavaScript, das einen Klick abfängt, eine Klasse setzt, den Fokus verschiebt und die Escape-Taste abfragt. Seit dem 12. Dezember 2025 öffnen und schließen Buttons Dialoge und Popover in allen großen Browsern mit denselben zwei Attributen und ohne eigenes Skript (Web Features Explorer): Mit command und commandfor sagt ein <button> dem Browser, welches Element er öffnen oder schließen soll. Chrome und Edge können das seit Version 135, Firefox seit Version 144 und Safari seit Version 26.2 (Web Features Explorer). Dieser Beitrag zeigt, was die sogenannten Invoker Commands leisten, wie sie mit <dialog> und dem Attribut popover zusammenspielen, welcher Rückfallweg für ältere Browser sinnvoll ist und was die Umstellung für Hauptthread und Interaction to Next Paint bringt. Er sagt auch, wo weiterhin ein Skript nötig bleibt.

Das Wichtigste in Kürze

  • Seit dem 12. Dezember 2025 öffnen und schließen Buttons mit command und commandfor Dialoge und Popover in Chrome, Edge, Firefox und Safari ohne eigenes Skript (Web Features Explorer).
  • Die mittlere mobile Seite lud 2024 558 KB JavaScript (Web Almanac 2024). Steuert der Browser Overlays selbst und fällt das alte Skript dafür weg, sinken Download, Auswertung und Last im Hauptthread.
  • Ein <dialog> mit command="show-modal" sperrt den Rest der Seite, schließt per Escape und setzt den Fokus selbst. Ein Popover schließt standardmäßig bei Klick daneben und liegt ohne z-index über allem.
  • Als weitgehend verfügbar gelten Invoker Commands voraussichtlich erst ab dem 12. Juni 2028 (Web Features Explorer). Bis dahin lädt ein kleines Ersatzskript nur dort, wo command fehlt.
  • Daten nachladen, Eingaben prüfen und Zustände speichern bleiben Aufgabe von JavaScript. Eigene Befehle mit -- lösen nur ein command-Ereignis aus, das ein Listener am Ziel verarbeitet.
  • Gemessen wird vorher und nachher: Total Blocking Time im Labor, INP im Feld. Die mittlere TBT mobiler Seiten lag 2025 bei 1.916 ms (Web Almanac 2025).

Warum Overlays bisher JavaScript kosten

Ein Dialog wirkt auf der Seite wie eine Kleinigkeit. Im Code steckt mehr dahinter: Ein Skript sucht den Button, hängt einen Klick-Listener an, setzt aria-expanded, öffnet das Overlay, hält den Fokus darin fest, sperrt das Scrollen im Hintergrund, schließt bei Escape und bei einem Klick daneben und gibt den Fokus danach an den Button zurück. Viele Themes und Baukästen bringen dafür eigene Modal- und Menübibliotheken mit, manchmal mehrere nebeneinander, weil Plugins ihre eigene einbinden. Dazu kommen Regeln für z-index, damit das Overlay über Kopfzeile, Chat-Fenster und Cookie-Hinweis liegt.

Das summiert sich. Die mittlere mobile Seite lud 2024 558 KB JavaScript, die mittlere Desktopseite 613 KB, ein Plus von 14 Prozent gegenüber dem Vorjahr (Web Almanac 2024). Bei der mittleren mobilen Seite blieben 206 KB beim Laden ungenutzt, das sind 44 Prozent der ausgelieferten JavaScript-Bytes (Web Almanac 2024). Overlays sind ein typischer Fall dafür: Ihr Code lädt mit der Seite, gebraucht wird er erst beim ersten Klick, und auf vielen Seiten gar nicht.

Wie verbreitet selbst gebaute Dialoge sind, zeigt die Auszeichnung. Die ARIA-Rolle dialog steht auf 36 Prozent der mobilen und 34 Prozent der Desktopseiten (Web Almanac 2025). Diese Rolle braucht, wer einen Dialog aus <div>-Elementen zusammensetzt; das native <dialog> wird von Browsern ohnehin wie ein Dialog an Hilfstechnologien gemeldet (MDN). Hinter vielen dieser Rollen steckt Skriptcode, der Verhalten nachbildet, das der Browser inzwischen selbst mitbringt.

Der Preis zeigt sich im Hauptthread. Die mittlere Total Blocking Time mobiler Seiten stieg 2025 auf 1.916 Millisekunden, 58 Prozent mehr als die 1.209 Millisekunden von 2024 (Web Almanac 2025). Solange der Browser Skripte auswertet, wartet jede Eingabe. Bei einem per Skript verdrahteten Button kommt ein zweites Problem dazu: Solange sein Skript nicht geladen ist, passiert beim Tippen gar nichts. Seiten mit Hydration kennen das besonders gut, wie der Beitrag zu Server-Side Rendering und Hydration zeigt.

Interactions that take place during load can be delayed because the page is busy evaluating scripts.

web.dev, Script evaluation and long tasks

Was command und commandfor leisten

Die Invoker Commands drehen das Muster um. Statt dass ein Skript den Button sucht, nennt der Button sein Ziel selbst: commandfor trägt die ID des Elements, das gesteuert wird, command die Aktion. Der Browser führt sie aus, sobald jemand den Button anklickt oder per Tastatur auslöst (MDN). Damit funktioniert der Button, sobald das HTML geparst ist, unabhängig davon, ob und wann ein Skript ankommt.

This can be advantageous for built-in commands as the user does not have to wait for JavaScript to download and execute to make these buttons interactive.

MDN Web Docs, Invoker Commands API

Der HTML Living Standard legt sechs eingebaute Befehle fest (HTML Living Standard): toggle-popover, show-popover und hide-popover für Popover, show-modal, close und request-close für Dialoge. Daneben gibt es eigene Befehle, die mit zwei Bindestrichen beginnen, etwa --rotate-left. Sie lösen am Ziel nur ein command-Ereignis aus; was dann passiert, entscheidet ein Listener. Ein vollständiges Beispiel für einen Hinweisdialog braucht keine Zeile JavaScript:

shipping-info.html
<!-- Der Button nennt sein Ziel und die Aktion -->
<button type="button" commandfor="shipping-info" command="show-modal">
  Versandkosten anzeigen
</button>

<dialog id="shipping-info" aria-labelledby="shipping-title">
  <h2 id="shipping-title">Versandkosten</h2>
  <p>Die Versandkosten richten sich nach Gewicht und Lieferland.</p>
  <button type="button" commandfor="shipping-info" command="close">
    Schließen
  </button>
</dialog>

Chrome beschreibt die Attribute als Ersatz für popovertarget und popovertargetaction, die nur für Popover gedacht waren (Chrome for Developers). Neben dem Öffnen übernimmt der Browser einen Teil der Zugänglichkeit: Er stellt die Beziehung zwischen Button und Ziel für Hilfstechnologien her, sodass niemand aria-expanded von Hand pflegen muss (Chrome for Developers). Für Teams, die mehrere Themes oder Komponentensysteme betreuen, ist das ein angenehmer Nebeneffekt: Das Verhalten steht im Markup und hängt nicht mehr an einer bestimmten Bibliothek.

Zwei Details zählen in der Praxis. Erstens ist ein Button mit command und commandfor kein Absendeknopf, auch wenn er in einem Formular steht und kein type trägt (HTML Living Standard). Trotzdem gehört type="button" dazu, denn ältere Browser kennen die Attribute nicht und würden das Formular abschicken. Zweitens kommt das Muster ohne Inline-Handler wie onclick aus. Solche Handler sind außerhalb von Demos häufig durch die Content Security Policy verboten (Chrome for Developers); deklarative Attribute sind davon nicht betroffen.

Dialog: Rückfragen und Hinweise ohne Skript öffnen

Das Element <dialog> ist älter als die Invoker Commands und gut abgesichert. Es läuft seit März 2022 in allen großen Browsern (MDN) und gilt seit dem 14. September 2024 als weitgehend verfügbar (Web Features Explorer). Neu ist nur, dass es sich jetzt auch ohne showModal() im Skript als modaler Dialog öffnen lässt.

Ein modal geöffneter Dialog bringt mit, was Bibliotheken bisher nachbauen mussten. Der Rest der Seite wird inert, ist also für Maus, Tastatur und Screenreader gesperrt. Der Fokus springt auf das erste fokussierbare Element im Dialog, die Escape-Taste schließt ihn, und bei mehreren offenen Dialogen schließt sie nur den zuletzt geöffneten (MDN). Den abgedunkelten Hintergrund gestaltet das Pseudo-Element ::backdrop; ein eigenes Overlay-Element mit Klick-Listener entfällt.

Für Rückfragen wie „Artikel wirklich entfernen?“ reicht ein einziger Listener. Mehrere Buttons mit command="close" schließen den Dialog und hinterlegen ihren value als returnValue (Chrome for Developers). Das Skript liest danach nur noch aus, welcher Button es war, und muss weder den Dialog noch den Fokus verwalten. Ein Formular mit method="dialog" im Dialog schließt ihn beim Absenden ebenfalls, ohne die Daten an den Server zu schicken (MDN).

cart-confirm.html
<button type="button" commandfor="remove-item" command="show-modal">
  Artikel entfernen
</button>

<dialog id="remove-item" aria-labelledby="remove-title">
  <h2 id="remove-title">Artikel wirklich entfernen?</h2>
  <button type="button" commandfor="remove-item" command="close" value="cancel" autofocus>
    Behalten
  </button>
  <button type="button" commandfor="remove-item" command="close" value="remove">
    Entfernen
  </button>
</dialog>

<script type="module">
  // Ein einziger Listener: Welcher Button hat den Dialog geschlossen?
  const dialog = document.getElementById('remove-item');
  dialog.addEventListener('close', () => {
    if (dialog.returnValue === 'remove') {
      removeCartItem(); // eigene Funktion des Shops
    }
  });
</script>

Wer das Schließen per Klick neben den Dialog möchte, setzt closedby="any". Das Attribut läuft in Chrome und Edge ab Version 134 und in Firefox ab Version 141, Safari unterstützt es noch nicht (Web Features Explorer). Ohne Unterstützung bleibt der Dialog einfach offen, bis jemand Schließen oder Escape wählt, denn ein modal geöffneter Dialog ohne gültiges closedby verhält sich wie closedby="closerequest" (MDN). Das ist ein harmloser Rückfall, solange ein sichtbarer Schließen-Button im Dialog steht.

Popover: Menüs, Hinweise und Filter-Schubladen

Das Attribut popover macht aus einem beliebigen Element eine Ebene über der Seite. Geöffnet liegt sie im Top Layer über allen anderen Elementen und wird weder von position noch von overflow der Elternelemente beeinflusst (MDN). Der Wettlauf um möglichst hohe z-index-Werte, der Menüs und Hinweise in vielen Themes begleitet, fällt damit weg. Drei Arten stehen zur Wahl:

  • popover oder popover="auto": schließt bei einem Klick daneben und bei Escape und blendet andere offene Auto-Popover aus, sofern sie nicht verschachtelt sind (MDN). Passt für Menüs, Sprachwahl und Filter-Schubladen.
  • popover="manual": schließt nur über einen Button oder ein Skript, mehrere können gleichzeitig offen sein (MDN). Passt für Hinweise, die stehen bleiben sollen, etwa eine Bestätigung im Warenkorb.
  • popover="hint": für Tooltips, die ein offenes Menü nicht schließen sollen. Unterstützt in Chrome ab Version 151 und Firefox ab Version 153, in Safari noch nicht (Web Features Explorer).

Das Attribut popover läuft seit April 2024 in den aktuellen Versionen aller großen Browser (MDN), ebenso der ältere Weg über popovertarget an Buttons (Web Features Explorer). Die Popover-Funktion als Ganzes führt der Web Features Explorer erst seit dem 27. Januar 2025 als neu verfügbar, weil Safari auf iOS einen Teil davon erst mit Version 18.3 nachgeliefert hat; weitgehend verfügbar ist sie voraussichtlich ab dem 27. Juli 2027 (Web Features Explorer).

mobile-nav.html
<button type="button" commandfor="main-nav" command="toggle-popover">
  Menü
</button>

<nav id="main-nav" popover aria-label="Hauptmenü">
  <ul>
    <li><a href="/leistungen/">Leistungen</a></li>
    <li><a href="/kontakt/">Kontakt</a></li>
  </ul>
</nav>

<style>
  /* Seitenleiste von links, ohne z-index: das Popover liegt im Top Layer */
  #main-nav {
    inset: 0 auto 0 0;
    width: min(20rem, 85vw);
    height: 100dvh;
    margin: 0;
  }
  #main-nav::backdrop {
    background: rgb(0 0 0 / 0.4);
  }
</style>

Eine Filter-Schublade im Shop-Listing ist ein typischer Fall. Der Button „Filter“ öffnet ein Popover, das auf dem Smartphone als Seitenleiste erscheint; ein Klick auf die Seite daneben schließt es wieder. Soll die Schublade den Rest der Seite sperren, etwa weil sie den ganzen Bildschirm füllt, ist ein <dialog> mit command="show-modal" die bessere Wahl, denn ein Popover lässt die Seite dahinter bedienbar. Was nach dem Anwenden eines Filters passiert, bleibt Sache des Listings, das wir im Beitrag zu schnellen Filtern im Shop-Listing beschreiben.

Für die Lage eines Popovers direkt an seinem Button ist CSS Anchor Positioning gedacht. Der Web Features Explorer führt die Ankerpositionierung derzeit als „Limited availability“, also nicht als Baseline (Web Features Explorer). Wer heute ausliefert, setzt das Popover mit festen Abständen oder als Seitenleiste und ergänzt die Ankerposition als Verbesserung. Für Hinweise beim Überfahren mit der Maus oder beim Fokus gibt es außerdem das Attribut interestfor. Es läuft bisher nur in Chrome und Edge ab Version 142 (Web Features Explorer) und ist damit ein Fall für später.

Browserstand 2026 und ein Rückfallweg

Invoker Commands kamen in drei Schritten: Chrome und Edge mit Version 135 im April 2025, Firefox mit Version 144 am 14. Oktober 2025, Safari mit Version 26.2 am 12. Dezember 2025 (Web Features Explorer). Seit diesem Tag gelten sie als Baseline „newly available“. Als „widely available“ führt sie der Explorer voraussichtlich ab dem 12. Juni 2028 (Web Features Explorer). Der Abstand hat einen Grund: Weitgehend verfügbar heißt, dass eine Funktion in jedem Baseline-Browser seit mindestens 2,5 Jahren durchgehend unterstützt wird (MDN).

Baseline ist eine Zusammenfassung, kein Test. MDN weist ausdrücklich darauf hin, dass Baseline womöglich nicht verrät, ob eine Funktion auf älteren Geräten und Browserversionen, in Web-Ansichten des Betriebssystems, wie Apps sie einbetten, und mit Hilfstechnologien wie Screenreadern funktioniert (MDN). Gerade Web-Ansichten spielen für Shops eine Rolle, weil Links aus Apps häufig in solchen eingebetteten Ansichten öffnen. Wer Invoker Commands heute einsetzt, braucht deshalb einen Rückfallweg.

Ein vernünftiger Weg ist schrittweise Verbesserung. Das HTML trägt die Attribute für alle, und ein kleines Skript bildet das Verhalten nur dort nach, wo der Browser command nicht kennt. Die Erkennung prüft, ob das Button-Element die Eigenschaft command besitzt. In aktuellen Browsern endet das Skript nach dieser einen Abfrage:

commands.js
// commands.js: Ersatzweg nur für Browser ohne Invoker Commands
if (!('command' in HTMLButtonElement.prototype)) {
  document.addEventListener('click', (event) => {
    const button = event.target.closest('button[commandfor][command]');
    if (!button) return;
    const target = document.getElementById(button.getAttribute('commandfor'));
    if (!target) return;
    const command = button.getAttribute('command');
    if (command === 'show-modal') target.showModal();
    else if (command === 'close') target.close(button.value);
    else if (command === 'toggle-popover') target.togglePopover?.();
    else if (command === 'show-popover') target.showPopover?.();
    else if (command === 'hide-popover') target.hidePopover?.();
  });
}

Für reine Popover gibt es bis dahin noch eine Abkürzung: popovertarget läuft seit April 2024 in den aktuellen Versionen aller großen Browser (Web Features Explorer) und braucht kein Ersatzskript. Chrome beschreibt command allerdings als vollständigen Ersatz für popovertarget (Chrome for Developers). Wer beides pflegt, legt sich auf einen Weg je Bauteil fest, damit Tests und Wartung übersichtlich bleiben.

Welche Browserversionen Ihre Besucher tatsächlich nutzen, zeigen die eigenen Zugriffsdaten. Danach richtet sich, ob ein Ersatzskript nötig ist oder ob der Anteil älterer Browser so klein ist, dass ein schlichter Rückfall genügt, etwa ein Link auf eine eigene Seite statt eines Dialogs. Diese Abwägung treffen wir mit Ihnen in einer technischen Analyse, für ein vollständiges Audit auf Wunsch auch anhand Ihrer Server-Logs.

Was die Umstellung für INP und den Hauptthread bringt

Ehrlich vorweg: Eine veröffentlichte Messreihe, die den INP-Gewinn durch Invoker Commands beziffert, haben wir nicht gefunden. Der Effekt ergibt sich aus der Mechanik, also aus weniger Skript, das geladen, ausgewertet und beim Klick ausgeführt werden muss. Wie stark er ausfällt, hängt davon ab, wie viel Code die alte Lösung mitbrachte. Wie sich INP zusammensetzt, erklärt der Beitrag INP optimieren.

  • Weniger Code beim Laden: Fällt eine Modal- oder Menübibliothek weg, sinken Download und Auswertungszeit. Das zeigt sich in der Total Blocking Time, die im Labor als Stellvertreter für INP dient und mit ihm korreliert (Web Almanac 2025).
  • Kein toter Klick während des Ladens: Der Button reagiert, sobald das HTML da ist. Bei einem per Skript verdrahteten Button geht ein früher Klick dagegen ins Leere.
  • Kurzer Weg beim Klick: Bei eingebauten Befehlen läuft kein eigener Event-Handler, der Browser öffnet das Ziel direkt. Was bleibt, ist die Darstellung: Stile berechnen, Layout, Zeichnen des Overlays.

Wie viel Spielraum es gibt, zeigen die Felddaten. 77 Prozent der Websites erreichen auf Mobilgeräten einen guten INP-Wert, nach 74 Prozent im Jahr 2024 (Web Almanac 2025). Startseiten liegen mobil bei 80 Prozent, Unterseiten nur bei 69 Prozent (Web Almanac 2025). Der Web Almanac weist darauf hin, dass Unterseiten oft komplexere Interaktionen wie Filter, Karussells und Formularprüfungen enthalten (Web Almanac 2025). Genau dort sitzen auch Dialoge, Schubladen und Rückfragen.

Die Wirkung hat Grenzen. Ein großer Dialog bleibt ein großes Stück DOM, auch wenn er versteckt ist. Wer viele Dialoge mit Formularen und Bildern in jede Seite schreibt, verlagert die Last nur vom Skript in den Dokumentbaum; dazu mehr im Beitrag DOM-Größe reduzieren. Und wer beim Öffnen weiterhin Daten nachlädt, Messereignisse feuert oder Animationen per Skript steuert, hat den Klick nicht entlastet, sondern nur das Öffnen. Die mittlere mobile Seite verzeichnete 2024 14 lange Aufgaben (Web Almanac 2024). Solche Aufgaben teilen Sie mit scheduler.yield auf, rechenintensive Arbeit gehört in einen Web Worker.

Grenzen: wo weiterhin ein Skript nötig ist

Invoker Commands ersetzen das Öffnen und Schließen, nicht die Logik dahinter. In diesen Fällen bleibt JavaScript im Spiel:

  • Daten nachladen: Ein Mini-Warenkorb, der den aktuellen Inhalt zeigt, oder ein Knopf „Mehr laden“ im Listing braucht einen Abruf. Wie sich das schnell hält, beschreibt der Beitrag Seitenzahlen, Mehr laden oder Endlos.
  • Eigene Befehle: Werte mit zwei Bindestrichen wie --rotate-left lösen nur ein command-Ereignis am Ziel aus (HTML Living Standard). Die Wirkung schreibt ein Listener, allerdings einer am Ziel statt einer je Button.
  • Shadow DOM: commandfor verweist über eine ID und reicht deshalb nicht über die Grenze einer Shadow Root. Dort setzt ein Skript die Eigenschaft commandForElement (Chrome for Developers).
  • Zustand merken: Ob ein Hinweis schon geschlossen wurde, muss irgendwo gespeichert werden. Das erledigt ein kurzer Listener auf das Ereignis close oder toggle.
  • Formulare im Dialog: Pflichtfelder prüft der Browser selbst, das Senden an den Server und die Antwort darauf bleiben Aufgabe des Skripts.

Native Elemente nehmen viel Arbeit ab, ersetzen aber keinen Test. Ein Dialog braucht einen sichtbaren Schließen-Button und einen sinnvollen Startfokus, notfalls über autofocus (MDN), dazu eine Überschrift, auf die aria-labelledby zeigt. Der Web Almanac sieht außerdem die wachsende Verbreitung der Rolle button kritisch: Sie steht auf 53 Prozent der Desktop- und 54 Prozent der mobilen Seiten (Web Almanac 2025) und sitzt oft auf <div>- oder <span>-Elementen. Invoker Commands funktionieren nur an echten <button>-Elementen (MDN). Die Umstellung ist damit ein guter Anlass, solche Nachbauten zu ersetzen.

Die Umstellung Schritt für Schritt

Die Umstellung lohnt sich am meisten, wenn sie eine Bibliothek tatsächlich aus dem Bundle entfernt. Einzelne Dialoge umzubauen, während die alte Modal-Bibliothek für andere Bauteile weiter lädt, spart Wartung, aber kaum Ladezeit. Diese Reihenfolge empfehlen wir:

  1. Bestand aufnehmen: Welche Overlays gibt es je Vorlage, welches Skript öffnet sie, welche Bibliothek steckt dahinter? Die Coverage-Ansicht der Entwicklerwerkzeuge zeigt, wie viel davon beim Laden ungenutzt bleibt.
  2. Einfache Fälle zuerst: Rückfragen, Hinweise und Menüs ohne Datenabruf auf <dialog> oder popover mit command umstellen.
  3. Rückfall festlegen: Ersatzskript per Erkennung oder für Popover vorerst popovertarget; jeden Button mit type="button" versehen.
  4. Bibliothek entfernen, nicht nur umgehen: Erst wenn kein Bauteil die alte Bibliothek mehr braucht, fällt sie aus dem Bundle. Ein JavaScript-Budget hält fest, dass sie nicht zurückkommt.
  5. Messen: Total Blocking Time im Labor vor und nach der Änderung, INP im Feld über mehrere Wochen. Als Richtwert nennt web.dev 100 KB je einzelnem Skript (web.dev).
  6. Zugänglichkeit prüfen: Tastatur, Screenreader und Zoom, dazu der Fokus beim Öffnen und Schließen jedes Dialogs.

Für Drittanbieter-Widgets, die eigene Overlays mitbringen, hilft die Umstellung nur bedingt. Dort liegt der Hebel im Entschlacken von Third-Party-Skripten, denn deren Code steuern Sie nicht selbst.

In unserer Frontend-Optimierung gehen wir genau diese Liste für Ihre Vorlagen durch: Wir finden die Overlays, ersetzen, was der Browser selbst kann, behalten das Skript dort, wo es gebraucht wird, und messen TBT und INP vor und nach der Änderung. Die Werte ordnen wir in die Core Web Vitals ein, im Labor mit Lighthouse und im Feld mit den Daten des Chrome UX Report.

Quellen und Dokumentation

Dieser Artikel basiert auf Daten aus: Web Features Explorer (Invoker commands, Popover, <dialog>, <dialog closedby>, popover="hint", Interest invokers, Anchor positioning); HTML Living Standard (The button element); MDN Web Docs (Invoker Commands API, popover, <dialog>, Baseline); Chrome for Developers (Introducing command and commandfor, 2025); HTTP Archive Web Almanac 2024 (Kapitel JavaScript); HTTP Archive Web Almanac 2025 (Kapitel Performance und Accessibility); web.dev (Script evaluation and long tasks).

Verwandte Artikel

Shops & CMS

Seitenzahlen, Mehr laden oder Endlos: Listing schnell halten

Seitenzahlen, Mehr laden oder endloses Scrollen im Shop-Listing: wie Startlast, INP, Layoutsprünge, Rücksprung und eigene URL je Seite zusammenhängen.

21 Min. Lesezeit
Frontend-Optimierung

Produktgalerie und Zoom: schnelle Produktseite trotz Bildern

Produktgalerie und Zoom ohne Tempoverlust: erstes Bild eager und priorisiert, Folgebilder lazy, Zoom-Datei erst beim Klick, Variantenwechsel ohne Neuladen.

18 Min. Lesezeit
Shops & CMS

Filter im Shop-Listing: schnelle Facetten ohne Wartezeit

Jeder Filterklick im Shop zählt zur INP. So bestätigen Sie den Klick sofort, rechnen Zähler sparsam, cachen Ergebnisse und bauen das Listing ruhig neu auf.

19 Min. Lesezeit