상품 목록은 빠르게 열렸다. 그런데 상품을 누르자 화면이 잠시 멈춘다. 뒤로 돌아가는 동작은 괜찮지만, 다른 상품을 선택하면 다시 기다려야 한다.
이런 서비스의 성능을 첫 페이지 로딩 결과만으로 설명하기는 어렵다. 사용자는 사이트에 접속하는 시간뿐 아니라, 그 안에서 이동하는 시간도 경험하기 때문이다.
클라이언트 라우팅을 사용하는 프론트엔드라면 이 차이를 살펴볼 필요가 있다. 최근 Chrome이 공개한 Soft Navigation을 포함하는 실험적 성능 지표도 바로 이 문제를 다룬다.
브라우저가 보는 페이지와 사용자가 보는 페이지
전통적인 페이지 이동에서는 브라우저가 새로운 HTML 문서를 불러온다. 반면 SPA는 현재 문서를 유지한 채 JavaScript로 화면과 URL을 바꾼다.
사용자에게는 둘 다 ‘다음 페이지로 이동한 것’이다. 하지만 성능을 측정하는 입장에서는 경계가 다르다. 문서를 새로 불러오지 않았다면, 어디부터 어디까지를 하나의 페이지 경험으로 볼 것인가?
Chrome의 Soft Navigation 감지는 다음 세 조건을 기준으로 삼는다.
- 사용자 동작으로 시작한다.
- 사용자에게 보이는 URL이 바뀐다.
- 해당 상호작용으로 화면에 시각적 변화가 발생한다.
따라서 모든 컴포넌트 업데이트를 새로운 페이지로 세는 것은 아니다. URL이 그대로인 아코디언이나 모달을 여는 동작까지 자동으로 페이지 전환으로 취급한다고 이해해서는 안 된다. 감지 기준에는 오탐과 누락 가능성도 있다. Chrome 공식 문서
이번에 달라진 것은 ‘측정의 경계’다
2026년 10월 13일, Chrome은 실제 사용자 경험 데이터인 CrUX에 Soft Navigation을 포함하는 실험적 지표를 공개했다. 기존의 LCP, INP, CLS에 화면 전환이라는 경계를 추가한 것이다.
| 지표 | Soft Navigation을 포함하면 달라지는 관점 |
|---|---|
| LCP: 주요 콘텐츠 표시 속도 | 최초 문서 로딩뿐 아니라 후속 화면 전환도 측정 대상에 포함한다. |
| INP: 상호작용 응답성 | SPA 전체 이용 중 발생한 상호작용을 최초 페이지에 묶는 대신, 전환 단위로 나누어 본다. |
| CLS: 시각적 안정성 | 화면 이동 전후를 구분해 레이아웃 이동을 평가한다. |
중요한 제한도 있다. 현재 공개된 것은 실험적 지표이며, 기존 안정판 Core Web Vitals 점수가 바로 대체된 것은 아니다. 새로운 수치가 보인다고 Search Console의 평가 방식까지 이미 바뀌었다고 해석하면 안 된다. CrUX 공식 발표
이 변화는 프레임워크의 우열을 가리는 기능이라기보다, 사용자가 경험한 지연을 더 적절한 화면에 연결하는 작업에 가깝다.
점수가 좋아져도 코드가 빨라진 것은 아닐 수 있다
측정 방식이 바뀌면 같은 서비스의 결과도 달라질 수 있다.
최초 접속에서는 코드와 리소스를 내려받아야 하지만, 후속 이동에서는 이미 받은 자원을 재사용할 수 있다. 이 후속 이동이 측정에 포함되면 전체적인 LCP 분포가 좋아질 수 있다. INP와 CLS도 화면별로 구간을 나누면서 기존 결과와 차이가 생길 수 있다. 지표별 변화 설명
따라서 실험적 지표가 기존 지표보다 좋다는 이유만으로 “이번 배포로 성능을 개선했다”고 기록하는 것은 적절하지 않다.
배포 효과를 확인하려면 같은 측정 방식끼리 비교해야 한다. 그 위에서 기기, 네트워크, 방문 경로 같은 조건이 얼마나 달라졌는지도 살펴야 한다. 측정 체계의 변경과 제품의 개선은 별개의 사건이다.
프론트엔드에서는 무엇부터 확인하면 될까
당장 라우터를 교체하거나 별도의 성능 수집 시스템을 만들 필요는 없다. 우선 서비스에서 중요한 이동 하나를 골라보는 편이 좋다.
쇼핑몰이라면 ‘상품 목록에서 상세 페이지로 이동’, 관리 도구라면 ‘검색 결과에서 상세 화면으로 이동’처럼 사용자가 반복하는 경로가 적합하다.
Chrome DevTools의 Performance 패널은 Soft Navigation의 실시간 지표와 기록 분석을 지원한다. 다만 관련 API의 브라우저 지원은 아직 동일하지 않으므로, 모든 브라우저에서 같은 정보를 얻을 수 있다고 가정해서는 안 된다. 지원 범위와 DevTools 안내
다음은 이러한 이동을 분석할 때 권하는 확인 순서다.
먼저 새로고침으로 해당 URL에 직접 진입한 경우와, 앱 내부 링크로 이동한 경우를 나누어 기록한다. 두 경로를 하나의 결과로 취급하지 않는 것이 출발점이다.
이후 기다리는 시간이 어디서 발생하는지 확인한다. 예를 들어 다음과 같은 가설을 세울 수 있다.
- 클릭 후 API 요청이 늦게 시작된다면, 요청 전에 필요한 코드나 상태 처리가 있는가?
- 응답은 도착했는데 화면이 늦게 바뀐다면, 데이터 가공이나 렌더링 작업이 길어지는가?
- 화면은 빠르게 바뀌지만 내용이 밀린다면, 이미지나 비동기 콘텐츠의 공간을 미리 확보했는가?
이 목록은 특정 서비스의 진단 결과가 아니다. 기록을 보고 원인을 좁히기 위한 질문이다. 같은 ‘느린 페이지 전환’이라도 네트워크 대기와 메인 스레드 작업은 해결 방법이 다르다.
한 번 방문한 화면을 다시 열었을 때만 빠른지도 구분해야 한다. 캐시가 준비된 개발 환경에서의 인상만으로 처음 방문한 사용자의 경험을 판단하기는 어렵다.
첫 화면 최적화 다음에 남는 일
첫 로딩을 빠르게 만드는 일은 여전히 중요하다. 다만 그 결과만으로 사용자가 서비스 전체를 빠르게 이용한다고 말할 수는 없다.
Soft Navigation 측정이 던지는 질문은 단순하다.
“처음 들어왔을 때 얼마나 빨랐는가”에 더해, “다음 화면으로 이동할 때는 어땠는가.”
새로운 지표를 대시보드에 추가하는 것보다 먼저 할 일은, 우리 서비스에서 중요한 화면 전환을 하나 정하고 실제로 기록해보는 것이다. 그 과정에서 발견한 지연이야말로 다음 최적화 작업의 구체적인 출발점이 된다.
2026년 10월 26일 기준 공식 문서를 바탕으로 작성했다. 실험적 지표와 브라우저 지원 범위는 이후 변경될 수 있다.