필드 데이터 vs 실험실 데이터: 대부분의 Core Web Vitals 논쟁이 실패하는 이유
대부분의 성능 관련 논쟁은 사람들이 잘못된 데이터셋을 사용하기 때문에 발생합니다.
한 사람은 실제 사용자 결과를 보고, 다른 사람은 실험실 시뮬레이션을 봅니다. 둘 다 맞습니다. 둘은 서로 다른 질문에 답하고 있기 때문입니다.
사용 중인 데이터셋이 무엇인지 정의할 수 없다면, 당신은 진단하고 있는 것이 아니라 그저 논쟁하고 있는 것입니다.
차이점을 이해하세요:
- 필드 데이터는 실제 사용자들이 대규모로 문제를 겪고 있는지 알려줍니다. 여기에는 느린 휴대폰과 좋지 않은 셀룰러 서비스 환경이 포함됩니다.
- 실험실 데이터는 왜 문제가 발생하는지 알려줍니다. 제어된 트레이스(trace)와 반복 가능한 테스트를 제공합니다.
LCP, INP, CLS와 같은 Core Web Vitals는 결과 지표입니다. 이 지표들은 '무엇이 일어났는지'를 알려줄 뿐, '왜' 일어났는지는 알려주지 않습니다.
평균값을 사용하는 것을 멈추세요. 75번째 백분위수(75th percentile)를 사용하세요. 사이트가 본인에게는 빠르게 느껴질 수 있지만, 75번째 백분위수는 느린 네트워크와 저사양 기기를 고려하기 때문에 여전히 기준 미달일 수 있습니다.
성능 문제를 해결하려면 다음 순서를 따르세요:
- 필드 데이터: 문제가 존재하는지 확인하고 그 범위를 파악합니다.
- 실험실 데이터: 테스트 가능한 원인을 격리합니다.
- 필드 데이터: 원래의 증거를 바탕으로 수정 사항을 검증합니다.
주장과 증거를 일치시키세요:
- 사용자들이 문제를 겪고 있다면: Search Console 트렌드를 확인하세요.
- 템플릿이 원인이라면: 유사한 URL 전반에서 발생하는 실패 사례를 찾아보세요.
- 서버 문제로 LCP가 느리다면: 실험실 트레이스를 사용하여 문서 응답(doc response)이 늦어지는 지점을 찾으세요.
- INP가 기준 미달이라면: DevTools를 사용하여 롱 태스크(long tasks)를 찾으세요.
- 배포로 인해 성능 저하(regression)가 발생했다면: 배포 로그와 시점을 대조해 보세요.
단 한 번의 Lighthouse 실행 결과에 의존하지 마세요. 데스크톱 테스트 결과로 모바일의 실패 원인을 설명하려 하지 마세요. "더 빠르게 느껴진다"는 말을 증거로 사용하지 마세요.
다음 단계를 따르세요:
- 사용 중인 데이터셋을 한 문장으로 정의하세요.
- 범위를 확인하세요. 반증하기 전까지는 템플릿 문제라고 가정하세요.
- 제약 요인을 식별하세요. 서버인가요, 렌더링 경로(render path)인가요, 아니면 제3자(third party) 서비스인가요?
- 자신의 가설이 틀렸음을 증명할 수 있는 가장 작은 규모의 테스트를 실행하세요.
병목 현상을 찾는 데는 실험실 데이터를 사용하세요. 병목 현상이 사라졌음을 증명하는 데는 필드 데이터를 사용하세요.