원문: WebKit Page Cache I – The Basics
WebKit Page Cache I – The Basics
This is the first of two posts that will center around a modern browser engine feature that doesn’t usually get a lot of press: The Page Cache.
webkit.org
이 포스트는 페이지 캐시에 대한 두 포스트 중 첫번째 포스트입니다. 페이지 캐시는 일반적으로 관련해서 많이 포스팅되지 않는 모던 브라우저 브라우저 기능입니다.
오늘 저는 이 기능이 무엇인지, 왜 종종 동작하지 않는지, 그리고 이를 개선하기 위해 어떤 계획을 세워야 하는지에 대해 이야기하려고 합니다.
페이지 캐시의 개요 Page Cache Overview
다른 브라우저에서의 페이지 캐시(Page Cache)의 명칭에 대해 더 친숙한 사람들도 있을 것입니다. 파이어폭스(Firefox)는 "Back-Forward Cache" 혹은 "bfcache"라고 부릅니다. 오페라(Opera)는 "Fast History Navigation"이라고 부릅니다. 웹킷에서는 최근에 "Back/Forward List"와의 혼동을 줄이기 위해 "Page Cache"라고 부르기 시작했습니다.
페이지 캐시는 웹 탐색을 훨씬 더 원활하게 해 주는 엔드 유저 기능입니다. "HTTP 의미"의 "캐시"가 아닙니다. 물리적 리소스가 로컬 디스크에 저장되는 "디스크 캐시" 의미의 "캐시"도 아닙니다. 또한 WebKit이 중복된 리소스를 메모리에 저장해서 여러 웹 페이지 간에 공유하는 전통적인 "메모리 캐시"측면에서는 "캐시"가 아닙니다.
그래서... 정확히 무엇일까요?
빠르고 간단하게, 페이지 캐시는 당신이 페이지를 떠날 때 "일시정지" 버튼을 누르고, 페이지로 돌아왔을 때 "재생" 버튼을 누릅니다.
사용자가 링크를 클릭하여 새 페이지로 이동하면 이전 페이지가 완전히 버려지는 경우가 많습니다. DOM이 삭제되고, Javascript 객체는 가비지 콜렉팅되며, 플러그인은 해제되고, 디코딩 된 이미지 데이터가 삭제되며, 모든 종류의 정리가 발생합니다.
위의 일들이 발생하고, 사용자가 나중에 뒤로 가기 버튼을 누르면 고통스러울지도 모릅니다. WebKit는 네트워크를 통해 리소스를 다시 다운로드 받고, 기본 HTML파일을 다시 파싱하고, 페이지를 동적으로 설정하기 위해 스크립트를 재실행하고, 이미지 데이터를 다시 디코딩하고, 페이지 레이아웃을 다시 정렬하고, 올바른 위치로 다시 스크롤하고, 화면을 다시 그려야 할 수 있습니다. 이 모든 작업에는 시간, CPU 사용량, 배터리 전원이 필요합니다.
대신 이상적으로, 이전 페이지는 Page Cache에 있을 수 있습니다. 전체 활성(live) 페이지는 스크린에 있지 않아도 메모리에 저장됩니다. 즉, 화면에 표시되는 모든 다양한 비트와 조각들과 인터렉션 하는 방법들이 파괴되는 대신에 일시 중지 됩니다. 그런 다음 뒤로가기 버튼을 클릭할 경우 나중에 다시 활성화할 수 잇습니다.
왜 이게 중요한가요? Why is This Important?
페이지 캐시가 작동하면, 뒤로가기 버튼을 클릭하는 거의 즉시 실행됩니다.
검색 하고, 검색 결과를 클릭한 다음에, 뒤로 돌아가기를 누르면 즉시 정확히 똑같은 검색 결과 페이지를 볼 수 있습니다. Reddit이나 Digg같은 집계 사이트(aggregator site)를 탐색할 수 있으며, 동일한 탭에서 여러 다양한 링크를 빠르게 볼 수 있습니다. 이미지 갤러리를 탐색하고 "뒤로", "앞으로"를 빠르게 클릭하여 두 이미지를 비교할 수 있습니다. 또는 단순히 잘못된 링크를 클릭한 실수를 고치기 위해 되돌아가려고 할 수도 있습니다.
언제든지 당신이 뒤로가기 버튼이나 앞으로가기 버튼을 클릭하면 당신이 모르게 페이지 캐시가 함께할 것입니다. 페이지 캐시를 사용될 때, 사용자가 그 뒤에 숨겨진 마법을 모르더라도 행복합니다.
반대로 페이지 캐시를 무시하면, 사용자는 일반적으로 브라우저와 웹 모두에 대해 불만을 느낍니다.
왜 작동하지 않을까요? Why Wouldn’t it Work?
그래서 페이지 캐시가 그렇게 놀라운데, 왜 Webkit은 새 페이지를 탐색할 때 항상 페이지 캐시를 사용하지는 않는 걸까요?
그 질문에 대한 몇가지 메인 답변을 드리겠습니다.
어떤 페이지는 관심이 없습니다 Some Pages aren’t Interesting
우선, 가끔은 완전히 똑같은 상태로 이전으로 돌아가는 것에 관심이 없기 때문에 페이지를 캐싱할 의미가 없습니다. 예를 들면, 페이지가 아직 로딩을 끝마치지 않았을 수도 있습니다. 혹은 로딩 중에 에러가 발생했을 수도 있습니다. 혹은 해당 페이지가 사용자를 자동으로 어떤 새로운 URL로 이동하기 위한 리다이렉션 페이지일 수도 있습니다.
이러한 케이스는 Webkit에서 현재의 페이지 캐시로 만족하는 경우입니다.
어떤 페이지는 복잡합니다 Some Pages are Complicated
둘째로, 페이지가 페이지 캐시를 고려하지 않았을 수도 있습니다. 페이지 캐시가 어떻게 "일시 정지"를 해야하는지 알아내기 어렵기 때문입니다. 이것은 흥미로운 일을 하는 더 복잡한 페이지에서 일어납니다.
예를 들면, 플러그인이 원하는 모든 작업에 대한 네이티브 코드를 포함하고 있어서, Webkit은 "일시 정지 버튼을 누를 수" 없습니다. 다른 예시로는 페이지가 Webkit이 이전에 캐시하지 않은 여러 프레임을 가지고 있을 수 있습니다.
(복잡해서 페이지 캐시를 적용하기는) 어렵지만, 이러한 고급 페이지를 탐색할 때가 페이지 캐시의 이점을 최대한 활용할 수 있을 때입니다.
어떤 페이지는 안전합니다 Some Pages are Secure
HTTPS 사이트의 서버 관리자는 종종 특정한 보안 문제를 겪고 있으며, 브라우저의 작동 방식에 대해 아주 민감합니다. 예를 들어, 금융 기관들은 종종 고객을 사용하도록 허용 하기 전에 각각의 특정 브라우저의 동작을 철저하게 확인합니다.
주로 초점이 맞춰지는 영역 중 하나는 뒤로/앞으로 가는 동작입니다. 이러한 기관은 사용자가 이동할 때 브라우저에 남아 있는 데이터의 유형에 대해 (당연히) 매우 까다롭습니다. 따라서 극도로 주의를 기울이기 위해 WebKit는 처음부터 모든 HTTPS사이트에 페이지 캐시를 허용하지 않았습니다.
좀 더 세분화 된 접근방법은 사용자 경험을 개선하는 데 크게 도움이 될 수 있습니다.
계획 중인 개선 사항 Planned Improvements
분명히 우리가 처리하지 않는 중요한 케이스가 있으므로 개선할 여지가 많이 있습니다.
WebKit의 페이지 캐시는 최초의 Safari 베타 릴리즈 이전인, 2002년에 작성되었습니다. 2002년 당시 웹 환경과 당시의 Webkit 아키텍처 둘 다 반영했습니다.
2009년의 웹은 매우 달랐기 때문에, 우리는 페이지 캐시를 동급으로 올려야 합니다. 다행히도 이 작업은 잘 진행되고 있습니다.
예를 들어, 48036 개정판에서 주요한 제한 사항들이 완화되었고, 프레임이 있는 페이지도 페이지 캐시에 배치됩니다. 최신 Webkit Nightly를 이용하여 검색할 때 이유는 딱 꼬집어 말할 수 없지만 항상 "빠르다고 느끼는" 것 같습니다. 그리고 몇 사용자들은 최근에 이 기능 향상을 경험 했을 수도 있습니다.
하지만 해야 하는 일이 더 많습니다.
우리의 요주의 리스트(hit list)에서 다음으로 큰 것은 플러그인입니다. 앞서 언급했듯이 플러그인은 원하는 네이티브 코드를 실행할 수 있기 때문에 "일시 중지"버튼을 신뢰할 수 없습니다.
이전 버전의 Webkit에서는 몇가지 종류의 플러그인이 있는 단일 프레임 페이지를 처리했습니다. Webkit은 사용자가 떠날 때 플러그인을 해제하고, 사용자가 돌아왔을 때 복원했습니다. 그러나 더 빠르고 쉽게 포팅 할 수 있도록 WebCore에 대한 작업이 계속되면서 이 기능이 손실되었습니다.
Bug #13634 에서 모든 페이지의 모든 플러그인에 대해서 이 작업을 수행하는 것에 대해 이야기 되고 있습니다.
그리고 HTTPS 페이지가 있습니다. 지금은 모두 금지하고 있지만, 좀 더 선택적인 접근법은 사용자에게 이점을 주는 것 뿐 아니라, 보안에 민감한 기관에도 만족을 줄 수 있어야 합니다.
Bug #26777 에서 "cache-control:no-store" 혹은 "cache-control: no-cache"가 응답헤더에 포함되어있지 않는 경우, HTTPS 페이지 캐시를 허용하는 것에 대해 이야기 되고 있습니다.
다른 아이디어나, 개선해야 할 사항이 있다면 언제든지 적절한 버그에 대해 의견을 제시하거나, 새로운 버그를 등록하세요!
Unload 핸들러 Unload Handlers
unload 이벤트 핸들러가 있는 페이지에 대해서 아직 언급하지 않았는데요.
unload 이벤트는 사용자가 페이지를 닫을 때 페이지가 몇 가지 정리 작업을 수행하도록 설계되었습니다.
브라우저는 페이지를 페이지 캐시에 배치하기 전에는 unload 이벤트를 발생시킬 수 없습니다. 페이지가 터미널 상태에 있다고 가정하고 중요한 부분을 파괴 할 수 있기 때문입니다. 이것은 페이지 캐시의 목적을 완전히 상실합니다.
그러나 브라우저가 unload 핸들러를 실행하지 않고 페이지를 페이지 캐시에 배치하면 페이지가 "일시 중지"되어 숨겨져있는 동안 브라우저에 의해 페이지가 손상 될 수 있으며 정리 작업 (매우 중요 할 수 있음)은 절대 발생하지 않습니다.
unload 이벤트의 목적은 "페이지를 닫을 때 중요한 작업"을 허용하는 것이므로, 모든 주요 브라우저는 해당 페이지를 페이지 캐시에 넣기를 거부하여 사용자 경험에 직접적인 부정적인 영향을 미칩니다.
앞으로의 포스트에서 unload 이벤트 핸들러에 대해 더 이야기 할 것이고, 실제로 많은 웹 개발자에게 숙제가 있을 것입니다! 채널 고정...
2009년 글이라서, 위에서 언급한 계획 중인 개선사항은 개선 된 것으로 보입니다.