예약 플로우에서 레이아웃 이동이 발생하던 싱글 페이지 애플리케이션
Prijsvrij는 휴가 상품을 검색, 비교, 예약하는 네덜란드 여행 사이트입니다. 사이트 전체가 싱글 페이지 애플리케이션이며, 동일한 팀이 Prijsvrij.be와 D-reizen도 함께 운영합니다.
현장에서 하루 4시간씩 이틀 동안 작업했습니다. 첫째 날에는 사이트를 진단했습니다. 둘째 날에는 팀과 함께 결과를 검토하며 가장 시급한 문제부터 해결하는 방법을 단계별로 설명했습니다.
첫 화면, 예약 플로우, 클릭
대부분의 레이아웃 이동은 소프트 내비게이션에서 발생했습니다. 페이지를 새로 로드하지 않고 앱이 콘텐츠만 교체하는 동작입니다. 홈페이지를 대상으로 실행한 Lighthouse로는 이를 전혀 감지할 수 없습니다. 반면 예약을 진행하며 클릭하는 실제 방문자는 이를 겪게 되며, CrUX는 처음 접속한 URL에 해당 이동을 집계합니다.
2026년 3월 말에 진단 결과를 전달했고, 4월 15일 덴보스 현장에서, 일주일 뒤에는 온라인으로 개발팀과 함께 검토했습니다. CLS 해결이 가장 까다로웠습니다. 이런 아키텍처에서 일반적인 수준보다 원인이 더 많았습니다. 개발팀은 3개 사이트 모두에서 문제를 해결했고, 5월에는 전 사이트의 데스크톱 CLS가 녹색(Good) 구간에 진입했습니다.
6월의 어느 날 아침, 프론트엔드 리드에게서 이메일이 왔습니다. 지난 몇 주간 Claude Code로 연동된 CoreDash 데이터를 보며 prijsvrij.nl을 손보았는데, 그래프가 좋은 방향으로 움직이고 있다는 소식이었습니다. D-reizen도 연동할 수 있는지 물어왔고, 한 시간 만에 D-reizen과 Prijsvrij.be 모두 CoreDash에 추가되었습니다.
다음 과제는 INP입니다. 6월 말에 데이터를 살펴보았을 때 익숙한 패턴이 눈에 들어왔습니다. 이미 수없이 접했던 패턴으로, 각 단계를 정확히 밟아가면 검증된 단계별 계획으로 해결할 수 있습니다. 그렇게 가장 큰 비중을 차지하는 문제를 먼저 걷어내야 합니다. 그래야 그 아래 가려져 있던 문제들이 드러나며, 그 문제들은 언제나 더 작고 다루기 쉽습니다. 그래서 이론을 늘어놓기보다 실무에 바로 뛰어들어 작고 정밀한 수정을 거치는 방식을 제안했습니다. 7월에는 고객사 사무실에서 점심을 함께하며 만났고, 이후 매 분기 미팅을 이어가고 있습니다.
휴가철에는 직접 휴가를 떠난 사용자들의 트래픽이 몰리면서 모바일 LCP가 상승합니다. 하지만 여전히 2.5초 훨씬 아래를 안정적으로 유지하고 있으며, 이미 다시 하락세로 돌아섰습니다.
로딩 애니메이션은 레이아웃 이동을 뒤로 미룰 뿐입니다
애니메이션이 대기 시간을 가려주는 것처럼 보였지만, 항공편 상세 정보에 자리를 내어주는 순간 레이아웃 이동이 발생했습니다.
클릭 핸들러 내부의 트래킹은 모든 클릭에 비용을 치르게 합니다
클릭 핸들러 안의 태그는 화면이 갱신되기도 전에 먼저 실행됩니다. 이를 화면 업데이트 뒤로 옮기면, 방문자는 화면 반응을 먼저 보고 태그는 태그대로 정상 실행됩니다.
싱글 페이지 애플리케이션은 끊임없이 변합니다
배포할 때마다 지난 점검에서는 없었던 새로운 컴포넌트와 태그가 추가됩니다. 제가 분기마다 다시 찾아가는 이유입니다.
Lighthouse가 잡아내지 못하는 싱글 페이지 앱의 레이아웃 이동이 있습니까?
예약이나 결제 플로우 URL을 보내주시면 소프트 내비게이션을 포함해 실제 방문자가 이용하는 방식 그대로 직접 클릭하며 점검해 드립니다.
또는 컨설팅 살펴보기. 더 많은 성과는 고객사 사례 페이지에서 확인할 수 있습니다.
