랜딩이나 대시보드를 맡고 있다면 Lighthouse 90점대인데도 “아이폰에서만 버벅인다”는 피드백을 받았을 수 있습니다. Lighthouse는 Chromium에서 돌고 Safari(WebKit)는 다른 렌더·입력 경로를 씁니다. 2026년 기준으로 LCP·INP·CLS를 어떻게 설명할지, Chrome UX Report(CrUX)와의 관계, WebKit 진짜 숫자가 필요할 때 클라우드 Mac mini가 왜 실용적인지 정리합니다.
Google이 제시하는 Core Web Vitals “양호” 기준은 75백분위에서 LCP 2.5초 미만, INP 200ms 미만, 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 악화가 300ms 넘으면 머지를 막는 정책에 잘 맞습니다. macOS WebKit 스모크는 릴리스 브랜치나 야간에 돌려도 충분한 경우가 많습니다. 둘이 충돌하면 대외 Safari 체감은 WebKit을 우선하고, Chrome 중심 대시보드는 Lighthouse·CrUX로 설명하세요.
데스크톱 Safari에서도 INP를 봐야 하나요?
SaaS처럼 키보드·트랙패드 중심 제품이라면 모바일과 구분해 측정하세요. 데스크톱 WebKit에서도 메인 스레드 블로킹이 길면 INP가 나쁘게 나올 수 있으며, 이는 Lighthouse 한 번의 내비게이션 점수만으로는 드러나지 않습니다. 팀은 최소 분기별로 원격 Mac에서 대표 시나리오(로그인, 테이블 정렬, 모달 열기)를 스크립트로 재현하는 것을 권장합니다.
FAQ
모바일 에뮬로 Safari를 대체할 수 있나요?
뷰포트·스로틀만 바뀌며 엔진은 바뀌지 않습니다.
Search Console과 Lighthouse가 다른 이유는?
콘솔은 약 28일간 Chrome 실사용자 집계입니다. 기기 믹스·캐시 상태가 실험실과 다릅니다.
Apple Silicon Mac mini는 네이티브 WebKit, 저소음, 장시간 부하 테스트에 적합한 설계를 갖춥니다. MacHTML로 임대하면 조달 주기 없이 SSH·VNC를 즉시 쓰고 캠페인 때 확장·한산기 축소가 가능합니다. Core Web Vitals를 경영에 보고할 때 Chromium 실험실과 주기적인 클라우드 Mac mini 실측을 함께 제시하는 것이 2026년에도 가장 정직한 내러티브입니다.