PlaywrightをCIで回していると、だいたいこの思考に行き着きませんか。
「毎回ブラウザ落としてるし、キャッシュしたら速くなるのでは？」
……はい、だいたい一度は通る道です。
でも結論から言うと、
Playwright公式は、ブラウザキャッシュを推奨していません。
この記事では「なぜキャッシュが微妙なのか」「じゃあどうするのが正解なのか」を、公式情報ベースでまとめます。
まず結論：ブラウザキャッシュは公式に非推奨
Playwrightのドキュメントには、わりとストレートに書いてあります。
"Caching browser binaries is not recommended"
理由も明確です。
- キャッシュ復元にかかる時間 ≒ ブラウザを普通にダウンロードする時間
- Linuxでは OS依存ライブラリがキャッシュできない
つまり、頑張ったわりに、あまり速くならないという現実。
CIが遅い原因、だいたいそこじゃないことが多いです。
「でも毎回落としてるの、気持ち悪くない？」
わかります。キャッシュ職人としては放っておけないですよね。
ただ、Playwrightの場合、以下がセットで効いてきます。
- ブラウザ本体
- glibc前提のOS依存ライブラリ
- フォントや描画系の依存関係
特にLinux CIでは、
- OS依存はキャッシュ不可
- キャッシュしても結局
apt installが走る
結果、
キャッシュしたのにあまり速くならない。むしろ設定が複雑になる
という、悲しい状態になりがちです。
よくあるキャッシュ実装の例
# 公式非推奨のパターン
- name: Cache Playwright browsers
id: playwright-cache
uses: actions/cache@v4
with:
path: ~/.cache/ms-playwright
key: ${{ runner.os }}-playwright
restore-keys: ${{ runner.os }}-playwright
- name: Install Playwright with deps
if: steps.playwright-cache.outputs.cache-hit != 'true'
run: npx playwright install --with-deps
- name: Install Playwright system dependencies
if: steps.playwright-cache.outputs.cache-hit == 'true'
run: npx playwright install-deps
このパターン、他の記事を見ると割とありますが、「頑張るところが違う」と思います。
コンテナを使おう！
ここで出てくるのが 公式Dockerイメージ。
mcr.microsoft.com/playwright:v1.57.0-noble
このイメージ、全部入りです。
- Playwright本体
- Chromium / Firefox / WebKit
- 必要なOS依存関係
なので、
-
playwright install不要 - ブラウザキャッシュ不要
- OS差分もなし
GitHub ActionsでのDocker実装例
name: Playwright Tests
on: push
jobs:
test:
runs-on: ubuntu-latest
container:
image: mcr.microsoft.com/playwright:v1.57.0-noble
options: --init --ipc=host
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 'lts/*'
- name: Install dependencies
run: npm ci
- name: Run Playwright tests
run: npx playwright test
ポイント：
-
playwright installが消えた -
--ipc=hostでChromiumクラッシュを回避（後述） - シンプルで安定
公式もGitHub Actions × Dockerを推奨
公式ドキュメントでは、GitHub ActionsでのDocker利用を普通に推奨しています。
"This is useful to not pollute the host environment with dependencies and to have a consistent environment for e.g. screenshots/visual regression testing across different operating systems."
理由はシンプル。
- ホスト環境を汚さない
- 一貫した実行環境を作れる
「Dockerは特殊構成」という扱いではなく、公式に想定された使い方です。
CIで「たまに落ちる」人へ
DockerでPlaywrightを動かす場合、公式が推奨しているオプションがあります。
container:
image: mcr.microsoft.com/playwright:v1.57.0-noble
options: --init --ipc=host
特に --ipc=host。
これがないと、Chromiumがメモリ不足でクラッシュする可能性があると、公式に書かれています。
CIでの謎クラッシュ、だいたいここを疑うと幸せになれます。
各オプションの意味：
-
--init: ゾンビプロセス対策 -
--ipc=host: Chromiumのメモリ不足クラッシュ防止
じゃあ --with-deps はダメなの？
全然ダメじゃないです。
ただし、
「キャッシュ頑張るくらいならDockerでよくない？」
というのが、公式ドキュメントを素直に読んだ感想です。
まとめ：キャッシュするより、環境を固定しよう
CIでPlaywrightを回していて、
「毎回落としてるの、気持ち悪くない？」と思ったことがあるなら、
Dockerを検討してみるのがおすすめです。