TBT를 30배 줄이고 Next.js로 이전한 결과, The Ecomonic Times는 INP를 거의 4배 줄여 이탈률은 50% 감소하고 페이지뷰는 43% 높일 수 있었습니다.
다음 페인트에 대한 상호작용 (INP)은 사용자 입력에 대한 웹사이트의 응답성을 평가하는 측정항목입니다. 우수한 응답성은 페이지가 사용자 상호작용에 빠르게 반응한다는 의미입니다. 페이지의 INP가 낮을수록 사용자 상호작용에 더 잘 대응할 수 있습니다.
모호한 시작
Google이 Core Web Vitals 측정항목 중 하나로 발전할 가능성이 있는 실험용 측정항목으로 INP를 처음 도입했을 때, Economic Times팀은 세계적 수준의 사용자 경험을 제공하는 것이 핵심 비즈니스 가치에 매우 중요하므로 이 측정항목을 개선하기 전에 문제를 해결해야 했습니다.
INP는 지금까지 해결하기 가장 어려운 측정항목 중 하나였습니다. 처음에는 INP를 효과적으로 측정하는 방법이 명확하지 않았습니다. 가장 어려운 점은 아직 커뮤니티를 지원하지 않는 대다수 Real User Monitoring (RUM) 제공업체를 포함한 커뮤니티 지원이 부족하다는 점이었습니다. 하지만 Chrome 사용자 환경 보고서 (CrUX), web-vitals JavaScript 라이브러리 등 Google RUM 도구들이 이를 지원하는 Google RUM 도구를 통해 앞으로 나아갈 방향을 평가하는 동안 Google이 어떤 위치에 있는지 파악할 수 있었습니다. 시작했을 때 INP는 원본 수준에서 1,000밀리초에 가까웠습니다.
필드에서 INP를 수정하는 과정에서 발견한 한 가지는 타겟팅할 실습 측정항목 중 하나가 총 차단 시간 (TBT)일 수 있다는 점입니다. TBT는 이미 충분히 문서화되어 있으며 커뮤니티의 지원을 받고 있습니다. 이미 코어 웹 바이탈 기준점을 충족했지만 시작했을 때는 3초가 넘었기 때문에 TBT 측면에서는 성과가 좋지 않았습니다.
TBT란 무엇이며 이를 개선하기 위해 어떤 조치를 취했나요?
TBT는 페이지 로드 중 사용자 입력에 대한 웹페이지의 반응성을 측정하는 실험실 측정항목입니다. 실행하는 데 50밀리초 넘게 걸리는 모든 작업은 긴 작업으로 간주되며 50밀리초 기준 이후의 시간을 차단 시간이라고 합니다.
TBT는 페이지 로드 중 모든 긴 작업의 차단 시간의 합계를 사용하여 계산됩니다. 예를 들어 로드 중에 2개의 장기 작업이 있는 경우 차단 시간은 다음과 같이 결정됩니다.
- 작업 A에 80밀리초가 소요됨 (50밀리초보다 30밀리초가 소요됨)
- 작업 B에 100밀리초가 소요됩니다 (50밀리초보다 50밀리초가 걸림).
페이지의 TBT는 80밀리초 (30 + 50)입니다. TBT가 낮을수록 좋습니다. 또한 TBT는 INP와도 상관관계가 있습니다.
다음은 TBT 개선을 위한 조치를 취하기 전과 후의 TBT를 실습한 것입니다.
기본 스레드 작업 최소화
브라우저의 기본 스레드는 HTML 파싱, DOM 빌드, CSS 파싱, 스타일 적용, 자바스크립트 평가 및 실행에 이르기까지 모든 작업을 처리합니다. 기본 스레드는 클릭, 탭, 키 누름과 같은 사용자 상호작용도 처리합니다. 기본 스레드가 다른 작업을 실행 중인 경우 사용자 입력에 효율적으로 응답하지 못할 수 있으며 이로 인해 사용자 환경이 저하될 수 있습니다.
이는 저희에게 가장 어려운 작업이었습니다. A/B 테스트, 분석 등을 위한 서드 파티 스크립트와 구독 상태를 기반으로 광고를 게재하기 위한 사용자 신원을 감지하는 자체 알고리즘이 있기 때문입니다.
처음에는 중요도가 낮은 비즈니스 자산의 로드 우선순위를 낮추는 등의 작은 조치를 취했습니다. 둘째, 중요하지 않은 작업에 requestIdleCallback를 사용했으므로 TBT를 줄이는 데 도움이 될 수 있습니다.
if ('requestIdleCallback' in window) {
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}
requestIdleCallback를 사용할 때는 제한 시간을 지정하는 것이 좋습니다. 지정된 시간이 경과하고 콜백이 아직 호출되지 않은 경우 제한 시간 직후에 콜백을 실행하기 때문입니다.
스크립트 평가 시간 최소화
로드 가능한 구성요소를 사용하여 서드 파티 라이브러리를 지연 로드하기도 합니다. 또한 Chrome DevTools의 커버리지 도구로 페이지를 프로파일링하여 사용되지 않는 자바스크립트 및 CSS를 삭제했습니다. 이를 통해 페이지 로드 중에 더 적은 코드를 전송하는 데 트리 쉐이킹이 필요한 영역을 파악하여 애플리케이션의 초기 번들 크기를 줄일 수 있었습니다.
DOM 크기 줄이기
Lighthouse에 따르면 DOM 크기가 클수록 메모리 사용량이 늘어나고, 스타일 재계산이 길어지고, 비용이 많이 드는 레이아웃 리플로우가 발생합니다.
우리는 두 가지 방법으로 DOM 노드의 수를 줄였습니다.
- 먼저 사용자의 요청에 따라 메뉴 항목을 렌더링했습니다 (클릭 시). DOM 크기를 약 1,200개 줄였습니다.
- 둘째, 덜 중요한 위젯을 지연 로드했습니다.
이러한 모든 노력 덕분에 TBT를 크게 줄였으며 이에 따라 INP도 거의 50% 감소했습니다.
이 시점에서는 TBT (및 프록시별 INP)를 더욱 줄이기 위한 간단한 방법을 거의 다 써버렸지만, 개선의 여지가 많이 있다는 것을 알고 있었습니다. 이때, 구성요소를 불필요하게 다시 렌더링하는 것을 방지하기 위해 후크를 더 잘 사용하기 위해 맞춤 빌드된 UI 상용구를 Next.js와 함께 최신 버전의 React로 업그레이드하기로 했습니다.
웹사이트의 다른 부분에 비해 업데이트 빈도가 더 높고 트래픽이 상대적으로 적어 Google은 주제 페이지를 Next.js로 이전하기 시작했습니다. 또한 PartyTown을 사용하여 중요하지 않은 작업을 지연시키는 requestIdleCallBack와 같은 기술과 함께 과도한 추가 기본 스레드 작업을 웹 작업자에게 오프로드했습니다.
INP 개선이 The Economic Times에 어떤 도움이 되었나요?
출처의 현재 TBT 및 INP
이 게시물을 게시했을 당시 원본의 TBT는 120밀리초로 최적화 작업을 시작한 시점의 3,260밀리초에서 줄었습니다. 마찬가지로 오리진의 INP는 최적화 작업 후 257밀리초로 1,000밀리초가 넘게 줄었습니다.
INP CrUX 추세
주제 페이지에서 발생한 트래픽은 전체 트래픽에서 차지하는 비중이 현저히 적습니다. 따라서 이곳은 실험을 진행하기에 이상적인 장소였습니다. CrUX 결과와 비즈니스 성과는 매우 고무적이었으며, 전체 웹사이트 전반에서 노력을 확장하여 더 많은 이점을 얻을 수 있었습니다.
Akamai mPulse TBT 분석
당사는 현장의 TBT를 측정하는 RUM 솔루션으로 Akamai mPulse를 사용합니다. TBT의 지속적인 감소는 INP를 줄이기 위한 당사의 노력의 결과를 명확하게 보여줍니다. 아래 스크린샷에서 볼 수 있듯이 TBT 값은 결국 필드에서 약 5초에서 약 200밀리초로 떨어졌습니다.
비즈니스 결과
전반적으로 TBT를 30배 낮추고 Next.js로 이전하면서 INP를 거의 4배 줄인 결과 주제 페이지의 이탈률은 50% 감소하고 페이지 조회수가 43% 증가했습니다.
결론
요약하자면, INP는 Economic Times 웹사이트 일부에서 런타임 성능 문제를 확인하는 데 광범위하게 도움을 주었습니다. 비즈니스 성과에 긍정적인 영향을 미치는 가장 효과적인 측정항목 중 하나로 입증되었습니다. 이러한 노력의 결과로 얻은 매우 고무적인 수치에 힘입어 웹사이트 내의 다른 영역으로도 최적화 활동을 확대하고 더 많은 이익을 얻고자 합니다.