코드 캐싱 (Code Caching)
지난 몇 년간 JS 관련 비용의 가장 주목할 만한 변화는 브라우저의 스크립트 파싱 및 컴파일 속도가 크게 향상되었다는 점이다.
2024년 기준으로 파싱과 컴파일 비용은 더 이상 과거 만큼 느리지 않다.
구글의 JS 엔진 V8의 원시 JS 파싱 속도는 크롬 60 이후로 계속 빨라졌으며, 크롬의 다른 최적화들로 인해 원시 파싱 및 컴파일 비용은 덜 가시적이고 덜 중요해지게 되었다.
V8에서는 메인 스레드의 파싱과 컴파일양이 평균 40% 줄었고, 워커 스레드로 하여금 이를 수행 하게 했다.
이것은 기존의 오프-메인-스레드 스트리밍 파싱 및 컴파일에 추가 된다.
V8은 메인 스레드를 중지시키지 않고 JS를 파싱 및 컴파일 할 수 있다.
이는 이전 버전의 크롬은 스크립트 전체를 다운로드한 뒤 파싱 한 것에 비해 눈에 띄게 개선된 것이다.
#정의
코드 캐싱 (바이트코드 캐싱이라고도 함)은 브라우저에서 중요한 최적화 기능이다.
파싱 및 컴파일 결과를 캐싱하여 자주 방문하는 췝 사이트의 시작 시간을 단축한다.
#동작
1. 콜드 런 - 처음 방문
- 사용자가 웹 사이트에 처음 접속
- Chrome은 웹 사이트에 필요한 리소스 (예: ./code/sample/js) 다운로드
- V8엔진에 리소스를 넘겨 컴파일 및 원본 ./code/sample/js 파일을 브라우저 캐시(디스크 캐시)에 저장
2. 웜 런 - 두 번째 방문
- 사용자가 다시 웹 사이트에 접속
- Chrome은 웹 사이트에 필요한 리소스를 브라우저 캐시에서 바로 읽음 (다운로드 x)
- V8엔진에 리소스를 넘겨 컴파일 및 원본 ./code/sample/js 파일 + 바이트 코드(컴파일 결과)를 브라우저 캐시에 저장
3. 핫 런 - 세 번째 이후 방문
- 사용자가 다시 웹 사이트에 접속
- 원본 ./code/sample/js + 바이트 코드(컴파일 결과)가 있기 때문에 V8엔진은 역직렬화 해서 바로 실행 가능 (컴파일 과정을 건너 뛴다.)
쉽게 이해하기 위해 비유를 해보면.
첫번째 책을 처음부터 읽기 → 두번째 책 읽을 때 요약 정리 → 세번째 책 읽을 때 요약 정리만 읽고 바로 이해
참고)
대규모 리액트 웹 앱 개발 서적