クロスブラウザテストとは、訪問者が使うブラウザと端末で、Webサイトが正しく表示・動作するかを確認することです。実際には、3つのレンダリングエンジン（ChromiumのBlink、SafariのWebKit、FirefoxのGecko）をPCとモバイルの両方で確認することになります。大部分は、インストールしたブラウザ、Playwright、スマホ表示ツールを使えば無料でカバーでき、手元にない実機が必要なときだけクラウドの端末に費用をかければ十分です。
どのブラウザをテストするか
世界全体のシェアではなく、自分のサイトのアクセス解析から考えましょう。B2B向けのダッシュボードならPC版のChromeとEdgeが中心かもしれませんし、一般消費者向けのショップならiPhoneのSafariが大半かもしれません。直近3か月のブラウザ別・端末別のレポートを見て、セッションの数パーセントを超えるものはすべて対象にします。
まだデータがない場合は、次の組み合わせでエンジンと実際のトラフィックの大部分をカバーできます。
| ブラウザ | エンジン | 重要な理由 |
|---|---|---|
| Chrome（PCとAndroid） | Blink | PCとAndroidで最大のシェア |
| Safari（iPhone、iPad、Mac） | WebKit | すべてのiPhoneユーザー。「スマホでだけ起きる」不具合の多くはここ |
| Edge | Blink | Windowsの標準ブラウザ。通常はChromeと同じ挙動 |
| Firefox | Gecko | 独自のエンジン。実はChromium特有の挙動だった、という思い込みを見つけられる |
| Samsung Internet | Blink | Samsung製スマホにプリインストール。独自の更新サイクルとダークモードを持つ |
特に注意すべきエンジンは2つです。iPhoneで使われるWebKitと、AppleでもGoogleでもない唯一の主要エンジンであるGeckoです。
各ブラウザで確認すること
クロスブラウザの不具合が起きやすい場所はある程度決まっています。主要なページごとに次のリストを確認しましょう。
- レイアウト。 flexboxやgridの
gap、position: sticky、aspect-ratio、古いバージョンでのコンテナクエリ。 - フォント。 Webフォントが読み込まれるか、代替フォントの文字幅が近いか、読み込み中に文字が見えなくならないか。
- フォーム。 日付・時刻ピッカー、
selectのスタイル、自動入力時の色、バリデーションメッセージ、入力欄ごとのスマホキーボードの種類。 - メディア。 動画の自動再生ルール（多くのモバイルブラウザはミュート時のみ許可）、AVIFなどの画像形式、
srcsetで選ばれる画像。 - スクロールとビューポート単位。 スマホでの
100vhと動的な100dvhの違い、スクロールスナップ、スムーズスクロール、オーバースクロール。 - JavaScript API。 ここ2年ほどで登場したものは、使う前に対応状況を確認します。
- 操作性。 タッチ端末でのホバー専用メニュー、キーボード利用者向けのフォーカス表示、タップ領域。
- ダークモードと拡大表示。 200%に拡大したときと、OSのダークモードを有効にしたときの表示。
作業の大半をこなせる無料ツール
ブラウザをインストールする。 Chrome、Edge、FirefoxはどのPC用OSでも動きます。SafariはmacOSでしか動かないため、Macを持っていないテスターには追加のツールが必要になります。
コードを書く前に対応状況を確認する。 Baselineは、Web機能が主要ブラウザで「newly available」か「widely available」かを示し、Can I useはバージョンごとの対応表を提供しています。先に確認しておけば、クロスブラウザの不具合の多くを防げます。
Playwrightで自動化する。 Playwrightは、同じテストスクリプトをWindows、macOS、Linux上のChromium、Firefox、WebKitで実行でき、モバイル端末のエミュレーションも可能です。重要な10ページを3つのエンジンで開いてスクリーンショットを保存する短いスクリプトがあれば、プルリクエストごとに大半のデグレを検出できます。
レスポンシブの確認にはスマホ表示ツールを使う。 スマホのレイアウト崩れは、ブラウザの問題と混同されがちです。まずDevToolsのデバイスモードやMobile View Extensionのような拡張機能でレイアウトの問題を切り分け、そのうえでエンジン固有の原因を探しましょう。2つのツールの違いはスマホシミュレーター拡張機能とDevToolsの比較で説明しています。
モバイルのエンジンはエミュレーターで確認する。 XcodeのシミュレーターならMac上で本物のiOS Safariを使えます（解説）。Android Studioのエミュレーターなら本物のAndroid版Chromeを使えます（解説）。
有料のクロスブラウザテストツールが役立つ場面
クラウドのテストサービスでは、実機や多数のブラウザバージョンを借りられます。次のような場合は費用をかける価値があります。
- Macがなく、iPhoneのSafariを定期的に確認する必要がある
- 顧客が古いバージョンのブラウザを使っており、並べてインストールできない
- クライアントとの契約で特定の機種での確認が求められている
- 自動テストを実機のモバイル端末で実行する必要がある
小規模なサイトなら、リリース週だけ月額プランを使えば十分なことが多く、たまの確認なら無料トライアルでもかなり対応できます。
軽量なクロスブラウザ確認の流れ
- 開発中： 新しい機能を使う前にBaselineを確認し、コーディングしながらスマホ表示をプレビューする。
- プルリクエストごと： PlaywrightでChromium、Firefox、WebKitのスクリーンショットを撮る。
- リリース前： Safari（Macまたはシミュレーター）、Firefox、AndroidのChromeで主要な導線を操作して確認する。
- リリース後： エラー監視とアクセス解析で、ブラウザ別にまとめたエラーを確認する。
リリース前のモバイル側の確認は、スマホサイトのテストチェックリストで詳しく解説しています。
よくある質問
無料で複数のブラウザでサイトを確認するには？
Chrome、Edge、Firefoxをインストールし、PlaywrightでどのOSでもWebKitを動かし、スマホサイズの確認にはDevToolsかスマホ表示の拡張機能を使います。Macがあれば、XcodeのシミュレーターでiOS Safariも確認できます。
Chromeで確認したら、Edgeでのテストは不要ですか？
EdgeはChromeと同じエンジンなので、違いが出ることはまれです。利用者がEdge固有の機能や企業向けポリシーを使っていない限り、軽く確認するだけで十分です。
現在、クロスブラウザの不具合で最も多い原因は？
ユーザーが使うすべてのブラウザで対応される前に、CSSやJavaScriptの機能を使ってしまうことです。採用前にBaselineのステータスを確認すれば、そのほとんどを防げます。