モダンWebアプリのクロスブラウザテスト：実践的ワークフロー

ユーザーはChrome、Firefox、Safariなど、さまざまなブラウザでサイトを訪問します。あるブラウザエンジンで完璧にレンダリングされるレイアウトが、CSS解釈の違い、フォントレンダリング、Flexboxの動作により別のブラウザで壊れる可能性があります。クロスブラウザテストは、重要なすべての環境でUIが正しく表示されることを保証します。

このガイドでは実践的なワークフローを紹介します：何をテストするか、どう優先順位をつけるか、CIでクロスブラウザチェックを効率的に実行する方法です。

クロスブラウザテストがまだ重要な理由

モダンブラウザはかつてないほど標準準拠ですが、同一ではありません。3つのレンダリングエンジンがWebを支配しています：

• Blink（Chrome、Edge、Opera）— 最も広く使用されているエンジン。
• Gecko（Firefox）— 独自のCSS解釈を持つ独立エンジン。
• WebKit（Safari）— すべてのiOSブラウザとmacOS Safariで使用。

これらのエンジン間の差異は微妙ですが実在します。GridやFlexboxのgap計算、フォントシェーピング、サブピクセルの丸め、スクロール動作はすべて目に見えるレイアウトの違いを生む可能性があります。1つのエンジンだけでテストしていると、他のエンジンでのリグレッションに気づけません。

ブラウザとデバイスのマトリクス構築

網羅的なテストマトリクス（すべてのブラウザ、すべてのデバイス、すべてのページ）は現実的ではありません。目標はビジネスインパクトで重み付けされた代表的なカバレッジです。

ステップ1：トラフィックデータを監査する

アナリティクスで実際のユーザーのブラウザとデバイスの内訳を確認します。典型的な分布：

• Chromeデスクトップ：45%
• Chromeモバイル：20%
• Safariモバイル：15%
• Firefoxデスクトップ：8%
• Safariデスクトップ：7%
• その他：5%

トラフィックの85〜90%をカバーする組み合わせを優先します。

ステップ2：代表的なブレークポイントを選択する

モダンレスポンシブデザインはフルイドレイアウトを使用しますが、ビジュアルテストには固定ビューポートが必要です。各デバイスクラスを代表するブレークポイントを選択します：

• モバイル：375×667（iPhone SE相当）
• タブレット：768×1024（iPad相当）
• デスクトップ：1440×900（標準的なノートPC）
• ワイドデスクトップ：1920×1080（フルHDモニター）

すべてのページに4つすべてが必要なわけではありません。モバイル＋デスクトップをベースラインとし、複雑なレスポンシブ動作のあるページにタブレットを追加します。

ステップ3：ページをリスクレベルにマッピングする

すべてのページに同じ深さのカバレッジは不要です：

• 高リスク（ホームページ、料金、チェックアウト、ダッシュボード）：すべてのブラウザ、すべてのブレークポイント。
• 中リスク（機能ページ、ドキュメント）：プライマリブラウザ＋モバイルとデスクトップ。
• 低リスク（法的ページ、静的コンテンツ）：プライマリブラウザ、デスクトップのみ。

この段階的アプローチにより、最も重要なサーフェスをカバーしつつテストスイートを高速に保てます。

レスポンシブブレークポイントと壊れやすいポイント

最も一般的なクロスブラウザのレスポンシブバグは以下のトランジションポイントで発生します：

ナビゲーションの折りたたみ

ハンバーガーメニュー、ドロップダウンの位置、固定ヘッダーはエンジン間で異なる動作をします。特にモバイルとデスクトップレイアウトの間の遷移で、すべてのブレークポイントでナビゲーションをテストしましょう。

GridとFlexboxの折り返し

デスクトップで収まる3カラムグリッドがタブレット幅で2カラムに折り返される場合があります。折り返しのしきい値がChromiumとWebKitで数ピクセル異なるだけで、片方のブラウザでレイアウトが壊れます。

タイポグラフィのリフロー

フォントメトリクスはエンジンとOSで異なります。Chromeで1行に収まる見出しがFirefoxでは2行に折り返され、その下のコンテンツの位置がずれる可能性があります。

オーバーフローとクリッピング

スクロール可能なコンテナ、テキストの切り詰め、overflow-hiddenの動作はエンジン間で微妙に異なります。データテーブル、長いコンテンツ、カードレイアウトのページを狭い幅でテストしましょう。

トラフィックとビジネスインパクトによる優先順位付け

すべてのブラウザに同じ注意を払う必要はありません。加重スコアリングモデルを使用します：

トラフィック8%でもレイアウト問題のサポートチケットが25%を占めるブラウザは、生のトラフィック数字が示すよりも多くのテスト投資に値します。

クロスブラウザチェックのCI戦略

すべてのプルリクエストでクロスブラウザテストを実行すると遅くなる可能性があります。レイヤード実行モデルを使用しましょう：

すべてのPRで

高リスクページに対してプライマリブラウザ（Chromium）をモバイルとデスクトップのブレークポイントで実行。通常2分以内の高速フィードバック。

mainへのマージ時

3つのブラウザエンジン（Chromium、Firefox、WebKit）すべてに拡大し、高リスクと中リスクのページにタブレットのブレークポイントを追加。

ナイトリーまたはウィークリー

フルマトリクスを実行：すべてのブラウザ、すべてのブレークポイント、すべてのページ。高速PRチェックをすり抜けたリグレッションをキャッチします。

# 例：レイヤードCIマトリクス
name: Visual Regression
on:
  pull_request:
    branches: [main]

jobs:
  visual-pr:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        browser: [chromium]
        viewport: [375x667, 1440x900]
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
      - run: npm run test:visual -- --browser=${{ matrix.browser }} --viewport=${{ matrix.viewport }}

クロスブラウザ結果の解釈方法

ビジュアル差分が表示された場合、アクションを決定する前に原因を特定します：

エンジン固有のレンダリング

差分がFirefoxのみに表示されChromiumやWebKitでは表示されない場合、Gecko固有のレンダリング動作の可能性が高いです。gap、aspect-ratio、カスタムフォントなどのCSSプロパティで既知のエンジン差異を確認しましょう。

フォントレンダリングの違い

サブピクセルフォントレンダリングはOSとエンジンで異なります。テキスト関連の小さな差分（アンチエイリアシング、カーニング）は通常ノイズです。テキストの多いページにはやや高めのしきい値を使用しましょう。

真のリグレッション

同じ差分が複数のブラウザに表示される場合、ほぼ確実にコード変更です — エンジンの特性ではありません。これらの差分は解決されるまでマージをブロックすべきです。

レスポンシブ専用の問題

特定のブレークポイントのみで表示される差分は、CSSメディアクエリの問題やコンテナクエリのエッジケースを示すことが多いです。修正前に正確なビューポートサイズでローカルに再現しましょう。

推奨テスト頻度

モダンフレームワークの実践的ヒント

シングルページアプリケーション

SPAはキャプチャ前に特定のルートへのナビゲーションが必要です。テストセットアップがクライアントサイドレンダリングの完了とネットワークリクエストの安定を待つことを確認しましょう。

サーバーサイドレンダリングアプリ

SSRアプリはビジュアルのちらつきを生むハイドレーションの不一致を示す場合があります。偽の差分を避けるため、完全なハイドレーション後にキャプチャしましょう。

デザインシステムコンポーネント

コンポーネントライブラリを管理している場合、StorybookやPlayground環境で独立してテストしましょう。コンポーネントレベルのビジュアルテストは、アプリケーションページに影響する前にドリフトをキャッチします。

ScanUで始める

ScanUはChromium、Firefox、WebKitと6つのデバイスプリセットをサポートしているため、ブラウザインフラを管理せずに実践的なクロスブラウザマトリクスを構築できます。プランオプションは料金、テストの仕組みは使い方、実装の詳細はFAQをご覧ください。