Benchmark Adobe Experience Manager, Datenstand August 2026, Version 2026-Q3
AEM Core Web Vitals Benchmark 2026 4.222 Auftritte im DACH-Raum, ausgewertet nach Ursachen statt nach Punktwerten
Adobe Experience Manager trägt die größten Auftritte im deutschsprachigen Raum, und genau dort entscheidet die Auslieferung über die Nutzererfahrung. Diese Auswertung nimmt 4.222 AEM-Auftritte aus Googles Nutzerdaten auseinander und ergänzt sie um einen eigenen Abruf von 46.394 Domains, der zeigt, welche Generation ausliefert und ob eine langsame Seite am Betrieb oder am Frontend hängt.
- 49,4 Prozent der AEM-Auftritte bestehen die Core Web Vitals auf Mobilgeräten, gegenüber 68,7 Prozent über alle Websites der drei Länder.
- Bei 80,3 Prozent der Auftritte mit zu langsamem Hauptinhalt ist bereits die Antwortzeit des Servers zu hoch. Die Arbeit beginnt dort im Betrieb, nicht im Frontend.
- Unter den Auftritten, die durchfallen, verfehlen 55,9 Prozent die Ladezeit des Hauptinhalts (LCP).
- 28,8 Prozent der im eigenen Abruf erkannten AEM-Auftritte liefern noch über die Pfade der Generationen bis 6.3 aus.
- Auftritte auf Edge Delivery Services bestehen zu 54,0 Prozent, 4,6 Prozentpunkte besser als die klassische Auslieferung.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie sehen, wo Ihre Plattform in dieser Verteilung steht und welche der beiden Ursachen bei Ihnen überwiegt.
- Zwei Datenquellen: Googles Nutzerdaten für die Breite, ein eigener Abruf für Generation und Ursache
- Kein Zugang, kein Formular. Rohdaten, Methodik und Abfragen stehen auf dieser Seite
AEM-Auftritte liegen 19,3 Punkte unter dem Marktdurchschnitt, und Größe allein erklärt das nicht
Der erste Vergleich stellt die AEM-Auftritte im DACH-Raum allen erfassten Websites der drei Länder gegenüber, jeweils auf Mobilgeräten.
Der naheliegende Einwand
Der Abstand hat einen strukturellen Anteil. AEM steht dort, wo Auftritte groß sind: mehrere Märkte und Sprachen, Kampagnenflächen, Personalisierung, Tag-Management, Einwilligungsdialog. Der Durchschnitt über alle Websites wird dagegen von vielen kleinen, technisch einfachen Auftritten getragen. Insofern vergleicht die erste Zahl zwei unterschiedliche Klassen von Websites.
Was dagegen spricht
Der Einwand trägt nur bis zur zweiten Zahl. Innerhalb der 100.000 meistbesuchten Websites, also in derselben Größenklasse, bestehen AEM-Auftritte zu 53,9 Prozent, und damit 4,5 Prozentpunkte besser als über alle Ränge. Der Rückstand auf den Gesamtmarkt bleibt bestehen. Die Größe der Auftritte erklärt einen Teil des Abstands, nicht den ganzen.
Betrieb oder Frontend: bei 80,3 Prozent der langsamen Auftritte antwortet schon der Server zu spät
Die wichtigste Frage einer Analyse lautet nicht, wie schlecht ein Wert ist, sondern wer ihn beheben kann. Das lässt sich trennen, weil neben der Ladezeit des Hauptinhalts auch die Antwortzeit des Servers als Nutzerdatum vorliegt.
Wie die Trennung funktioniert
Die Antwortzeit des Servers misst, wie lange es dauert, bis das erste Byte der Seite beim Browser ankommt. Bis 800 Millisekunden gilt sie als gut. Ist dieser Wert schon schlecht, verpufft jede Optimierung an Bildern und Skripten, weil die Verzögerung davor entsteht: im Dispatcher, in der Trefferquote des Caches, in der Renderzeit der Publish-Instanz. Ist die Antwortzeit gut und der Hauptinhalt trotzdem spät da, liegt die Ursache im Frontend.
Was die Daten zeigen
Von 71 Auftritten mit zu langsamem Hauptinhalt haben 57 bereits eine zu hohe Antwortzeit des Servers, im Mittel 1.565 Millisekunden. Bei den übrigen 14 Auftritten antwortet der Server im Mittel nach 614 Millisekunden, die Verzögerung entsteht also danach. Über alle geprüften Auftritte hinweg halten 68,7 Prozent die Antwortzeit im guten Bereich.
Für die Praxis heißt das: Ein Performance-Ticket an das Frontend-Team ist bei der Mehrheit dieser Auftritte an der falschen Adresse. Der erste Blick gehört der Trefferquote des Dispatcher-Caches, den Invalidierungsregeln nach jeder Aktivierung und der Frage, wie viele Seitenvarianten die Personalisierung erzeugt. Erst wenn die Antwortzeit steht, lohnt die Arbeit an Bildern, Schriften und Skripten.
LCP entscheidet über das Ergebnis
Eine Website besteht die Core Web Vitals nur, wenn alle drei Kennzahlen im grünen Bereich liegen. Die Aufteilung zeigt, welche davon in der Praxis den Ausschlag gibt.
Ladezeit des Hauptinhalts
67,6 Prozent halten den Grenzwert von 2,5 Sekunden, der Mittelwert liegt bei 2,0 Sekunden. Gemessen wird, wann das größte sichtbare Element im ersten Bildschirmausschnitt fertig geladen ist, meist das Titelbild. Auf AEM-Auftritten ist das fast immer ein Asset aus dem DAM, ausgeliefert über eine Renditions-Kette, die selten für mobile Bildschirmbreiten optimiert ist.
Reaktionszeit auf Eingaben
74,4 Prozent bleiben unter 200 Millisekunden, im Mittel sind es 150 Millisekunden. Diese Kennzahl steigt mit der Menge an JavaScript, die im Hauptthread arbeitet. Auf großen Auftritten kommt die selten aus dem CMS: Tag-Manager, Einwilligungsdialog, Testwerkzeuge und Analytik teilen sich denselben Thread wie die Bedienelemente der Seite.
Layoutstabilität
75,7 Prozent liegen unter 0,1, der Mittelwert beträgt 0,05. Gemessen wird, wie stark Inhalte während des Ladens verspringen. Das ist die am besten beherrschte der drei Kennzahlen, weil feste Abmessungen für Bilder und Werbeflächen zum Handwerk gehören. Wo sie reißt, liegt es meist an nachgeladenen Kampagnenbannern ohne reservierten Platz.
Im eigenen Abruf von 364 Auftritten mit Nutzerdaten fallen 127 durch. Davon verfehlen 47,2 Prozent die Reaktionszeit, 55,9 Prozent die Ladezeit und 46,5 Prozent die Layoutstabilität. Bei 37,8 Prozent sind es mehrere Kennzahlen gleichzeitig, was in aller Regel auf eine gemeinsame Ursache hindeutet und nicht auf drei getrennte Baustellen.
Generationen: 140 von 486 Auftritten liefern über die alten Pfade aus
Welche AEM-Generation ein Auftritt einsetzt, verrät keine öffentliche Statistik. Die Technologie-Erkennung des HTTP Archive kennt für Adobe Experience Manager genau einen Eintrag und keine Version. Sichtbar ist die Generation trotzdem, am Auslieferungspfad der Client Libraries.
Woran sich die Generation erkennen lässt
Bis einschließlich AEM 6.3 liegen die gebündelten Skripte und Stylesheets unter /etc/designs/ und /etc/clientlibs/. Ab 6.4 liefert der Proxy sie unter /etc.clientlibs/ aus. Edge Delivery Services meldet sich über eigene Hostnamen und über /scripts/aem.js. Alle drei Muster stehen im Quelltext jeder Seite und lassen sich mit einem einzigen Aufruf der Startseite prüfen.
Was der Befund aussagt
Von 486 erkannten Auftritten liefern 140 ausschließlich über die alten Pfade aus. Das ist kein Beweis für eine bestimmte Version, aber ein belastbarer Hinweis auf einen Stand, den der Hersteller nicht mehr unterstützt. Für den Betreiber ist die Zahl vor allem eine Aussage über Handlungsspielraum: Wer auf dieser Ebene steht, kann weder Core Components in aktueller Form noch die neueren Bild- und Auslieferungsfunktionen nutzen.
| Generation | Auftritte | bestanden | ohne Verbundauftritte | Antwortzeit des Servers |
|---|---|---|---|---|
| AEM 6.4+ mit Altpfaden | 25 | 72,0 % | 72,0 % bei 25 | 493 ms |
| CQ5 bis AEM 6.3 | 134 | 87,3 % | 70,6 % bei 51 | 636 ms |
| AEM 6.4+ | 154 | 51,3 % | 51,3 % bei 154 | 792 ms |
| Edge Delivery Services | 51 | 45,1 % | 45,1 % bei 51 | 782 ms |
Ein einzelner Verbund verschiebt die Statistik einer ganzen Generation
Auf den ersten Blick schneiden die Altinstallationen glänzend ab: 87,3 Prozent von 134 Auftritten bestehen die Core Web Vitals. Der Grund ist nicht das Alter der Software. 83 dieser Auftritte gehören zum Sparkassen-Finanzverbund, laufen auf einer gemeinsam betriebenen Plattform mit einheitlichen Vorlagen und bestehen zu 97,6 Prozent. Gezählt werden sie als viele Websites, zurück gehen sie auf eine einzige technische Entscheidung.
Ohne diese Gruppe bleiben 51 Auftritte auf einer Generation ohne Herstellersupport, die zu 70,6 Prozent bestehen, gegenüber 54,2 Prozent bei den 179 Auftritten ab Version 6.4. Der Abstand von 16,4 Prozentpunkten geht weiterhin zugunsten der älteren Gruppe, fällt aber deutlich kleiner aus. Erklärbar ist er ohne Rückgriff auf die Version: Wer seit Jahren nicht migriert hat, betreibt in der Regel auch den schlankeren Auftritt, ohne Personalisierung und ohne die Kampagnenlogik neuerer Projekte. Eine neue Version macht eine Plattform nicht langsamer, sie kommt in der Praxis nur mit mehr Funktionen.
Die verwertbare Erkenntnis: Ein Upgrade verbessert die Core Web Vitals nicht von selbst, und ein Verzicht auf das Upgrade schützt sie nicht. Was zählt, ist die Menge dessen, was mit jedem Release an Kampagnen-, Personalisierungs- und Drittanbieter-Logik dazukommt. Deshalb gehört ein Performance-Budget in die Abnahme jedes Releases, unabhängig von der Version.
Edge Delivery Services: 4,6 Punkte Vorsprung, aber kein Freifahrtschein
Adobe bewirbt Edge Delivery Services mit Bestwerten in Lighthouse. Die Nutzerdaten zeigen ein nüchterneres, aber immer noch klares Bild.
Was die Zahlen hergeben
Im DACH-Raum sind 87 Auftritte mit Edge Delivery Services erfasst. Davon bestehen 54,0 Prozent die Core Web Vitals, gegenüber 49,4 Prozent bei der klassischen Auslieferung. Der Vorsprung ist real, die Gruppe aber klein und in ihrer Zusammensetzung nicht zufällig: Wer heute auf Edge Delivery wechselt, baut das Frontend neu und trennt sich dabei meist von Altlasten, die mit der Auslieferungsart nichts zu tun haben.
Was der Wechsel nicht löst
Die Auslieferung über das Edge-Netz verkürzt die Antwortzeit des Servers, also genau den Teil, der bei 80,3 Prozent der langsamen Auftritte das Problem ist. Nicht gelöst wird alles, was danach im Browser passiert. Tag-Manager, Einwilligungsdialog und Personalisierung wandern bei einer Migration in aller Regel unverändert mit. Ein Auftritt, dessen Reaktionszeit heute an drei Analytics-Werkzeugen hängt, wird davon auf Edge Delivery nicht schneller.
Für die Entscheidung heißt das: Die Frage vor einer Migration lautet nicht, ob Edge Delivery schneller ist, sondern welcher Anteil der eigenen Verzögerung vor dem ersten Byte liegt. Diese Zahl steht in den eigenen Nutzerdaten und ist in einer Stunde ermittelt. Liegt der Schwerpunkt im Frontend, bringt die Migration weniger als die Hälfte dessen, was die Beispielwerte versprechen.
Mobil und Desktop liegen 3,1 Punkte auseinander
Beide Formfaktoren werden getrennt bewertet, und für das Ranking zählt in der Regel der mobile Wert.
Im eigenen Abruf bestehen 65,1 Prozent der Auftritte auf Mobilgeräten und 62,0 Prozent auf dem Desktop. Der Hauptinhalt ist mobil im Mittel nach 1,9 Sekunden sichtbar, auf dem Desktop nach 1,4 Sekunden. Diese Schere entsteht nicht durch die Bildschirmgröße, sondern durch Rechenleistung und Netz: Dasselbe JavaScript-Bündel braucht auf einem Mittelklasse-Telefon ein Vielfaches der Zeit, die es auf einem Arbeitsplatzrechner benötigt. Wer die Abnahme eines Releases auf Desktop-Werte stützt, misst systematisch den günstigeren Fall.
Branchen: 67,8 Punkte zwischen der besten und der schwächsten Gruppe
Die Branche wird am Domainnamen zugeordnet, die Muster stehen in der Methodik. Ausgewiesen werden nur Gruppen mit mindestens zehn Auftritten.
| Branche | Auftritte | bestanden | Hauptinhalt | Antwortzeit |
|---|---|---|---|---|
| Versicherungen | 27 | 81,5 % | 1,8 s | 637 ms |
| Banken und Finanzdienstleister | 50 | 76,0 % | 1,8 s | 629 ms |
| Industrie und Maschinenbau | 37 | 64,9 % | 1,9 s | 782 ms |
| Chemie, Pharma und Medizintechnik | 19 | 57,9 % | 2,2 s | 1.072 ms |
| Konsumgüter und Handel | 14 | 50,0 % | 2,3 s | 1.049 ms |
| Automobil und Zulieferer | 38 | 36,8 % | 2,3 s | 667 ms |
| Telekommunikation und IT | 22 | 13,6 % | 2,6 s | 969 ms |
Die Spannweite zwischen Versicherungen mit 81,5 Prozent und Telekommunikation und IT mit 13,6 Prozent beträgt 67,8 Prozentpunkte. Sie ist damit um ein Vielfaches größer als der Abstand zwischen den AEM-Generationen. Das ist der eigentliche Befund dieser Tabelle: Wie ein Auftritt betrieben und bestückt wird, wiegt schwerer als die Frage, welche Version darunter läuft.
Die letzten beiden Spalten trennen zwei verschiedene Probleme, die auf den ersten Blick gleich aussehen. Branchen mit guter Antwortzeit und trotzdem später Ladezeit des Hauptinhalts haben ihre Verzögerung im Browser: große Titelbilder, blockierende Stylesheets, spät geladene Schriften. Dort hilft Arbeit an der Auslieferung der Medien, nicht am Cache. Branchen, in denen bereits die Antwortzeit über dem Grenzwert liegt, tragen ihr Problem davor, in Dispatcher, Renderzeit und Cache-Trefferquote. Wer die eigene Branche in dieser Tabelle sucht, liest die Zeile am besten von rechts nach links: erst die Antwortzeit, dann die Ladezeit, dann den Anteil bestandener Auftritte.
Die Zuordnung erfolgt über Muster im Domainnamen. Von 364 Auftritten des eigenen Abrufs stehen 207 in den ausgewiesenen Gruppen. Weitere 51 verteilen sich auf Branchen unterhalb der Mindestgröße von 10 Auftritten, 23 passen auf kein Muster. Beide Teile bleiben außen vor. Die 83 Auftritte des Sparkassen-Finanzverbunds sind ebenfalls herausgenommen, weil sie auf einer gemeinsamen Plattform laufen und die Branche sonst allein bestimmen würden. Die Tabelle beschreibt damit die genannten Gruppen, nicht die gesamte Erhebung.
Deutschland, Österreich und die Schweiz im Vergleich
Die drei Märkte werden getrennt ausgewiesen, sofern mindestens 30 Auftritte vorliegen.
In Deutschland bestehen 50,6 Prozent von 2.605 Auftritten, in Österreich 44,4 Prozent von 734 und in der Schweiz 50,1 Prozent von 883. Ein Auftritt kann in mehreren Ländern erfasst sein, wenn er dort jeweils genug Nutzerdaten erreicht; die Summe der drei Zahlen liegt deshalb über der Zahl der einzelnen Auftritte. Die Unterschiede zwischen den Märkten sind kleiner als die zwischen den Branchen und taugen nicht als Erklärung für einen schwachen eigenen Wert.
Verlauf: 4,3 Prozentpunkte seit Januar 2024
Die Schnittstelle des HTTP Archive liefert die Werte monatsweise. Über 32 Monate ergibt sich eine Zeitreihe statt einer Momentaufnahme.
Der Anteil bestandener AEM-Auftritte ist seit Januar 2024 um 4,3 Prozentpunkte gestiegen, der Abstand zum Gesamtmarkt bleibt dabei bestehen. Zwei Effekte überlagern sich in dieser Linie: die tatsächliche Arbeit an den Plattformen und die Veränderung der Grundgesamtheit, weil monatlich Auftritte hinzukommen und wegfallen. Für die Bewertung einer einzelnen Plattform ist deshalb der eigene Verlauf über dieselben 28-Tage-Fenster aussagekräftiger als die Marktlinie.
Die schnellsten AEM-Auftritte im DACH-Raum
Genannt werden nur Auftritte, die alle drei Kennzahlen im grünen Bereich halten. Plattformen unterhalb der Grenzwerte erscheinen ausschließlich in aggregierter Form.
| Website | Branche | Hauptinhalt | Reaktionszeit | Antwortzeit |
|---|---|---|---|---|
| www.zh.ch | Öffentliche Hand | 0,7 s | 83 ms | 306 ms |
| svazurich.ch | Öffentliche Hand | 0,8 s | 88 ms | 269 ms |
| www.fraunhofer.at | Hochschule und Forschung | 0,8 s | ms | 335 ms |
| www.datev.de | Telekommunikation und IT | 0,9 s | 104 ms | 316 ms |
| www.aral.de | Energie und Versorgung | 0,9 s | 103 ms | 407 ms |
| www.ebill.ch | Banken und Finanzdienstleister | 1,0 s | 108 ms | 331 ms |
| www.elco.de | Industrie und Maschinenbau | 1,0 s | 80 ms | 323 ms |
| www.dzbank.de:443 | Banken und Finanzdienstleister | 1,1 s | 133 ms | 430 ms |
| www.horbach.de:443 | Versicherungen | 1,1 s | 91 ms | 599 ms |
| www.techem.com | Industrie und Maschinenbau | 1,1 s | 135 ms | 485 ms |
Auffällig ist die letzte Spalte. Fast alle Auftritte dieser Liste liefern das erste Byte deutlich unter dem Grenzwert von 800 Millisekunden aus. Eine schnelle Auslieferung ist damit keine hinreichende, aber in der Praxis eine notwendige Bedingung für grüne Werte.
Was aus diesen Zahlen für Ihre Plattform folgt
Vier Schritte, in dieser Reihenfolge, abgeleitet aus der Verteilung der Ursachen in dieser Erhebung.
Zuerst die Antwortzeit klären, nicht die Bilder
Der erste Wert, den es zu holen gilt, ist die Antwortzeit des Servers aus den eigenen Nutzerdaten, getrennt nach Seitentyp. Liegt sie über 800 Millisekunden, ist die Reihenfolge entschieden: Trefferquote des Dispatcher-Caches, Invalidierungsregeln, Zahl der personalisierten Varianten. Alles andere wartet, weil es im Ergebnis nicht sichtbar würde.
Die Skripte inventarisieren, die niemand bestellt hat
Die Reaktionszeit auf Eingaben ist die Kennzahl, die am seltensten aus dem CMS stammt. Eine Liste aller über den Tag-Manager ausgelieferten Skripte, mit Eigentümer und letztem Nutzungsnachweis, bringt auf großen Auftritten regelmäßig mehr als jede Frontend-Optimierung. Entscheidend ist dabei nicht die Menge, sondern wie viel davon vor der ersten Interaktion ausgeführt wird.
Zielwerte je Seitentyp statt eines Gesamtwerts
Startseite, Übersichtsseite, Detailseite und Formular haben verschiedene Lastprofile. Ein einziger Wert für die Domain verdeckt, welcher Seitentyp das Ergebnis nach unten zieht, und macht die Abnahme eines Releases unmöglich, weil niemand sagen kann, was sich verschlechtert hat.
Jedes Release gegen ein Budget abnehmen
Google berechnet die Werte aus einem rollierenden Fenster von 28 Tagen. Eine Verschlechterung wird Wochen nach dem Release sichtbar, eine Korrektur ebenso. Wer die Werte halten will, prüft vor dem Livegang gegen ein Performance-Budget, und zwar auf denselben Seitentypen, für die die Zielwerte gelten.
Methodik: zwei Quellen, beide öffentlich, beide nachrechenbar
Entstanden ist die Auswertung am 15. September 2026 mit dem Datenmonat August 2026.
Breite: Googles Nutzerdaten
Der Chrome UX Report sammelt die Messwerte echter Chrome-Nutzer und veröffentlicht sie monatlich je Website und Land. Das HTTP Archive verbindet diese Werte mit einer Technologie-Erkennung und stellt die Auswertung über eine offene Schnittstelle bereit. Daraus stammen alle Zahlen zur Grundgesamtheit, zu den Ländern, zu den Rangklassen und zum Verlauf: 4.222 AEM-Auftritte und 812.368 Auftritte als Vergleichswert.
Tiefe: eigener Abruf
Für Generation, Antwortzeit des Servers und Branchenzuordnung reicht die Aggregat-Schnittstelle nicht. Dafür wurden 46.394 Domains aus der Rangliste Majestic Million, gefiltert auf die Endungen de, at und ch, je einmal auf der Startseite abgerufen und auf sichtbare Ressourcenpfade geprüft. Für die 486 erkannten AEM-Auftritte wurden anschließend die Nutzerdaten je Auftritt abgefragt; 364 davon haben genug Verkehr für belastbare Werte.
Grenzwerte und Bewertung
Bewertet werden die Ladezeit des Hauptinhalts mit 2,5 Sekunden, die Reaktionszeit auf Eingaben mit 200 Millisekunden und die Layoutstabilität mit 0,1, jeweils im 75. Perzentil über 28 Tage. Bestanden heißt: alle vorhandenen Kennzahlen im grünen Bereich. Die Antwortzeit des Servers zählt mit 800 Millisekunden als gut; sie gehört nicht zu den Core Web Vitals, ist aber die Größe, die Betrieb und Frontend trennt.
Zuordnungen und ihre Grenzen
Die Branche wird am Domainnamen erkannt, etwa an Endungen wie gv.at und admin.ch für die öffentliche Hand, an Herstellernamen für Automobil und Industrie oder an Namensbestandteilen wie versicher und bank für die Finanzwirtschaft. Die Muster stehen im Repository an einer Stelle und sind damit nachvollziehbar. Was auf kein Muster passt, bleibt ohne Zuordnung und geht in keine Gruppe ein; eine falsche Einordnung wäre schlechter als eine fehlende. Auftritte des Sparkassen-Finanzverbunds werden bei den Generationen gesondert ausgewiesen, weil sie auf einer gemeinsamen Plattform laufen und sonst eine ganze Gruppe bestimmen würden.
Quellen: Chrome UX Report und die Technology-Report-Schnittstelle des HTTP Archive, beide abgerufen am 15. September 2026. Die Kandidatenliste Majestic Million steht unter Creative Commons Attribution 3.0.
Einschränkungen: Der Chrome UX Report enthält nur Websites mit ausreichend Chrome-Verkehr, kleinere Auftritte fehlen systematisch. Eine Website entspricht nicht einem Unternehmen. Die Technologie-Erkennung übersieht Installationen, deren Ressourcenpfade hinter einem Content Delivery Network liegen. Alle Zusammenhänge in dieser Auswertung sind Beobachtungen, keine Ursachen.
Fragen zur Auswertung
Fünf Punkte, die bei dieser Art von Erhebung regelmäßig aufkommen.
Warum weichen diese Zahlen von meinem Ergebnis aus PageSpeed Insights ab?
PageSpeed Insights zeigt zwei Dinge nebeneinander: eine Labormessung mit einem Punktwert und die Felddaten aus dem Chrome UX Report. Diese Auswertung verwendet ausschließlich die Felddaten, also die Werte echter Nutzer über 28 Tage. Der Punktwert aus dem Labor kann bei 100 liegen, während die Felddaten den Grenzwert verfehlen, weil im Labor weder Einwilligungsdialog noch Tag-Manager noch echte Endgeräte im Spiel sind.
Unsere Seiten liegen im Dispatcher-Cache. Warum sind die Werte trotzdem gelb?
Der Cache beschleunigt die Antwort des Servers, also den ersten Schritt. Die Core Web Vitals entstehen danach im Browser, durch Bilder, Skripte, Schriften, Tag-Manager und Einwilligungsdialog. Ein Cache-Treffer nach 80 Millisekunden hilft wenig, wenn anschließend zwei Megabyte JavaScript geladen und ausgeführt werden. Umgekehrt gilt der Befund dieser Auswertung: Bei der Mehrheit der langsamen Auftritte ist der Cache eben nicht der Grund, weil die Antwortzeit schon vorher zu hoch liegt.
Lohnt sich der Wechsel auf Edge Delivery Services für die Core Web Vitals?
Das hängt davon ab, wo Ihre Verzögerung entsteht. Liegt der Schwerpunkt vor dem ersten Byte, also in Cache und Auslieferung, bringt der Wechsel viel. Liegt er danach, im Frontend und in den Drittanbieter-Skripten, wandert das Problem mit. Die Antwort steht in den eigenen Nutzerdaten und lässt sich vor jeder Architekturentscheidung ermitteln.
Warum werden Websites mit schlechten Werten nicht genannt?
Weil die Zahlen aus einem Monatsfenster stammen und eine Momentaufnahme sind. Eine Kampagne, ein neues Titelbild oder ein zusätzliches Skript kann das Ergebnis eines Monats erklären. Eine öffentliche Liste schlecht bewerteter Auftritte wäre damit eine Behauptung über den Zustand einer Organisation, die die Datenlage nicht trägt.
Wie oft wird die Auswertung erneuert?
Vierteljährlich, mit dem jeweils aktuellen Datenmonat. Die Zeitreihe wächst mit, sodass sich Veränderungen über Jahre verfolgen lassen. Jede Ausgabe trägt eine eigene Version, damit Zahlen aus verschiedenen Ständen unterscheidbar bleiben.
Daten, Nachnutzung, Zitierweise
Die aufbereiteten Daten stehen als Datei bereit, ohne Registrierung und ohne Formular.
- Alle Kennzahlen als JSON, einschließlich der Zeitreihe über 32 Monate
- Aggregierte Werte als CSV für die Weiterverarbeitung in einer Tabellenkalkulation
- Die entsprechende Auswertung für Magnolia CMS
| Version | Datenstand | Veröffentlicht | Bestanden, mobil | Auftritte |
|---|---|---|---|---|
| 2026-Q3 | August 2026 | 15. September 2026 | 49,4 % | 4.222 |
Die Auswertung erscheint vierteljährlich unter dieser Adresse. Ältere Auflagen werden nicht gespiegelt; maßgeblich ist der oben ausgewiesene Datenstand, und das Protokoll hält fest, was vorher galt.
Zitiervorschlag: Schreiber, Christian: AEM Core Web Vitals Benchmark 2026 für den DACH-Raum, Version 2026-Q3, ch-schreiber.net, Datenstand August 2026.
Wo steht Ihre Plattform in dieser Verteilung?
In der kostenfreien Performance-Erstanalyse sehen Sie die Nutzerdaten Ihrer Plattform im Vergleich zu zwei Wettbewerbern Ihrer Wahl, getrennt nach Antwortzeit und Frontend, und erfahren, welcher der beiden Teile bei Ihnen den Ausschlag gibt.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video, ohne Vorbereitung Ihrerseits. Sie erhalten die Auswertung, unabhängig davon, ob wir zusammenarbeiten.