페이지에서 unload 핸들러를 다시 사용 설정하도록 명시적으로 선택하지 않는 한 unload 핸들러가 페이지에서 실행되지 않도록 기본값을 점진적으로 변경하여 unload 이벤트가 점진적으로 지원 중단됩니다.
지원 중단 타임라인
뒤로/앞으로 캐시 구현 의도를 발표한 2019년 1월부터 언로드 동작이 변경될 수 있음을 알려드린 바 있습니다. 구현 작업과 동시에 대규모 홍보 활동을 진행한 결과 로드 취소 사용량이 크게 감소했습니다. 이러한 홍보를 보완하기 위해 Chrome 115에서 로드 취소를 지원 중단하는 효과를 테스트하는 방법도 제공하기 시작했습니다.
- Chrome 115의 로드 취소를 위한 권한 정책 API를 통한 실제 테스트 (2023년 7월)
- Chrome 117에서 플래그를 사용 설정하여 로컬 테스트 (2023년 9월)
이러한 홍보 및 체험판 단계에 이어 조용히 지원 중단이 출시될 예정입니다.
- 인기 사이트 상위 50개에서 로드 취소가 점진적으로 중단되는 범위가 지정된 단계입니다 (작성 시점의 참조).
- Chrome 120부터 사용자의 1% 를 대상으로 시작 (2023년 11월 말)
- 2024년 3분기 말까지 모든 사용자에게 적용됨
- 또한 2024년 3분기부터 모든 사이트에서 로드 취소가 점진적으로 중단되는 일반 단계를 시작할 예정입니다. 이 단계는 사용자의 1% 로 시작하여 2025년 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 이벤트가 표시되는 위치를 찾는 데 도움이 되는 다양한 도구가 있습니다. 이를 통해 사이트는 자체 코드 또는 라이브러리를 통해 이 이벤트를 사용 중이며 향후 지원 중단의 영향을 받을 수 있는지 확인할 수 있습니다.
Chrome DevTools
Chrome DevTools에는 unload 핸들러의 사용을 비롯하여 페이지가 뒤로/앞으로 캐시를 사용할 수 없게 하는 문제를 식별하는 데 도움이 되는 back-forward-cache 감사가 포함되어 있습니다.
뒤로/앞으로 캐시를 테스트하려면 다음 단계를 따르세요.
페이지에서 DevTools를 열고 애플리케이션 > 백그라운드 서비스 > 뒤로/앞으로 캐시로 이동합니다.
뒤로/앞으로 캐시 테스트를 클릭하면 Chrome이 자동으로
chrome://terms/로 이동한 후 페이지로 돌아갑니다. 또는 브라우저의 뒤로 및 앞으로 버튼을 클릭해도 됩니다.
페이지에서 뒤로/앞으로 캐시를 사용할 수 없는 경우 뒤로/앞으로 캐시 탭에 문제 목록이 표시됩니다. 실행 가능한 작업에서 unload을 사용 중인지 확인할 수 있습니다.
Reporting API
Reporting API를 읽기 전용 권한 정책과 함께 사용하여 웹사이트 사용자의 unload 사용을 감지할 수 있습니다.
자세한 내용은 Reporting API를 사용하여 언로드를 찾는 방법을 참고하세요.
Bfcache notRestoredReasons API
PerformanceNavigationTiming 클래스에 추가된 notRestoredReasons 속성은 문서가 탐색 시 bfcache를 사용하는 것이 차단되었는지 여부와 그 이유에 관한 정보를 보고합니다. 사용 안내는 여기에서 확인할 수 있습니다. 다음은 기존 unload 리스너의 응답 객체 경고가 표시되는 방식의 예입니다.
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-handler"}
],
src: null,
url: "https://www.example.com/page/"
}
unload에 대한 액세스 제어
Chrome에서는 unload 이벤트를 점진적으로 지원 중단할 예정입니다. 그동안 다른 도구를 사용하여 이 동작을 제어하고 예정된 지원 중단에 대비할 수 있습니다. 이러한 기법은 장기적으로 사용해서는 안 되며 가능한 한 빨리 대안으로 이전할 계획을 세워야 합니다.
다음 옵션을 사용하면 unload 핸들러를 사용 설정 또는 중지하여 unload 핸들러 없이 사이트가 작동하는 방식을 테스트할 수 있으므로 예정된 지원 중단에 대비할 수 있습니다. 정책에는 다음과 같은 여러 유형이 있습니다.
- 권한 정책: 사이트 소유자가 HTTP 헤더를 사용하여 사이트 또는 개별 페이지 수준에서 기능에 대한 액세스를 제어할 수 있는 플랫폼 API입니다.
- 엔터프라이즈 정책: IT 관리자가 조직 또는 비즈니스에 맞게 Chrome을 구성할 수 있는 도구입니다. Google 관리 콘솔과 같은 관리 패널을 통해 구성할 수 있습니다.
- Chrome 플래그: 이를 통해 개별 개발자는
unload지원 중단 설정을 변경하여 다양한 사이트에 미치는 영향을 테스트할 수 있습니다.
권한 정책
사이트에서 unload 핸들러 사용을 선택 해제하고 bfcache의 이점을 즉시 활용하여 사이트 성능을 개선할 수 있도록 Chrome 115부터 권한 정책이 추가되었습니다. 사이트에 이를 설정하는 방법에 관한 예시를 참고하세요. 이를 통해 사이트에서 unload 지원 중단에 대비할 수 있습니다.
Chrome 117에서 확장되어 사이트에서 반대로 할 수 있고, Chrome에서 향후 unload 핸들러가 실행되지 않도록 기본값을 변경하므로 unload 핸들러를 계속 실행하려고 할 수 있습니다. 사이트에서 언로드 핸들러가 계속 실행되도록 허용하는 방법에 관한 예시를 참고하세요. 이 선택사항은 영구적으로 유지되지 않으며 사이트가 unload 핸들러에서 이전할 시간을 확보하는 데 사용해야 합니다.
엔터프라이즈 정책
unload 이벤트에 종속되어 올바르게 작동하는 소프트웨어가 있는 기업은 ForcePermissionPolicyUnloadDefaultEnabled 정책을 사용하여 제어하는 기기의 점진적인 지원 중단을 방지할 수 있습니다. 이 정책을 사용 설정하면 unload가 모든 출처에 대해 기본적으로 사용 설정된 상태로 계속 유지됩니다. 페이지에서 원하는 경우 더 엄격한 정책을 설정할 수 있습니다. 권한 정책 선택 해제와 마찬가지로 이는 잠재적인 중단을 완화하기 위한 도구이지만 무기한으로 사용해서는 안 됩니다.
Chrome 플래그 및 명령줄 스위치
엔터프라이즈 정책 외에도 Chrome 플래그 및 명령줄 스위치를 통해 개별 사용자에 대해 지원 중단을 사용 중지할 수 있습니다.
chrome://flags/#deprecate-unload를 enabled로 설정하면 지원 중단 기본값이 적용되고 unload 핸들러가 실행되지 않습니다. 권한 정책을 통해 사이트별로 재정의할 수는 있지만 기본적으로 계속 실행됩니다.
이러한 설정은 명령줄 스위치로도 제어할 수 있습니다.
옵션 비교
다음 표에는 이전에 설명한 옵션의 다양한 용도가 요약되어 있습니다.
| 지원 중단 조기 적용 | 지원 중단 조기 적용 (예외 포함) | 이전할 시간을 확보하기 위해 지원 중단 방지 | |
|---|---|---|---|
| 권한 정책 (페이지/사이트에 적용됨) |
예 | 예 | 예 |
| 엔터프라이즈 정책 (기기에 적용됨) |
아니요 | 아니요 | 예 |
| Chrome 플래그 (개별 사용자에게 적용됨) |
예 | 아니요 | 아니요 |
| Chrome 명령줄 스위치 (개별 사용자에게 적용됨) |
예 | 아니요 | 예 |
결론
unload 핸들러가 지원 중단됩니다. 오랫동안 신뢰할 수 없었으며 문서가 삭제되는 모든 경우에 실행되지 않을 수 있습니다. 또한 unload 핸들러는 bfcache와 호환되지 않습니다.
현재 unload 핸들러를 사용하는 사이트는 기존 unload 핸들러를 테스트하거나 삭제 또는 이전하거나, 더 많은 시간이 필요한 경우 최후의 수단으로 지원 중단을 지연하여 예정된 지원 중단에 대비해야 합니다.
감사의 말씀
이 도움말 검토에 도움을 주신 켄지 바에흐, 퍼갈 댈리, 아드리아나 자라, 제레미 바그너님께 감사드립니다.
Unsplash의 Anja Bauermann님 제공 히어로 이미지