같은 용량이더라도 이미지는 파일을 다운로드한 후 디코딩만 하면되지만 JS를 실행하기위해서는 위와같이 작업단계가 많으므로 JS 실행이 이미지 로딩보다 오래걸리게된다.
브라우저에서 JS실행을 최적화 하기위해서 번들 최적화는 매우 중요하다.
1. 원인 찾기
Webpack을 기준으로 Bundle 분석 도구로는 Webpack Analyse, Webpack Visualizer, Webpack Bundle Analyzer 3개가 있다.
Webpack Bundle Analyzer가 용량별로 시각화를 해주기때문에 어떤 라이브러리가 많이 사용되고 있는지 알 수있고 사이드바를 이용해 검색과 필터링도 가능하다사용하기 쉽고 기능이 좋다.
같은 라이브러리이지만 버전이 다른경우
npm이 dependency conflict를 해결하는 특성때문이다. npm은 라이브러리간 관계를 검색하고 필요한 라이브러리를 다운받는다. 이 때 dependency가 같은 라이브러리를 참조하지만 이 라이브러리의 버전이 다르다면 해당 버전을 모두 설치한다. 각 library별로 가상 환경의 node_modules를 이용하기 때문에 충돌이 없다.
browserfy는 직접 사용자에게 어떤 버전을 설치할지 물어본다.
node_modules의 용량이 과도하게 커질 수 있다.
2. 라이브러리 중복 줄이기
node_modules의 용량이 과도하게 커지는 문제를 해결하기위해 npm은 라이브러리들이 시멘틱버전(semver)을 지킨다고 가정한다. major 버전이 바뀌지 않는한 더 높은 버전을 사용해도 문제가 생기지 않는다고 가정
npm dedupe 명령어로 중복된 모듈을 지워준다.
특정 라이브러리가 다양한 버전의 라이브러리가 있다면 webpack의 resolve.alias기능을 이용하여 특정 라이브러리만 사용하도록한다.
lodash와 같은 라이브러리에는 다양한 라이브러리가 있다는 것이다. (lodash-es, lodash.get, lodash.isPlainObject, ...)
사용자가 특정 section을 보고있는지(intersecting)의 여부가 바뀔때마다 observe callback funtion이 실행된다
현재 intersecting 여부는 entry.isIntersecting의 true/false값으로 판별한다.
observer : 특정 node를 observe하는 observer 자기 자신의 instance.
options
options없이 기본적인 intersection observer는 viewport안에 node의 변화가 있을때마다 callback 함수를 실행시키기 때문에 무거운 감이 있다. 이를 해결하기위해 options를 사용한다.
root: intersecting 영역을 지정한다. observer를 동작시키기 위해서는 당연히 타겟의 조상 node element여야한다. default는 { root: null; } 이다. 이는 브라우저의 viewport를 intersecting 영역으로 삼겠다는 것이다.
threshold: section이 root element 기준 얼마 비중으로 들어와야 callback 함수를 실행할지 설정한다. 0~1의 값을 가진다.
rootMargin : root element안에서 intersecting 영역의 범위(px)를 설정한다. default는 0이다. "-150px" 이라면 현재 intersecting중인 페이지에서 동서남북 각각 안쪽으로 150px씩 움직인 범위안에서 intersecting여부를 찾게 된다.
lazy loading
그럼 이제 사용자가 특정 이미지를 intercept중일때만 해당 image를 로드하도록 lazy loading을 구현해보자
