TBT를 30배 줄이고 Next.js로 이전한 결과 The Ecomonic Times가 INP를 거의 4배 줄여 이탈률이 50% 감소하고 페이지 조회가 43% 증가하는 성과를 얻었습니다.
다음 페인트에 대한 상호작용 (INP)은 사용자 입력에 대한 웹사이트의 응답성을 평가하는 측정항목입니다. 응답성이 좋다는 것은 페이지가 사용자 상호작용에 빠르게 반응한다는 의미입니다. 페이지의 INP가 낮을수록 사용자 상호작용에 더 잘 반응합니다.
퍼지 시작점
Google에서 INP를 Core Web Vitals 측정항목 중 하나로 발전시킬 수 있는 실험용 측정항목으로 처음 도입했을 때 Economic Times팀은 세계적 수준의 사용자 경험을 제공하는 것이 Google의 핵심 비즈니스 가치에 중요하기 때문에 INP를 수정하기 전에 문제를 해결했습니다.
INP는 지금까지 해결하기 가장 어려운 측정항목 중 하나였습니다. 처음에는 INP를 효과적으로 측정하는 방법이 명확하지 않았습니다. 대부분의 실시간 사용자 모니터링 (RUM) 제공업체가 아직 지원하지 않고 있는 등 커뮤니티 지원이 부족하기 때문에 문제가 더욱 어려웠습니다. 하지만 Chrome 사용자 환경 보고서 (CrUX), web-vitals JavaScript 라이브러리 등 이를 지원하는 Google RUM 도구가 있었기 때문에 앞으로의 경로를 평가하는 동안 Google이 어떤 상황에 처해 있는지 파악할 수 있었습니다. 시작 당시 INP는 원본 수준에서 1,000밀리초에 가까웠습니다.
현장에서 INP를 수정하는 과정에서 나타난 한 가지는 타겟팅할 실습 측정항목 중 하나가 총 차단 시간 (TBT)일 수 있다는 것이었습니다. TBT는 이미 커뮤니티에서 잘 문서화되고 지원되고 있습니다. 이미 Core Web Vitals 기준을 충족했음에도 불구하고 시작했을 때 시간이 3초가 넘었기 때문에 TBT 측면에서는 좋은 성과를 얻지 못했습니다.
TBT란 무엇이며 이를 개선하기 위해 어떤 조치를 취했습니까?
TBT는 페이지 로드 중에 사용자 입력에 대한 웹페이지의 반응성을 측정하는 실습 측정항목입니다. 실행하는 데 50밀리초 이상 걸리는 작업은 장기 작업으로 간주되며, 50밀리초 임계값 이후의 시간을 차단 시간이라고 합니다.
TBT는 페이지 로드 중에 모든 장기 작업의 차단 시간을 합하여 계산됩니다. 예를 들어, 로드하는 동안 두 개의 장기 작업이 있는 경우 차단 시간은 다음과 같이 결정됩니다.
- 작업 A는 80밀리초가 걸립니다 (50밀리초보다 30밀리초가 많음).
- 작업 B가 100밀리초가 걸립니다 (50밀리초보다 50밀리초 초과).
페이지의 TBT는 80밀리초 (30 + 50)입니다. TBT는 낮을수록 좋으며 TBT는 INP와도 잘 연관이 있습니다.
다음은 TBT를 개선하기 위한 조치를 취하기 전과 후의 실습 TBT를 간단히 비교한 것입니다.
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">기본 스레드 작업 최소화
브라우저의 기본 스레드는 HTML 파싱, DOM 빌드, CSS 파싱 및 스타일 적용, JavaScript 평가 및 실행 등 모든 작업을 처리합니다. 기본 스레드는 클릭, 탭, 키 누름과 같은 사용자 상호작용도 처리합니다. 기본 스레드가 다른 작업을 하고 있으면 사용자 입력에 효율적으로 응답하지 못할 수 있으며 이로 인해 사용자 환경이 저하될 수 있습니다.
A/B 테스트, 분석 등을 위해 구독 상태와 서드 파티 스크립트를 기반으로 광고를 게재할 때 사용자 ID를 감지하는 자체 알고리즘을 갖추고 있었기 때문에 이 작업이 가장 어려웠습니다.
저희는 처음에는 덜 중요한 비즈니스 자산의 로딩 우선순위를 낮추는 것과 같은 작은 조치를 취했습니다. 둘째, 중요하지 않은 작업에 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의 적용 범위 도구로 페이지를 프로파일링하여 사용하지 않는 JavaScript 및 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는 최적화 노력을 시작했을 당시의 3,260밀리초에서 120밀리초로 단축되었습니다. 마찬가지로 Google의 원본에 대한 INP는 최적화 작업 후 1,000밀리초에서 257밀리초로 단축되었습니다.
INP CrUX 추세
주제 페이지에서 발생한 트래픽은 전체 트래픽 중 훨씬 적은 부분을 차지합니다. 실험하기에 이상적인 장소였습니다. 비즈니스 성과와 함께 CrUX 결과는 매우 고무적이었고, 더 많은 이익을 얻기 위해 웹사이트 전체로 노력을 확대하는 계기가 되었습니다.
Akamai mPulse TBT 분석
현장에서 TBT를 측정하는 RUM 솔루션으로 Akamai mPulse를 사용합니다. TBT가 지속적으로 감소했으며 이는 INP를 줄이기 위한 노력의 결과와도 일치합니다. 아래 스크린샷에서 볼 수 있듯이, TBT 값은 결국 필드에 약 5초에서 약 200밀리초로 감소했습니다.
비즈니스 성과
전반적으로 Next.js로 이전하면서 TBT를 30배 낮추기 위해 노력한 결과 INP가 거의 4배 감소했으며, 결과적으로 주제 페이지의 이탈률이 50% 감소하고 페이지 조회수가 43% 증가하는 결과로 이어졌습니다.
결론
요약하자면 INP는 Economic Times 웹사이트의 런타임 성능 문제를 확인하는 데 광범위하게 도움을 주었습니다. 이는 비즈니스 성과에 긍정적인 영향을 미치는 가장 효과적인 측정항목 중 하나로 입증되었습니다. 이러한 노력의 결과로 매우 고무적인 수치가 확인되었기 때문에 최적화 노력을 웹사이트의 다른 영역으로 확대하고 추가 혜택을 얻고자 합니다.