自動化に Playwright CLI を使用している場合は、すぐに実際的な問題に遭遇することになります。それは、相互に干渉せずに同時に複数のブラウザー セッションを開くことができるかということです。答えは「はい」です。Playwright CLI により、このメカニズムが非常に簡単になりました。
この記事は、公式 session-management リファレンス ドキュメントに従い、名前付きセッション、セッション分離、永続性プロファイル、同時実行モード、一般的なクリーンアップ コマンドなどの最も実用的な部分を整理します。この記事のコマンド ラインとコマンド ブロックの説明は、参考コンテンツとして保持されています。
01 ブラウザセッションに名前を付けます
公式の推奨事項は、-s パラメーターを使用して、異なるブラウザー コンテキストを分離することです。
|
|
ここで重要な点は、異なる session 名が異なるブラウザー コンテキストに対応するということです。ログインプロセスには auth を使用し、匿名アクセスには public を使用できます。 Cookie やローカル状態を共有しません。
02 ブラウザセッションは何を分離しますか?
各ブラウザ セッションは、次のコンテンツを独立して保持します。
- Cookies
- LocalStorage / SessionStorage
- IndexedDB
- Cache
- Browsing history
- Open tabs
これは、auth セッションで Web サイトにログインしても、自動的には public セッションに影響を与えないことを意味します。これは、複数アカウントのテスト、ログイン検証、匿名比較を行う場合に特に重要です。
03 ブラウザセッション関連コマンド
公式ドキュメントには、セッション管理で最も一般的に使用される一連のコマンドがまとめられています。
|
|
これらは、次の 3 種類の操作として理解できます。
list: 現在利用可能な会話を確認しますclose/close-all/kill-all: セッションを終了するか、スタックしたブラウザー プロセスをクリーンアップしますdelete-data: セッションに対応するユーザー データ ディレクトリを削除します
ブラウザを終了するだけの場合は、通常、最初に close を使用します。残留プロセスまたはゾンビ プロセスがある場合は、kill-all を使用する方が適切です。
04 環境変数を使用してデフォルトのセッションを設定します
コマンドごとに -s=mysession を繰り返し書きたくない場合は、公式が環境変数メソッドも提供しています。
|
|
このように、-s が明示的に指定されていない場合、コマンドはデフォルトで mysession ブラウザー セッションを使用します。
05 一般的なパターン: 同時クロール
参考資料には、同時クロールの非常に典型的な例が示されています。
|
|
このモードは、複数のサイトを同時に開き、ページのステータスを個別に取得して、それらをまとめてクリーンアップするのに適しています。各サイトは個別のセッションで実行されるため、互いのローカル状態を汚染することはありません。
06 一般的なパターン: A/B テスト セッション
もう 1 つの一般的なシナリオは、異なる実験版を同時に比較することです。
|
|
この書き方は、2 つのバージョンが独立したセッションで実行され、スクリーンショットとステータス チェックを個別に管理しやすいため、A/B ページの差分比較に非常に適しています。
07 永続的なブラウザプロファイル
公式ドキュメントには具体的に次のように記載されています: デフォルトでは、ブラウザーのプロファイルはメモリにのみ保存されます。
ブラウザー プロファイルをディスクに保存したい場合は、--persistent を open に追加する必要があります。
|
|
この機能は、ログイン ステータス、ローカル キャッシュ、または拡張デバッグ環境の長期的な再利用が必要なシナリオに適しています。特に、同じサイトを何度もデバッグする場合は、毎回最初から開始するよりもプロファイルを永続化する方が効率的であることがよくあります。
08 デフォルトのブラウザセッション
-s が明示的に渡されない場合、コマンドはデフォルトのブラウザー セッションを使用します。
|
|
つまり、-s のない複数のコマンドは、デフォルトで同じデフォルト セッション内で継続的に実行されます。
09 セッション構成で開く
セッション名に加えて、公式ではいくつかの一般的な起動設定方法も提供しています。
|
|
これらのパラメータはセッション管理と組み合わせて使用できます。たとえば、名前付きセッションを常に firefox で実行したり、セッションを常に headed モードで開始して手動で観察しやすくしたりできます。
10 の公式ベスト プラクティス
参考資料には、3 つの非常に実践的なベスト プラクティスがリストされています。
1. セマンティックなセッション名を使用する
|
|
目的を直接表現するセッション名を付けるのが最善です。 github-auth や docs-scrape のような名前は、後でスクリプトを保守するときにはるかに明確になります。
2. 使用後は適時に掃除してください
|
|
タスクの完了後にブラウザを閉じないと、セッションとバックグラウンド プロセスが残ります。短期的には大きな問題ではありませんが、タスクが多すぎると環境が混乱しやすくなります。
3. 古いブラウザデータを削除する
|
|
一部の古いセッションが使用されなくなった場合、対応するデータ ディレクトリを削除すると、ディスク領域を節約し、後で期限切れステータスの悪用を避けることができます。
11 簡単なまとめ
重要なポイントだけに焦点を当てると、次のことを思い出すことができます。
-s=<name>は、独立したブラウザ セッションを作成および使用するために使用されます。- Cookie、ストレージ、キャッシュ、履歴、タブはセッション間で分離されます
close-allは統合シャットダウンに適しており、kill-allは異常な残留プロセスの処理に適しています。--persistentは、長期間の再利用に適したプロファイルをディスクにダウンロードするために使用されます。- セッション名はできる限りセマンティックである必要があり、古いデータは定期的にクリーンアップする必要があります。
ワークフローにすでにログイン状態の再利用、複数アカウントの並列処理、A/B 比較、またはバッチ クロールのニーズがある場合、基本的に session management は、Playwright CLI の機能を習得するのに最も価値があります。
参考リンク
- Playwright CLI セッション管理リファレンス ドキュメント: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/session-management.md
- Playwright CLI プロジェクトのホームページ: https://github.com/microsoft/playwright-cli