読み込み時間を決め打ちで再現するページ群。アプリのローディング表示を 「いつ出して・いつ消すか」を実機で見て決めるために使います。
エンドポイントの状態を確認中…
プリセットに無い秒数を試すとき用。単位はすべて秒（小数可）。
「一定時間応答しない」を作りたいときは hang と入れてください
（上限は 秒。関数のタイムアウトを超えて保持はできません）。
| シナリオ | 確認する挙動 |
|---|---|
fast |
ローディング表示がそもそも出ないこと。一瞬出て消える点滅が起きていないか |
normal |
白い間だけ表示され、内容が見え始めた時点で消えること |
slow |
同上。待ち時間が長くても「止まっている」と誤解されない見え方かどうか |
stall |
本命。実テナントで報告されている「読み込み率が止まったまま プログレスが回り続ける」の再現（このシナリオでは 80% で停止）。 内容は完成しているのに表示が残らないこと |
blank |
真っ白のまま描画されないケース。表示が消えて真っ白＋無表示にならないこと、 一定時間後に再読み込み導線が出ること |
loadingSim が返します。
同一オリジンに揃えてあるので、アプリに渡すのは URL 1 本だけで、
Service Worker の登録などの前準備は要りません<link rel="stylesheet"> の遅延で first contentful paint を止め、
画像の遅延で段階的な描画を作り、末尾リソースで
「描画には影響しないが読み込み完了だけを遅らせる」計測タグ相当を再現していますtailKind で選べます。
?scenario=stall&tailKind=img のようにプリセットへ種別だけ
上書きすることもできます。progress を止められる種別は限られます
（下表）first-contentful-paint を画面と
コンソールの両方に出します。コンソールは [LOADSIM] で始まるので
logcat で絞れますCache-Control: no-store。2 回目以降も同じ遅延になりますPixel 7a / Android 17 での実測。progress を止められたのは parser-blocking script だけでした。種別の効き方は WebView 実装に 依存するので、別端末では改めて確かめてください。
| シナリオ | tailKind | progress の推移 | FCP |
|---|---|---|---|
stall | blocking-script |
20 → 70 → 80 で停止（22秒そのまま） | 1452ms |
stall_img | img |
20 → 80 → 100 | 1524ms |
他の要素を持たない最小ページで種別だけを変えて測ったもの。 止まる位置（%）はページのリソース構成で変わるので、 上のシナリオの数字とは一致しません。ここで見るのは「止まるか否か」だけです。
| 種別 | progress の推移 | 止まるか |
|---|---|---|
img | 10 → 0 → 100（143ms） | 止まらない |
async-script | → 100（1497ms） | 止まらない。実テナントの計測タグ（GTM 等）はこの形 |
| iframe（参考・未実装） | 10 → 0 → 80 → 100（138ms） | 止まらない |
blocking-script |
10 → 0 → 20 → 30 で停止 | 止まる。FCP は 232ms で内容は見えている |
末尾に置く限り parser-blocking でも描画は止まりません（手前は全てパース済み）。 ただし計測スクリプトより後に置くことが必須で、前に置くと計測自体が走りません。
止まる割合はページ構成に依存します。最小ページでは 30%、
このツールの stall では 80% で止まりました。
「何%で止まるか」は再現したい現象の本質ではなく、
「内容は完成しているのに progress が進まない」ことが本質です。
裏を返すと、progress の割合を閾値に使う設計はページ構成に左右されることになります。
onPageCommitVisible の時刻と、その時点の progressfirst-contentful-paint の時刻（このページが出力する値）onPageFinished / progress 100% の時刻
2 と 3 の差が、そのまま「余分にプログレスを回していた時間」になります。
stall ではこの差が上限（ 秒）まで開き続けます。