새로운 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 코드의 라우팅, 이벤트 처리, 구분을 위한 중요한 추상화를 제공합니다. 따라서 이를 사용하는 웹사이트의 반응성과 사용자 환경을 최적화하는 데 중요한 역할을 합니다.
프레임워크는 이전에 웹사이트의 FID를 개선하여 응답성을 개선하기 위한 조치를 취했을 수 있습니다. 하지만 이제는 사용 가능한 응답성 측정항목 데이터를 분석하고 확인된 공백을 해결하기 위해 노력해야 합니다. 일반적으로 INP의 통과율은 낮은 경향이 있으며 측정 프로세스의 차이로 인해 추가 코드 최적화가 필요합니다. 다음 표에는 그 이유가 요약되어 있습니다.
Chrome의 Aurora팀은 오픈소스 웹 프레임워크를 사용하여 개발자가 성능 및 CWV 측정항목을 비롯한 다양한 사용자 환경 측면을 개선할 수 있도록 지원합니다. INP 도입과 함께 프레임워크 기반 웹사이트의 CWV 측정항목 변경에 대비하고자 합니다. CrUX 보고서의 실험적 응답성 측정항목을 기반으로 데이터를 수집했습니다. 프레임워크 기반 웹사이트의 INP 측정항목으로 원활하게 전환할 수 있도록 유용한 정보와 조치를 공유합니다.
실험용 응답성 측정항목 데이터
INP가 200밀리초 이하이면 응답성이 우수함을 나타냅니다. CrUX 보고서 데이터와 2023년 6월의 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 점수를 얻기 위해 페이지에서의 모든 상호작용 후에 실행되는 코드를 검토하고 퍼스트 파티 및 서드 파티 스크립트의 청크 처리, 재수화, 로드 전략, 각 render() 업데이트 크기를 최적화하는 데 집중해야 합니다.
Aurora와 프레임워크는 INP 문제를 어떻게 해결하나요?
Aurora는 권장사항을 통합하여 프레임워크와 함께 작동하여 일반적인 문제에 사전 빌드된 솔루션을 제공합니다. Google은 Next.js, Nuxt.js, Gatsby, Angular와 협력하여 성능을 최적화하기 위해 프레임워크 내에서 강력한 기본값을 제공하는 솔루션을 개발했습니다. 다음은 이 맥락에서 Google이 수행한 작업의 주요 내용입니다.
React 및 Next.js: Next.js 스크립트 구성요소는 서드 파티 스크립트의 비효율적인 로드로 인해 발생하는 문제를 해결하는 데 도움이 됩니다. 공유 코드의 크기가 더 작은 청크를 허용하기 위해 Next.js에 세분화된 청크 처리가 도입되었습니다. 이렇게 하면 모든 페이지에서 다운로드되는 사용되지 않는 공통 코드의 양을 줄일 수 있습니다. 또한 Google은 Next.js와 협력하여 INP 데이터를 애널리틱스 서비스의 일부로 제공할 수 있도록 하고 있습니다.
Angular: Aurora는 서버 측 렌더링 및 하이드라이션 개선을 모색하기 위해 Angular팀과 협력하고 있습니다. 또한 INP를 개선하기 위해 이벤트 처리 및 변경 감지 기능을 개선할 계획입니다.
Vue 및 Nuxt.js: 주로 스크립트 로드 및 렌더링과 관련된 공동작업 방안을 모색하고 있습니다.
프레임워크는 INP 개선을 어떻게 생각하고 있나요?
React 및 Next.js
startTransition
및 Suspense
를 통해 구현된 React.js 시간 슬라이싱을 사용하면 선택적 또는 점진적 하이드라이션을 선택할 수 있습니다. 즉, 하이드라이션은 동기식 블록이 아닙니다. 언제든지 중단할 수 있는 작은 슬라이스로 실행됩니다.
이렇게 하면 INP가 개선되고 전환 중 키 입력, 마우스 오버 효과, 클릭에 더 빠르게 반응할 수 있습니다. 또한 자동 완성과 같은 대규모 전환에서도 React 앱의 반응성을 유지하는 데 도움이 됩니다.
Next.js는 경로 전환에 기본적으로 startTransition
를 사용하는 새로운 라우팅 프레임워크를 구현했습니다. 이를 통해 Next.js 사이트 소유자는 React 시간 슬라이스를 채택하고 경로 전환의 응답성을 개선할 수 있습니다.
Angular
Angular팀은 INP에도 도움이 될 수 있는 몇 가지 아이디어를 모색하고 있습니다.
- Zoneless: 초기 번들 크기와 앱에서 렌더링하기 전에 로드해야 하는 필수 코드를 줄입니다.
- 수분 공급: 상호작용을 위해 깨워야 하는 앱의 양을 제한하는 섬 스타일의 수분 공급
- CD 오버헤드 줄이기: 예를 들어 변경 감지를 더 저렴하게 만들고, 앱을 더 적게 확인하는 방법을 찾고, 변경된 사항에 관한 반응형 신호를 활용합니다.
- 더 세분화된 코드 분할: 초기 번들을 더 작게 만듭니다.
- 로드 표시기 지원 개선: SSR 재렌더링 중, 경로 탐색 중, 지연 로드 작업 중 등
- 프로파일링 도구: 상호작용 비용을 파악하는 데 도움이 되는 향상된 개발자 도구로, 특히 특정 상호작용의 변경 감지 비용에 관한 도구입니다.
이러한 개선사항을 통해 반응성과 사용자 환경이 저하되는 다양한 문제를 해결하고 프레임워크 기반 웹사이트의 CWV 측정항목과 새로운 INP 측정항목을 개선할 수 있습니다.
결론
INP 점수는 향후 웹사이트가 응답성과 성능을 개선하는 데 더 나은 나침반이 될 것으로 기대됩니다. 2023년에는 기존 INP 가이드를 기반으로 프레임워크 개발자를 위한 더 실용적인 도움말을 제공할 예정입니다. 이를 위해 다음과 같은 조치를 취할 예정입니다.
- 프레임워크 및 웹 개발자를 위해 INP의 필드 데이터에 쉽게 액세스할 수 있는 채널을 만듭니다.
- 프레임워크를 사용하여 기본적으로 INP를 개선하는 기능을 빌드합니다.
프레임워크 사용자가 INP 최적화 여정을 시작할 때 보내 주시는 의견을 기다립니다.