다음 페인트에 대한 상호작용 최적화

다음 페인트에 대한 웹사이트의 상호작용을 최적화하는 방법을 알아봅니다.

Jeremy Wagner
Philip Walton

다음 페인트에 대한 상호작용 (INP)은 사용자가 페이지를 방문하는 전체 기간에 발생하는 모든 적격한 상호작용의 지연 시간을 관찰하여 사용자 상호작용에 대한 페이지의 전반적인 응답성을 평가하는 안정적인 Core Web Vitals 측정항목입니다. 최종 INP 값은 관찰된 가장 긴 상호작용이며 이상점을 무시하는 경우도 있습니다.

우수한 사용자 환경을 제공하기 위해 웹사이트에서는 다음 페인트에 대한 상호작용이 200밀리초 이하로 발생하도록 노력해야 합니다. 사용자 대부분이 이 목표를 달성할 수 있도록 하려면 모바일과 데스크톱 기기로 분류되는 페이지 로드의 75번째 백분위수를 측정하는 것이 좋습니다.

양호한 INP 값은 200밀리초 이하이고, 낮은 값은 500밀리초를 초과하며, 그 사이의 모든 값은 개선이 필요합니다.

웹사이트에 따라 주로 텍스트로 이루어진 페이지와 상호작용 요소가 거의 없는 이미지와 같이 상호작용이 거의 또는 전혀 없을 수 있습니다. 또는 텍스트 편집기나 게임과 같은 웹사이트의 경우 수백, 심지어 수천 회의 상호작용이 발생할 수도 있습니다. 두 경우 모두 INP가 높으면 사용자 경험이 저하될 수 있습니다.

INP를 개선하는 데는 시간과 노력이 필요하지만 보상은 더 나은 사용자 경험을 제공하는 것입니다. 이 가이드에서는 INP를 개선하는 방법을 알아봅니다.

낮은 INP의 원인 파악

느린 상호작용을 해결하려면 먼저 웹사이트의 INP가 낮은지 또는 개선이 필요한지 알려주는 데이터가 필요합니다. 이 정보를 확보하면 실습으로 이동하여 느린 상호작용을 진단하고 해결책을 찾을 수 있습니다.

현장에서 느린 상호작용 찾기

INP 최적화 여정은 필드 데이터에서 시작하는 것이 가장 좋습니다. 가능한 한 RUM (Real User Monitoring) 제공업체의 필드 데이터는 페이지의 INP 값뿐만 아니라 INP 값 자체에 기여한 특정 상호작용, 페이지 로드 중 또는 페이지 로드 이후에 상호작용이 발생했는지 여부, 상호작용 유형 (클릭, 키 누름 또는 탭) 및 기타 중요한 정보를 강조하는 문맥 데이터도 제공합니다.

필드 데이터를 가져오는 데 RUM 제공업체에 의존하지 않는 경우 INP 필드 데이터 가이드에서 PageSpeed Insights를 통해 Chrome 사용자 환경 보고서 (CrUX)를 사용하여 공백을 메울 수 있다고 안내합니다. CrUX는 Core Web Vitals 프로그램의 공식 데이터 세트로 INP를 비롯한 수백만 개의 웹사이트에 대한 측정항목을 개괄적으로 요약합니다. 그러나 문제 분석에 도움이 되도록 RUM 제공자로부터 얻을 수 있는 상황별 데이터를 CrUX에서 제공하지 않는 경우가 많습니다. 따라서 가능한 경우 사이트에서는 RUM 제공업체를 사용하거나 자체 RUM 솔루션을 구현하여 CrUX에서 제공되는 기능을 보완하는 것이 좋습니다.

실습에서 느린 상호작용 진단하기

상호작용이 느리다는 것을 나타내는 필드 데이터가 있는 경우 실험실에서 테스트를 시작하는 것이 가장 좋습니다. 필드 데이터가 없는 경우 실습에서 느린 상호작용을 식별하기 위한 몇 가지 전략이 있습니다. 이러한 전략에는 사용자 환경의 중요한 부분에서 느린 상호작용을 표시하기 위해 일반적인 사용자 플로우를 따르고 그 과정에서 상호작용을 테스트하거나 로드하는 동안(기본 스레드가 가장 많을 때) 페이지와 상호작용하는 것이 포함됩니다.

상호작용 최적화

느린 상호작용을 식별하고 실습에서 수동으로 재현할 수 있음을 확인한 후 다음 단계는 이를 최적화하는 것입니다. 상호작용은 세 단계로 나눌 수 있습니다.

  1. 입력 지연: 사용자가 페이지와 상호작용을 시작할 때 시작되고 상호작용의 이벤트 콜백이 실행되기 시작할 때 종료됩니다.
  2. 처리 기간: 이벤트 콜백이 완료될 때까지 실행되는 데 걸리는 시간으로 구성됩니다.
  3. 프레젠테이션 지연: 브라우저에서 상호작용의 시각적 결과가 포함된 다음 프레임을 표시하는 데 걸리는 시간입니다.

이 세 단계의 합계가 총 상호작용 지연 시간입니다. 상호작용의 모든 단일 단계는 전체 상호작용 지연 시간에 어느 정도 시간이 걸리므로, 상호작용이 가능한 한 짧은 시간 동안 실행되도록 상호작용의 각 부분을 최적화하는 방법을 아는 것이 중요합니다.

입력 지연 식별 및 줄이기

사용자가 페이지와 상호작용할 때 해당 상호작용의 첫 번째 부분은 입력 지연입니다. 페이지의 다른 활동에 따라 입력으로 인한 지연이 상당히 길어질 수 있습니다. 이는 기본 스레드에서 발생하는 활동 (예: 스크립트 로드, 파싱, 컴파일), 가져오기 처리, 타이머 함수 또는 빠르게 연속해서 서로 겹치는 다른 상호작용으로 인해 발생할 수 있습니다.

상호작용의 입력 지연 원인이 무엇이든, 상호작용이 가능한 한 빨리 이벤트 콜백을 실행할 수 있도록 입력 지연을 최소한으로 줄이는 것이 좋습니다.

스크립트 평가와 시작 중 장기 작업의 관계

페이지 수명 주기에서 상호작용의 중요한 측면은 시작 시입니다. 페이지가 로드되면 처음에는 렌더링되지만, 페이지가 렌더링되었다고 해서 페이지의 로드가 완료된 것은 아닙니다. 페이지가 제대로 기능하기 위해 필요한 리소스의 양에 따라, 로드 중에 사용자가 페이지와 상호작용을 시도할 수 있습니다.

페이지가 로드되는 동안 상호작용의 입력 지연을 연장할 수 있는 방법으로 스크립트 평가가 있습니다. 네트워크에서 JavaScript 파일을 가져온 후에도 브라우저에서 JavaScript를 실행하기 전에 해야 할 작업이 있습니다. 이 작업에는 스크립트를 파싱하여 구문이 유효한지 확인하고, 이를 바이트 코드로 컴파일한 다음 최종적으로 실행하는 작업이 포함됩니다.

스크립트의 크기에 따라 이 작업은 기본 스레드에 긴 작업을 발생시킬 수 있으며, 이로 인해 브라우저가 다른 사용자 상호작용에 응답하지 못하게 됩니다. 페이지가 로드되는 동안 사용자 입력에 반응하도록 페이지를 유지하려면, 페이지를 간결하게 유지하기 위해 페이지 로드 중 긴 작업의 가능성을 줄이기 위해 무엇을 할 수 있는지 이해하는 것이 중요합니다.

이벤트 콜백 최적화

입력 지연은 INP에서 측정하는 항목의 첫 번째 부분일 뿐입니다. 또한 사용자 상호작용에 대한 응답으로 실행되는 이벤트 콜백이 최대한 빨리 완료될 수 있도록 해야 합니다.

기본 스레드에 자주 양보

이벤트 콜백 최적화에 관한 가장 좋은 일반적인 조언은 가능한 한 작업을 적게 실행하는 것입니다. 그러나 상호작용 로직이 복잡할 수 있고 수행하는 작업을 미미하게 줄일 수 있을 뿐입니다.

귀하의 웹사이트가 이 경우에 해당한다면 이벤트 콜백의 작업을 별도의 작업으로 나누어 보는 것이 좋습니다. 이렇게 하면 집합 작업이 기본 스레드를 차단하는 긴 작업이 되는 것을 방지하므로 기본 스레드에서 대기 중인 다른 상호작용이 더 빨리 실행될 수 있습니다.

setTimeout는 작업을 분할하는 한 가지 방법입니다. 이는 작업에 전달된 콜백이 새 작업에서 실행되기 때문입니다. setTimeout를 단독으로 사용하거나 사용을 별도의 함수로 추상화하여 보다 인체 공학적인 결과를 도출할 수 있습니다.

무분별하게 양보하는 것이 전혀 양보하지 않는 것보다 낫습니다. 하지만 기본 스레드에 항복하는 더 미묘한 방법이 있으며, 여기에는 렌더링 로직이 더 빨리 실행될 수 있도록 사용자 인터페이스를 업데이트하는 이벤트 콜백 직후에만 양보하는 것이 포함됩니다.

렌더링 작업이 더 빨리 발생하도록 양보

고급 산출 기법에는 이벤트 콜백에 코드를 구조화하여 다음 프레임에 시각적 업데이트를 적용하는 데 필요한 로직으로만 실행할 항목을 제한하는 것이 포함됩니다. 나머지는 모두 후속 작업으로 연기할 수 있습니다. 이렇게 하면 콜백을 가볍고 민첩하게 유지할 수 있을 뿐만 아니라, 이벤트 콜백 코드에서 시각적 업데이트가 차단되지 않도록 하여 상호작용의 렌더링 시간도 개선됩니다.

예를 들어 입력할 때 텍스트의 서식을 지정하는 동시에 작성한 내용에 따라 UI의 다른 부분 (예: 단어 수, 맞춤법 실수 강조 표시, 기타 중요한 시각적 피드백)을 업데이트하는 서식 있는 텍스트 편집기를 생각해 보세요. 또한 애플리케이션에서 나갔다가 돌아왔을 때 작업 내용을 잃지 않도록 작성한 내용을 저장해야 할 수도 있습니다.

이 예에서는 사용자가 입력한 문자에 대한 응답으로 다음 네 가지가 발생해야 합니다. 그러나 다음 프레임이 표시되기 전에 첫 번째 항목만 완료되어야 합니다.

  1. 사용자가 입력한 내용으로 텍스트 상자를 업데이트하고 필요한 서식을 적용합니다.
  2. 현재 단어 수를 표시하는 UI 부분을 업데이트합니다.
  3. 맞춤법 오류가 있는지 검사하는 로직을 실행합니다.
  4. 최근 변경사항을 로컬 또는 원격 데이터베이스에 저장합니다.

이를 위한 코드는 다음과 같습니다.

textBox.addEventListener('input', (inputEvent) => {
  // Update the UI immediately, so the changes the user made
  // are visible as soon as the next frame is presented.
  updateTextBox(inputEvent);

  // Use `setTimeout` to defer all other work until at least the next
  // frame by queuing a task in a `requestAnimationFrame()` callback.
  requestAnimationFrame(() => {
    setTimeout(() => {
      const text = textBox.textContent;
      updateWordCount(text);
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

다음 시각화는 다음 프레임 이후까지 중요하지 않은 업데이트를 지연하면 처리 시간을 줄여 전반적인 상호작용 지연 시간을 줄일 수 있음을 보여줍니다.

두 가지 시나리오에서 키보드 상호작용과 후속 작업을 보여주는 이미지 위 그림에서 렌더링에 중요한 작업과 이후의 모든 백그라운드 작업은 프레임을 표시할 수 있는 기회가 될 때까지 동기식으로 실행됩니다. 아래 그림에서는 렌더링에 중요한 작업이 먼저 실행된 다음 기본 스레드에 양보되어 새 프레임을 더 빨리 표시합니다. 그 후에 백그라운드 작업이 실행됩니다.
고해상도 버전을 보려면 위의 그림을 클릭하세요.

이전 코드 예에서 requestAnimationFrame() 호출 내에서 setTimeout()를 사용하는 것은 약간 난해한 것 같지만, 중요하지 않은 코드가 다음 프레임을 차단하지 않도록 모든 브라우저에서 작동하는 효과적인 방법입니다.

레이아웃 스래싱 피하기

레이아웃 스래싱(강제 동기식 레이아웃이라고도 함)은 레이아웃이 동기식으로 발생하는 렌더링 성능 문제입니다. JavaScript에서 스타일을 업데이트한 다음 동일한 작업에서 읽을 때 발생합니다. JavaScript에는 레이아웃 스래싱을 일으킬 수 있는 속성이 많이 있습니다.

Chrome DevTools의 성능 패널에 표시된 레이아웃 스래싱의 시각화
Chrome DevTools의 성능 패널에 표시된 레이아웃 스래싱의 예 레이아웃 스래싱이 포함된 렌더링 작업에는 호출 스택 부분의 오른쪽 상단에 빨간색 삼각형이 표시됩니다. 보통 ReCalculate Style 또는 Layout이라고 라벨이 지정됩니다.

레이아웃 스래싱은 성능 병목 현상입니다. 스타일을 업데이트하고 JavaScript에서 해당 스타일의 값을 즉시 요청하면 브라우저가 동기식 레이아웃 작업을 강제로 하게 되고, 그렇지 않으면 이벤트 콜백 실행이 완료된 후 나중에 비동기적으로 실행될 때까지 기다려야 할 수 있기 때문입니다.

표시 지연 최소화

상호작용의 프레젠테이션 지연은 상호작용의 이벤트 콜백 실행이 완료된 시점부터 브라우저가 결과 시각적 변화를 보여주는 다음 프레임을 그릴 수 있는 시점까지입니다.

DOM 크기 최소화

페이지의 DOM이 작으면 일반적으로 렌더링 작업이 빠르게 완료됩니다. 그러나 DOM이 매우 커지면 DOM 크기가 증가함에 따라 렌더링 작업이 확장되는 경향이 있습니다. 렌더링 작업과 DOM 크기 간의 관계는 선형 관계는 아니지만 대형 DOM은 작은 DOM보다 렌더링에 더 많은 작업이 필요합니다. 큰 DOM은 다음 두 가지 경우에 문제가 됩니다.

  1. 대형 DOM에서 페이지의 초기 상태를 렌더링하는 데 많은 작업이 필요한 초기 페이지 렌더링 중.
  2. DOM이 크면 렌더링 업데이트 비용이 매우 높아지므로 브라우저가 다음 프레임을 표시하는 데 걸리는 시간이 늘어날 수 있는 사용자 상호작용에 대한 응답으로

큰 DOM을 크게 줄일 수 없는 경우가 있습니다. DOM 크기를 줄이기 위해 DOM을 평면화하거나, 사용자 상호작용 중에 DOM에 추가하여 초기 DOM 크기를 작게 유지하는 등 여러 방법을 사용할 수 있지만, 이러한 기술은 겨우 겨우 사용할 수 있습니다.

content-visibility를 사용하여 화면 밖의 요소를 지연 렌더링

페이지 로드 중 렌더링 작업과 사용자 상호작용에 응답하여 렌더링 작업의 양을 제한할 수 있는 한 가지 방법은 CSS content-visibility 속성을 사용하는 것입니다. 이 속성은 요소가 표시 영역에 접근할 때 요소를 느리게 렌더링하는 것과 같습니다. content-visibility를 효과적으로 사용하려면 몇 가지 연습이 필요하지만, 그 결과로 렌더링 시간이 단축되어 페이지의 INP를 개선할 수 있는지 조사하는 것이 좋습니다.

JavaScript를 사용하여 HTML을 렌더링할 때 성능 비용에 유의

HTML이 있는 곳에는 HTML 파싱이 있으며, 브라우저가 HTML을 DOM으로 파싱한 후에는 스타일을 적용하고 레이아웃 계산을 수행한 후에 레이아웃을 렌더링해야 합니다. 이는 불가피한 비용이지만 HTML 렌더링 방법이 중요합니다.

서버가 HTML을 보내면 브라우저에 스트림으로 도착합니다. 스트리밍은 서버의 HTML 응답이 청크로 도착함을 의미합니다. 브라우저는 스트림의 청크가 도착할 때 점진적으로 파싱하고 이를 조금씩 렌더링하여 스트림 처리 방식을 최적화합니다. 이는 페이지가 로드되는 동안 브라우저가 암시적으로 주기적으로 그리고 자동으로 생성한다는 점에서 성능 최적화이며, 이 기능은 무료로 제공됩니다.

웹사이트를 처음 방문할 때는 항상 약간의 HTML이 관련되지만, 일반적인 방법은 최소한의 HTML로 시작한 후 콘텐츠 영역을 채우는 데 JavaScript가 사용됩니다. 해당 콘텐츠 영역에 대한 후속 업데이트도 사용자 상호작용의 결과로 발생합니다. 이를 일반적으로 단일 페이지 애플리케이션 (SPA) 모델이라고 합니다. 이 패턴의 한 가지 단점은 클라이언트에서 JavaScript로 HTML을 렌더링하면 HTML을 생성하는 데 JavaScript 처리 비용을 얻을 뿐만 아니라 브라우저가 HTML 파싱 및 렌더링을 완료할 때까지 결과를 생성하지 않는다는 점입니다.

하지만 SPA가 아닌 웹사이트에서도 상호작용의 결과로 JavaScript를 통해 일정량의 HTML을 렌더링할 수 있다는 점을 기억해야 합니다. 클라이언트에서 많은 양의 HTML을 렌더링하지 않는 한 일반적으로 괜찮습니다. 이로 인해 다음 프레임의 표시가 지연될 수 있습니다. 그러나 브라우저에서 HTML을 렌더링하는 이 접근 방식이 성능에 미치는 영향과 JavaScript를 통해 많은 HTML을 렌더링하는 경우 사용자 입력에 대한 웹사이트의 반응성에 어떤 영향을 미칠 수 있는지 이해하는 것이 중요합니다.

결론

사이트의 INP는 반복적인 프로세스입니다. 현장에서 느린 상호작용을 수정하면(특히 웹사이트에서 많은 상호작용을 제공하는 경우) 느린 다른 상호작용을 발견하게 되므로 최적화해야 할 가능성이 높습니다.

INP 개선의 핵심은 지속성입니다. 시간이 지남에 따라 사용자가 제공한 환경에 만족하는 위치에 페이지의 반응성을 높일 수 있습니다. 또한 사용자를 위해 새로운 기능을 개발할 때 사용자와 관련된 상호작용을 최적화할 때 동일한 프로세스를 거쳐야 할 수도 있습니다. 시간과 노력은 필요하지만 시간과 노력을 잘 들인 것입니다.

Unsplash의 히어로 이미지(David Pisnoy)이며 Unsplash 라이선스에 따라 수정됨