SPA 화면 전환이 느릴 때, Chrome에서 전환별 LCP 측정하기

Performance를 열고 앱 안에서 이동한다

첫 화면은 빨리 열리는데 메뉴를 누른 뒤 다음 화면이 늦게 뜬다면, 그 이동을 Chrome DevTools의 Performance 패널에서 재현해야 한다. Live Metrics 화면은 SPA의 클라이언트 측 전환도 반영하며, 감지한 전환에 SOFT NAV 배지를 보여 준다.

앱을 연 상태에서 DevTools의 Performance 탭을 선택하고 실제 링크나 메뉴를 클릭한다. 새 URL의 화면으로 이동했을 때 배지와 지표가 바뀌는지 본다. LCP 값에 마우스를 올리면 세부 값을 볼 수 있고, 표시된 LCP 요소를 확인하면 어떤 콘텐츠가 측정 대상인지 알 수 있다.

이 값은 현재 장치와 네트워크에서 측정한 결과다. 반복 비교할 때는 출발 화면과 클릭 경로, 장치·네트워크 조건을 함께 맞추는 편이 좋다. 다른 이용자의 전체 경험을 대표하는 수치로 바로 해석해서는 안 된다.

Record를 누른 뒤 느린 전환을 재현한다

지연이 재현된다면 실행 중 동작을 기록한다. 공식 런타임 기록 절차를 SPA 이동에 적용하면 다음 순서가 된다.

1. 느린 이동이 시작되는 화면에서 Performance의 Record를 누른다.
2. 앱 안의 링크나 버튼을 눌러 다음 화면으로 이동한다.
3. 새 화면이 나타난 뒤 Stop을 누른다.
4. 기록에서 소프트 내비게이션 마커와 해당 전환의 Insights를 살핀다.

첫 진입을 분석하는 Record and reload는 별도 기능이다. 내부 이동에서만 생기는 지연이라면 주소창에서 목적지를 새로 여는 대신 문제가 생기는 앱 동작을 기록해야 한다.

10월 DevTools 소식은 Chrome 152의 Live Metrics·트레이스 지원에 이어 Insights에도 소프트 내비게이션 분석이 추가됐다고 설명한다. 기록에서 전환을 찾은 다음 지표의 세부 구간과 관련 활동을 살펴볼 수 있게 된 것이다.

첫 로딩이 빠르다고 다음 화면도 빠른 것은 아니다

기존 largest-contentful-paint 항목은 사용자 상호작용이 일어나면 확정돼 초기 페이지 로딩을 측정한다. 소프트 내비게이션 측정은 이후 이동을 일으킨 상호작용과 연결된 새 콘텐츠 표시를 사용한다. 이전 화면에서 받은 LCP 숫자를 다음 화면의 지연으로 읽으면 안 되는 이유다.

측정하는 요소도 달라질 수 있다. 예를 들어 큰 배너는 그대로 있고 그 아래 본문만 바뀌는 앱에서는 내부 이동의 LCP가 새 본문을 대상으로 잡힐 수 있다. 같은 URL을 직접 열면 배너도 새로 그려져 LCP 대상이 될 수 있다. 숫자를 비교할 때는 이동 경로와 대상 요소를 함께 보아야 한다.

마커가 없으면 전환 감지 조건부터 확인한다

Chrome의 소프트 내비게이션 판정에는 사용자 동작, 사용자에게 보이는 URL 변경, 그 동작에 따른 화면 표시 변화가 필요하다. DOM 일부가 바뀌었다는 사실만으로 모든 작업이 새 전환으로 기록되지는 않는다. 브라우저의 판정과 앱 사용자가 생각하는 화면 이동이 맞지 않는 경우도 있다.

관련 API는 Chrome 151부터 기본 활성화됐지만 DevTools의 표시·분석 지원은 이후 단계적으로 확장됐다. 최신 Chrome에서 같은 클릭 경로를 재현하고 전환 표시를 먼저 확인한다. 마커가 없는 경우에도 기록 자체는 남으므로 해당 동작의 실행 구간을 분석할 수 있다. 목적은 첫 로딩 점수를 다시 보는 것이 아니라, 사용자가 기다린 그 이동의 원인을 좁히는 것이다.