AEM Client Libraries JavaScript und CSS nach Seitentyp bündeln, verzögert laden und lange zwischenspeichern
Client Libraries sind der Mechanismus, mit dem Adobe Experience Manager JavaScript und CSS bündelt und ausliefert. Sie bestimmen, wie viel Code ein Browser laden und ausführen muss, bevor eine Seite reagiert. Auf gewachsenen Plattformen lädt oft jede Seite dasselbe große Bündel. Das belastet den Hauptthread und damit die Interaction to Next Paint, also die Zeit zwischen einer Eingabe und der sichtbaren Reaktion. Diese Seite zeigt, wie Client Libraries nach Seitentyp getrennt, verzögert geladen und lange zwischengespeichert werden.
Im AEM Core Web Vitals Benchmark 2026 erreichen 74,4 Prozent der AEM-Auftritte im DACH-Raum auf Mobilgeräten eine gute Reaktionszeit. Unter den Auftritten, die die Core Web Vitals im eigenen Abruf nicht bestehen, verfehlen 47,2 Prozent den Grenzwert für die Reaktionszeit.
Client Libraries in AEM: Kategorien, embed und dependencies
Eine Client Library ist ein Ordner vom Typ cq:ClientLibraryFolder mit JavaScript- und CSS-Dateien. Drei Eigenschaften steuern, was am Ende im Browser ankommt:
categoriesgibt der Bibliothek einen Namen, über den Seiten und Komponenten sie einbinden.embedfügt den Code anderer Kategorien in die eigene Datei ein. Aus mehreren Bibliotheken wird so eine einzige Anfrage, aber auch ein einziges, nicht mehr trennbares Bündel.dependencieslädt andere Kategorien als eigene Dateien vor der eigenen Bibliothek.
Mit allowProxy werden Bibliotheken aus /apps über den Pfad /etc.clientlibs ausgeliefert. Besucher erreichen sie so, ohne dass /apps freigegeben werden muss, und der Dispatcher speichert sie unter diesem Pfad zwischen. Adobe rät inzwischen davon ab, embed und dependencies ohne Not einzusetzen. Eingebunden werden sie im HTL der Seitenkomponente oder über die Richtlinie der Core-Components-Seitenkomponente.
Ein Bündel für alle Seiten: Folge von gewachsenem embed
Der AEM-Projektarchetyp legt eine Basisbibliothek an, die die Bibliotheken der Core Components und des Rasters einbettet, dazu eine Site-Bibliothek aus dem Frontend-Modul. Für den Start ist das sinnvoll. Über Jahre kommen Komponenten, Kampagnen und Bibliotheken von Drittanbietern hinzu, und jede neue Kategorie wird an das bestehende Bündel gehängt, weil das am wenigsten Abstimmung kostet.
Das Ergebnis ist eine Plattform, auf der eine Detailseite mit drei Komponenten den Code aller Komponenten lädt. Auf einfachen Seiten kann das gemeinsame Bündel der größte Einzelposten sein. Den Anteil ungenutzten Codes zeigt die Abdeckungsanzeige der Chrome-Entwicklertools je Seitentyp. Bei Plattformen mit einem einzigen Gesamtbündel ist dieser Anteil oft ein großer Hebel für die Reaktionszeit.
Bündel je Seitentyp: Kategorien nach Vorlage statt nach Komponente
Wirksam ist die Trennung nach Seitentypen statt nach Autorenlogik:
- Eine schlanke Grundbibliothek für alles, was jede Seite braucht, etwa Raster, Navigation und Typografie.
- Je Vorlage oder Seitentyp eine eigene Kategorie mit den Komponenten, die dort tatsächlich vorkommen. Über die Richtlinie der Seitenkomponente lässt sich je Vorlage festlegen, welche Kategorien geladen werden.
- Selten genutzte, schwere Komponenten wie Konfiguratoren, Karten oder Videospieler als eigene Bibliothek, die erst geladen wird, wenn die Komponente auf der Seite steht.
Die Trennung erhöht die Zahl der Anfragen leicht. Bei HTTP/2 und langen Cache-Laufzeiten ist das ein geringer Preis gegenüber dem Code, der auf jeder Seite nicht mehr ausgeführt werden muss.
Laden im Kopf oder am Ende: CSS früh, JavaScript verzögert
CSS im Kopf blockiert die Darstellung, bis es geladen ist. Das ist für die Regeln der ersten Ansicht richtig, für den Rest nicht. Ein großes Stylesheet für alle Seiten verzögert den ersten Aufbau und damit den Largest Contentful Paint.
JavaScript gehört an das Ende der Seite oder mit defer eingebunden, sofern es nicht für die erste Ansicht nötig ist. Die Richtlinie der Core-Components-Seitenkomponente trennt die Bibliotheken für den Kopf von denen am Ende der Seite. Aktuelle Core Components bieten für die Einbindung zusätzlich Attribute wie async und defer. Ob sie im ausgelieferten HTML ankommen, gehört im Quelltext geprüft, weil ältere Projekte eigene Vorlagen zur Einbindung verwenden.
Minifizierung und Cache-Laufzeit: HTML Library Manager und versionierte Adressen
Der HTML Library Manager fasst die Dateien einer Kategorie zusammen und kann sie minifizieren und komprimieren. Ob das auf der Publish-Instanz aktiv ist, zeigt ein Blick auf die ausgelieferten Dateien. Unminifizierte Bibliotheken sind auf älteren Plattformen keine Seltenheit.
Für lange Cache-Laufzeiten braucht jede Fassung einer Bibliothek eine eigene Adresse. AEM as a Cloud Service versioniert die Adressen von Client Libraries mit einem Hash des Inhalts, sodass Browser und CDN sie dauerhaft zwischenspeichern können. AEM 6.5 bringt diese Versionierung nicht mit, dort leistet das häufig die Funktion Versioned ClientLibs aus ACS AEM Commons. Ohne Versionierung bleibt nur eine kurze Cache-Laufzeit, und wiederkehrende Besucher laden unveränderten Code neu. Wie /etc.clientlibs im Dispatcher zwischengespeichert wird, beschreibt AEM Dispatcher Cache.
Client Libraries und Tags: der Code, der nicht aus dem Projekt stammt
Neben den Client Libraries lädt fast jede AEM-Plattform JavaScript aus der Tag-Verwaltung, etwa Adobe Experience Platform Tags (früher Adobe Launch) mit Analyse, Personalisierung und Einwilligungsdialog. Dieser Teil steht in keiner Kategorie und taucht in keiner Projektprüfung auf, wirkt aber auf dieselbe Reaktionszeit. Ein Budget für Client Libraries ohne Budget für Tags verschiebt das Problem nur. Bei AEM Edge Delivery Services ersetzen Blöcke die Client Libraries, die Frage nach Tags und ihrer Ladephase bleibt dieselbe.
Client-Library-Anforderungen im Lastenheft: Budget je Seitentyp
- Ein Budget je Seitentyp für JavaScript und CSS in Kilobyte, komprimiert übertragen, abgeleitet aus dem gemessenen Ausgangswert.
- Eine Obergrenze für den Anteil ungenutzten Codes je Seitentyp, gemessen mit der Abdeckungsanzeige.
- Eine dokumentierte Ladeart je Kategorie: im Kopf, am Ende, verzögert oder nur bei Bedarf.
- Versionierte Adressen mit langer Cache-Laufzeit für alle Bibliotheken.
- Abnahme gegen die Interaction to Next Paint echter Besucher je Seitentyp.
Die vollständigen Formulierungen stehen in der Vorlage Performance-Anforderungen im AEM-Lastenheft. Wie Implementierungspartner und unabhängige Abnahme dabei zusammenarbeiten, beschreibt Performance-Partner für AEM-Agenturen. Alle Ursachen auf AEM-Plattformen ordnet Adobe Experience Manager Performance ein.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie erhalten die Google-Nutzerdaten Ihrer Plattform im Vergleich zu zwei Wettbewerbern, unabhängig davon, ob wir zusammenarbeiten.
Häufige Fragen zu AEM Client Libraries
Was ist der Unterschied zwischen embed und dependencies in AEM Client Libraries?
Mit embed wird der Code anderer Kategorien in die eigene Datei eingefügt, das spart Anfragen, erzeugt aber ein untrennbares Bündel. Mit dependencies werden andere Kategorien als eigene Dateien vor der eigenen Bibliothek geladen. Für Performance entscheidend ist, dass eine Seite nur die Kategorien lädt, die ihre Komponenten tatsächlich brauchen.
Wie lässt sich JavaScript in AEM verzögert laden?
JavaScript, das für die erste Ansicht nicht nötig ist, gehört an das Ende der Seite oder wird mit defer eingebunden. Die Richtlinie der Core-Components-Seitenkomponente trennt Bibliotheken für Kopf und Seitenende, aktuelle Core Components bieten zusätzlich async und defer für die Einbindung. Das Ergebnis sollte im ausgelieferten HTML geprüft werden.
Wie groß dürfen die Client Libraries einer AEM-Seite sein?
Eine allgemeingültige Grenze gibt es nicht. Das Budget entsteht je Seitentyp aus dem gemessenen Ausgangswert und dem Zielwert für die Interaction to Next Paint. Maßgeblich ist neben der Größe der Anteil, der vor der ersten Interaktion ausgeführt wird.