networkidleとは何か？
Scrapeless Scraping Browserは、自動化ワークフロー向けに信頼性のあるナビゲーションとページの準備条件を選択しなければならない状態で、マネージドChromiumセッションを提供します。
要点だけ
- networkidleは自動化ツールのヒューリスティックであり、ブラウザライフサイクルイベントではありません。 ツールの定義に従って、接続が少ないか全くない期間を待ちます。
- 正確な意味はフレームワークとオプションによって異なります。 しきい値、アイドルウィンドウ、どのリクエストがカウントされるかは実装の詳細です。
- 静かなネットワークはUIが準備が整っていることを証明しません。 レンダリング、タイマー、アニメーション、ワーカー計算、または古いプレースホルダーが残ることがあります。
- 忙しいネットワークはUIが使用不可能であることを証明しません。 分析、ストリーミング、ポーリング、および長寿命の接続は、ターゲットコンテンツが準備できた後も続けることがあります。
- ターゲット化された待機は通常より強力です。 次のアクションに必要なセレクタ、レスポンス、状態フラグ、またはデータ条件を待ちます。
ネットワークの静寂が準備ではない理由
networkidleのヒューリスティックは、ブラウザが状態を公開する方法、コンテンツをレンダリングする方法、自動化されたアクションが安全であるかどうかを決定する方法に影響を与えます。正確な定義は、チームが狭い信号を普遍的な答えとして扱うのを防ぎます。また、期待されるブラウザの動作が文書化されたライフサイクル、API、またはシステム境界に結びついているため、テストの失敗を特定しやすくします。
ウェブ自動化では、実用的な質問は常に「ページは準備が整っていますか？」や「ブラウザはリアルに見えますか？」よりも狭いです。次のステップには、1つの制御を有効にする必要がある場合や、1つのフレームがナビゲーションを完了する場合、1つのコンポーネントが内部ツリーを接続する場合、または1つのレンダリング面が一貫性を保つ必要がある場合があります。以下のセクションでは、この概念を民間の伝承に依存せず、観察可能なチェックに変えます。
networkidleはヒューリスティックです。
networkidleは、十分に静かなネットワークをページの準備の代理として扱うブラウザ自動化待機条件です。自動化フレームワークは、関連するネットワークアクティビティをカウントまたは追跡し、アクティビティがアイドルのインターバルのしきい値を下回ると待機を解決します。ブラウザのウェブプラットフォームは、ページスクリプトにnetworkidleという標準のイベントを送信しません。
このヒューリスティックは魅力的です。なぜなら、現代のページは初期HTMLの後にデータを読み込むからです。DOMContentLoadedは、クライアントリクエストがインターフェースを満たす前に発火することがあり、loadはアプリケーションが開始したfetchの完了前に発火することがあります。ネットワークの静けさは、時々テスト作成者がページの内部セレクタを知らなくても、後の作業をキャッチします。
その便利さは弱点でもあります。この条件は、輸送活動を観察しますが、ユーザーが目にする正確性を保証するものではありません。どのリクエストが重要であるか、レスポンスがコンテンツを生成したか、ハイドレーションが完了したか、または意図されたボタンが有効であるかを知ることはできません。それは多数の信号の中の1つであり、完了の定義ではありません。
Puppeteerとアイドルの意味
The Puppeteer waitForNetworkIdleドキュメント は、ネットワークがアイドル状態になった後に解決されるページメソッドを公開し、少なくとも構成されたアイドル時間を保証します。ナビゲーションAPIは、ネットワークアイドルのしきい値に関連付けられたライフサイクル値も受け入れます。正確な動作は、プロジェクトで使用されるバージョンされたドキュメントから読み取るべきです。
歴史的に、Puppeteerのユーザーは、アクティブな接続がゼロの状態と小さな許可された数を区別するラベルに出くわします。それらの名前は実装の語彙であり、ポータブルなウェブ標準ではありません。コードレビューでは、選択されたフレームワーク、バージョン、しきい値の動作、およびタイムアウトを記録すべきであり、スクリプトがnetworkidleを待っているとだけ言ってはいけません。
リクエストの傍受、サービスワーカー、キャッシュされたリソース、WebSockets、およびバックグラウンドアクティビティは、ツールが観察する内容に影響を与える可能性があります。長寿命の接続が通常のリクエストのようにカウントされない場合でも、ポーリングや分析は静かなウィンドウを妨げることがあります。1つのオプションがすべてのサイトに適合すると仮定するのではなく、ターゲットページに対してこのヒューリスティックを検証してください。
Playwrightがテストの準備としてこれを推奨しない理由
The Playwrightページロード状態ドキュメント は、networkidleをテスト用に推奨しないとマークし、準備を証明するウェブアサーションを推奨します。このアドバイスは、Playwrightのより広範な自動待機モデルを反映しています：アクションとアサーションは、ページ全体のリクエストの不在ではなく、関連する要素条件を待ちます。
攻撃的なアサーションは、より強力な契約を生み出します。テストが提出された注文行を必要とする場合、その行を待ちます。レスポンスが必要な場合、適切なレスポンスを待ってからUI状態を検証します。無効なローディングオーバーレイが消える必要がある場合、その遷移を確認します。これらの条件は製品の動作を説明し、分析やアセットの読み込みに関する無関係な変更に耐えます。
Networkidleは、探索、診断、またはネットワークアクティビティの形状がよく理解されたページにとって依然として有用です。問題は、それが決して機能しないことではありません。問題は、それが次の自動化の行動が実際に必要とする状態よりも広く、より意味が無いことがしばしばあることです。
偽陽性：静かだが準備ができていない
ページは、JavaScriptが高価な計算を実行したり、大きなレスポンスを解析したり、仮想リストをレンダリングしたりしている間、リクエストを停止することがあります。CSSのトランジションやアニメーションも続けることができます。クライアントサイドのルーターはデータを取得しているかもしれませんが、最終的なDOMをコミットしていないかもしれません。壊れたリクエストは、ページがエラーまたは空のプレースホルダーを表示している間、ネットワークを静かに保つこともあります。
レイジーコンテンツは、リクエストを開始する前にスクロールや交差点を待つ場合があるため、ページは関連する作業が始まる前にアイドル状態になることがあります。タイマーはアイドルウィンドウ後に次のfetchをスケジュールする可能性があります。サービスワーカーのレスポンスは、通常のネットワークの読み込みとは異なるパスから来る場合があります。これらの状態のいずれも、ターゲットがアクション可能であることを保証するものではありません。
回復はアプリケーションレベルの条件です。安定したカウント、空でないテキスト、データ属性、有効なコントロール、またはビジーマーカーの消失を待ってください。可能であれば、アプリケーションチームにトラフィックから推測するのではなく、テスト可能な準備状態を示すように依頼してください。
偽陰性：ビジーだが準備完了
分析ビーコンサービス、広告のリフレッシュ、ライブチャット、テレメトリ、ポーリング、イベントストリーム、リアルタイムデータは、ページを無限にアクティブに保つことができます。主要なコンテンツは数秒前に利用可能かもしれません。ネットワークアイドル待機は、操作が安全に進行する可能性があったにもかかわらず、全タイムアウトを消費します。
メディアページやダッシュボードはよくある例です。ビデオプレーヤーはセグメントリクエストを続けることができます。価格ボードはストリーミング更新を維持できます。検索ページはバックグラウンドでメトリクスを報告するかもしれません。意味のある状態は沈黙ではありません。必要なワークフローの特定のコンテンツの存在と安定性です。
実用的なナビゲーションパターンは、DOMContentLoadedを早期のマイルストーンとして使用し、その後ターゲットセレクターまたは応答を待ちます。これにより、関係のないバックグラウンドトラフィックを待つことを避けます。視覚的なレイアウトが要素が表示された後に短い安定期間を必要とする場合は、それをグローバルなヒューリスティックの中に隠すのではなく、別々に測定し正当化してください。
より良い待機戦略の選択
その DOMContentLoadedライフサイクルリファレンス は、標準で定義された早期のマイルストーンを提供します。これをドメイン条件と組み合わせます。結果コンテナには行が含まれ、アプリケーションの状態は水和が完了したことを示し、既知のAPI応答は成功し、画像はデコードが完了したことを報告します。条件は次のアクションに直接マッピングされるべきです。
アクション可能性チェックのために可視性、安定性、有効状態、ヒットターゲットを含むロケーターと主張を優先してください。抽出の場合、存在とコンテンツの形状の両方を確認します。ページネーションの場合、ページトークンまたは最初の行のIDが変更されるのを待ちます。スクリーンショットの場合、すべての接続ではなく、フォントや関連する画像を待ちます。
タイムアウトを安全な境界として保持し、準備メカニズムとしては使用しないでください。待機が失敗した場合は、どの条件が不足していたか、現在のURL、可視状態、コンソールメッセージ、および関連する応答をキャプチャしてください。診断証拠は、あいまいなタイムアウトをページ状態の問題に変え、修正できるものになります。
証拠に基づくグローバルヒューリスティックの置き換え
タスクが進行できることを証明する最小の条件または構成から始めます。標準に互換性のあるブラウザの動作を保ちながら、ワークフローが要求する場合にのみプロファイルコントロールを追加します。ブラウザのビルドと関連する状態を記録して、後の違いを説明できるようにします。再現可能な観察は、ページ、フレーム、表示、またはフィンガープリンが単に「完成」または「安全」とされるという広範な主張よりもより有用です。
- 次のアクションを定義する。 スクリプトまたはユーザーが待機または構成ステップの後に何をすべきかを正確に述べます。
- 観察可能な信号を選択します。 そのアクションを直接サポートするブラウザプロパティ、ライフサイクル状態、要素状態、またはレンダリング結果を優先してください。
- 関連する値を一貫性のあるものに保つ。 ブラウザ、オペレーティングシステム、スクリーン、ロケール、グラフィックス、セッション設定は、ひとつの妥当な環境を説明する必要があります。
- 通常のアプリケーションの動作を検証します。 プライバシーや自動化の介入は、変更されるAPIやコンポーネントを静かに壊してはなりません。
- 診断証拠をキャプチャします。 チェックが失敗したときに関連するURL、状態、コンソールメッセージ、および構成名を保存します。
結論
networkidleは観察されたネットワーク活動の静かな期間から準備状態を推定します。これはフレームワーク依存であり、遅延レンダリングで早すぎたり、継続的なトラフィックのあるページで遅すぎたりすることがあります。ページのリクエストパターンがヒューリスティックを意味のあるものにするときにのみ使用してください。それ以外の場合は、早期のナビゲーションマイルストーンを、次に必要な正確なセレクター、応答、またはアプリケーションの状態と組み合わせてください。
その Scrapeless Scraping Browserのドキュメント は管理されたブラウザセッションがどのように構成されるかを説明し、 Scraping Browserの製品概要 はブラウザ自動化の表面を示します。これらのリソースは、承認されたワークフローで概念を適用するための製品コンテキストを提供します。
より信頼性の高いブラウザの待機を構築する準備はできましたか？
ブラウザのレンダリング、セッション設定、および自動化インフラを管理されたChromium環境に移動します。
今日サインアップして、 $5の無料クレジット — クレジットカードは不要.
$5のクレジットを取得する →FAQ
networkidleは標準のブラウザイベントですか？
いいえ。これは自動化フレームワークのヒューリスティックであり、通常のページスクリプトは標準のnetworkidleライフサイクルイベントを受け取りません。
networkidle0とnetworkidle2は普遍的な名前ですか？
いいえ。特定のツールとしきい値の意味のあるものであり、プロジェクトはそれぞれのフレームワークとバージョンに関するドキュメントを参照する必要があります。
動作するページでnetworkidleがタイムアウトするのはなぜですか？
ポーリング、分析、メディア、チャット、テレメトリ、およびその他のバックグラウンド接続がターゲットUIが準備完了後にネットワークをアクティブに保つ可能性があります。
networkidleの代わりに何を使用すべきですか？
ナビゲーションマイルストーンと、次の操作に必要なセレクター、応答、データ値、読み込み状態、または他の条件のターゲット主張を使用してください。