원글 페이지 : 바로가기
Webpack 마이그레이션을 진행하면서, 사이드 이펙트를 발생시키지 않고 소스 코드의 구조 변경을 최소화하는 최적화에 대해서 고민을 하며, 어떤 최적화를 할 수 있을까 하다 ‘패키지 최적화’를 진행하기로 선택하였다. 번들링의 방식과 구조를 변경하면서 사이즈를 축소시키고, 웹 페이지 리소스 로딩 속도 개선을 충분히 할 수 있었기 때문이다. 사실, 렌더링 최적화와 로직 최적화는 기존 레거시 구조에서 변경시키는데 상당히 많은 변화를 발생시키기 때문에 선택할 여지가 없었기도 한다. 번들링 사이즈 측정은 webpack-bundle-analyze로 하였고, Chrome의 Network 기능과 Lighthouse를 통하여 측정하였다. 측정결과 [webpack-bundle-analzye] Parsed Size: 10.18MB -> 4.5MB 감소 (-55.8%) 위 분석 결과에 나타나는 Stat, Parsed, Gzipped Size 옵션의 의미는, 세가지 옵션 모두 번들 사이즈의 측정 기준으로 Stat은 빌드된 그대로의 상태, Parsed는 웹팩이 트리셰이킹을 마친 결과물, Gzipped는 결과적으로 서빙을 위해 압축된 사이즈이다. Parsed 사이즈를 줄이면 자연스레 Gzipped은 비례하여 줄어듦으로 Parsed size 줄이기를 기본으로 시도하는 것이 좋다고 한다. 패키지 사이즈에 큰 영향을 주는 번들을 일부 개선하는 작업을 했다. 특히, ‘moment-timezone’ 라이브러리가 아주 큰 사이즈를 갖고있었기 때문에 이 라이브러리 중 필요한 정보만 사용하여 전체 번들 사이즈를 크게 줄였다. => 2.26MB -> 38.81KB (-98%) 또한, 사용하지 않는 전체 라이브러리를 삭제하여 개선하였다. 사실, 더 좋은 개선을 하기 위해서는 moment.js 라이브러리를 day.js 라이브러리로 전환하여 번들 사이즈를 최소화하고, 일부 사용하는 모듈들을 가져와 적용하는 등 라이브러리들을 대체하거나 더 나은 최적화를 하는 것이지만, 프로젝트 목적 상, 내부 히스토리 문제로 인하여 이 부분은 진행 할 수 없었기 때문에 매우 아쉬운 부분이었다. 또한, 웹팩의 Optimization(최적화) 기능을 통하여 많은 번들 사이즈를 개선했다. splitChunk를 통하여 동일한 모듈의 chunk가 중복해서 각 번들에 포함되는 것을 방지하고 공통된 부분의 모듈을 별도의 파일로 추출한 벤더를 만들어 최적화를 수행하도록 하였다. 이를 통하여 많은 사이즈를 감소시켰다. [Chrome Network / Lighthouse] DomContentLoaded: 평균 7초대 -> 4초대 (-40% 감소) FIP (First Contentful Paint): 평균 1.7초 -> 평균 1.4초 (-17% 감소) 전체 번들 사이즈를 감소 시키고, webpack 4의 SplitChunk 기능과 Minify Plugin 기능을 통하여 더 나은 성능을 보여주게 되었다. SplitChunk를 통해, 공통된 모듈을 별도의 파일로 추출한 벤더를 생성하기 때문에 초기에 용량이 -60% 이상 작아진 main js파일 (app.js)을 다운로드 받는 시간을 줄이게 되었다. 또한, Minify Plugin은 Uglify -> Terser Plugin으로 변경하였다. Terser는 UglifyJS에 비해서 꾸준한 유지 보수를 하고 있으며 압축율은 비슷하면서도 최대 3배 이상의 매우 빠른 압축속도를 보여주며 webpack 공식문서에서도 소개되고 있다. [출처] https://company.wingeat.com/story/?idx=12871881&bmode=view 번들 시스템 마이그레이션 결과 결과적으로, webpack 3를 webpack 4로 업그레이드 하는데 성공했고, 자바스크립트를 제외한 모든 파일들을 gulp task로 진행하는 빌드 시스템에서 webpack으로 통합 마이그레이션에 하는데 성공했다. 가능한 범위 내에서 최적화도 진행하였고 특히, 개발 중 HMR 기능을 사용할 수 있는 것이 만족도가 높았다. 더 이상 gulp watch를 통하여 개발 중 수정사항 반영을 하지 않아도 되고, 개발 중 gulp build를 한 이후에 local에서 시작할 필요도 없어졌다. 다만 아쉬운 점도 많다. 사실 더 높은 수준의 개선을 위해서는 TTI (Time To Interactive)에 도달하는 시간을 앞당겨야 UX에서 큰 의미가 있는 최적화 개선이라고 할 수 있을 것 같다. 이를 위해서는 Light house의 LCP (Largest Contentful Paint) 수치를 높여야 하는데 현재 구조상, 매일 이벤트가 진행이 되어 이미지가 모두 자주 바뀌고 이미지는 다른 구조로 불러와 자동화가 되어 있는 시스템이기 때문에 개선하기가 어려웠다. 사실, 프론트엔드의 고도화는 webpack5, next … 점진적으로 고도화 될 것이기 때문에 리스크를 감수하면서까지 최적화를 할 수 없는 상황이기도 하다. 너무 재밌고 유의미한 경험이었다! [출처] https://velog.io/@bluestragglr/%EC%89%BD%EA%B2%8C-%EB%94%B0%EB%9D%BC%ED%95%98%EB%8A%94-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EC%9B%B9-%EC%96%B4%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%ED%8C%A8%ED%82%A4%EC%A7%80-%EC%B5%9C%EC%A0%81%ED%99%94 쉽게 따라하는 프론트엔드 웹 어플리케이션 패키지 최적화 본 포스트는 Next.js 기반 프로젝트의 트리셰이킹 진행 과정을 따라할 수 있도록 설명과 함께 정리한 글입니다. 비록 가능한 모든 최적화를 진행하지는 못했지만, 방법의 문제는 아니었으며 결과 velog.io https://medium.com/myrealtrip-product/fe-website-perf-part1-6ae5b10e3433 마이리얼트립 웹사이트 성능 측정 및 최적화 Part 1. 리소스 로딩 여행 경험을 돕는 웹사이트 가꾸기 medium.com https://company.wingeat.com/story/?idx=12871881&bmode=view 윙잇 FE 개발 및 빌드 환경 개선기 (feat. Webpack) : 스토리 – 윙잇 FE 개발자들은 ECMA Script의 최신 문법들을 사용할 수 있게 되었답니다. 안녕하세요, 윙잇 개발팀 커뮤니티셀 프론트엔드 개발자 김우조입니다.최근 윙잇 개발팀의 규모가 커지면서 더욱 탄탄한 company.wingeat.com