redBus에서 웹사이트의 'Next Paint(다음 페인트)에 대한 상호작용(INP)'을 개선하고 판매를 7% 늘린 방법

INP 최적화를 통해 redBus의 매출 약 7% 증가

Amit Kumar

Saurabh Rajpal

웹과 그 기능은 빠른 속도로 진화하고 있습니다. 이제 풍부한 기능과 모든 기능을 갖춘 환경을 웹에서 빌드하여 기능 면에서 기본 애플리케이션이 할 수 있는 수준의 많은 것을 달성할 수 있습니다.

JavaScript는 웹 전반에서 상호작용을 촉진하는 주요 수단이지만, 주의해서 사용하지 않으면 상호작용이 느려지고 사용자가 웹사이트가 응답하지 않거나 전혀 작동하지 않는다고 인식할 수 있습니다. 다행히 이 특정 사용자 환경 문제를 해결하기 위해 다음 페인트에 대한 상호작용 (INP) 측정항목이 생성되었습니다.

INP는 수명 주기 동안 페이지와의 모든 상호작용을 측정하고 웹사이트의 사용자 입력에 응답하는 속도를 나타내는 단일 값을 보고합니다. 간단히 말해 페이지의 INP가 양호한 기준점 이하라면 페이지와의 모든 상호작용이 안정적으로 빠르다고 말할 수 있습니다.

인도에 기반을 둔 버스 예약 및 티켓 판매 웹사이트인 redBus는 웹사이트의 INP를 개선하기 위해 상당한 노력을 기울였는데, 이는 INP가 실험 측정항목으로 여겨졌던 시기에도 마찬가지입니다. 이러한 노력의 결과, 매출을 7% 늘릴 수 있었으며, 이는 웹 성능과 비즈니스 건전성의 관계를 다시 한번 입증했습니다. 다음은 redBus에서 웹사이트의 INP를 개선하기 위해 취한 조치입니다.

상위 목표

redBus에서는 웹사이트의 INP를 최적화하기 위해 다음 세 가지 목표를 염두에 두고 있었습니다.

1. 네트워크 속도와 기기 기능에 관계없이 상호작용 지연 시간에 집중하여 사용자에게 더 나은 사용자 환경을 제공합니다.
2. 상호작용을 최대한 빠르게 유지하도록 웹사이트를 최적화합니다.
3. 프런트엔드로 데이터를 빠르게 전송할 수 있도록 API의 응답이 가능한 한 적은지 확인합니다.

여정

redBus에서는 상호작용 지연 시간을 두 가지 방식으로 분류했습니다.

1. 클라이언트에서 자바스크립트를 차단하여 발생한 상호작용 지연 시간입니다. 상호작용에서 기본 스레드를 차단하는 과도한 자바스크립트를 사용하면 렌더링이 지연되고 페이지의 INP에 영향을 미칩니다.
2. API 호출로 인해 발생한 네트워크 지연 시간입니다. 네트워크 활동은 INP로 측정할 수 있는 것이 아니지만, 원격 API 호출에 의존하는 상호 작용은 네트워크 속도가 느리거나 요청으로 큰 응답이 발생하는 경우 느리게 느껴질 수 있습니다.

redBus에서는 초기에 웹사이트의 INP가 적합할 것이라고 확신했지만 이 측정항목의 95번째 백분위수에서 실제 사용자 모니터링 (RUM) 데이터는 다른 결과를 보여주었습니다.

redBus의 INP 측정 방식

redBus에서는 INP뿐 아니라 웹사이트 내 모든 페이지의 중요한 사용자 환경 측정항목을 모두 추적하기 위해 Google에서 개발한 web-vitals 자바스크립트 라이브러리를 활용했습니다. web-vitals JavaScript 라이브러리 외에도 redBus는 ELK를 사용하여 프런트엔드에서 수집된 INP 데이터를 분석했습니다.

하지만 필드에서 웹사이트의 INP를 추적하는 방법은 redBus에서 문제를 접근한 방법과 매우 다를 수 있습니다. 현장에서 느린 상호작용을 찾는 방법을 읽어 웹사이트에서 INP를 추적하는 가장 좋은 방법을 알아본 다음 상호작용 최적화를 시작하기 전에 실험실에서 INP를 재현하는 방법을 알아보시기 바랍니다.

redBus에서 INP를 추적하는 시스템을 마련하자 데이터를 분석하여 상호작용 속도가 느린 부분을 더 잘 파악할 수 있게 되었습니다.

redBus에서 필드에서 수집한 INP 값을 분석하는 데 사용하는 로깅 시스템의 스크린샷 (이미지의 고해상도 버전을 보려면 클릭하세요.)

사용 사례

사용자가 redBus 웹사이트에서 요금을 검색할 때 검색 페이지에서 날짜를 변경하여 원하는 목적지에 대해 선택한 요금을 필터링할 수 있습니다. 이 페이지의 날짜 변경에 대한 상호작용이 느리기 때문에 INP 문제가 발생했습니다.

또한 사용자가 요금을 스크롤하면 API에서 추가 요금이 지연 로드됩니다. 스크롤 자체는 INP 측정 방식에 영향을 미치지 않지만 scroll 이벤트 리스너 자체는 기본 스레드에서 실행해야 하는 많은 작업을 예약합니다. 이 작업으로 인해 기본 스레드에서 경합이 발생하여 상호작용 지연 시간이 증가했고, 이로 인해 검색 페이지의 INP가 낮아졌습니다.

스크롤 시 API에서 추가 요금을 로드하는 데 사용되는 지연 로드 동작입니다. (이 동영상의 고해상도 버전을 보려면 클릭하세요.)

검색 페이지에 맞게 INP를 최적화한 redBus

검색 페이지의 INP를 개선하기 위해 redBus에서는 다음과 같은 몇 가지 최적화를 수행했습니다.

• 지정된 기간에 이벤트 콜백이 실행되는 횟수를 줄이기 위해 scroll 이벤트 핸들러가 디바운스되었습니다. scroll 이벤트 콜백이 실행되는 빈도를 줄임으로써 기본 스레드가 검색 페이지에서의 사용자 상호작용에 더 빠르게 응답할 수 있었습니다.
• 결과 렌더링 작업의 우선순위가 requestAnimationFrame 콜백을 사용하여 지정되었습니다. requestAnimationFrame는 브라우저에 콜백의 작업이 다음 프레임 전에 실행되어야 한다고 알립니다.

이전: 디바운싱 없이 실행되는 스크롤 핸들러가 이벤트 콜백에 적용되었습니다. 기본 스레드에 상당한 수의 차단 작업이 있어 상호작용이 지연됩니다.

후: 디바운싱이 적용된 상태로 실행되는 스크롤 핸들러가 스크롤 이벤트 콜백은 자주 실행되지 않으므로 기본 스레드가 사용자 상호작용에 응답할 기회를 더 많이 제공합니다.

또한 검색결과 페이지를 다음과 같이 추가로 최적화했습니다.

• 지연 로드를 더 일찍 트리거하여 사용자 환경과 시각적 성능을 개선하기 위해 검색결과 페이지의 마지막에서 두 번째 카드에서 새로운 결과 배치를 가져왔습니다.
• 지연 로드 중에 각 네트워크 호출에서 가져온 결과가 더 적습니다. 가져오기 결과를 30개에서 10개로 줄이면 INP 범위가 870개에서 900개에서 350개에서 370개로 감소하는 것으로 관찰되었습니다.

스크롤 시 API에서 추가 요금을 로드하는 데 사용되는 지연 로드 동작입니다. (이 동영상의 고해상도 버전을 보려면 클릭하세요.)

이러한 변경으로 검색 페이지의 INP가 크게 개선되었지만 검색 페이지의 입력란에 있는 change 이벤트가 값비싼 감소기 함수를 호출하여 사용자 인터페이스를 업데이트하는 문제가 여전히 있었습니다. 이로 인해 사용자 인터페이스가 불필요하게 다시 렌더링되어 페이지의 INP에 영향을 미쳤습니다.

사용자가 입력란에 입력하는 동안 콘솔에 보고된 INP 값입니다. 실험실 설정에서 관찰된 결과 INP 값 344는 '개선 필요' 기준점에 속합니다. (이 동영상의 고해상도 버전을 보려면 클릭하세요.)

이 상호작용을 최적화하기 위해 redBus는 입력 구성요소의 상태를 로컬에서 관리하고 입력의 blur 이벤트가 발생했을 때만 Redux 저장소와 동기화했습니다. 이러한 변경으로 인해 재렌더링 수가 감소했으며, 감소기 호출 빈도가 줄어 사용자 인터페이스의 원치 않는 다시 렌더링이 사라졌습니다.

입력란 변경 시 감소기를 덜 자주 호출한 결과 INP가 개선되었습니다. (이 동영상의 고해상도 버전을 보려면 클릭하세요.)

이 변경사항으로 페이지의 INP가 72% 개선되어 사용자가 참여할 가능성이 더 높은 빠르고 원활한 사용자 환경을 제공할 수 있습니다.

비즈니스에 영향

비즈니스 상태와 페이지 성능 간의 관계는 잘 알려져 있습니다. INP는 다른 코어 웹 바이탈에 비해 상대적으로 새로운 측정항목이지만 redBus는 중요한 사용자 중심 성능 측정항목을 개선하는 데 집중하여 더 나은 비즈니스 성과를 확인했습니다. 그 결과 전체 판매가 7% 증가했습니다.

간단히 말해, INP는 redBus 웹사이트에서 런타임 성능 문제를 파악하는 데 도움을 주었습니다. 개선해야 할 점이 있다는 것을 알게 된 후 redBus는 문제를 관찰하고 재현하고 중요한 정보를 사용하여 redBus와 그 비즈니스에 도움이 되는 최적화를 수행할 수 있었습니다.