「SafariとChromeでは問題ない、特定の1ブラウザだけで不具合が出る」。サイト制作中にこの状況に出会うことがあります。
時間をかければ原因を突き止められるかもしれません。けれど対象ブラウザのシェアと修正コストを並べてみると、そのブラウザ限定の問題と割り切ってサイト側の修正をやめたほうが、コスト的に得なことが多いです。問題は、どこで割り切るか。その線引きの手順を書きます。
切り分けの手順
主要環境で再現するか
まず手元の環境で、どこまで再現するかを確認します。
| OS | ブラウザ |
|---|---|
| macOS | Safari、Chrome、Edge、Firefox |
| Windows | Chrome、Edge、Firefox |
| iOS | Safari、Chrome、Brave (日本など多くの地域ではWebKit強制) |
| Android | Chrome、Samsung Internet、Brave |
このうち1つでも再現するなら、ブラウザ単独ではなくサイト側にも原因があると見ます。ただし、1つ再現したからといってサイト側が主因と即断しないでください。複数ブラウザに共通する拡張機能、OS設定、ネットワーク要因が重なっている場合もあるので、どの条件で再現したかは丁寧に書き出します。
エンジンで分類する
レンダリングエンジンはBlink (Chrome、Edge、Brave-desktop、Opera、Samsung Internet)、WebKit (Safari、日本市場のiOSブラウザのほとんど)、Gecko (Firefox)の3系統です。同じエンジン内で挙動が割れているかどうかが、最初の判断材料になります。
「Chromeでは出ないがEdgeでは出る」なら、同じBlinkで挙動が割れるのは珍しいので、拡張機能かEdge固有機能(Read Aloud等)を疑います。「Safariでは出ないがiOS Braveでは出る」なら、同じWebKitなのにBraveだけで出ているので、レンダリング以外の機能(Shields、Fingerprint Protection、Rewards)が干渉していると見るのが自然です。
ブラウザ拡張機能を疑う
該当ブラウザの拡張機能を全部無効化して再現するか確認します。広告ブロッカー、プライバシー保護、セキュリティ拡張はJavaScriptやイベント、スクロールに干渉します。拡張オフで再現しないなら、ユーザー側の拡張機能が原因なので、サイト側の責任外です。
ブラウザ固有機能を順にオフ
該当ブラウザのセキュリティ機能やプライバシー機能を1つずつ無効化します。BraveならShields、Fingerprint Protection、Block Cookies。EdgeならTracking Prevention、Defender SmartScreen。FirefoxならEnhanced Tracking Protection、privacy.resistFingerprinting。
「Fingerprint Protectionをオフにしたら再現しない」なら、ブラウザが意図的にAPIのタイミングを改変しているのが原因です。これはサイト側で完全に塞ぐのは難しい。ここで切る判断に大きく傾きます。
ブラウザのフォーラムで検索
該当ブラウザのGitHub Issues、フォーラム、Stack Overflowで同じ症状が報告されていないか確認します。報告例があればknown issueとして扱います。
断念する基準
ここまでの結果が次の全部に当てはまるなら、サイト側の修正は対象外にしてかまいません。
- 主要環境で再現せず、1ブラウザのみ
- そのブラウザのセキュリティ機能やプライバシー機能をオフにすると再現しない
- シェアが小さい(例: 該当ブラウザのユーザー比率が 5%未満)
- 同issueがブラウザ側known issueとして報告されている
全部Yesなら、そのブラウザのユーザーには別ブラウザでの閲覧を案内し、サイト側は対応外とします。
判定後のユーザーへの案内
利用環境ページかFAQに対応ブラウザと推奨ブラウザを書き、Safari、Chrome、Edge、Firefoxを列挙します。Brave等の派生ブラウザは「主要機能のみ確認済み」程度にとどめます。
該当ブラウザでアクセスがあった時にヒントを出すのも手ですが、Brave検出はUA文字列や navigator.brave で試みる程度で、どれも標準仕様ではなく外れる時期もあります。検出に頼りすぎず、案内は利用環境ページに寄せたほうが安全です。
完全に諦めるのではなく、fix-itバックログに残して3〜6ヶ月ごとに見直します。ブラウザ側が直すこともあるし、そのブラウザのシェアが伸びたら対応する判断もありえます。
諦める判断がコスト上有利な理由
ブラウザ互換性を100%追うとコストが跳ね上がります。主要4ブラウザの実機テストなら時間内に終わるプロジェクトでも、派生ブラウザを全部見ようとすると終わりません。
派生ブラウザを使う人は、privacy重視、軽量、広告ブロックといった理由でそのブラウザを選んでいて、機能のトレードオフを承知しています。だから自分が選んだブラウザの制約は、利用者側で吸収してもらう。これがWebの暗黙の前提です。
そのかわり主要ブラウザではちゃんと動かす。Safari、Chrome、Edge、Firefox、iOS Safari、Android Chromeの6環境は死守し、それ以外はベストエフォート。これが現実的な品質基準です。
5ステップの切り分けで「主要4ブラウザで再現しない」「ブラウザの特殊機能オフで消える」と確認できたら、サイト側の修正を切る。シェアとコスト、利用者側の選択を踏まえれば、そのほうが得です。
「どこまで対応するか」の線引き設計も含めて、Webプロジェクトの品質基準づくりはSystem PM領域で支援しています。