Scheduler.yield 오리진 트라이얼 소개

Jeremy Wagner

사용자 입력에 빠르게 반응하는 웹사이트를 빌드하는 것은 웹 성능의 가장 어려운 측면 중 하나이며, Chrome팀은 웹 개발자가 이를 충족할 수 있도록 지원하기 위해 노력해 왔습니다. 올해 Interaction to Next Paint (INP) 측정항목이 실험용에서 보류 중인 상태로 전환된다고 발표되었습니다. 이제 2024년 3월에 Core Web Vital로 첫 입력 지연 (FID)을 대체할 예정입니다.

웹 개발자가 웹사이트를 최대한 빠르게 만들 수 있도록 지원하는 새로운 API를 제공하기 위해 Chrome팀은 현재 Chrome 버전 115부터 의 오리진 트라이얼을 실행하고 있습니다.scheduler.yield scheduler.yield는 스케줄러 API에 제안된 새로운 추가 기능으로, 기존에 사용되던 메서드보다 더 쉽고 더 나은 방식으로 기본 스레드에 제어를 다시 제공할 수 있습니다.

제공 시

JavaScript는 실행 완료 모델을 사용하여 작업을 처리합니다. 즉, 작업이 기본 스레드에서 실행될 때 해당 작업은 완료하는 데 필요한 만큼 실행됩니다. 작업이 완료되면 제어가 기본 스레드로 다시 제공 되어 기본 스레드가 대기열의 다음 작업을 처리할 수 있습니다.

예를 들어 무한 루프와 같이 작업이 완료되지 않는 극단적인 경우를 제외하고 제공은 JavaScript의 작업 예약 로직에서 불가피한 측면입니다. 제공은 발생하며, 언제 발생하느냐의 문제일 뿐이며, 나중에 발생하는 것보다 빨리 발생하는 것이 좋습니다. 작업을 실행하는 데 너무 오래 걸리는 경우(정확히 50밀리초 초과) 긴 작업으로 간주됩니다.

긴 작업은 브라우저가 사용자 입력에 응답하는 기능을 지연시키므로 페이지 응답성이 저하되는 원인이 됩니다. 긴 작업이 더 자주 발생하고 더 오래 실행될수록 사용자는 페이지가 느리다고 생각하거나 완전히 중단되었다고 느낄 가능성이 높아집니다.

그러나 코드가 브라우저에서 작업을 시작한다고 해서 제어가 기본 스레드로 다시 제공될 때까지 해당 작업이 완료될 때까지 기다릴 필요는 없습니다. 작업에서 명시적으로 제공하여 페이지에서 사용자 입력에 대한 응답성을 개선할 수 있습니다. 이렇게 하면 다음 사용 가능한 기회에 완료되도록 작업이 분할됩니다. 이렇게 하면 긴 작업이 완료될 때까지 기다려야 하는 경우보다 다른 작업이 기본 스레드에서 더 빨리 시간을 확보할 수 있습니다.

작업을 분할하면 입력 응답성이 어떻게 개선되는지 보여주는 그림 상단에서 긴 작업은 작업이 완료될 때까지 이벤트 핸들러가 실행되지 않도록 차단합니다. 하단에서 청크로 분할된 작업은 이벤트 핸들러가 그렇지 않은 경우보다 더 빨리 실행되도록 허용합니다.
기본 스레드에 제어를 다시 제공하는 시각화 상단에서는 작업이 완료될 때까지 실행된 후에만 제공이 발생합니다. 즉, 기본 스레드에 제어를 다시 제공하기 전에 작업이 완료되는 데 더 오래 걸릴 수 있습니다. 하단에서는 제공이 명시적으로 이루어지며 긴 작업을 여러 개의 작은 작업으로 분할합니다. 이렇게 하면 사용자 상호작용이 더 빨리 실행되어 입력 응답성과 INP가 개선됩니다.

명시적으로 제공할 때는 브라우저에 '내가 하려는 작업이 시간이 걸릴 수 있다는 것을 알고 있으며, 사용자 입력이나 중요한 다른 작업에 응답하기 전에 모든 작업을 수행하지 않기를 바랍니다'라고 말하는 것입니다. 개발자 도구 상자의 유용한 도구로, 사용자 환경을 개선하는 데 큰 도움이 될 수 있습니다.

현재 제공 전략의 문제

일반적인 제공 메서드는 을 setTimeout의 제한 시간 값과 함께 사용합니다0. 이는 setTimeout에 전달된 콜백이 나머지 작업을 후속 실행을 위해 대기열에 추가될 별도의 작업으로 이동하기 때문에 작동합니다. 브라우저가 자체적으로 제공할 때까지 기다리는 대신 '이 큰 작업 덩어리를 더 작은 비트로 나누세요'라고 말하는 것입니다.

그러나 setTimeout을 사용한 제공에는 잠재적으로 바람직하지 않은 부작용이 있습니다. 제공 지점 후 에 오는 작업이 작업 대기열의 끝으로 이동합니다. 사용자 상호작용으로 예약된 작업은 여전히 대기열의 맨 앞으로 이동하지만, 명시적으로 제공한 후에 수행하려는 나머지 작업은 대기열에 추가된 경쟁 소스의 다른 작업으로 인해 더 지연될 수 있습니다.

실제로 확인하려면 이 CodePen 데모를 사용해 보거나 다음 삽입된 버전에서 실험해 보세요. 데모는 클릭할 수 있는 몇 개의 버튼과 작업이 실행될 때 기록하는 상자로 구성됩니다. 페이지에 도착하면 다음 작업을 실행합니다.

  1. **작업을 주기적으로 실행** 이라는 상단 버튼을 클릭합니다. 이렇게 하면 차단 작업이 주기적으로 실행되도록 예약됩니다. 이 버튼을 클릭하면 작업 로그에 차단 작업을 setInterval 실행했습니다 라는 여러 메시지가 채워집니다.
  2. 다음으로 각 반복에서 setTimeout으로 제공하는 루프 실행 이라는 버튼을 클릭합니다.

데모 하단의 상자에 다음과 같은 내용이 표시됩니다.

Processing loop item 1
Processing loop item 2
Ran blocking task via setInterval
Processing loop item 3
Ran blocking task via setInterval
Processing loop item 4
Ran blocking task via setInterval
Processing loop item 5
Ran blocking task via setInterval
Ran blocking task via setInterval

이 출력은 setTimeout으로 제공할 때 발생하는 '태스크 큐의 끝' 동작을 보여줍니다. 실행되는 루프는 5개의 항목을 처리하고 각 항목이 처리된 후 setTimeout으로 제공합니다.

이는 웹에서 흔히 발생하는 문제를 보여줍니다. 특히 서드 파티 스크립트가 특정 간격으로 작업을 실행하는 타이머 함수를 등록하는 것은 드문 일이 아닙니다. setTimeout으로 제공할 때 발생하는 '태스크 큐의 끝' 동작은 다른 태스크 소스의 작업이 제공 후 루프에서 수행해야 하는 나머지 작업보다 먼저 대기열에 추가될 수 있음을 의미합니다.

애플리케이션에 따라 바람직한 결과일 수도 있고 아닐 수도 있지만, 많은 경우 이 동작은 개발자가 기본 스레드의 제어를 쉽게 포기하기를 꺼리는 이유입니다. 제공은 사용자 상호작용이 더 빨리 실행될 수 있기 때문에 좋지만, 사용자 상호작용이 아닌 다른 작업도 기본 스레드에서 시간을 확보할 수 있습니다. 이는 실제 문제이지만 scheduler.yield를 사용하면 해결할 수 있습니다.

scheduler.yield 입력

scheduler.yield는 Chrome 버전 115부터 실험용 웹 플랫폼 기능으로 플래그 뒤에서 사용할 수 있습니다. 'setTimeout이 이미 제공하고 있는데 제공을 위한 특별한 함수가 필요한 이유는 무엇인가요?'라는 질문이 있을 수 있습니다.

제공은 setTimeout의 설계 목표가 아니라 나중에 실행될 콜백을 예약할 때 발생하는 부작용이라는 점에 유의해야 합니다. 제한 시간 값이 0으로 지정된 경우에도 마찬가지입니다. 그러나 더 중요한 것은 setTimeout을 사용한 제공은 나머지 작업을 태스크 큐의 끝 으로 보낸다는 점입니다. 기본적으로 scheduler.yield는 나머지 작업을 큐의 맨 앞 으로 보냅니다. 즉, 제공 직후에 다시 시작하려는 작업은 다른 소스의 작업 (사용자 상호작용은 예외)에 우선하지 않습니다.

scheduler.yield는 기본 스레드에 제공하고 호출 시 Promise를 반환하는 함수입니다. 즉, async 함수에서 await할 수 있습니다.

async function yieldy () {
  // Do some work...
  // ...

  // Yield!
  await scheduler.yield();

  // Do some more work...
  // ...
}

scheduler.yield가 실제로 작동하는지 확인하려면 다음 단계를 따르세요.

  1. chrome://flags로 이동합니다.
  2. 실험용 웹 플랫폼 기능 실험을 사용 설정합니다. 이렇게 한 후 Chrome을 다시 시작해야 할 수도 있습니다.
  3. 데모 페이지로 이동하거나 이 목록 다음에 나오는 삽입된 버전을 사용합니다.
  4. 작업을 주기적으로 실행 이라는 상단 버튼을 클릭합니다.
  5. 마지막으로 각 반복에서 scheduler.yield로 제공하는 루프 실행 이라는 버튼을 클릭합니다.

페이지 하단의 상자에 있는 출력은 다음과 같이 표시됩니다.

Processing loop item 1
Processing loop item 2
Processing loop item 3
Processing loop item 4
Processing loop item 5
Ran blocking task via setInterval
Ran blocking task via setInterval
Ran blocking task via setInterval
Ran blocking task via setInterval
Ran blocking task via setInterval

setTimeout을 사용하여 제공하는 데모와 달리 루프는 모든 반복 후에 제공되더라도 나머지 작업을 대기열의 끝으로 보내지 않고 대기열의 맨 앞으로 보냅니다. 이렇게 하면 웹사이트에서 입력 응답성을 개선하기 위해 제공할 수 있을 뿐만 아니라 제공 후 에 완료하려는 작업이 지연되지 않도록 할 수 있습니다.

한번 사용해 보세요.

scheduler.yield가 흥미롭고 사용해 보고 싶다면 Chrome 버전 115부터 두 가지 방법으로 사용할 수 있습니다.

  1. scheduler.yield를 로컬에서 실험하려면 Chrome의 주소 표시줄에 chrome://flags를 입력하고 실험용 웹 플랫폼 기능 섹션의 드롭다운에서 사용 설정 을 선택합니다. 이렇게 하면 scheduler.yield (및 기타 실험용 기능)가 Chrome의 인스턴스에서만 사용할 수 있게 됩니다.
  2. 공개적으로 액세스할 수 있는 오리진에서 실제 Chromium 사용자를 위해 scheduler.yield를 사용 설정하려면 scheduler.yield 오리진 트라이얼에 가입해야 합니다. 이렇게 하면 제안된 기능을 일정 기간 동안 안전하게 실험할 수 있으며 Chrome팀은 이러한 기능이 현장에서 어떻게 사용되는지에 관한 유용한 통계를 얻을 수 있습니다. 오리진 트라이얼의 작동 방식에 관한 자세한 내용은 이 가이드를 참고하세요.

scheduler.yield를 구현하지 않는 브라우저를 계속 지원하면서 scheduler.yield를 사용하는 방법은 목표에 따라 다릅니다. 공식 폴리필을 사용할 수 있습니다. 다음이 상황에 적용되는 경우 폴리필이 유용합니다.

  1. 애플리케이션에서 scheduler.postTask를 사용하여 작업을 예약하고 있습니다.
  2. 작업 및 제공 우선순위를 설정할 수 있기를 원합니다.
  3. scheduler.postTask API에서 제공하는 TaskController 클래스를 사용하여 작업을 취소하거나 우선순위를 다시 지정할 수 있기를 원합니다.

이 설명이 상황에 맞지 않는다면 폴리필이 적합하지 않을 수 있습니다. 이 경우 몇 가지 방법으로 자체 대체를 롤아웃할 수 있습니다. 첫 번째 접근 방식은 scheduler.yield를 사용할 수 있는 경우 사용하지만 사용할 수 없는 경우 setTimeout으로 대체합니다.

// A function for shimming scheduler.yield and setTimeout:
function yieldToMain () {
  // Use scheduler.yield if it exists:
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();
  }

  // Fall back to setTimeout:
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

// Example usage:
async function doWork () {
  // Do some work:
  // ...

  await yieldToMain();

  // Do some other work:
  // ...
}

이 방법은 작동할 수 있지만, scheduler.yield를 지원하지 않는 브라우저는 '대기열의 맨 앞' 동작 없이 제공합니다. 즉, 제공하지 않는 것이 좋다면 scheduler.yield를 사용할 수 있는 경우 사용하지만 사용할 수 없는 경우 제공하지 않는 다른 접근 방식을 시도해 볼 수 있습니다.

// A function for shimming scheduler.yield with no fallback:
function yieldToMain () {
  // Use scheduler.yield if it exists:
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();
  }

  // Fall back to nothing:
  return;
}

// Example usage:
async function doWork () {
  // Do some work:
  // ...

  await yieldToMain();

  // Do some other work:
  // ...
}

scheduler.yield는 스케줄러 API에 흥미로운 추가 기능으로, 개발자가 현재 제공 전략보다 더 쉽게 응답성을 개선할 수 있기를 바랍니다. scheduler.yield가 유용한 API라고 생각되면 연구에 참여하여 개선에 도움을 주고 추가 개선 방법에 관한 의견을 제공해 주세요.

Unsplash의 조너선 앨리슨이 촬영한 히어로 이미지