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