새로운 INP 측정항목이 JavaScript 프레임워크 및 라이브러리를 사용하여 빌드된 사이트의 경험에 어떤 영향을 미치는지 알아보세요.
Chrome은 최근 Chrome UX 보고서 보고서에 새로운 실험 응답성 측정항목을 도입했습니다. 다음 페인트에 대한 상호작용 (INP)이라고 하는 이 측정항목은 페이지에서의 사용자 상호작용에 대한 전반적인 응답성을 측정합니다. 오늘은 최신 JavaScript 프레임워크를 사용하여 빌드된 웹사이트가 이 측정항목과 관련하여 어떤 위치에 있는지 알아보고자 합니다. INP가 프레임워크와 관련이 있는 이유와 Aurora와 프레임워크가 응답성을 최적화하기 위해 어떻게 작동하는지 설명해 드리고자 합니다.
배경
Chrome은 Core Web Vitals (CWV)의 일부로 최초 입력 지연 (FID)을 사용하여 웹사이트의 로드 응답성을 측정합니다. FID는 첫 번째 사용자 상호작용부터 브라우저가 상호작용에 연결된 이벤트 핸들러를 처리할 수 있는 순간까지의 대기 시간을 측정합니다. 이벤트 핸들러를 처리하거나, 동일한 페이지에서 후속 상호작용을 처리하거나, 이벤트 콜백이 실행된 후 다음 프레임을 페인트하는 시간은 포함되지 않습니다. 그러나 페이지가 로드된 후 사용자가 페이지에서 약 90% 를 소비하기 때문에 응답성은 페이지 수명 주기 전반에서 사용자 환경에 매우 중요합니다.
INP는 사용자가 상호작용을 시작한 시점부터 화면에 다음 프레임이 그려질 때까지 웹페이지가 사용자 상호작용에 응답하는 데 걸리는 시간을 측정합니다. INP를 통해 페이지 수명 주기에서 모든 상호작용의 인지된 지연 시간을 종합적으로 측정할 수 있기를 바랍니다. INP가 보다 정확한 웹페이지 추정치를 제공하리라 생각합니다. 로드 및 런타임 응답성을 제공합니다.
FID는 첫 번째 상호작용의 입력 지연만 측정하기 때문에 웹 개발자는 CWV 개선 프로세스의 일부로 후속 상호작용을 사전에 최적화하지 않았을 가능성이 높습니다. 따라서 사이트, 특히 상호작용성이 높은 사이트의 경우 이 측정항목을 효과적으로 향상시키기 위해 노력해야 합니다.
프레임워크의 역할
많은 웹사이트에서 상호작용을 제공하기 위해 JavaScript를 사용하므로 INP 점수는 주로 기본 스레드에서 처리되는 JavaScript의 양에 의해 영향을 받습니다. JavaScript 프레임워크는 최신 프런트엔드 웹 개발의 핵심으로, 개발자에게 JavaScript 코드의 라우팅, 이벤트 처리, 구획화를 위한 유용한 추상화를 제공합니다. 따라서 API를 사용하는 웹사이트의 응답성과 사용자 경험을 최적화하는 데 핵심적인 역할을 합니다.
프레임워크는 웹사이트의 FID를 더 일찍 개선하여 응답성을 개선하기 위한 조치를 취했을 수 있습니다. 그러나 이제는 사용 가능한 대응성 측정항목 데이터를 분석하고 식별된 격차를 해결하기 위해 노력해야 합니다. 일반적으로 INP는 통과율이 낮은 경향이 있으며 측정 프로세스의 차이로 인해 추가적인 코드 최적화가 필요합니다. 다음 표에 그 이유가 요약되어 있습니다.
Chrome의 Aurora팀은 오픈소스 웹 프레임워크를 활용하여 개발자가 성능 및 CWV 측정항목을 비롯한 사용자 환경의 다양한 측면을 개선할 수 있도록 지원합니다. INP의 도입으로 Google은 프레임워크 기반 웹사이트에 대한 CWV 측정항목의 변화에 대비하고자 합니다. 저희는 CrUX 보고서의 실험적 반응성 측정항목에 근거하여 데이터를 수집했습니다. Google은 프레임워크 기반 웹사이트를 INP 측정항목으로 손쉽게 전환할 수 있도록 유용한 정보와 작업 항목을 공유할 예정입니다.
실험 반응성 측정항목 데이터
INP가 200밀리초 미만이면 응답성이 우수함을 나타냅니다. 2023년 6월의 CrUX 보고서 데이터 및 CWV 기술 보고서에는 인기 JavaScript 프레임워크의 응답성에 관한 다음과 같은 정보가 나와 있습니다.
표에는 각 프레임워크의 응답성 점수가 좋은 출처의 비율이 표시됩니다. 수치는 고무적이지만 개선의 여지가 많습니다.
JavaScript는 INP에 어떤 영향을 주나요?
현장의 INP 값은 실험실에서 관찰된 총 차단 시간 (TBT)과 상관관계가 있습니다. 이는 메인 스레드를 오랫동안 차단하는 스크립트는 INP에 좋지 않음을 의미할 수 있습니다. 상호작용 후 과도한 JavaScript를 실행하면 기본 스레드가 장시간 차단되고 해당 상호작용에 대한 응답이 지연될 수 있습니다. 스크립트 차단이 발생하는 일반적인 원인은 다음과 같습니다.
최적화되지 않은 JavaScript: 중복 코드나 잘못된 코드 분할 및 로드 전략으로 인해 JavaScript가 팽창되고 오랫동안 기본 스레드가 차단될 수 있습니다. 코드 분할, 점진적 로드, 장기 작업 분할을 통해 응답 시간을 크게 개선할 수 있습니다.
서드 파티 스크립트: 때로는 상호작용 (예: 광고 스크립트)을 처리하는 데 필요하지 않은 서드 파티 스크립트를 사용하면 기본 스레드를 차단하고 불필요한 지연이 발생할 수 있습니다. 필수 스크립트에 우선순위를 두면 서드 파티 스크립트의 부정적인 영향을 줄이는 데 도움이 될 수 있습니다.
여러 이벤트 핸들러: 모든 상호작용과 연결된 여러 개의 이벤트 핸들러는 각각 다른 스크립트를 실행하면 서로 간섭하여 긴 지연을 초래할 수 있습니다. 이러한 작업 중 일부는 필수적이지 않을 수 있으며 웹 작업자에서 또는 브라우저가 유휴 상태일 때 예약할 수 있습니다.
이벤트 처리의 프레임워크 오버헤드: 프레임워크에 이벤트 처리를 위한 추가 기능/구문이 있을 수 있습니다. 예를 들어 Vue는 v-on을 사용해 이벤트 리스너를 요소에 연결하는 반면 Angular는 사용자 이벤트 핸들러를 래핑합니다. 이러한 기능을 구현하려면 바닐라 JavaScript보다 높은 추가 프레임워크 코드가 필요합니다.
하이드레이션: JavaScript 프레임워크를 사용할 때 서버에서 페이지의 초기 HTML을 생성한 다음 이벤트 핸들러 및 애플리케이션 상태를 사용하여 보강해야 웹브라우저에서 상호작용할 수 있습니다. 이 과정을 수화라고 합니다. JavaScript를 로드하고 하이드레이션하는 데 걸리는 시간에 따라 로드 중에 과도한 프로세스가 발생할 수 있습니다. 또한 페이지가 실제 사용 중이 아닐 때도 양방향으로 작동하는 것처럼 보이게 할 수 있습니다. 수화는 페이지 로드 중에 또는 느리게 (예: 사용자 상호작용 시) 자동으로 발생하는 경우가 많으며 작업 예약으로 인해 INP 또는 처리 시간에 영향을 미칠 수 있습니다. React와 같은 라이브러리에서는
useTransition를 활용하여 구성요소 렌더링의 일부가 다음 프레임에 있고 더 많은 비용이 드는 부작용이 향후 프레임에 발생하도록 할 수 있습니다. 따라서 전환 과정에서 클릭과 같이 더 긴급한 업데이트로 이어지는 업데이트는 INP에 좋은 패턴이 될 수 있습니다.미리 가져오기: 후속 탐색에 필요한 리소스를 적극적으로 미리 가져오면 성능이 향상됩니다. 그러나 SPA 경로를 동기적으로 미리 가져오고 렌더링하는 경우, 비용이 많이 드는 모든 렌더링 시도가 단일 프레임에서 완료되기 때문에 INP에 부정적인 영향을 미칠 수 있습니다. 경로를 미리 가져오지 않고 대신 필요한 작업 (예:
fetch())을 시작하고 페인트 차단을 해제하는 것과 비교해 보세요. 프레임워크의 미리 가져오기 접근 방식이 최적의 UX를 제공하는지, 이것이 INP에 어떤 영향을 미칠 수 있는지 다시 검토해 보는 것이 좋습니다.
지금부터 좋은 INP 점수를 얻으려면 개발자는 페이지의 모든 상호작용 후에 실행되는 코드를 검토하고 퍼스트 파티 및 서드 파티 스크립트의 청킹, 리하이드레이션, 로드 전략, 각 RenderScript 업데이트 크기를 최적화하는 데 집중해야 합니다.
Aurora와 프레임워크에서 INP 문제를 어떻게 해결하나요?
Aurora는 권장사항을 통합하여 일반적인 문제에 대한 기본 솔루션을 제공하는 방식으로 프레임워크와 연동합니다. Google에서는 Next.js, Nuxt.js, Gatsby, Angular와 협력하여 성능 최적화를 위해 프레임워크 내에서 강력한 기본값을 제공하는 솔루션을 개발했습니다. 이러한 맥락에서 저희가 수행한 작업의 주요 내용은 다음과 같습니다.
React 및 Next.js: Next.js 스크립트 구성요소는 서드 파티 스크립트를 비효율적으로 로드하여 발생한 문제를 해결하는 데 도움이 됩니다. 공유 코드를 위해 더 작은 크기의 청크를 사용할 수 있도록 Next.js에서 세분화된 청크 처리가 도입되었습니다. 이렇게 하면 모든 페이지에서 다운로드되는 사용되지 않는 공통 코드의 양을 줄일 수 있습니다. 또한 Google은 Next.js와 협력하여 INP 데이터를 Analytics 서비스의 일부로 제공하기 위해 노력하고 있습니다.
Angular: Aurora는 Angular팀과 협력하여 서버 측 렌더링 및 수화 기능 개선을 모색하고 있습니다. 또한 INP를 개선하기 위해 이벤트 처리 및 변경 감지를 개선할 계획입니다.
Vue 및 Nuxt.js: Google에서는 주로 스크립트 로드 및 렌더링과 관련하여 공동작업을 위한 방법을 모색하고 있습니다.
프레임워크에서는 INP 개선을 어떻게 생각하고 있나요?
React 및 Next.js
startTransition 및 Suspense를 통해 구현되는 React.js 타임 슬라이싱을 사용하면 선택적 또는 점진적인 수분 섭취를 선택할 수 있습니다. 즉, 수화는 동기식 블록이 아닙니다. 언제든지 중단할 수 있는 작은 슬라이스로 실행됩니다.
이를 통해 INP를 개선하고 키 입력, 전환 중 마우스 오버 효과, 클릭에 더 빠르게 대응할 수 있습니다. 또한 자동 완성과 같은 대규모 전환 시에도 React 앱의 응답성을 유지하는 데 도움이 됩니다.
Next.js는 경로 전환에 기본적으로 startTransition를 사용하는 새 라우팅 프레임워크를 구현했습니다. 이를 통해 Next.js 사이트 소유자는 React 시간 분할을 채택하고 경로 전환의 응답성을 개선할 수 있습니다.
Angular
Angular팀은 INP에 도움이 될 다음과 같은 몇 가지 아이디어를 검토 중입니다.
- 영역 없음: 초기 번들 크기와 앱이 렌더링하기 전에 로드해야 하는 필수 코드를 줄입니다.
- 수분 섭취: 상호작용을 위해 절전 모드가 해제되어야 하는 앱의 양을 제한하는 섬 스타일의 수분 공급입니다.
- CD의 오버헤드 감소: 예를 들어 변경 감지 비용을 낮추고, 앱을 적게 확인할 방법을 찾고, 변경사항에 관한 사후 대응 신호를 활용합니다.
- 보다 세분화된 코드 분할: 초기 번들을 더 작게 만듭니다.
- 로드 표시기 지원 개선: 예를 들어 SSR 재렌더링 중, 경로 탐색 중, 지연 로드 작업 중이 이에 해당합니다.
- 프로파일링 도구: 특히 특정 상호작용에 대한 변경 감지 비용에 관한 상호작용 비용을 파악할 수 있도록 개발 도구가 개선되었습니다.
이러한 개선사항을 통해 응답성과 사용자 경험을 저하시키는 다양한 문제를 해결하고 프레임워크 기반 웹사이트에 대한 CWV 측정항목과 새로운 INP 측정항목을 강화할 수 있습니다.
결론
INP 점수를 통해 향후 웹사이트 응답성과 실적을 개선할 수 있는 더 나은 나침반이 될 것으로 예상됩니다. 2023년에는 기존 INP 가이드를 기반으로 프레임워크 개발자에게 보다 실용적인 팁을 제공할 예정입니다. 이를 위해 다음과 같은 노력을 기울이고 있습니다.
- 프레임워크 및 웹 개발자가 INP의 현장 데이터에 쉽게 액세스할 수 있도록 채널을 만듭니다.
- 프레임워크를 사용하여 INP를 기본적으로 개선하는 기능을 빌드하세요.
프레임워크 사용자의 INP 최적화 여정을 시작할 때 의견을 보내주시기 바랍니다.