Performance- und Core-Web-Vitals-Audit

Phase P3 · Stufe A — Verstehen
Zeitrahmen: 4–8 Stunden für ein repräsentatives Audit; 2–5 Arbeitstage für eine vorlagenweite Untersuchung mit Entwicklungs-Traces. Die 28-Tage-Feldvalidierung erfolgt nach den Optimierungen und verlängert nicht den anfänglichen Audit-Zeitrahmen.
Verantwortlich: Der technische SEO-Leiter trägt die Verantwortung für Umfang und Abnahme. Ein Performance-Ingenieur oder leitender Frontend-Ingenieur ist für die Diagnose zuständig; Plattform-, CDN-, Analyse-, Design- und Produktverantwortliche tragen dort bei, wo ihre Systeme Verzögerungen oder Instabilität verursachen.

Diese Phase wandelt reale Benutzer-Feldnachweise und reproduzierbare Labortests in ein Maßnahmenregister um, das URLs, Vorlagen, Metriken, Verantwortliche und Erfolgskriterien zuordnet – nicht einen generischen Geschwindigkeits-Score.

Warum diese Phase und warum hier

Performance gehört in Stufe A, weil eine Seite, die eine Zeitüberschreitung verursacht, zuerst ein Crawling-Problem und dann ein Benutzererlebnis-Problem ist. Ein Crawler oder Retrieval-Agent hat ein begrenztes Anfragebudget. Wenn der Server stockt, wiederholt weiterleitet oder eine unvollständige Antwort zurückgibt, kann der Client die Seite aufgeben, bevor er den Inhalt bewerten kann. Schnellere Überschriften, bessere Texte und stärkere Schemaauszeichnungen helfen nicht bei Inhalten, die nicht zuverlässig abgerufen werden.

P3 übernimmt die kanonischen Hosts, die beabsichtigten indexierbaren Vorlagen, prioritäre Journeys, Statuscode-Nachweise und ungelöste Infrastruktur-Erkenntnisse aus dem technischen Basis-Audit . Diese Reihenfolge verhindert Fehldiagnosen. Beispielsweise ist eine fünfsekündige „Seitenladezeit", die durch eine Weiterleitungsschleife verursacht wird, keine Aufgabe zur Bildoptimierung, und ein schneller Test einer gecachten Fehlerseite ist kein Bestehen. P2 stellt sicher, dass die richtige URL angefragt und ausgewählt werden kann; P3 stellt sicher, dass sie innerhalb akzeptabler Zeit- und Stabilitätsgrenzen ausgeliefert und genutzt werden kann.

Wenn diese Phase zu spät durchgeführt wird, entsteht Nacharbeit. Ein Content-Team könnte in eine Vorlage veröffentlichen, deren Hero-Element immer das langsamste ist, oder eine Werbefläche freigeben, die jede Produktkarte verschiebt. Der Fehler multipliziert sich dann über neue Seiten hinweg.

Eingaben und Ausgaben

Die Eingaben machen die Stichprobe repräsentativ. Die Ausgaben bilden den Vertrag mit der nächsten Phase: genau welche Seiten zuverlässig verfügbar sind, welche Bedingungen weiterhin schwach sind und welche Performance-Einschränkungen spätere Messungen qualifizieren müssen.

Felddaten und Labordaten sind unterschiedliche Nachweise

Felddaten beschreiben, was berechtigte Chrome-Nutzer tatsächlich erlebt haben. Der Chrome User Experience Report, meist CrUX abgekürzt, aggregiert Messungen von realen Besuchen und meldet das 75. Perzentil: den Wert, bei oder unter dem 75 % der aufgezeichneten Erfahrungen liegen. Er umfasst die Unwägbarkeiten realer Geräte, Netzwerke, Standorte, Caches, Consent-Tools, Sitzungen und Interaktionen. Nutzen Sie ihn, um zu entscheiden, ob Nutzer die veröffentlichten Schwellenwerte bestehen und ob eine ausgelieferte Änderung die Population letztendlich verbessert hat.

Labordaten beschreiben ein einziges kontrolliertes Seitenladen oder eine Interaktion unter festgelegten Bedingungen. Lighthouse ist ein Labortest, der Geräte- und Netzwerksimulation anwendet, einen Trace aufzeichnet und wahrscheinliche Ursachen erklärt. Nutzen Sie ihn, um ein Problem zu reproduzieren, zwei Builds unter denselben Bedingungen zu vergleichen, Request-Chains zu inspizieren und Optimierungsansätze zu identifizieren. Ein Labor-Score ist ein nützlicher Nachweis, aber er beweist nicht, dass reale Nutzer bestehen.

Die beiden Quellen können widersprüchlich sein, ohne dass eine von ihnen falsch liegt. Ein schneller Labordurchlauf kann einen nahegelegenen Standort, einen warmen CDN-Cache und keine nennenswerten Interaktionen nutzen, während Feldbesucher ältere Telefone und entfernte Netzwerke umfassen. Dokumentieren Sie den Widerspruch und untersuchen Sie seine Bedingungen; mitteln Sie niemals die Werte und wählen Sie nicht den gesünder aussehenden.

Die Checkliste

Führen Sie diese Prüfungen in der angegebenen Reihenfolge durch. Jeder Punkt nennt Aktion, Grund, Methode, Werkzeug und Abnahmekriterium, damit er zugewiesen und erneut getestet werden kann.

1. Repräsentative URL- und Bedingungsmatrix festlegen

Was: Definieren Sie die zu testenden URLs, Vorlagen, Geräteprofile, geografischen Standorte, Consent-Zustände und Cache-Zustände. Warum: Ein Nur-Startseiten-Audit kann bestehen, während die Produkt-, Artikel- oder Checkout-Vorlage durchfällt. Wie: Kombinieren Sie das P2-Inventar mit Traffic- und Geschäftsprioritätsdaten; wählen Sie typische, schwere und conversionskritische Beispiele aus. Werkzeug: Analysetools, Crawl-Inventar, Release-Register und ein gemeinsames Testblatt. Erledigt wenn: Jede priorisierte Vorlage eine fachlich freigegebene Produktionsstichprobe hat und jeder Test Gerät, Netzwerk, Standort, Anmeldestatus, Consent und Cache-Annahmen dokumentiert.

2. Die CrUX-Feld-Baseline erfassen

Was: Erfassen Sie verfügbare p75-Feldmetriken auf URL-Ebene und getrennt auf Origin-Ebene. Warum: Der Origin kann eine schwache Vorlage verbergen, während eine einzelne verkehrsschwache URL möglicherweise keine verwertbaren Daten hat. Wie: Verwenden Sie dasselbe Beobachtungsdatum und dasselbe 28-Tage-Fenster, kennzeichnen Sie URL versus Origin explizit und dokumentieren Sie leere Werte als „unzureichende Daten". Werkzeug: AmICited Web Vitals und CrUX. Erledigt wenn: Jede beprobte URL LCP-, INP-, CLS-, FCP- und TTFB-Werte oder einen dokumentierten unbekannten Status hat; Quelllevel und Fenster sind eindeutig.

3. Antwortzuverlässigkeit vor der Pixel-Bewertung prüfen

Was: Wiederholen Sie Anfragen und dokumentieren Sie Status, Weiterleitungen, Time to First Byte (TTFB), Zeitüberschreitungen und inkonsistente Antworten. TTFB ist der Zeitraum vom Beginn der Anfrage bis zum Eintreffen des ersten Antwort-Bytes. Warum: Eine Seite kann nichts darstellen, bevor ihr HTML einzutreffen beginnt, und ein intermittierender Fehler ist schwerwiegender als eine kosmetische Verlangsamung. Wie: Testen Sie Kalt- und Warm-Cache-Verhalten aus relevanten Regionen, prüfen Sie Server-Timing und korrelieren Sie Anomalien mit CDN- und Origin-Logs. Werkzeug: Request-Monitor, Browser-Netzwerk-Panel, CDN/Origin-Beobachtbarkeit und Lighthouse-Wasserfalldiagramm. Erledigt wenn: Prioritäre URLs die beabsichtigte 200-Antwort ohne unerwartete Sprünge oder Zeitüberschreitungen zurückgeben und jede langsame oder fehlgeschlagene Antwort einen protokollierten Befund mit einem Verantwortlichen hat.

4. Largest Contentful Paint diagnostizieren

Was: Identifizieren Sie das Largest Contentful Paint -Element (LCP) und unterteilen Sie seine Zeit in Serververzögerung, Ressourcenentdeckung, Ressourcendownload und Renderverzögerung. LCP misst, wann das größte sichtbare Bild oder der größte sichtbare Textblock fertig gerendert ist. Warum: Das Komprimieren eines Bildes bringt wenig, wenn der Browser es spät entdeckt, und Frontend-Änderungen können eine langsame Serverwartezeit nicht ausgleichen. Wie: Untersuchen Sie Trace und Wasserfalldiagramm, vergleichen Sie gecachte und ungecachte Durchläufe, prüfen Sie Preload-Priorität, responsive Bildgrößen, renderblockierende Ressourcen, Schriftverhalten und clientseitiges Rendering. Werkzeug: Lighthouse, Browser-Performance-Tools, Request-Wasserfalldiagramm und Bildinspektion. Erledigt wenn: Das tatsächliche LCP-Element und die dominante Unterkomponente für jede fehlschlagende Vorlage benannt sind, mit einer reproduzierbaren Vorher-Messung und einer spezifischen Optimierungshypothese.

5. Interaction to Next Paint diagnostizieren

Was: Testen Sie den Interaction to Next Paint -Pfad (INP) für reale Aktionen wie Menüöffnung, Filterung, Warenkorb-Ergänzung, Formulareingabe und Consent-Ablehnung. INP misst die Verzögerung von einer Benutzerinteraktion bis zur nächsten visuellen Aktualisierung des Browsers, basierend auf einer Interaktion mit hoher Latenz aus dem Besuch. Warum: Eine Seite kann vollständig erscheinen, aber den Nutzer dennoch ignorieren, während JavaScript den Hauptthread blockiert. Wie: Reproduzieren Sie wichtige Aktionen, untersuchen Sie lange Tasks und Event-Handler, testen Sie Drittanbieter-Skripte und trennen Sie Eingabeverzögerung, Verarbeitungszeit und Darstellungsverzögerung. Werkzeug: CrUX, Browser-Performance-Trace, Interaktionsprofiling und ein realistisches Gerät. Erledigt wenn: Jede wichtige Interaktion ausgeführt wurde, die langsame Interaktion und der verantwortliche Task für fehlschlagende Vorlagen identifiziert wurden und die Optimierung über einen reproduzierbaren Interaktionstest verfügt.

6. Cumulative Layout Shift diagnostizieren

Was: Lokalisieren Sie unerwartete Bewegungen, die zum Cumulative Layout Shift (CLS) beitragen. CLS ist ein einheitenloser Score, der unerwartete visuelle Bewegung während der Lebensdauer einer Seite darstellt. Warum: Ein spät geladenes Banner, ein nicht dimensioniertes Bild, eine ausgetauschte Schriftart, eine Anzeige oder eine hydrierte Komponente kann den Link verschieben, den ein Nutzer gleich klicken möchte, und kann verändern, wo die automatisierte Extraktion Inhalte findet. Wie: Nutzen Sie Layout-Shift-Regionen und einen Filmstrip, testen Sie verzögerte Assets und Consent-Zustände und inspizieren Sie Elemente ohne reservierte Abmessungen. Werkzeug: CrUX, Lighthouse-Trace, Browser-Rendering-Diagnose und visuelle Regressionserfassung. Erledigt wenn: Jede wesentliche Verschiebung ein Quellelement, einen Auslöser und eine Optimierung durch reservierten Platz oder Rendering hat; erwartete Bewegungen, die sofort durch eine Benutzeraktion verursacht werden, sind separat dokumentiert.

7. FCP zur Trennung der Leerbildschirm-Verzögerung nutzen

Was: Messen Sie First Contentful Paint (FCP), die Zeit bis der Browser den ersten Text, das erste Bild, Canvas- oder SVG-Element rendert. Warum: FCP unterscheidet ein frühes Anzeichen von Fortschritt von einer Seite, die leer bleibt, auch wenn es nicht beweist, dass der Hauptinhalt bereit ist. Wie: Vergleichen Sie FCP mit TTFB und LCP, untersuchen Sie dann blockierendes CSS, Schriftarten, Skripte, serverseitig gerendertes Markup und Streaming-Verhalten. Werkzeug: CrUX, Lighthouse und die Netzwerk-/Performance-Aufzeichnung. Erledigt wenn: Jeder langsame FCP einer Serververzögerung, renderblockierendem oder rein clientseitigem Rendering oder einer anderen nachgewiesenen Ursache zugeordnet ist, anstatt nur als „die Seite fühlt sich langsam an" beschrieben zu werden.

8. Befunde nach Schweregrad, Reichweite und Abhängigkeit einordnen

Was: Ordnen Sie das Backlog nach Fehlerband, betroffenem Traffic und Vorlagen, geschäftlicher Kritikalität und vorgelagerten Abhängigkeiten. Warum: Die Behebung von fünf gelben Scores kann den Sprint verbrauchen, während ein roter TTFB-Fehler jede Seite auf dem Server verzögert. Wie: Setzen Sie Zuverlässigkeitsfehler an die erste Stelle, dann schlechte Metriken vor solchen mit Verbesserungsbedarf; innerhalb desselben Schweregrads beheben Sie zuerst gemeinsame Plattformursachen und TTFB vor nachgelagerter LCP-Arbeit. Werkzeug: Befundregister, Analysedaten, Vorlageninventar und technische Aufwandsschätzung. Erledigt wenn: Jeder Befund einen Schweregrad, eine betroffene URL-Anzahl oder einen Vorlagenumfang, Nachweise, einen Verantwortlichen, Aufwand, Abhängigkeit und eine explizite Priorität hat.

9. Implementierung im Labor validieren

Was: Vergleichen Sie den geänderten Build mit der aufgezeichneten Baseline unter identischen Bedingungen. Warum: Felddaten können kein unmittelbares Release-Feedback liefern, und ein nicht reproduzierbarer „Nachher"-Durchlauf kann nicht belegen, dass die Codeänderung den Unterschied verursacht hat. Wie: Führen Sie mehrere kontrollierte Stichproben durch, vergleichen Sie Mediane statt des einzelnen besten Durchlaufs, untersuchen Sie den Trace auf Regressionen und testen Sie kritische Interaktionen und Layouts. Werkzeug: Lighthouse, Browser-Performance-Tools, Staging-Umgebung oder kontrolliertes Produktionsrelease und Request-Monitoring. Erledigt wenn: Die beabsichtigte Ursache beseitigt ist, die Zielmetrik das vereinbarte Labor-Budget über mehrere Durchläufe hinweg erreicht, keine andere kritische Metrik regrediert und der Befund mit Nachweisen versehen ist.

10. Release annotieren und auf Feldbestätigung warten

Was: Dokumentieren Sie Bereitstellungszeitpunkt, Umfang, erwartete Metrik und Validierungsdaten. Warum: CrUX ist ein rollierendes 28-Tage-Fenster, sodass Besuche vor dem Release nach der Auslieferung der Optimierung weiterhin im gemeldeten Perzentil enthalten sind. Wie: Überwachen Sie sofort Fehler, prüfen Sie die richtungsweisende Feldveränderung, sobald neue Daten eintreffen, und führen Sie den endgültigen Vergleich erst durch, wenn genügend Tage nach dem Release das Fenster repräsentieren. Werkzeug: Deployment-Log, AmICited Web Vitals, CrUX und Monitoring. Erledigt wenn: Unmittelbare technische Prüfungen bestanden sind, die Release-Annotation sichtbar ist und ein benannter Verantwortlicher sowie ein Datum für die Feldbestätigung existieren; der Befund wird nicht allein aufgrund von Labornachweisen als „verifiziert" markiert.

Tools in AmICited

Öffnen Sie https://app.amicited.com/audit/web-vitals, um Ihre Domain mit verfolgten Wettbewerbern anhand realer CrUX-Nutzerdaten zu vergleichen. Das Audit stellt LCP, INP, CLS, FCP und TTFB in einer Tabelle dar, markiert Ihre Domain und macht fehlende Felddaten sichtbar, anstatt sie in eine irreführende Null zu verwandeln. Nutzen Sie den Vergleich, um zwei Fragen zu beantworten: ob die Domain die veröffentlichten Schwellenwerte erfüllt und ob ein Wettbewerber, der dieselbe Zielgruppe bedient, ein wesentlich besseres Feldergebnis erzielt hat.

Die Performance Impact -Funktion verbindet die Performance auf Seitenebene mit der Zitationsposition und -wahrscheinlichkeit. Behandeln Sie diese Beziehung als Priorisierungsnachweis, nicht als Beleg dafür, dass Geschwindigkeit allein eine Zitationsänderung verursacht hat. Wenn sich eine langsame, zitierte Seite und eine schnelle, nicht zitierte Seite in Autorität, Relevanz oder Inhalt unterscheiden, ist Performance nur eine Variable. Das nützliche Signal ist, dass eine betroffene Seite wertvoll genug ist, um optimiert und überwacht zu werden.

Für die Produktbedienung folgen Sie der Anleitung So überprüfen Sie Ihre Core Web Vitals in AmICited . Dieses Playbook definiert Audit-Umfang, Entscheidungen und Übergabe; das Tutorial behandelt die Klicks und Messwerte, sodass eine Duplizierung hier zwei Anleitungen schaffen würde, die auseinanderdriften können.

Entscheidungsregeln: Wie schlecht aussieht

Bewerten Sie Core Web Vitals anhand von Felddaten beim 75. Perzentil. „Gut" bedeutet, dass der p75-Wert auf oder unter der guten Grenze liegt. Ein Wert auf einer Grenze gehört zum besseren Band; zum Beispiel ist ein LCP von genau 2,5 Sekunden gut. Die unterstützenden FCP- und TTFB-Schwellenwerte leiten die Diagnose und Abnahme, sind aber nicht Teil der Drei-Metrik-Core-Web-Vitals-Bewertung.

Verwenden Sie diese Prioritätsregeln:

1. Fehlgeschlagene Anfragen, Zeitüberschreitungen und ungültige Antworten haben Vorrang vor Scores. Zuverlässigkeit ist das Auslieferungstor.
2. Beheben Sie zuerst schlechte Bänder, dann Bänder mit Verbesserungsbedarf. Rot ist eine nachgewiesen schlechte Erfahrung, keine Gelegenheit zur Feinarbeit.
3. Beheben Sie TTFB vor LCP, wenn TTFB fehlschlägt. LCP kann nicht stattfinden, bevor die Antwort beginnt, daher verbraucht die Backend-Verzögerung das LCP-Budget, bevor der Browser etwas rendern kann.
4. Bevorzugen Sie gemeinsame Ursachen gegenüber isolierten Symptomen. Eine Cache-Richtlinien-Reparatur über vier Vorlagen hinweg hat Vorrang vor vier separaten Bildanpassungen mit geringerer Reichweite.
5. Berücksichtigen Sie Traffic und Journey-Wert innerhalb desselben Schweregrads. Ein schlechter Checkout-INP oder ein hochfrequentierter Artikel-LCP hat Vorrang vor einem verkehrsschwachen Archiv im selben Band.
6. Bezeichnen Sie einen leeren CrUX-Wert nicht als gut. Er ist unbekannt. Verwenden Sie reproduzierbare Labornachweise und eine vergleichbare Vorlage, bis Feldvolumen vorhanden ist.
7. Versprechen Sie keine sofortige Feldveränderung. Validieren Sie das Deployment jetzt, erlauben Sie dann dem rollierenden Fenster, ältere Erfahrungen zu ersetzen, bevor Sie das Feldergebnis akzeptieren oder ablehnen.

Ergebnis: Das Performance-Maßnahmenregister

Übergeben Sie der Entwicklung ein Register plus seinen Nachweisordner. Eine Tabellenkalkulation, ein Issue-Tracker oder eine strukturierte Projekttabelle ist akzeptabel, wenn sie diese Felder bewahrt und eine Filterung nach Vorlage, Schweregrad, Verantwortlichem und Status erlaubt:

ID und Befund:
Betroffene URLs und Vorlagen:
Prioritäre Journey und Traffic-Kontext:
Metrik und Feld-Band:
CrUX-Level, p75-Wert und 28-Tage-Fenster:
Laborkonfiguration und wiederholte Baseline:
Beobachtete Ursache und Nachweisreferenz:
Erwartete Bedingung und Ziel:
Empfohlene Änderung:
Schweregrad und Begründung der Priorität:
Verantwortlicher, Abhängigkeit und Aufwand:
Releasedatum und Annotation:
Sofortiges Labor-Abnahmeergebnis:
Feldbestätigungsdatum und -ergebnis:
Status: Offen | Geplant | Labor abgenommen | Feld verifiziert | Akzeptiertes Risiko

Fügen Sie die URL-Matrix, den CrUX-Export, Labor-Traces, Wasserfalldiagramme, Filmstrips, Interaktionsaufzeichnungen, Layout-Shift-Nachweise und Release-Annotationen bei. Entfernen Sie Duplikate nach Ursache: Wenn dieselbe ungecachte Origin-Abfrage einen schlechten TTFB über drei Vorlagen hinweg verursacht, erstellen Sie einen übergeordneten Befund mit drei betroffenen Bereichen anstelle von drei konkurrierenden Diagnosen.

„Akzeptiertes Risiko" benötigt einen benannten Genehmiger, Grund, betroffenen Umfang, Ablauf- oder Überprüfungsdatum und Überwachungsbedingung. Es ist kein Ersatz für einen Verantwortlichen. Die Übergabe ist abgeschlossen, wenn ein Entwickler den Fehler reproduzieren kann und der Verantwortliche der nächsten Phase identifizieren kann, welche Ergebnisse noch durch Performance eingeschränkt sind.

Was schiefgeht

Lighthouse als endgültiges Urteil behandeln. Ein Score von 100 in einem Labordurchlauf überschreibt keine schlechten p75-Felddaten. Bewahren Sie Lighthouse als Diagnosenachweis und CrUX als Bevölkerungsnachweis.

Nur die Startseite testen. Beproben Sie jede hochwertige Vorlage plus ein schweres Beispiel, sonst entgehen Vorlagenmängel dem Audit.

Das LCP-Bild optimieren, bevor TTFB geprüft wird. Das Asset mag klein sein, während der Server zwei Sekunden mit der HTML-Generierung verbringt. Zerlegen Sie LCP in seine Komponenten und beheben Sie zuerst die vorgelagerte Zeit.

Den einzelnen schnellsten Durchlauf verwenden. Cache-Wärme, Hintergrundaktivität und Netzwerkvariation können einen schmeichelhaften Ausreißer erzeugen. Halten Sie die Konfiguration fest und vergleichen Sie Mediane wiederholter Durchläufe.

Gleich am Tag nach dem Release den Sieg erklären. Das Labor kann beweisen, dass sich Code und Auslieferung sofort geändert haben; das 28-Tage-Feld-Fenster kann das nicht. Dokumentieren Sie das Release und planen Sie die Feldabnahme.

Fehlende CrUX-Daten als Null markieren. Keine Daten bedeutet, dass die Berechtigungs- oder Traffic-Schwelle nicht erreicht wurde. Es sagt nichts über die Performance-Qualität aus.

Dem zusammengesetzten Score nachjagen, anstatt der fehlschlagenden Erfahrung. Ein zusammenfassender Score kann sich verbessern, während eine Checkout-Interaktion immer noch stockt oder ein Hero-Element sich weiterhin verschiebt. Akzeptieren Sie benannte Metriken und Journeys, keine kosmetische Score-Verbesserung.

Nützliche Funktionalität entfernen, um einen Test zu gewinnen. Das Löschen von Consent, Personalisierung, Analyse oder Barrierefreiheitsverhalten aus der Laborvariante erzeugt ein Ergebnis, das Nutzer nie erhalten. Optimieren Sie die Produktionsanforderung oder treffen Sie eine explizite Produktentscheidung.

Regressionen außerhalb der Zielmetrik ignorieren. Das Zurückstellen von Skripten kann LCP verbessern, aber einen schlechten INP bei der ersten Interaktion verursachen; das Reservieren der falschen Abmessungen kann eine Ladeverzögerung durch CLS ersetzen. Testen Sie alle fünf Metriken und die kritische Journey erneut.

Nächste Phase: KI-Zugänglichkeit und Agentenbereitschaft

Die Phase KI-Zugänglichkeit und Agentenbereitschaft erhält die repräsentative URL-Matrix, Nachweise zur Antwortzuverlässigkeit, die TTFB-Verteilung, ungelöste Performance-Befunde und eine Aussage darüber, welche Inhalte in der ersten Antwort vorhanden sind. Ihr Verantwortlicher nutzt diese Nachweise, um einen Zugriffsrichtlinienfehler von einem Auslieferungsfehler zu unterscheiden und die realen Bedingungen zu reproduzieren, unter denen ein Agent die Seite abruft.

Die nächste Phase kann fortgesetzt werden, wenn kritische URLs zuverlässig antworten und kein ungelöster Performance-Mangel die Retrieval-Nachweise uninterpretierbar macht. Sie kann mit einer schriftlichen Einschränkung fortgesetzt werden, wenn eine Metrik mit Verbesserungsbedarf Nutzer betrifft, aber keinen stabilen Zugriff verhindert. Sie sollte für betroffene Vorlagen pausieren, wenn Anfragen eine Zeitüberschreitung verursachen, intermittierende Fehler zurückgeben oder die Hauptantwort regelmäßig den vereinbarten kritischen Schwellenwert überschreitet.

Die Übergabe ist abgeschlossen, wenn der nächste Verantwortliche weiß, welche URLs welche Vorlage repräsentieren, die Testbedingungen, die verbleibenden Auslieferungsfehler und ob P3-Nachweise bereits einen langsamen Agentenabruf erklären.

FAQ

Häufig gestellte Fragen