ランディングページやダッシュボードを担当していると、Lighthouse 性能スコア 90 点台なのに「iPhone だけ遅い」と言われる経験は珍しくありません。Lighthouse は Chromium 上で動き、Safari（WebKit）は別のレンダリング・入力経路を持ちます。本稿では 2026 年時点で LCP・INP・CLS をどう経営層に説明すべきか、Chrome UX Report（CrUX）との関係、そして WebKit の真値が必要なときに クラウド Mac mini が効く理由を整理します。
Google が公表する Core Web Vitals の「良好」閾値は第 75 百分位で、LCP 2.5 秒未満、INP 200 ミリ秒未満（FID の後継）、CLS 0.1 未満です。これらはフィールド（実ユーザー）指標であり、単発のラボ計測とは一致しないのが普通です。
ラボとフィールドと WebKit の整理
| ソース | エンジン | 用途 | 限界 |
|---|---|---|---|
| Lighthouse | Blink | CI ゲート、バジェット | Safari 固有のペイント差を見ない |
| CrUX | Chrome 実ユーザー | SEO 向けトレンド | Safari 偏重の業界では過小評価になりうる |
| macOS Safari | WebKit | 実機検証 | Linux ランナーでは再現しにくい |
いつ本物の Safari が必須か
- アナリティクスで Safari／WKWebView 系がセッションのおおよそ 25% 超。
- ヒーロー画像やウェブフォントが LCP の主因で、WebKit の優先度制御を疑うとき。
- SPA 遷移後のタッチ INP が課題で、単発ナビの Lighthouse では再現しないとき。
リモート Mac での再現手順（2026 推奨）
ユーザーに近いリージョンの Mac mini に SSH 接続し、Node.js 22 LTS と Playwright WebKit などを固定バージョンで入れる。各 URL についてコールド 5 回＋ウォーム 5 回を取得し、最初のコールド外れ値を捨てる。必要なら VNC で Web Inspector を開き、レイアウトシフトを目視確認する。計測中は Spotlight の大量インデックスやチャットアプリを止め、CPU 競合による LCP の数百 ms ブレを避ける。
Lighthouse CI と WebKit 夜間ジョブの役割分担
Linux 上の Lighthouse CI はコスト効率が高く、main からの LCP 悪化が 300 ms を超えたらマージを止めるなどのポリシーに向く。一方、macOS 上の WebKit スモークはリリースブランチやナイトリーで十分なことが多い。二者が矛盾したら、対外の Safari 体験を守るなら WebKit 側を優先し、Chrome 中心のダッシュボードは Lighthouse／CrUX を基準に説明する。
FAQ
モバイルエミュレーションで Safari を代用できる？
ビューポートとスロットリングだけの変更であり、エンジンは変わりません。
Search Console と Lighthouse が違うのはなぜ？
Search Console は約 28 日分の Chrome 実ユーザーの集計です。端末構成とキャッシュ状態がラボと一致しません。
Apple Silicon の Mac mini はネイティブ WebKit、静音、長時間の負荷試験に向いた熱設計を兼ね備えます。MacHTML でレンタルすれば調達サイクルを待たず SSH／VNC を即利用でき、キャンペーン時に台数を上げ、閑散期に下げる弾力運用が可能です。コア Webバイタルを経営会議で語るなら、Chromium ラボと定期的な クラウド Mac mini 実測をセットで提示するのが 2026 年もっとも誠実なストーリーです。
実 Safari で Vitals を測る
近いリージョンの Mac mini で WebKit トレースを取得し、LCP／INP を iOS 体感に寄せましょう。