Die Seite lädt nie fertig, egal welches Zeitlimit Sie setzen

Zehn Sekunden: Fehlschlag. Fünfundvierzig Sekunden: derselbe Fehlschlag. Das Ziel ist nicht langsam – es wird nie fertig sein, und kein Zeitlimit ändert daran etwas.

Das Symptom. TimeoutError bei der ersten Navigation. Sie erhöhen --timeout von 10 s auf 45 s. Es scheitert erneut, auf genau dieselbe Weise.

Genau dieses identische Scheitern ist die Diagnose: Es ist kein Problem der Dauer.

Worauf Diwall wartet

Standardmäßig ist die Navigation bei networkidle abgeschlossen – nach 500 ms Netzwerkstille. Das ist eine gute Voreinstellung: Sie bedeutet, dass die Seite wirklich zur Ruhe gekommen ist, die Skripte gelaufen sind und der Inhalt angekommen ist.

Manche Ziele werden nie still. Ein Dashboard, das Zähler auffrischt, eine Live-Statistik, die Verwaltungsoberfläche eines Routers, die ihren eigenen Status abfragt – sie reden bauartbedingt ständig mit dem Netzwerk. Es gibt keinen ruhigen Moment, auf den man warten könnte, also wartet Diwall jedes Mal bis zum Zeitlimit, bei jeder Dauer.

Die Bedingung ändern, nicht die Dauer

diwall-shot --url http://target.local/ --wait-until load --som --a11y \
  --guide-version 1.3

--wait-until load ist abgeschlossen, wenn das Ladeereignis der Seite selbst ausgelöst wird, ohne Netzwerkstille zu verlangen. Dieselbe Option gibt es bei diwall-rpa, das sie weiterreicht.

Ein Szenario kann sie als Eigenschaft der obersten Ebene mitführen, damit es für sich allein steht – wer Ihr Szenario wiederverwendet, muss die Eigenheit des Ziels nicht kennen:

{"url": "http://target.local/", "wait_until": "load", "actions": [...]}

Die Kommandozeile hat Vorrang vor dem Szenario Anders als boolesche Optionen, die sich addieren, trägt diese einen Wert – und zwei Werte addieren sich nicht. Sind beide gesetzt, entscheidet die Option auf der Kommandozeile.

Welcher Wert

Wert	Abgeschlossen bei	Verwenden, wenn
`networkidle`	500 ms Netzwerkstille	Voreinstellung – behalten, solange sie funktioniert
`load`	dem Ladeereignis der Seite	das Ziel ständig abfragt
`domcontentloaded`	geparstem HTML, Unterressourcen ausstehend	Sie die frühestmögliche Ansicht brauchen

Greifen Sie nicht vorsorglich zu load. Die Voreinstellung liefert Ihnen eine Seite, die fertig angekommen ist; sie zu ändern heißt zu akzeptieren, dass zum Zeitpunkt der Aufnahme noch Inhalte unterwegs sein können. Ändern Sie sie, wenn die Voreinstellung versagt, nicht vorher.

Wie man das von einer langsamen Seite unterscheidet

Eine langsame Seite gelingt, wenn man lange genug wartet – ein höheres Zeitlimit ändert das Ergebnis. Eine Seite, die nie still wird, scheitert bei jeder Dauer gleich.

Der Test ist also billig: zweimal ausführen, einmal mit dem Standard-Zeitlimit, einmal mit einem viel größeren. Gleicher Fehler, gleiches Tempo? Ändern Sie die Bedingung. Anderes Verhalten? Dann haben Sie ein gewöhnliches langsames Ziel, und das Zeitlimit ist die richtige Stellschraube.

Kurz gesagt

Gleiches Scheitern bei 10 s und 45 s = falsche Bedingung, nicht falsche Dauer.
--wait-until load für Ziele, die ständig abfragen.
In das Szenario schreiben, damit es mit dem Ziel reist.
Überall sonst bei networkidle bleiben.