Vorlage statt Startseite: wo die Ladezeit wirklich entsteht

Die Startseite ist die am besten gepflegte Adresse eines Auftritts. Genau das macht sie als Messobjekt schwach: Was dort auffällt, ist längst behoben. Dazu kommt ein Missverständnis in den Zahlen selbst. Der Wert, den ein Felddatenbericht für den Ursprung ausweist, stammt nicht von der Startseite - erfüllt ein Ursprung die Aufnahmekriterien, werden die Erlebnisse auf allen seinen Seiten auf Ursprungsebene zusammengefasst, unabhängig davon, ob die einzelne Seite auffindbar ist (Chrome UX Report). Der Ursprungswert ist also ein Mischwert über den ganzen Bestand, in dem die Startseite nur eine Stimme hat. Wer ihn neben eine Labormessung der Startseite legt, vergleicht zwei verschiedene Dinge; wie sich Felddaten und eigene Messung unterscheiden, entscheidet hier über die Deutung der Zahl.

Für die einzelne Unterseite fehlt der Seitenwert dagegen häufig ganz. Aufgenommen wird eine Seite erst, wenn sie eine Mindestzahl an Besuchern erreicht; Seiten und Ursprünge unterhalb dieser Schwelle bleiben draußen (Chrome UX Report). Ein Katalog mit einigen tausend Produktseiten hat damit für fast keine davon einen eigenen Feldwert, für den Ursprung aber sehr wohl. Übrig bleibt genau eine Ebene, auf der sich beides verbinden lässt: die Vorlage. Sie ist grob genug, um genügend Aufrufe zu bündeln, und fein genug, um eine Ursache zu benennen. An den Core Web Vitals ändert das nichts - wohl aber an der Frage, woran sie gemessen werden.

Die Gliederung beginnt nicht bei der Adresse, sondern bei dem System, das die Antwort erzeugt. Shop und Redaktionssystem kennen den Namen der Vorlage, aus der eine Seite entstanden ist. Diesen Namen in einen Antwortkopf zu schreiben, kostet eine Zeile und macht jede Zeile im Zugriffsprotokoll gruppierbar - rückwirkend für alles, was danach aufgezeichnet wird. Wer stattdessen aus dem Adressmuster rät, liegt bei den Ausnahmen daneben: bei der Kategorie mit eigener Vorlage, beim Artikel im Sonderlayout, bei der Trefferliste, die je nach Filter zwei verschiedene Ansichten liefert. Wie viel Zeit dabei im Backend entsteht, lässt sich auf demselben Weg je Vorlage ausweisen - über Server-Timing.

Steht die Gliederung, braucht jede Vorlage einen Vertreter - und zwar nicht die Seite, die am besten aussieht. Tragfähig sind zwei je Vorlage: ein typischer Fall aus der Mitte der Verteilung und ein schwerer Fall vom oberen Rand, also die Kategorie mit einigen hundert Artikeln statt der mit einer Handvoll. Der Unterschied zwischen beiden ist kein Messfehler, sondern das Ergebnis: Er zeigt, wie stark die Vorlage mit der Datenmenge skaliert. Gemessen wird auf dem Zielgerät statt auf dem Testgerät, sonst verschiebt sich der Befund in Richtung der Entwicklungsmaschine.

Die erste Falle steckt in den Adressen. Im öffentlichen Felddatensatz werden Parameter und Sprungmarken aus der Adresse entfernt, damit alle Erlebnisse einer Seite zusammenfließen (Chrome UX Report). Das ist gewollt, hat aber eine Kehrseite, die dieselbe Dokumentation ausdrücklich nennt: In seltenen Fällen werden dadurch Erlebnisse verschiedener Seiten zusammengefasst, etwa wenn ?productID=101 und ?productID=102 verschiedene Seiten meinen (Chrome UX Report). Wer seine Varianten über Parameter unterscheidet, sieht im Bericht eine Seite, wo in Wirklichkeit eine ganze Vorlage steht. In der eigenen Auswertung muss dieselbe Normalisierung nachgebaut werden, nur mit der umgekehrten Entscheidung: Kampagnenparameter entfernen, unterscheidende Parameter behalten.

Die zweite Falle ist die Gruppe, die ein fremder Bericht bildet. Dort werden Adressen zu Gruppen von Seiten mit ähnlichem Nutzungserlebnis zusammengefasst; unterstellt wird dabei, dass diese Gruppen einen gemeinsamen technischen Unterbau haben und schlechtes Verhalten derselben Ursache entspringt (Search Console-Hilfe). Das ist genau die Annahme, auf der auch die Arbeit nach Vorlagen beruht - nur bildet der fremde Bericht seine Gruppen selbst, und sie müssen nicht mit den Vorlagen des Systems übereinstimmen. Eine Gruppe kann zwei Vorlagen enthalten, eine Vorlage kann auf zwei Gruppen verteilt sein. Die fremde Gruppierung taugt als Hinweis, die eigene als Arbeitsgrundlage. Welche Berichtszeile welchen Befund trägt, klärt der Weg über den Lighthouse-Bericht.

Die dritte Falle ist der Zustand, in dem gemessen wird. Ein Vertreter, der zehnmal hintereinander abgerufen wird, liegt beim zweiten Durchlauf im Cache und liefert einen Wert, den kein Besucher je sieht - und umgekehrt trifft der Cache bei personalisierten Vorlagen seltener, als der Aufbau vermuten lässt; wie schnell ein Cookie die Trefferquote zerlegt, gehört deshalb zur Vorlagenmessung dazu. Wer mehrere Vertreter parallel misst, um Zeit zu sparen, handelt sich zusätzlich die Sitzungssperre ein: Die Aufrufe warten dann aufeinander, und die Wartezeit steht anschließend im Messwert der Vorlage.