Eine Tempomessung im Browser wirkt harmlos: ein kleines Skript, ein paar Millisekundenwerte, keine Namen, keine Adressen. Genau diese Harmlosigkeit führt regelmäßig zu einer Verkürzung – dass eine Messung ohne Personenbezug auch ohne Einwilligung laufen dürfe. Der Maßstab dafür steht aber nicht zuerst in der Datenschutz-Grundverordnung, sondern in § 25 des Telekommunikation-Digitale-Dienste-Datenschutz-Gesetzes, und der fragt nicht nach dem Personenbezug, sondern nach dem Endgerät. Wer Felddaten erhebt, beantwortet deshalb zwei Fragen nacheinander: Wird auf dem Gerät gespeichert oder daraus ausgelesen – und erst danach, auf welcher Grundlage die dabei anfallenden Daten verarbeitet werden. Dieser Beitrag ordnet die gängigen Messverfahren in diese beiden Fragen ein, zeigt den schmalen Pfad der gesetzlichen Ausnahme und benennt, welche Datenquellen ohne Einwilligung an Aussagekraft übrig bleiben.
Das Wichtigste in Kürze
- § 25 Abs. 1 TDDDG knüpft die Einwilligung an das Endgerät, nicht an den Personenbezug (TDDDG). Prüfen Sie zuerst den Speicher- oder Auslesevorgang und erst danach die Rechtsgrundlage der Verarbeitung.
- Ein Messskript, das lokal berechnete Werte an einen Server zurückschickt, gilt als Zugriff auf bereits gespeicherte Informationen (EDPB). Dass die Rechnung im Endgerät stattfindet, ändert daran nichts – entscheidend ist die Rückgabe.
- Für die Ausnahme der unbedingten Erforderlichkeit nennen die Aufsichtsbehörden 4 Prüfkriterien (DSK): Zeitpunkt, Inhalt, Dauer und Auslesbarkeit. Eine Reichweitenmessung ist damit nicht pauschal einwilligungsfrei, sondern nur in einer genau beschriebenen Konfiguration.
- Aggregierte Fremddaten bleiben ohne eigene Einwilligung nutzbar, kosten aber Auflösung: Das öffentliche Feldarchiv mittelt über 28 Tage (Chrome for Developers) und erfasst nur Nutzer, die vier Bedingungen gleichzeitig erfüllen.
- Legen Sie den Messaufbau so an, dass er ohne Einwilligung eine Grundlinie trägt: serverseitige Zeitmessung, Laborstichproben und das 75. Perzentil (web.dev) als Schwelle sind von der Zustimmungsquote unabhängig.
Zwei Fragen, die nacheinander zu beantworten sind
Ein häufiger Kurzschluss in Messkonzepten lautet: Wenn keine personenbezogenen Daten anfallen, braucht es keine Einwilligung. Diese Verkürzung geht an der einschlägigen Norm vorbei. § 25 Abs. 1 Satz 1 TDDDG stellt darauf ab, ob Informationen in der Endeinrichtung gespeichert werden oder ob auf bereits dort gespeicherte Informationen zugegriffen wird (TDDDG). Ob sich diese Informationen einer Person zuordnen lassen, spielt für diese erste Frage keine Rolle: Die Aufsichtsbehörden halten in ihrer Orientierungshilfe fest, dass das Einwilligungserfordernis unabhängig von einem Personenbezug der Informationen besteht (DSK). Erst wenn diese erste Frage beantwortet ist, folgt die zweite – auf welcher Grundlage die entstehenden Daten weiterverarbeitet werden. Beide Fragen haben eigene Prüfmaßstäbe, eigene Ausnahmen und eigene Nachweispflichten, und sie fallen in der Praxis regelmäßig auseinander. Welche Kennzahlen dabei überhaupt zur Debatte stehen, fasst unsere Seite zu den Core Web Vitals zusammen.
Die Herkunft der Regel erklärt, warum sie so weit greift. § 25 TDDDG setzt Art. 5 Abs. 3 der ePrivacy-Richtlinie um, der die Speicherung von Informationen im Endgerät und den Zugriff darauf an eine Einwilligung auf Grundlage klarer und umfassender Informationen bindet (ePrivacy-Richtlinie). Der Europäische Datenschutzausschuss hat den technischen Anwendungsbereich dieser Vorschrift in Leitlinien beschrieben, die am 7. Oktober 2024 (EDPB) in der zweiten Fassung angenommen wurden. Der Begriff der Information umfasst danach personenbezogene wie nicht personenbezogene Daten, unabhängig davon, wie und von wem sie gespeichert wurden (EDPB). Damit ist die häufige Gegenfrage – ob ein Millisekundenwert überhaupt ein personenbezogenes Datum sei – für die erste Prüfstufe ohne Bedeutung. Sie wird erst auf der zweiten Stufe wieder wichtig, wenn es um Zweck, Rechtsgrundlage und Speicherdauer geht.
Die Reihenfolge entscheidet
Was § 25 TDDDG tatsächlich verlangt
Der Wortlaut ist bewusst technikneutral gehalten. Erfasst sind alle Verfahren, mit denen sich Informationen auf einem Endgerät ablegen oder von dort auslesen lassen – Cookies sind dabei nur der bekannte Standardfall. Die Aufsichtsbehörden nennen ausdrücklich auch Local-Storage- und Session-Storage-Objekte, das Auslesen von Hardware-Kennungen und die serverseitige Bildung eines Fingerabdrucks aus Browsereigenschaften (DSK). Für die Performance-Messung ist ein weiterer Satz aus derselben Orientierungshilfe aufschlussreich: Als Zugriff ist es auch zu werten, wenn aktiv – beispielsweise mittels JavaScript-Code – Eigenschaften eines Endgeräts ausgelesen und für die Erstellung eines Fingerprints an einen Server übermittelt werden (DSK). Die Aufsichtsbehörden beschreiben damit ausdrücklich den Fingerabdruck, nicht jede Messung. Die technische Bauform ist allerdings dieselbe wie bei einer Feldmessung – Auslesen im Browser, Übermittlung an einen Server – und für den allgemeinen Fall führt der Europäische Datenschutzausschuss diesen Gedanken einen Schritt weiter, wie der nächste Abschnitt zeigt.
Das Gesetz kennt zwei Ausnahmen. Nach § 25 Abs. 2 Nr. 1 TDDDG entfällt die Einwilligung, wenn der alleinige Zweck die Durchführung der Übertragung einer Nachricht über ein öffentliches Telekommunikationsnetz ist. Praktisch wichtiger ist Nr. 2: Die Einwilligung entfällt, wenn der Vorgang unbedingt erforderlich ist, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten digitalen Dienst zur Verfügung stellen kann (TDDDG). Beide Begriffe sind eng: unbedingt erforderlich, nicht nützlich, und ausdrücklich gewünscht aus Sicht des Nutzers, nicht aus Sicht des Betreibers. Die folgende Übersicht ordnet die gängigen Messwege in diesen Rahmen ein. Sie ersetzt keine juristische Prüfung des Einzelfalls, aber sie zeigt, an welcher Stelle die Prüfung ansetzt.
| Messweg | Vorgang am Endgerät | Einwilligung nach § 25 | Begründung |
|---|---|---|---|
| Zählung aus dem Serverprotokoll ohne Personenbezug | nicht enthalten | nicht einschlägig | Der Zähler läuft im Backend (DSK) |
| Server-Timing im Antwortkopf | nicht enthalten | nicht einschlägig | Der Messwert entsteht vor der Auslieferung |
| Skript liest Zeitwerte im Browser und sendet sie | enthalten | erforderlich, sofern keine Ausnahme trägt | Rückgabe an den Server ist Zugriff (EDPB) |
| Kennung im Local Storage für den Sitzungsbezug | enthalten | erforderlich, sofern keine Ausnahme trägt | Speicherung im Endgerät (DSK) |
| Auswertung allein über die IP-Adresse | abhängig von der Herkunft | im Zweifel erforderlich | IPv6 wird teils vom Endgerät gebildet (EDPB) |
Die letzte Zeile überrascht viele. Der Ausschuss hält fest, dass der Zugriff auf IP-Adressen die Vorschrift dann auslöst, wenn diese Information aus dem Endgerät des Nutzers stammt – was bei einer statischen IPv4-Adresse eines Routers und bei IPv6-Adressen der Fall sein kann, weil diese teilweise vom Endgerät selbst gebildet werden (EDPB). Solange eine Stelle nicht ausschließen kann, dass die Adresse aus dem Endgerät stammt, muss sie die Anforderungen des Art. 5 Abs. 3 beachten (EDPB). Für die Praxis heißt das: Auch eine scheinbar rein serverseitige Auswertung verlässt den sicheren Bereich, sobald sie einzelne Besucher über die Adresse wiedererkennt. Eine reine Zählung von Seitenabrufen ohne Wiedererkennung bleibt davon unberührt.
Warum die Vitals-Messung Zugriff ist
Für eine Feldmessung der Core Web Vitals ist eine Passage der Leitlinien maßgeblich, die auf den ersten Blick technisch klingt und praktisch alles entscheidet. Unter der Überschrift zur lokalen Verarbeitung heißt es: Wird die lokal verarbeitete Information an irgendeiner Stelle einem Dritten zugänglich gemacht, etwa über das Netz an einen Server zurückgeschickt, so stellt dieser Vorgang ein Erlangen von Zugriff auf bereits gespeicherte Informationen dar (EDPB). Genau das tut jede Messbibliothek: Sie beobachtet Ereignisse im Browser, rechnet daraus einen Kennwert und schickt ihn an einen Endpunkt. Dass die Berechnung im Endgerät stattfindet und nur ein Zahlenwert das Gerät verlässt, ist nach dieser Lesart kein Gegenargument, sondern genau der beschriebene Fall. Wie sich ein solcher Kennwert weiter zerlegen lässt, zeigt LCP in vier Teilphasen.
Lesen zählt wie Speichern
§ 25 Abs. 1 TDDDG nennt beide Vorgänge gleichrangig: die Speicherung von Informationen in der Endeinrichtung und den Zugriff auf bereits dort gespeicherte Informationen (TDDDG). Eine Messung ohne Cookie ist damit nicht automatisch eine Messung ohne Einwilligung – sie verschiebt nur, welcher der beiden Vorgänge geprüft wird.
Lokal rechnen verschiebt nur den Ort
Die Auslagerung der Auswertung in den Browser ist eine gute Idee für die Datensparsamkeit und eine schlechte für die Rechtsfrage: Sobald das Ergebnis an einen Server geht, liegt ein Erlangen von Zugriff vor (EDPB). Der Vorteil bleibt trotzdem bestehen, weil weniger Rohdaten das Gerät verlassen und die zweite Prüfstufe leichter fällt.
Ohne Personenbezug bleibt es Zugriff
Die Aufsichtsbehörden stellen klar, dass § 25 Abs. 1 TDDDG ein Einwilligungserfordernis unabhängig von einem Personenbezug begründet und damit über den Anwendungsbereich der Datenschutz-Grundverordnung hinausgeht (DSK). Anonymisierung ist deshalb ein Argument für die zweite Stufe, nicht für die erste.
Ein zweiter Punkt wird in Messkonzepten oft übersehen: Für Tracking-Links und Zählpixel halten die Leitlinien fest, dass bereits deren Verteilung an das Endgerät eine Speicherung darstellt, zumindest über den Zwischenspeicher der Clientsoftware, und zwar auch dann, wenn sie nicht dauerhaft ist (EDPB). Wer Messwerte über ein Zählpixel oder einen präparierten Link zurückmeldet, hat den Vorgang am Endgerät damit nicht erst beim Auslesen, sondern schon beim Ausliefern; bei einer Skriptmessung liegt der maßgebliche Vorgang dagegen im Zurückschicken der lokal berechneten Werte (EDPB). Für die Praxis folgt daraus weniger eine zusätzliche Hürde als eine Klarstellung: Die Frage ist nicht, ob ein Vorgang am Endgerät stattfindet, sondern ob er von einer Ausnahme getragen wird. Wer die Messung an eine Einwilligungsschicht hängt, sollte deshalb auch den Ausspielweg daran hängen – sonst steht die Entscheidung auf dem Papier, während der Datenverkehr sie längst überholt hat. Wie diese Schicht selbst auf das Tempo wirkt, steht in unserem Beitrag zu Cookie-Bannern und Core Web Vitals.
Der Kern in einem Satz
Der schmale Pfad der Ausnahme
Bleibt die Ausnahme. § 25 Abs. 2 Nr. 2 TDDDG verlangt zwei Dinge gleichzeitig: einen vom Nutzer ausdrücklich gewünschten digitalen Dienst und einen Vorgang, der für dessen Bereitstellung unbedingt erforderlich ist (TDDDG). Die Aufsichtsbehörden haben dazu zwei Kriterienlisten veröffentlicht. Für den gewünschten Dienst zählt eine granulare Festlegung, welcher Speicher- oder Auslesevorgang zu welcher Funktion gehört, und die Bestimmung, wessen Interessen diese Funktion primär dient (DSK). Für die unbedingte Erforderlichkeit nennen sie 4 Prüfkriterien (DSK). Der Zuschnitt ist eng: Es geht nicht darum, ob ein Cookie gesetzt wird, sondern darum, welche Information darin steht und wie lange sie lesbar bleibt.
Auf die naheliegende Frage, ob eine Reichweitenmessung damit pauschal ohne Einwilligung laufen darf, geben die Aufsichtsbehörden bewusst keine pauschale Antwort. Ihre Begründung ist für die Performance-Messung besonders lehrreich, weil sie auf den Zweck abstellt und nicht auf die Technik. Eine Festlegung, ob eine Reichweitenmessung ohne Einwilligung rechtmäßig ist, lasse sich allenfalls für eine genau definierte Konfiguration und Zweckbestimmung treffen und sei nicht mehr gültig, sobald weitere Informationen oder ein weiteres Auswertungsergebnis hinzukommen (DSK). Und weiter: Selbst die einfache Messung von Besucherzahlen sei nicht per se als Bestandteil des Basisdienstes einzustufen, sondern abhängig vom jeweils konkret verfolgten Zweck (DSK). Eine Tempomessung, die ausschließlich der Auslieferung der Seite dient, steht damit anders da als dieselbe Messung, sobald sie Segmente, Kampagnenkennungen oder Sitzungsverläufe mitführt.
- Zeitpunkt der Speicherung: Der Vorgang darf erst beginnen, wenn die Funktion tatsächlich in Anspruch genommen wird (DSK). Ein Messskript, das im Kopfbereich jeder Seite startet, ist damit schwerer zu begründen als eines, das an ein konkretes Ereignis gebunden ist.
- Inhalt der Informationen: Maßgeblich ist nicht, dass etwas gespeichert wird, sondern welche Information gespeichert oder ausgelesen wird (DSK). Ein Zeitwert ohne Kennung ist ein anderer Fall als derselbe Zeitwert mit einer wiedererkennbaren Sitzungsnummer.
- Dauer der Speicherung: Der Zeitraum darf nur so lang gewählt werden, wie es die granular festgelegte Funktion verlangt (DSK). Für eine Tempomessung heißt das in der Regel: Sitzungsdauer statt Monate.
- Auslesbarkeit der Informationen: Zu prüfen ist, für wen die Information vom Endgerät lesbar und verwertbar ist (DSK). Sobald ein weiterer Empfänger mitliest, verschiebt sich die Bewertung, selbst wenn der eigene Zweck unverändert bleibt.
- Granulare Zuordnung: Für jede Funktion wird einzeln festgehalten, welcher Speicher- oder Auslesevorgang zu ihr gehört (DSK). Eine Sammelbegründung für das gesamte Messwerkzeug trägt diese Prüfung nicht.
- Interessenzuordnung: Es wird bestimmt, wessen Interessen die Funktion primär dient – denen der Nutzenden, den eigenen oder denen Dritter (DSK). Diese Zuordnung ist der Punkt, an dem eine Tempomessung und eine Vermarktungsauswertung auseinanderlaufen.
Was die Ausnahme in der Regel nicht trägt
Was ohne Einwilligung übrig bleibt
Was bleibt ohne Einwilligung? Mehr, als der erste Eindruck nahelegt – allerdings mit anderer Auflösung. Die Aufsichtsbehörden beschreiben selbst, wie eine schlichte Zählung aussieht: Es reicht aus, bei jedem Abruf einer Seite den Zähler für diese Seite um Eins zu erhöhen (DSK). In derselben Passage nennen sie daneben ein einfaches Zählpixel – das löst allerdings wieder einen Vorgang am Endgerät aus, während der Zähler im Serverprotokoll die erste Prüfstufe gar nicht erreicht. Auf derselben Ebene liegt die serverseitige Zeitmessung. Der Antwortkopf Server-Timing überträgt Werte, die vor der Auslieferung im Backend entstanden sind; es wird nichts aus dem Endgerät geholt. Damit lassen sich Datenbankzeit, Renderzeit und Wartezeiten in der Anwendung sauber trennen, ohne die erste Prüfstufe überhaupt zu erreichen – wie das aufgebaut wird, steht in unserem Beitrag zu Server-Timing im Backend. Was dabei fehlt, ist der Blick auf das Gerät des Besuchers: Rechenzeit, Layoutstabilität und Reaktionslatenz entstehen dort und lassen sich serverseitig nicht rekonstruieren.
Die zweite Quelle ohne eigene Einwilligung ist das öffentliche Feldarchiv des Browsers. Es liefert aggregierte Verteilungen je Seite und je Ursprung, und der Betreiber der eigenen Website löst dabei keinen Vorgang auf einem fremden Endgerät aus. Der Preis ist Auflösung und Verzögerung. Die Daten sind ein rollierender Durchschnitt über 28 Tage (Chrome for Developers), Werte werden je Kennzahl als Histogramm und als Perzentilwert ausgegeben (Chrome for Developers), und in den Datensatz fließen nur Nutzer ein, die vier Bedingungen gleichzeitig erfüllen: aktivierte Nutzungsstatistik, synchronisierter Verlauf, keine gesetzte Synchronisierungspassphrase und eine unterstützte Plattform (Chrome for Developers). Wie hoch der Anteil dieser Nutzer ist, wird nicht veröffentlicht (Chrome for Developers). Der Abgleich zwischen dieser Quelle und einer eigenen Messung ist deshalb kein Widerspruch, sondern zwei Ausschnitte derselben Verteilung – wir haben das in Felddaten und Laborwerten im Vergleich auseinandergenommen.
// Zwei Messwege sauber trennen: einer läuft ohne Einwilligung,
// der andere erst nach einer dokumentierten Zustimmung.
// 1) Ohne Vorgang am Endgerät -- der Wert entsteht im Backend
// und reist im Antwortkopf mit:
// Server-Timing: db;dur=41, render;dur=88, total;dur=143
// 2) Mit Vorgang am Endgerät -- erst nach Einwilligung starten.
// buffered:true liest die schon vorliegenden Einträge nach,
// der Lesevorgang findet aber erst hier statt.
function messungStarten() {
const werte = [];
new PerformanceObserver((liste) => {
for (const eintrag of liste.getEntries()) {
werte.push({ name: eintrag.name, wert: Math.round(eintrag.startTime) });
}
}).observe({ type: 'largest-contentful-paint', buffered: true });
addEventListener('visibilitychange', () => {
if (document.visibilityState !== 'hidden') return;
if (werte.length === 0) return;
navigator.sendBeacon('/messung', JSON.stringify(werte));
werte.length = 0;
});
}
// Der Aufruf hängt am Einwilligungsstatus, nicht am Seitenaufruf.
// Auch das Nachladen der Bibliothek gehört hinter diese Bedingung.
if (einwilligung.erteilt('messung')) {
messungStarten();
}Vom Rechtsrahmen zum Messaufbau
Aus der Rechtsfrage wird ein Messaufbau, sobald man akzeptiert, dass die Zustimmungsquote eine Messgröße ist und keine Nebensache. Liegt sie bei der Hälfte der Besucher, halbiert sie nicht nur die Datenmenge, sondern verschiebt auch die Verteilung: Wer zustimmt, unterscheidet sich in Gerät, Netz und Verhalten von dem, der ablehnt. Ein Perzentilwert aus der zustimmenden Hälfte ist deshalb kein Perzentilwert der Besucher. Ein tragfähiger Aufbau hat darum zwei Ebenen: eine Grundlinie, die ohne Einwilligung entsteht und über die Zeit vergleichbar bleibt, und eine Detailschicht, die nach Zustimmung dazukommt und Ursachen zeigt. Die erste Ebene beantwortet, ob sich etwas verändert hat, die zweite, warum. Welche Schwellen dabei gelten, fasst Core Web Vitals 2026 zusammen.
- Jeden Messweg einzeln danach einordnen, ob er einen Vorgang am Endgerät auslöst. Diese Einordnung gehört in dieselbe Tabelle wie die technische Beschreibung, nicht in ein getrenntes Dokument.
- Die Grundlinie ohne Einwilligung festlegen: Zählung im Serverprotokoll, Server-Timing für die Backendphasen und regelmäßige Laborstichproben gegen dieselbe Konfiguration.
- Die aggregierte Fremdquelle als Kontrollgröße daneben stellen und ihr Zeitfenster von 28 Tagen (Chrome for Developers) in die Auswertung einrechnen – eine Verbesserung von heute erscheint dort verzögert und geglättet.
- Die Detailschicht hinter die Einwilligung legen, einschließlich des Nachladens der Bibliothek, und die Zustimmungsquote als eigene Kennzahl mitführen. Ohne sie lässt sich später nicht sagen, ob ein Wert gestiegen ist oder nur die Grundgesamtheit gewechselt hat.
- Für die Ausnahme je Funktion eine schriftliche Begründung entlang der vier Kriterien führen (DSK) und sie beim nächsten Umbau erneut prüfen, statt sie fortzuschreiben.
- Die Schwelle als Perzentil festschreiben statt als Mittelwert: Bewertet wird am 75. Perzentil (web.dev), getrennt nach Mobil und Desktop. Wie sich das in eine Abnahme übersetzen lässt, steht in Tempo in der Ausschreibung festschreiben.
Diese Trennung hat einen angenehmen Nebeneffekt: Sie macht die Messung selbst leichter. Eine Detailschicht, die nur für zustimmende Besucher lädt, kostet die übrigen keine Übertragung und keine Rechenzeit. Wer die Rückgabe der Werte zusätzlich in den Leerlauf verschiebt, nimmt ihr auch noch den Einfluss auf die Interaktionslatenz – die Bauformen dafür haben wir in Messdaten ohne Tempoverlust senden beschrieben. Bei Anwendungen mit clientseitigem Seitenwechsel kommt hinzu, dass die Zuordnung von Kennzahlen zu Ansichten ohnehin eine eigene Bauform braucht; wie das ohne zusätzliche Kennungen geht, steht in Core Web Vitals in SPAs messen.
Die unbequeme Frage in jedem Messkonzept ist nicht, ob die Daten anonym sind. Sie lautet: Was genau holt dieses Skript aus dem Gerät des Besuchers – und würde die Seite ohne diesen Vorgang schlechter funktionieren?
Damit ist die Frage aus der Überschrift beantwortbar, ohne sie pauschal zu beantworten. Zulässig ohne Einwilligung ist, was keinen Vorgang am Endgerät auslöst, und zusätzlich das, was eine eng geführte Ausnahme trägt. Alles Übrige braucht eine Zustimmung – und wer sie nicht bekommt, arbeitet mit einer Grundlinie aus Serverdaten und einer aggregierten Fremdquelle weiter, statt die Messung ganz aufzugeben. Diese Einordnung ist Teil jeder technischen Performance-Analyse bei uns: Wir beschreiben, welcher Messweg welchen Vorgang auslöst, welche Kennzahl daraus ohne Zustimmung tragfähig bleibt und an welcher Stelle eine Einwilligung tatsächlich Mehrwert bringt. Welche Kennzahlen dabei zusammenlaufen, steht auf unserer Seite zu den Core Web Vitals; wie sich Tempo im laufenden Betrieb halten lässt, klärt der Blick auf Regressionen im Bauprozess. Für die Messpunkte, an denen es im Verkauf wirklich eng wird, lohnt der Beitrag zum Checkout-Tempo in den letzten Sekunden; wenn die Bremse dagegen in der Laufzeit des Stylings steckt, hilft Style Recalculation als CSS-Laufzeitbremse.
Quellen und Studien
Verwandte Artikel
RUM vs. CrUX: Felddaten richtig für Tempo nutzen
Lighthouse-Laborwerte beeinflussen kein Ranking. Google bewertet Core Web Vitals über CrUX-Felddaten am 75. Perzentil. So nutzen Sie RUM, CrUX und Budgets.
Wenn die Schnittstelle bremst: Fremdsysteme im Seitenaufbau
Wartet der Server im Seitenaufbau auf ein fremdes System, entscheiden Fristen, Zwischenspeicher und Ersatzwerte darüber, ob die Seite steht oder wartet.
TYPO3-Performance: Caching und Ladezeit im Griff behalten
Wie der Seiten-Cache in TYPO3 arbeitet, welche Einstellungen ihn aushebeln und wie Cache-Hash, Backends und das Deployment die Ladezeit einer Seite bestimmen.