페이지에서 명시적으로 다시 사용 설정하지 않는 한 unload 핸들러가 페이지에서 실행을 중지하도록 기본값을 점진적으로 변경하여 unload 이벤트를 점진적으로 지원 중단합니다.
지원 중단 일정
Google은 뒤로-앞으로 캐시를 구현하겠다는 계획을 발표한 2019년 1월부터 로드 취소 동작이 변경될 수 있음을 확인했습니다. 구현 작업과 동시에 대규모 연락을 취해 언로드 사용량이 크게 감소했습니다. 이러한 홍보 활동을 보완하기 위해 Google은 Chrome 115에서 로드 취소가 지원 중단되었을 때의 효과를 테스트하는 방법도 제공하기 시작했습니다.
- Chrome 115에서 언로드를 위한 Permission-Policy API를 통한 실제 테스트 (2023년 7월)
- Chrome 117에서 플래그를 사용 설정하여 로컬 테스트 (2023년 9월)
이러한 연락 및 시험 단계를 거친 후 소프트 지원 중단이 다음과 같이 적용될 예정입니다.
- 상위 50개 사이트에서 로드 취소 기능이 점진적으로 중단되는 범위가 지정된 단계 (작성 시점 기준 참조)
- Chrome 120 (2023년 11월 말)부터 사용자의 1% 를 대상으로 합니다.
- 2024년 3분기 말까지 모든 사용자를 대상으로 종료
- 또한 2024년 3분기부터 2025년 1분기 말까지 사용자 1% 를 대상으로 시작해 100% 의 사용자를 대상으로 하는 사이트에서 로드 취소 기능이 점진적으로 중단되는 일반 단계를 시작할 계획입니다.
이 소프트 지원 중단 타임라인으로 인해 로드 취소를 진행하기에 충분한 시간이 없는 경우 선택 해제 옵션 메뉴도 제공됩니다. Google의 목표는 이 소프트 지원 중단을 통해 이러한 수신 거부가 삭제되거나 축소되는 마지막 단계 (언로드 하드 지원 중단)의 타임라인을 알리는 것입니다.
배경
unload는 문서가 언로드될 때 실행되도록 설계되었습니다. 이론적으로는 사용자가 페이지에서 벗어날 때마다 코드를 실행하거나 세션 종료 콜백으로 사용하는 데 사용할 수 있습니다.
이 이벤트가 가장 많이 사용된 시나리오는 다음과 같습니다.
- 사용자 데이터 저장: 페이지를 나가기 전에 데이터를 저장합니다.
- 정리 작업 수행: 페이지를 닫기 전에 열려 있는 리소스를 닫습니다.
- 분석 전송: 세션 종료 시 사용자 상호작용과 관련된 데이터를 전송합니다.
하지만 unload 이벤트는 매우 불안정합니다.
데스크톱 Chrome 및 Firefox에서 unload는 비교적 안정적이지만 bfcache (뒤로-앞으로 캐시) 사용을 차단하여 사이트 성능에 부정적인 영향을 미칩니다.
모바일 브라우저에서는 탭이 자주 백그라운드로 전환되었다가 종료되므로 unload가 실행되지 않는 경우가 많습니다. 이러한 이유로 브라우저는 unload보다 모바일의 bfcache에 우선순위를 두기 때문에 더욱 불안정해집니다. Safari도 데스크톱에서 이 동작을 사용합니다.
Chrome팀은 데스크톱에서 unload보다 bfcache에 우선순위를 두는 모바일 모델을 사용하면 Chrome (및 Firefox)에서 bfcache의 안정성이 크게 향상되어 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를 열고 Application으로 이동합니다. 백그라운드 서비스 > 뒤로-앞으로 캐시.
뒤로-앞으로 캐시 테스트를 클릭하면 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 핸들러를 사용 설정하거나 사용 중지하여 예정된 지원 중단에 대비할 수 있도록 핸들러 없이 사이트가 어떻게 작동하는지 테스트할 수 있습니다. 정책에는 다음과 같은 여러 유형이 있습니다.
- 권한 정책: 사이트 소유자가 HTTP 헤더를 사용하여 사이트 또는 개별 페이지 수준에서 기능에 대한 액세스를 제어할 수 있는 플랫폼 API입니다.
- 엔터프라이즈 정책: IT 관리자가 조직이나 비즈니스를 위해 Chrome을 설정하는 데 사용하는 도구입니다. Google 관리 콘솔과 같은 관리 패널을 통해 구성할 수 있습니다.
- Chrome 플래그: 개별 개발자가
unload지원 중단 설정을 변경하여 다양한 사이트에 미치는 영향을 테스트할 수 있습니다.
권한 정책
사이트에서 unload 핸들러 사용을 선택 해제하고 bfcache를 즉시 활용하여 사이트 성능을 개선할 수 있도록 Chrome 115에 권한 정책이 추가되었습니다. 사이트에서 이를 설정하는 방법의 예를 참고하세요. 이렇게 하면 사이트가 unload 지원 중단에 한발 앞서 대비할 수 있습니다.
이 기능은 Chrome에서 향후 실행되지 않도록 기본값이 변경됨에 따라 사이트에서 unload 핸들러를 계속 실행하고 이 핸들러를 계속 실행하도록 선택할 수 있도록 Chrome 117에서 확장될 예정입니다. 사이트에서 로드 취소 핸들러가 실행되도록 계속 허용하는 방법의 예를 참고하세요. 이 선택은 영구적으로 유지되지 않으며 사이트가 unload 핸들러에서 이전할 때까지 기다리는 데 사용해야 합니다.
기업 정책
unload 이벤트에 의존하여 올바르게 작동하는 소프트웨어를 사용하는 기업은 ForcePermissionPolicyUnloadDefaultEnabled 정책을 사용하여 관리 대상 기기의 점진적인 지원 중단을 방지할 수 있습니다. 이 정책을 사용 설정하면 unload이(가) 모든 출처에 대해 기본적으로 사용 설정된 상태로 유지됩니다. 원한다면 페이지에서 더 엄격한 정책을 설정할 수도 있습니다. 권한 정책 선택 해제와 마찬가지로 이 도구는 잠재적인 브레이킹 체인지를 완화하기 위한 도구이지만 무기한으로 사용해서는 안 됩니다.
Chrome 플래그 및 명령줄 스위치
엔터프라이즈 정책뿐만 아니라 Chrome 플래그 및 명령줄 스위치를 통해 개별 사용자의 지원 중단을 사용 중지할 수 있습니다.
chrome://flags/#deprecate-unload를 enabled로 설정하면 지원 중단 기본값이 적용되고 unload 핸들러가 실행되지 않습니다. 권한 정책을 통해 사이트별로 계속 재정의할 수 있지만 기본적으로 계속 실행됩니다.
이 설정은 명령줄 스위치로 제어할 수도 있습니다.
옵션 비교
다음 표에는 앞에서 설명한 옵션의 다양한 용도가 요약되어 있습니다.
| 지원 중단 추진 | 지원 중단 예정 (예외 있음) | 마이그레이션 시간을 확보하기 위해 지원 중단을 방지하세요. | |
|---|---|---|---|
| 권한 정책 (페이지/사이트에 적용) |
예 | 예 | 예 |
| 엔터프라이즈 정책 (기기에 적용) |
아니요 | 아니요 | 예 |
| Chrome 플래그 (개별 사용자에게 적용) |
예 | 아니요 | 아니요 |
| Chrome 명령줄 스위치 (개별 사용자에게 적용) |
예 | 아니요 | 예 |
결론
unload 핸들러가 지원 중단됩니다. 오랫동안 불안정한 상태로 유지되어 왔으며 문서가 폐기되는 모든 경우에 반드시 실행되지는 않습니다. 또한 unload 핸들러는 bfcache와 호환되지 않습니다.
현재 unload 핸들러를 사용 중인 사이트는 기존 unload 핸들러를 테스트하거나, 핸들러를 삭제 또는 이전하거나, 시간이 더 필요한 경우 지원 중단을 연기하여 예정된 지원 중단에 대비해야 합니다.
감사의 말씀
이 기사를 검토하는 데 도움을 주신 켄지 바후, 퍼갈 달리, 아드리아나 하라, 제레미 와그너에게 감사의 인사를 전합니다.