언로드 이벤트 지원 중단

Demián Renzulli

Barry Pollard

unload 이벤트는 페이지에서 명시적으로 다시 사용 설정하도록 선택하지 않는 한 페이지에서 unload 핸들러가 실행을 중지하도록 기본값을 점진적으로 변경하여 점진적으로 지원 중단될 예정입니다.

지원 중단 타임라인

로드 취소 동작은 이르면 뒤로-앞으로 캐시 구현의 목적을 발표한 2019년 1월부터 변경될 수 있습니다. 구현 작업과 동시에 대대적인 홍보를 진행하여 언로드 사용량이 크게 감소했습니다. 이러한 홍보를 보완하기 위해 Google에서는 Chrome 115에서 로드 취소가 지원 중단되는 영향을 테스트하는 방법도 제공하기 시작했습니다.

• Chrome 115에서 언로드용 Permission-Policy API를 통한 공개 테스트 (2023년 7월)
• Chrome 117에서 플래그를 사용 설정하여 로컬 테스트 (2023년 9월)

이러한 고객 연락 및 무료 체험 단계를 마친 후 소프트 지원 중단이 적용되는 방식은 다음과 같습니다.

• 인기 있는 상위 50개 사이트에 대해 로드 취소 기능이 점진적으로 작동을 중단하는 범위 지정 단계입니다 (작성 시점을 기준으로 참조).
  • Chrome 120 사용자 중 1% 를 대상으로 출시됩니다 (2023년 11월 말).
  • 2024년 3분기 말까지 사용자의 100% 를 대상으로 종료
• 또한 2024년 3분기부터는 모든 사이트에서 언로드 기능이 점진적으로 중지되는 일반 단계를 시작하여 2025년 1분기 말까지 사용자의 1% 에서 시작하여 100% 에 도달할 예정입니다.

이 소프트 지원 중단 타임라인이 로드 취소로부터 이전하는 데 충분한 시간을 제공하지 않는 경우를 대비해 선택 해제 옵션 메뉴도 제공합니다. Google의 목표는 이러한 완곡한 지원 중단을 통해 이러한 선택 해제가 삭제되거나 축소되는 마지막 단계 (언로드의 강제 지원 중단)의 타임라인을 알리는 것입니다.

배경

unload는 문서 로드 취소 시 실행되도록 설계되었습니다. 이론적으로는 사용자가 페이지에서 나갈 때마다 코드를 실행하거나 세션 종료 콜백으로 코드를 실행하는 데 사용할 수 있습니다.

이 이벤트가 가장 많이 사용된 시나리오는 다음과 같습니다.

• 사용자 데이터 저장: 페이지에서 나가기 전에 데이터를 저장합니다.
• 삭제 작업 수행: 페이지를 종료하기 전에 열려 있는 리소스를 닫습니다.
• 분석 전송: 세션 종료 시 사용자 상호작용과 관련된 데이터를 전송합니다.

그러나 unload 이벤트는 매우 불안정합니다.

데스크톱 Chrome 및 Firefox에서 unload는 상당히 안정적이지만 bfcache (뒤로-앞으로 캐시) 사용을 차단하여 사이트 성능에 부정적인 영향을 미칩니다.

모바일 브라우저에서는 탭이 백그라운드에 자주 실행되었다가 종료되기 때문에 unload가 실행되지 않는 경우가 많습니다. 이러한 이유로 브라우저는 모바일에서 unload보다 bfcache에 우선순위를 두기 때문에 그만큼 안정성이 훨씬 떨어집니다. Safari는 데스크톱에서도 이 동작을 사용합니다.

Chrome팀은 이전에는 데스크톱에서 unload보다 bfcache에 우선순위를 지정하는 모바일 모델을 사용하면 Chrome (및 Firefox)에서 bfcache를 합리적으로 안정적으로 사용할 수 있었는데, 데스크톱에서도 안정성이 떨어짐에 따라 오해가 될 것이라고 생각합니다. 대신 Chrome의 목표는 unload 이벤트를 완전히 삭제하는 것입니다. 그때까지는 지원 중단을 명시적으로 거부한 사용자의 경우 데스크톱에서 안정적으로 계속 사용할 수 있습니다.

unload 이벤트가 지원 중단되는 이유는 무엇인가요?

unload의 지원 중단은 현재 우리가 사용 중인 웹을 훨씬 더 널리 인식하기 위한 중요한 단계입니다. unload 이벤트는 앱 수명 주기를 잘못된 방식으로 제어할 수 있게 해주며, 이 현상은 현대 컴퓨팅 세계에서 웹을 탐색하는 방식이 점점 더 진전되고 있습니다.

모바일 운영체제에서는 메모리를 절약하기 위해 웹페이지를 정지하거나 로드하는 경우가 많으며, 데스크톱 브라우저도 같은 이유로 이 작업을 점점 더 많이 수행하고 있습니다. 운영체제의 개입이 없어도, 사용자는 공식적으로 '페이지를 닫지 않고' 자주 탭을 전환하고 이전 탭을 종료합니다.

불필요하게 unload 이벤트를 삭제하는 것은 웹 개발자로서 패러다임이 실제 세상의 패러다임과 일치하도록 하고 더 이상 유효하지 않은 오래된 개념에 의존하지 않도록 해야 한다는 인식입니다.

unload 이벤트의 대안

unload 대신 다음을 사용하는 것이 좋습니다.

• visibilitychange: 페이지의 공개 상태가 변경되는 시점을 결정합니다. 이 이벤트는 사용자가 탭을 전환하거나 브라우저 창을 최소화하거나 새 페이지를 열 때 발생합니다. hidden 상태를 앱 및 사용자 데이터를 저장하는 신뢰할 수 있는 마지막 시간으로 간주합니다.
• pagehide: 사용자가 페이지에서 나간 시점을 파악합니다. 이 이벤트는 사용자가 페이지에서 벗어나거나, 페이지를 새로고침하거나, 브라우저 창을 닫을 때 발생합니다. 페이지가 단순히 최소화되거나 다른 탭으로 전환되면 pagehide 이벤트가 실행되지 않습니다. pagehide의 경우 페이지에서 뒤로-앞으로 캐시를 사용할 수 없으므로 이 이벤트가 발생한 후 페이지를 복원할 수 있습니다. 이 이벤트의 리소스를 삭제하는 경우 페이지 복원 시 복원해야 할 수 있습니다.

beforeunload 이벤트는 취소 가능한 이벤트라는 점에서 unload과 사용 사례가 약간 다릅니다. 이 버튼은 주로 페이지에서 나갈 때 저장되지 않은 변경사항을 사용자에게 경고하는 데 사용됩니다. 또한 이 이벤트는 백그라운드 탭이 종료되면 실행되지 않으므로 실행할 수 없습니다. beforeunload 사용을 제한하고 조건부로만 추가하는 것이 좋습니다. 대신 대부분의 unload 대체에 위 이벤트를 사용합니다.

자세한 내용은 unload 핸들러를 사용하지 않는 방법에 대한 도움말을 참고하세요.

unload 사용 감지

페이지에 unload 이벤트가 어떻게 표시되는지 찾는 데 도움이 되는 다양한 도구가 있습니다. 이를 통해 사이트에서 자체 코드 또는 라이브러리를 통해 이 이벤트를 사용하고 있는지 확인할 수 있으므로 향후 지원 중단의 영향을 받을 수 있습니다.

등대

Lighthouse에는 no-unload-listeners 감사가 있습니다. 이 감사는 페이지에 있는 JavaScript (서드 파티 라이브러리의 JavaScript 포함)가 unload 이벤트 리스너를 추가하는 경우 개발자에게 경고를 보냅니다.

Chrome DevTools

Chrome DevTools에는 back-foward-cache 감사가 포함되어 unload 핸들러 사용을 비롯하여 페이지에서 뒤로-앞으로 캐시를 사용할 수 없는 문제를 파악할 수 있습니다.

뒤로-앞으로 캐시를 테스트하려면 다음 단계를 따르세요.

1. 페이지에서 DevTools를 열고 애플리케이션 > 백그라운드 서비스 > 뒤로-앞으로 캐시로 이동합니다.

2. 뒤로-앞으로 캐시 테스트를 클릭하면 Chrome에서 자동으로 chrome://terms/로 이동한 후 내 페이지로 돌아옵니다. 또는 브라우저의 뒤로 버튼과 앞으로 버튼을 클릭해도 됩니다.

페이지에서 뒤로-앞으로 캐싱을 사용할 수 없는 경우 뒤로-앞으로 캐시 탭에 문제 목록이 표시됩니다. 작업 가능에서 unload를 사용 중인지 확인할 수 있습니다.

Reporting API

Reporting API는 읽기 전용 권한 정책과 함께 웹사이트 사용자의 unload 사용을 감지하는 데 사용할 수 있습니다.

자세한 내용은 usReporting API를 사용하여 언로드 찾기를 참고하세요.

Bfcache notRestoredReasons API

PerformanceNavigationTiming 클래스에 추가된 notRestoredReasons 속성은 문서가 탐색 시 bfcache를 사용하지 못하도록 차단되었는지 여부와 그 이유에 관한 정보를 보고합니다. 사용 안내는 여기에서 확인할 수 있습니다. 다음은 기존 unload 리스너의 응답 객체 경고가 어떻게 표시되는지 보여주는 예입니다.

{
   blocked: true,
   children: [],
   id: "",
   name: "",
   reasons: [ "Internal Error", "Unload handler" ],
   src: "",
   url: "a.com"
}

unload에 대한 액세스 제어

Chrome에서 unload 이벤트를 점진적으로 지원 중단할 예정입니다. 그동안 다양한 도구를 사용하여 이 동작을 제어하고 예정된 지원 중단에 대비할 수 있습니다. 이러한 기법에 장기적으로 의존해서는 안 되며, 가능한 한 빨리 다른 기법으로 마이그레이션할 계획을 세워야 합니다.

다음 옵션을 사용하면 unload 핸들러를 사용 설정하거나 사용 중지하여 핸들러가 없을 경우 사이트가 어떻게 작동하는지 테스트할 수 있으므로 예정된 지원 중단에 대비할 수 있습니다. 정책에는 여러 가지 유형이 있습니다.

• 권한 정책: 사이트 소유자가 HTTP 헤더 사용을 통해 사이트 또는 개별 페이지 수준에서 기능에 대한 액세스를 제어할 수 있는 플랫폼 API입니다.
• 엔터프라이즈 정책: IT 관리자가 조직 또는 비즈니스에 Chrome을 설정할 수 있는 도구입니다. Google 관리 콘솔과 같은 관리 패널을 통해 구성할 수 있습니다.
• Chrome 플래그: 개별 개발자가 unload 지원 중단 설정을 변경하여 다양한 사이트에 미치는 영향을 테스트할 수 있습니다.

권한 정책

Chrome 115부터 권한 정책이 추가되어 사이트에서 unload 핸들러 사용을 선택 해제하고 즉시 bfcache를 활용하여 사이트 속도를 개선할 수 있습니다. 사이트에 이를 설정하는 방법은 이 예를 참고하세요. 이렇게 하면 사이트에서 unload 지원 중단에 미리 대처할 수 있습니다.

이 조치는 Chrome 117에서 확장되어 사이트에서 이 작업을 실행하고 unload 핸들러를 계속 실행하도록 선택할 수 있게 됩니다. Chrome에서 향후 이 핸들러를 실행하지 않도록 기본값을 변경하기 때문입니다. 사이트에서 계속 로드 취소 핸들러를 실행하도록 허용하는 방법은 이 예를 참고하세요. 이 선택은 영구적으로 유지되지는 않으며 사이트가 unload 핸들러에서 이전할 시간을 확보하는 데 사용해야 합니다.

기업 정책

제대로 작동하기 위해 unload 이벤트에 의존하는 소프트웨어를 보유한 기업은 ForcePermissionPolicyUnloadDefaultEnabled 정책을 사용하여 제어 중인 기기의 점진적 지원 중단을 방지할 수 있습니다. 이 정책을 사용 설정하면 unload이(가) 모든 출처에 대해 기본적으로 사용 설정됩니다. 원하는 경우 페이지에서 더 엄격한 정책을 설정할 수 있습니다. 권한 정책 선택 해제와 마찬가지로 이 도구는 잠재적인 브레이킹 체인지를 완화하기 위한 도구이지만 무기한으로 사용해서는 안 됩니다.

Chrome 플래그 및 명령줄 스위치

엔터프라이즈 정책 외에도 Chrome 플래그와 명령줄 스위치를 통해 개별 사용자에 대해 지원 중단을 사용 중지할 수 있습니다.

chrome://flags/#deprecate-unload를 enabled로 설정하면 지원 중단 기본값이 적용되고 unload 핸들러가 실행되지 않습니다. 권한 정책을 통해 사이트별로 재정의할 수 있지만 기본적으로 계속 실행됩니다.

이러한 설정은 명령줄 스위치로도 제어할 수 있습니다.

옵션 비교

다음 표는 앞에서 설명한 옵션의 다양한 용도를 요약한 것입니다.

결론

unload 핸들러가 지원 중단됩니다. 오랫동안 신뢰할 수 없었기 때문에 문서가 파기될 때마다 반드시 실행되는 것은 아닙니다. 또한 unload 핸들러는 bfcache와 호환되지 않습니다.

현재 unload 핸들러를 사용하는 사이트는 기존 unload 핸들러를 테스트하고, 삭제 또는 이전하거나, 시간이 더 필요한 경우 최후의 수단으로 지원 중단을 지연하여 예정된 지원 중단에 대비해야 합니다.

감사의 말

이 도움말을 검토하는 데 도움을 주신 켄지 바휴, 퍼갈 댈리, 아드리아나 자라, 제레미 와그너님께 감사드립니다.

안자 바우어만의 Unsplash