현재 이 글은 Webpack bundle 사이즈 최적화 - (2) 의 시점 바로 다음에 최적화 했던 부분인데.. 현생이 바쁘단 이유로 글 써야지 써야지.. 만 반복하고 미루어 왔다가 지금 적게 되었습니다. 최근 회사 본부에서 사이트에 서비스를 런칭한 이 후 본부적으로 제가 담당하였던 캘린더 모듈의 초기 로딩 속도 및 렌더링 속도가 빠르다는 얘기를 듣게 되었습니다. 이에 본부 FE 연구원들에게 제가 적용하였던 부분에 대해 공유하는 자리가 있게 되었고 그에 따라 이 글을 적게 되었습니다. 오늘의 주제는 간단하게 코드 스플리팅 입니다. 지난 글 회고] 지난 포스트에서는 lighthouse와 관련해서 font 최적화 부분들과 (물론 CDN 부분은 추후에 적용 되었지만 누락 되어있는 부분), webpack 설정의 production 모드에 대해 글을 적었습니다. 기본적으로 앞서 설명하였던 production 모드를 통해서 번들링 사이즈를 줄이고, minify 및 compre

최근상황 요즘은 회사에서 캘린더를 담당하고 있다. 캘린더 모듈을 슈퍼앱 환경 앱스토어에 등록하고, 여러 유저가 사용할 수 있도록 하는 과정을 진행하였다. 웹팩 최적화나 lighthouse 같이 이론상으로만 알고는 있었지만 적용해보지 못한 것을 해보았던 경험을 적어 본다. LightHouse 확인 그간 개발과 기능 추가에만 열중한 탓에 개발된 환경이 얼마나 최적화 되어있을지 확인해보지 못하였어서 local환경에서 크롬의 lighthouse를 확인해 보았다. > 이럴수가.. perfomance 환경이 31점이라는