bfcache란 js heap까지 포함하여 페이지 전체를 다 캐시로 저장한다. 고로 전체 페이지의 정보가 메모리에 저장되어 있기 때문에 사용자가 이전 페이지로 복귀했을 때, 메모리에 저장된 정보를 노출하여주고, 결론적으로 빠른 페이지 로드가 가능하다. bfcache 동작 방식 페이지 전체(heap 포함)를 스냅샷을 떠 메모리에 올린다. ( 이와 반대로 HTTP 캐시는 단순 이전 요청에서 이루어진 응답만 캐싱하기 때문에 둘의 동작 방식은 조금 다르다) 모든 페이지를 스냅샷 뜨기 때문에 bfcache는 항상 빠르다. 만약 setTimeout 등의 함수가 동작하는 경우에는 어떻게 될까? task queue에 있는 모든 작업을 일시정지하고, 페이지가 복원되었을 때 해당 작업을 재실행한다. (개인적으로 이게 항상..
프론트앤드 개발자라면 아마 높은 확률로 사파리 브라우저를 좋아하지 않을거라 생각이 든다. 혹은 크롬을 좋아하지 않거나. 아무튼 두 개를 동시에 좋아할 수는 없다. 왜냐면 둘은 함께 할 수 없으니까! 개발을 하며, 브라우저 호환성에 대해 고민해보지 않은 개발자는 없을것이다. (만약 고민한 적이 없다면 반성해야 할 일..!) 그 차이 중 하나가 바로 bfcache이다. bfcache란 Back-Forward Cache로 사파리나 파이어폭스에서 이전 페이지를 빠르게 로딩하기 위해 스냅샷을 떠서 기억하고 있는 시스템이라고 생각하면 된다. (크롬에서는 96버전 이후부터 사용이 가능하다.) 이게 어떤 장점이 있는지 명확하게 보여주는 아주 좋은 유튜브를 찾았다. https://youtu.be/cuPsdRckkF0 크..
- Total
- Today
- Yesterday
- react
- 크롬
- 센트리모니터링
- 리액트
- 자바스크립트
- js
- gitRebase
- 프론트앤드
- sentry
- reacthook
- npm
- TIL
- storybookUI
- 사파리
- 깃
- 리액트상태관리
- js테스트
- 깃명령어
- 센트리
- 프론트엔드
- Git
- vue
- 모바일사파리
- 김민태
- javascript
- BFCache
- 리코일
- frontend
- CSS
- 리액트훅
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |