-
질문 & 답변
카테고리
-
세부 분야
프론트엔드
-
해결 여부
미해결
번들링 후 가져오는 파일의 용량에 대해서
21.03.31 08:39 작성 조회수 120
1
안녕하세요 강사님 강의 잘 듣고있습니다. 코드 스플리팅에 대해서 궁금한 점이 생겨서 질문을 남기게 되었습니다.
제가 이해한 바로는 웹팩에 의해 번들링된 파일이 너무 무거워지면 가져오는데 오랜시간이 걸리니 필요할 때 가져오는 방식으로 React.lazy를 사용해 Code splitting을 사용하는 것을 이해했습니다.
그래서 저는 같은 페이지면 js파일을 가져올 때 분리되어 조금 용량이 작아진 js 파일을 가져올 것이라고 예상을 했는데 splitting 전이나 후나 같은 용량의 파일을 여러개 가져오는 것을 보고 이상하다는 생각이 들었습니다. 이게 올바른 상황인건가요?
첫번째 사진이 splitting 전
두번째 사진이 splitting 후 입니다.
답변을 작성해보세요.
6
유동균
지식공유자2021.03.31
안녕하세요 이상훈님,
코드 분할 이후, 번들 파일들의 사이즈가 이상하다는 질문을 주셨는데요.
올려주신 이미지의 Size 항목을 보시면 202 바이트로 굉장히 작은 사이즈인 것을 확인하실 수 있습니다.
(현실적으로 번들 사이즈가 아무리 작아도 바이트 단위로 작아지기는 힘들죠?)
즉, 번들 파일을 그대로 로드한 것이 아니라 캐시되어 있는 번들 파일을 로드하다 보니 네트워크 상에서 찍힌 사이즈는 작은 것처럼 보이는 것 뿐입니다.
상태 코드를 보시면(Status) 304로 찍혀있는게 보이는데요, 304는 Not Modified의 의미(https://developer.mozilla.org/ko/docs/Web/HTTP/Status/304)로 로컬에 해당 리소스에 대한 캐시가 있고 서버에서 파일이 변경되었는지 확인했을 때, 캐시 리소스와 서버 리소스가 다르지 않다는 의미입니다. (즉, 캐시 리소스가 최신이라는 얘기) (만약 서버에서 코드에 수정사항이 있어서 번들이 바뀌었다면, 로컬의 캐시와 일치하지 않으므로 304 응답이 아닌 변경된 리소스를 정상적으로 전송해줍니다.)
브라우저는 304 코드를 받으면 캐시 리소스가 최신이라는 것을 알 수 있으므로 캐시되어 있는 리소스를 그대로 사용합니다.
물론 캐시 방식에도 종류가 있어 서버에 확인 없이 데이터를 그대로 사용하는 방식도 있지만(이런 경우 Size 항목에 캐시를 사용한다는 표시가 뜹니다.), 이상훈님께서 돌리신 서비스(아마 react-dev-server?)는 최신상태인지를 확인한 후, 캐시를 사용하는 방식일 것으로 생각됩니다.
때문에 캐시된 리소스 임에도 네트워크 리소스에 202B가 잡힌 이유는 서버에 캐시가 최신인지를 확인하는 로직 때문입니다.
캐시에 영향 없이 네트워크 상태를 확인하시고 싶다면, 네트워크 탭에서 "Disable cache" 옵션을 선택해주시면 됩니다.
정리하면,
위 현상은 캐시 때문에 발생하는 현상으로 캐시를 비활성화 해주시면 정상적으로 확인하실 수 있습니다.
캐시에 대한 내용은 현재 준비 중인 파트2 강의에서 나오니 나중에 참고하면 좋을 것 같습니다. :)
답변이 도움되었기를 바라며, 강의에 관심을 가져주셔서 감사합니다.
1
답변 2