크롬 151, SPA 라우팅도 측정한다 — 서치 콘솔엔 언제 반영될까?

크롬 151(2026년 7월 28일부터 순차 배포)은 앱처럼 화면만 바뀌는 '소프트 내비게이션'을 코어 웹 바이탈로 측정하는 기능을 처음 넣었다. 하지만 서치 콘솔의 코어 웹 바이탈 리포트와 페이지스피드 인사이트가 참조하는 크롬 사용자 경험 보고서(CrUX)는 아직 이 데이터를 담지 않는다. 그래서 SPA로 만든 사이트의 화면 전환이 실제로 빨라져도 서치 콘솔에 찍히는 숫자는 당장 움직이지 않는다.

소프트 내비게이션이 무엇이길래 크롬이 새로 측정하나?

React·Vue 등으로 만든 SPA는 메뉴를 눌러도 브라우저가 문서를 다시 내려받지 않고 자바스크립트로 URL과 화면 일부만 바꾼다. 기존 코어 웹 바이탈은 이런 전환을 별도로 구분하지 않고 첫 페이지 로드 하나에만 지표를 붙였다. 그 결과 사용자가 실제로 겪는 두 번째, 세 번째 화면 전환 지연은 통계에 전혀 잡히지 않았다.

크롬 151부터는 브라우저가 클릭 같은 상호작용으로 시작된, 같은 문서 안에서의 URL 변경을 감지해 그 시점을 새로운 '타이밍 기준점'으로 잡는다. 이 기준점부터 다시 로딩·페인트·상호작용 지연을 계산하는 것이 이번 업데이트의 핵심이다.

크롬 151에서 실제로 뭐가 바뀌었나?

Performance API에 soft-navigation, interaction-contentful-paint 두 항목이 새로 추가됐다. 기존의 first-paint, first-contentful-paint, largest-contentful-paint, event, layout-shift 항목에는 어느 소프트 내비게이션에서 발생했는지 구분하는 navigationId 값이 붙는다.

구글이 배포하는 자바스크립트 계측 라이브러리 web-vitals는 7월 21일 나온 6버전부터 이 항목을 지원한다. 이제 개발자가 자체 애널리틱스(RUM)에 코드 몇 줄만 추가하면 소프트 내비게이션 단위로 LCP·INP·CLS를 각각 따로 수집할 수 있다.

그럼 서치 콘솔 코어 웹 바이탈 리포트도 곧 바뀌나?

아니다. 서치 콘솔과 페이지스피드 인사이트가 실사용자 지표로 쓰는 크롬 사용자 경험 보고서(CrUX)는 지금도 하드 내비게이션, 즉 문서를 완전히 새로 불러오는 첫 진입만 집계한다. 크롬 151이 소프트 내비게이션을 브라우저 단에서 측정할 수 있게 됐다는 것과, 그 값이 CrUX라는 별도 집계 데이터셋에 들어가는 것은 다른 문제다. 구글은 소프트 내비게이션을 CrUX에 언제 어떤 방식으로 포함할지 아직 공식 일정을 내놓지 않았다.

즉 SPA 화면 전환을 아무리 개선해도, 서치 콘솔의 '코어 웹 바이탈' 보고서 수치는 당분간 그 개선을 반영하지 못한다. 리포트가 좋다고 SPA 내부 전환도 좋다는 뜻은 아니고, 리포트가 나쁘다고 소프트 내비게이션이 원인인 것도 아니다.

SPA를 운영한다면 지금 뭘 준비해야 하나?

서치 콘솔만 보고 있으면 화면 전환 지연을 놓친다. 지금 할 수 있는 준비는 세 가지다.

• 프런트엔드의 web-vitals 라이브러리를 6버전 이상으로 올려 소프트 내비게이션 이벤트를 코드에서 받을 수 있게 한다.
• 자체 애널리틱스나 로그 수집 파이프라인에 navigationId 기준 LCP·INP·CLS를 별도 필드로 쌓는다.
• 크롬 개발자 문서의 CrUX 릴리스 노트를 주기적으로 확인해, 소프트 내비게이션이 CrUX에 편입되는 시점을 놓치지 않는다.

정리

크롬 151(7월 28일)부터 브라우저가 SPA의 화면 전환을 소프트 내비게이션으로 인식해 코어 웹 바이탈을 측정하고, web-vitals 6버전(7월 21일)이 이를 지원한다. 그러나 서치 콘솔과 페이지스피드 인사이트가 쓰는 CrUX 필드 데이터엔 아직 이 값이 포함되지 않아, 리포트상 수치는 당장 바뀌지 않는다. SPA를 운영한다면 서치 콘솔을 기다리기보다 자체 RUM 계측으로 소프트 내비게이션 지표를 먼저 확보해야 한다.