기존의 다중 페이지 애플리케이션에서 사용자가 새 콘텐츠를 로드하도록 요청하면 실제로 서버에서 새 HTML 페이지를 요청하게 됩니다. 결과적으로 CloudWatch RUM 웹 클라이언트는 일반 성능 API 지표를 사용하여 로드 시간을 캡처합니다.
하지만 단일 페이지 웹 애플리케이션은 JavaScript와 Ajax를 사용하여 서버에서 새 페이지를 로드하지 않고도 인터페이스를 업데이트합니다. 단일 페이지 업데이트는 브라우저 타이밍 API에 의해 기록되지 않으며, 대신 경로 변경 타이밍을 사용합니다.
CloudWatch RUM은 서버의 전체 페이지 로드와 단일 페이지 업데이트에 대한 모니터링을 모두 지원하지만 다음과 같은 차이점이 있습니다.
경로 변경 타이밍의 경우
tlsTime,timeToFirstByte등과 같은 브라우저에서 제공하는 지표가 없습니다.경로 변경 타이밍의 경우
initiatorType필드가route_change입니다.
CloudWatch RUM 웹 클라이언트는 경로 변경을 유발할 수 있는 사용자 상호 작용을 수신하며, 이러한 사용자 상호 작용이 기록되면 웹 클라이언트는 타임스탬프를 기록합니다. 그리고 다음 두 가지 조건을 모두 만족할 때 경로 변경 타이밍이 시작됩니다.
경로 변경을 수행하는 데 브라우저 기록 API(브라우저 앞으로 및 뒤로 버튼 제외)가 사용되었습니다.
경로 변경 감지 시간과 최신 사용자 상호 작용 타임스탬프 간의 차이가 1,000ms 미만입니다. 이는 데이터 스큐를 방지합니다.
그런 다음 경로 변경 타이밍이 시작되면 진행 중인 AJAX 요청 및 DOM 변형이 없는 경우 해당 타이밍이 완료됩니다. 그리고 마지막으로 완료된 활동의 타임스탬프가 완료 타임스탬프로 사용됩니다.
10초 이상 진행 중인 AJAX 요청 또는 DOM 변형이 있는 경우 경로 변경 타이밍이 시간 초과됩니다(기본값). 이 경우 CloudWatch RUM 웹 클라이언트는 더 이상 이 경로 변경에 대한 타이밍을 기록하지 않습니다.
결과적으로, 경로 변경 이벤트의 기간이 다음과 같이 계산됩니다.
(time of latest completed activity) - (latest user interaction timestamp)
