Hanzo2012 hat geschrieben: ↑09.02.2026, 06:38
Du definierst Ladezeit also ausschließlich als den Download des reinen HTML-Dokument, isoliert von CSS, Bildern oder JS?
Natürlich! Wobei man das noch weiter eingrenzen muss. Das main_document ist nicht gleichbedeuted mit dem Laden von HTML, weil bereits durch das Rendern von HTML eine Zeitvariable entsteht, die sich nicht mehr objektiv messen lässt, weil die Leistungsfähigkeit des Clients dies massiv beeinflussen kann.
Hanzo2012 hat geschrieben: ↑09.02.2026, 06:38
Dann müssen wir hier zwei Dinge festhalten:
1.) Technischer Fakt: Selbst unter dieser sehr engen Definition liegst du falsch. PageSpeed Insights prüft Metriken, die direkt die Ladezeit des HTML-Dokuments beeinflussen. Dazu gehören:
-
Reduce initial server response time (TTFB): Wenn der Server schneller antwortet, ist das Dokument schneller da.
-
Enable Text Compression (Gzip/Brotli): Komprimierung verringert die Dateigröße des HTML-Dokuments massiv -> schnellere Übertragungszeit.
-
Minify HTML (und inline CSS/JS): Verringert ebenfalls die Byte-Größe des Dokuments.
Also ja: Die Umsetzung dieser Empfehlungen kann definitiv die Ladezeit des HTML-Dokuments reduzieren.
Das ist keineswegs eine enge Definition, sondern gehört zum Allgemeinwissen. Deswegen setzen 6! Wenn du die Ladezeit daran bemisst wie lange es dauert bis die angezeigte Seite bereit ist für eine Interaktion, hast Du 3 Millionen variable Störquellen, die eine objektive Messung unmöglich machen.
Der TTFB ist kein Metric um darüber eine Auskunft zur Ladezeit zu bekommen. Wie es der Name bereits sagt, ist TTFB gerade einmal das erste Signal des Webservers. Geladen wird zu diesem Zeitpunkt noch goar nix. Du kannst den TTFB gerade einmal dazu verwenden um Paket Laufzeiten zu messen. Gerne erkläre ich Dir das an einer Analogie.
Was Du zu Minify HTML usw. beschreibst, insbesondere zu den statischen Sourcen, sind Aktionen die nicht Teil des main_document sind. Das sind nachgeladene Sourcen. Zumal erst das main_document geladen werden muss bevor auch nur 1 Byte an statischen Sourcen geladen werden kann.
Hanzo2012 hat geschrieben: ↑09.02.2026, 06:38
2.) Praxis-Relevanz: Deine Definition von Ladezeit geht an der Realität vorbei. Für einen Nutzer (und Google) ist eine Seite nicht "geladen", wenn der HTML-Code heruntergeladen wurde, sondern wenn der Inhalt sichtbar und nutzbar ist. Eine "schnelle Ladezeit" des HTML-Dokuments bringt nichts, wenn das Render-Blocking CSS danach 3 Sekunden braucht.
Im Gegenteil! Das ist die und einzige Realität! Was Du da beschreibst, unterliegt der Wahrnehmung. Deswegen spricht auch Google von der "Perceived Speed". Du kannst Assets noch so gut optimieren, wenn es 4 Sekunden dauert, bis der Server die Daten überhaupt bereitstellt und erst dann beginnt das, was PageSpeed überhaupt messen kann.
Hanzo2012 hat geschrieben: ↑09.02.2026, 06:38
Dass ein hoher Score automatisch eine schnelle Ladezeit garantiert, habe ich übrigens nie behauptet – das ist ein klassisches Strohmann-Argument.
Dann bist du also ein Strohmann, weil Deine Ausführungen suggerieren, dass es so wäre.
Du hast mit Deinen Ausführungen das Maximum an Konditionierung publiziert wie man PageSpeed und bekannte Optimierungen falsch verstehen kann. Einen Preis bekommst Du dafür aber trotzdem nicht.
Why Only the Main Document Truly Matters
When a webpage loads, there's one crucial moment: receiving the Main Document — the actual HTML page the browser requests first.
Until this Main Document arrives, nothing else can even start loading:
- No CSS, no JavaScript, no images, no fonts — nothing.
- While the browser waits for the Main Document, everything else is completely on hold.
That's why the Main Document is the only truly reliable metric when it comes to real loading speed:
- It measures how fast your server responds, not how fast the browser renders content afterward.
- It is independent of browser-side caching — every fresh page visit starts with the Main Document.
- It represents the bottleneck before everything else, the starting point of any further optimization.
All other performance metrics (LCP, FCP, CLS, etc.) only start after the Main Document has arrived — which makes them secondary effects, not true indicators of server speed. Also note, Google PageSpeed ignores the Main Document and that's why PageSpeed doesn't measure the real speed!
