Web Components

Web Components, auf Deutsch auch Web-Komponenten genannt, erweitern HTML um individuell definierte Elemente. Ein Element wie <product-card> kann eigene Inhalte, Gestaltung und Funktionen enthalten. Der Browser behandelt dieses Element nach seiner Registrierung ähnlich wie ein bekanntes HTML-Element, beispielsweise <button> oder <video>.

Wie funktionieren Web Components?

Web Components sind kein einzelnes Dateiformat und keine Programmbibliothek. Der Begriff fasst mehrere standardisierte Browser-Schnittstellen zusammen. In der Praxis besteht eine Komponente meist aus einem benutzerdefinierten Element, einer JavaScript-Klasse und optional einem Shadow DOM sowie einer HTML-Vorlage.

• Custom Elements definieren neue HTML-Elemente und deren Verhalten.
• Shadow DOM kapselt interne HTML-Strukturen und CSS-Regeln.
• HTML Templates halten wiederverwendbare, zunächst inaktive Markup-Vorlagen bereit.
• Slots ermöglichen die Übergabe externer Inhalte an festgelegte Stellen der Komponente.

Custom Elements definieren

Ein Custom Element wird über JavaScript registriert und gewöhnlich von HTMLElement abgeleitet. Der Name eines autonomen Custom Elements muss einen Bindestrich enthalten. <product-card> ist daher zulässig, <productcard> dagegen nicht. Diese Bedingung verhindert Überschneidungen mit bestehenden oder zukünftigen HTML-Elementen.

Lebenszyklusmethoden steuern, wann eine Komponente reagiert. connectedCallback() wird beispielsweise aufgerufen, sobald das Element in das Dokument eingefügt wurde. disconnectedCallback() eignet sich dazu, Ereignis-Listener oder andere Ressourcen zu entfernen, wenn das Element nicht mehr im Dokument liegt.

Shadow DOM kapselt Inhalte

Das Shadow DOM erzeugt innerhalb eines Elements einen abgegrenzten DOM-Baum. CSS-Regeln der umgebenden Seite greifen dort grundsätzlich nicht unkontrolliert ein, während interne Styles normalerweise nicht nach außen wirken. Diese Kapselung reduziert Namenskonflikte, verlangt aber eine bewusst geplante Schnittstelle für Farben, Abstände und andere anpassbare Eigenschaften.

Templates und Slots einsetzen

Der Inhalt eines <template>-Elements wird beim Einlesen der Seite nicht unmittelbar gerendert. JavaScript kann die Vorlage klonen und in eine oder mehrere Komponenten einfügen. Ein <slot> markiert dabei eine Position, an der Inhalte aus dem normalen Dokumentbaum erscheinen sollen.

HTML Templates eignen sich für wiederkehrende Strukturen wie Teaser, Preisboxen oder Suchergebnisse. Bei vielen Instanzen sollte die Komponente jedoch nicht für jedes Element identische große Stylesheets und Skripte neu erzeugen. Gemeinsam genutzte Ressourcen und eine kontrollierte Initialisierung begrenzen den Aufwand im Browser.

Web Components im technischen SEO

Web Components sind weder grundsätzlich SEO-freundlich noch grundsätzlich problematisch. Für die Indexierung zählt, welche Inhalte und Links ein Suchsystem im initialen HTML sowie nach dem Rendering tatsächlich erkennen kann. Eine visuell vollständige Komponente kann für einen Crawler unvollständig bleiben, wenn zentrale Texte erst nach fehleranfälligen API-Aufrufen oder Nutzerinteraktionen eingefügt werden.

Der verbreitete Denkfehler besteht darin, die Browser-Unterstützung mit der Suchmaschinen-Verarbeitung gleichzusetzen. Ein moderner Browser kann ein Custom Element korrekt darstellen, während ein Crawler wegen blockierter Skripte, fehlender Daten oder eines JavaScript-Fehlers nur den leeren Elementnamen erhält. Prüfe deshalb nicht nur die sichtbare Seite, sondern auch den ausgelieferten Quelltext und das gerenderte HTML.

Serverseitige Inhalte absichern

Geschäftskritische Inhalte sollten möglichst bereits in der Serverantwort vorhanden sein. Dazu gehören Produktnamen, Preise, Überschriften, Kategorietexte und interne Links. Serverseitiges Rendering oder Declarative Shadow DOM kann eine Komponente so ausliefern, dass ihre Struktur vor der JavaScript-Ausführung im HTML steht. JavaScript ergänzt anschließend Interaktionen wie Filter, Variantenwechsel oder Warenkorbfunktionen.

Diese Aufteilung folgt dem Prinzip der progressiven Verbesserung: Der Kerninhalt bleibt ohne erfolgreiche JavaScript-Ausführung verständlich, während der Browser zusätzliche Funktionen aktiviert. Bei einem Website-Relaunch sollte diese Auslieferung vor dem Wechsel mit repräsentativen Produkt-, Kategorie- und Informationsseiten geprüft werden.

Links und strukturierte Daten prüfen

Interne Links innerhalb von Web Components sollten als echte HTML-Verweise mit <a href="..."> umgesetzt sein. Klickbare Container, die eine Zielseite ausschließlich über JavaScript öffnen, liefern Suchmaschinen kein gleichwertiges, verlässlich crawlbares Linksignal. Der Linktext sollte das Ziel beschreiben und die URL ohne vorherige Nutzeraktion verfügbar sein.

Strukturierte Daten sollten ebenfalls unabhängig von einer späteren Interaktion abrufbar sein und zum sichtbaren Seiteninhalt passen. JSON-LD lässt sich dafür zentral im Dokument ausgeben. Wenn eine Produktkomponente Preis oder Verfügbarkeit aktualisiert, müssen sichtbare Angaben und strukturierte Daten denselben Zustand beschreiben.

Performance und Core Web Vitals

Web Components können Code wiederverwendbar machen, garantieren aber keine schnelle Website. Jede Instanz kann JavaScript ausführen, DOM-Knoten erzeugen und Ereignis-Listener registrieren. Eine Seite mit vielen komplexen Komponenten belastet deshalb unter Umständen den Hauptthread und reagiert verzögert auf Eingaben.

Für die Core Web Vitals sind drei Auswirkungen besonders relevant:

• Spät geladene Hauptinhalte können den Largest Contentful Paint verlängern.
• Aufwendige Initialisierungen können die Reaktionsfähigkeit und damit den Interaction to Next Paint belasten.
• Komponenten ohne reservierte Höhe können nach ihrer Aktivierung Layout-Verschiebungen verursachen.

Messbar ist das zum Beispiel so: Vergleiche im Technik-Crawler der Performance Suite betroffene Seitentypen und prüfe zusätzlich reale Templates mit einem Ladezeitentest. Achte darauf, ob Produktlisten, Navigationen oder Formulare erst nach der Initialisierung ihre endgültige Größe erreichen. Der Vergleich sollte mobil und auf mehreren repräsentativen URLs erfolgen.

Prüfe eine konkrete URL direkt mit dem kostenlosen Ladezeiten-Check:

Analyse starten

Mit Nutzung dieses PageSpeed-Checks erklären Sie, dass Sie die Datenschutzerklärung zur Kenntnis genommen haben und damit einverstanden sind, dass die von Ihnen angegebenen Daten elektronisch erhoben und gespeichert werden. Ihre Daten werden dabei nur streng zweckgebunden zur Bearbeitung des PageSpeed-Checks benutzt. Mit der Nutzung dieses PageSpeed-Checks erklären Sie sich mit der Verarbeitung einverstanden.

?

Tageslimit erreicht!

Erstelle dir einen Free Account für die Performance Suite und erhalte trotzdem weitere Daten zu deiner URL.

Direkter Zugriff mit Free Account

Ladezeiten-Score: N/A von 100

i Ladezeiten (Desktop):	N/A
i Ladezeiten (Mobile):	N/A
i PageSpeed (Desktop):	N/A
i PageSpeed (Mobile):	N/A
i CMS:
i Gehosted bei:
i WordPress Theme:

Ladezeiten (Desktop)

Check fehlgeschlagen

✕ Optimierungsvorschläge

Leistungsmessung i

Performance-Möglichkeiten i

Ladezeiten (Mobile)

Check fehlgeschlagen

✕ Optimierungsvorschläge

Leistungsmessung i

Performance-Möglichkeiten i

Eine performante Umsetzung lädt den Code einer Komponente nur dort, wo er benötigt wird. Unterhalb des sichtbaren Bereichs liegende Elemente können verzögert initialisiert werden, sofern dadurch keine indexierbaren Inhalte oder internen Links zurückgehalten werden. Weitere Prüfpunkte enthält der Leitfaden zu den wichtigsten Maßnahmen im technischen SEO.

Web Components und Frameworks

Der Unterschied zwischen Web Components und Framework-Komponenten liegt in der technischen Grundlage. Web Components beruhen auf Browser-Standards. Komponenten aus React, Vue oder vergleichbaren Systemen folgen dagegen dem jeweiligen Framework-Modell und benötigen dessen Laufzeit oder Build-Prozess.

Web Components und JavaScript-Frameworks schließen sich nicht aus. Ein Unternehmen kann beispielsweise ein Designsystem als Custom Elements bereitstellen und diese Elemente in mehreren Anwendungen einsetzen. Vor der Einführung sollte die Entwicklung jedoch prüfen, wie Datenübergabe, Ereignisse, serverseitiges Rendering und automatisierte Tests im jeweiligen Framework funktionieren.

Typische Fehler bei Web Components

Ein häufiger Fehler ist eine zu starke Abschottung durch das Shadow DOM. Farben, Schriftgrößen oder Zustände lassen sich dann nur durch Änderungen am internen Code anpassen. CSS Custom Properties und klar dokumentierte Attribute schaffen eine kontrollierte Schnittstelle zwischen Designsystem und Komponente.

Auch Barrierefreiheit entsteht nicht automatisch durch technische Kapselung. Interaktive Elemente benötigen weiterhin passende HTML-Semantik, Tastaturbedienung, sichtbare Fokuszustände und zugängliche Namen. Ein klickbares <div> wird durch die Platzierung in einem Custom Element nicht zu einem semantischen Button.

• Custom Elements dürfen nicht dauerhaft leer bleiben, wenn sie indexierbaren Hauptinhalt enthalten.
• Interne Navigationen benötigen echte Links mit erreichbaren URLs.
• Komponenten müssen ohne verspätete Größenänderungen gerendert werden.
• Ereignis-Listener und Beobachter sollten beim Entfernen der Komponente bereinigt werden.
• Attribute, Events und anpassbare CSS-Eigenschaften benötigen eine feste Dokumentation.

Bei einer neuen Website-Entwicklung mit SEO-Fokus sollten Web Components deshalb nicht nur als Frontend-Bausteine bewertet werden. Zum Abnahmetest gehören Quelltext, Rendering, interne Verlinkung, strukturierte Daten, Barrierefreiheit und Core Web Vitals auf realen Seitentypen.

Häufige Fragen zu Web Components

Wenn du prüfen möchtest, wie deine Website Web Components, JavaScript und technische SEO-Signale ausliefert, kannst du einen unverbindlichen Potenzialcheck anfragen.

Kostenlosen Potenzialcheck anfragen