지난 15년 동안 JavaScript 생태계는 개발을 더 쉽게 해주는 수많은 도구를 도입하면서 빠르게 확장되었습니다. 그러나 이러한 도구에는 번들 크기 증가라는 비용이 발생합니다. 실제로 HTTP Archive의 데이터에 따르면 페이지당 전송된 평균 JavaScript 양이 2010년 90KB에서 2024년 650KB로 급증했습니다(출처).
압축 기술의 채택이 증가하고 발전하고 있음에도 불구하고 이러한 추세는 둔화될 기미를 보이지 않습니다. 기능을 계속 추가하는 동안 JavaScript를 어떻게 더 적게 출시할 수 있을까요?
라는 과제가 남아 있습니다.이상하게도 해결책은 쉽고도 어렵습니다. 쉬운 부분은 빠른 승리를 가져올 수 있는 프로젝트 수준의 조정입니다. 어려운 부분은 지속적인 영향을 미치는 것입니다. 이를 위해서는 번들러, 라이브러리 및 도구를 개선하기 위해 커뮤니티 전체의 변화가 필요합니다.
이 문서에서는 다음 내용을 포함하여 프로젝트에 실행 가능한 개선 사항을 중점적으로 다룹니다.
향후 기사에서는 생태계 전반에 걸쳐 우리가 할 수 있는 개선 사항을 다룰 예정이지만, 지금은 이러한 요소가 번들의 비대화에 어떻게 기여하는지, 그리고 이를 관리하는 방법을 다루도록 하겠습니다.
JavaScript는 최신 웹 상호작용의 엔진이지만 무료는 아닙니다. JavaScript는 브라우저가 처리해야 하는 가장 계산 비용이 많이 드는 리소스입니다. 번들이 커지면 렌더링을 차단하고 전반적인 성능이 저하될 수 있으므로 페이지가 빠른지 느린지 여부를 결정하는 것은 병목 현상인 경우가 많습니다.
JavaScript 번들의 크기가 클수록 로드, 구문 분석, 컴파일 및 실행에 더 오랜 시간이 걸립니다. 이로 인해 콘텐츠 표시나 사용자가 페이지와 상호 작용하는 등 다른 모든 작업이 지연됩니다. 광섬유 연결이 가능한 고급 노트북을 사용하는 사람에게는 이것이 약간의 성가심일 수 있습니다. 하지만 전력이 낮은 휴대전화를 사용하거나 네트워크가 불안정한 사용자에게는 사이트를 완전히 유지하거나 떠나는 것의 차이가 될 수 있습니다.
JavaScript 번들 크기를 줄이는 첫 번째 단계는 대부분의 번들러가 기본적으로 수행하는 트리 쉐이킹(또는 "데드 코드 제거")입니다. 그런데 번들러는 모두 똑같나요?
JavaScript의 번들링은 수동 연결 및 작업 실행기부터 정교한 번들러에 이르기까지 많은 발전을 이루었습니다. 오늘날 개발자는 더 빠른 빌드를 우선시하므로 번들러 성능이 주요 초점입니다. 하지만 빌드 속도가 전부는 아닙니다. 번들의 크기가 작을수록 사용자의 로딩 시간이 더 빨라지기 때문에 생산하는 번들의 크기도 마찬가지로 중요합니다.
더 나은 성능을 찾기 위해 번들러를 JavaScript로 작성하는 것에서 Rust 및 Go와 같은 언어로 전환했습니다. 이 스위치를 사용하려면 처음부터 작성해야 하므로 이전 번들러에 있던 모든 기능과 최적화를 다시 구현해야 합니다. 장기적으로 이는 성과를 거둘 가능성이 높습니다. 그러나 단기적으로 이는 좋은 트리 쉐이킹과 같이 JavaScript 번들러가 수년에 걸쳐 개발해야 했던 일부 기능이 누락되었음을 의미합니다. 그리고 이것이 바로 번들 크기를 최소화하는 데 도움이 되는 기능입니다.
물론 토크도 저렴하니 숫자로 살펴볼까요?
8개의 인기 라이브러리를 비교하고 7개의 인기 번들러와 함께 묶어 보겠습니다. 공정성을 유지하기 위해 다음을 사용했습니다.
정확한 구성은 벤치마크 설정 저장소에서 확인할 수 있습니다.
테스트된 번들러:
이 글을 쓰는 시점에서는 롤다운이 아직 알파 단계이므로 불리한 상황에 있으며 시간이 지나면서 결과가 개선될 가능성이 높습니다.
테스트된 라이브러리:
이러한 라이브러리는 크기와 기능이 다양하며 일부는 거의 독립 실행형 애플리케이션처럼 작동할 수 있습니다.
빌드 속도부터 시작해 보겠습니다. 개발자가 가장 중요하게 생각하는 부분이기 때문입니다. 이러한 라이브러리를 모두 번들로 묶으면 빌드 시간이 192ms로 esbuild가 승자입니다. 가장 느린 빌드 시간인 7.23초와 비교하면 37배 이상 빠른 속도입니다.
이러한 결과를 바탕으로 번들러를 세 가지 범주로 그룹화할 수 있습니다.
차이가 극명합니다. 예를 들어 Rolldown과 Rspack은 이전 버전인 Rollup과 webpack보다 각각 11.5배와 3.3배 빠릅니다. 동시에 이론적 하위 호환성도 유지합니다. 이러한 최신 번들러로 전환하면 대규모 프로젝트의 생산성이 크게 향상될 수 있습니다.
출력 크기의 경우 빌드 시간만큼 차이가 크지는 않지만 여전히 중요합니다.
8개 라이브러리를 모두 묶으면 출력 크기가 2087KiB인 Vite가 승자입니다. 최대 출력 크기인 2576KiB와 비교하면 23.5% 이상 작은 출력입니다.
23.5%의 출력 크기 차이가 상당합니다: 느린 3G 연결에서 가장 작은 번들은 다운로드하는 데 약 5.7초가 걸릴 수 있지만 가장 큰 번들은 7초에 가깝습니다. 구문 분석 및 실행 시간도 번들 크기에 따라 확장되므로 실제 차이가 훨씬 더 눈에 띌 수 있습니다.
이러한 결과를 바탕으로 번들러 출력을 다시 세 가지 범주로 그룹화할 수 있습니다.
프로젝트에서 위에 나열된 모든 라이브러리를 사용할 가능성이 없기 때문에 집계된 결과가 전체 그림을 그리지는 않습니다. 더 흥미로운 점은 이러한 번들러가 개별 라이브러리를 처리하는 방식입니다.
chart.js 및 mobx와 같은 라이브러리의 경우 번들러 선택은 출력 크기에 큰 영향을 미칠 수 있으며 차이는 70%에 이릅니다. 이는 특정 종속성을 사용하여 번들러를 테스트하는 것의 중요성을 강조합니다. 대부분의 경우 그 차이는 약 20-30%로 훨씬 작습니다.
게다가 종합적인 웹팩은 중간에 머물렀으나 8건 중 6건에서 가장 좋은 성능을 보였습니다. 그러나 Handsontable과 Chart.js를 번들로 묶을 때 성능이 훨씬 나빴기 때문에 결국에는 그렇게 되었습니다. 이는 사용하는 라이브러리에 따라 webpack이 좋은 선택이 될 수 있음을 의미합니다.
스펙트럼의 반대편에는 롤다운이 있습니다. 8개 중 7개에서 최악의 성능을 보였습니다(아직 알파 상태라는 점을 기억하세요).
Rspack도 비슷한 이야기입니다. Rolldown보다 성능이 더 좋았지만 여전히 다른 번들러보다 훨씬 큰 번들을 생성했습니다.
최신 번들러로의 마이그레이션을 고려하고 있다면 사용하는 라이브러리로 테스트하여 출력 크기가 커지는 대신 빌드 속도가 빨라지는지 확인하세요.
표시된 것처럼 최신 번들러는 훨씬 빠르지만 더 큰 번들을 생성할 수 있습니다. 이전 번들러에서 마이그레이션할 때 빌드 시간만 비교하지 말고 결과 번들 크기도 비교하세요. 더 빠른 빌드를 사용하여 더 큰 번들을 구매하게 될 수도 있습니다.
예를 들어 Angular가 webpack에서 esbuild로 전환한 후 일부 개발자는 빈 Angular 앱의 크기가 약 20KB 증가했다고 보고했습니다. 이는 빌드 속도와 번들 크기의 균형을 완벽하게 강조합니다.
개발자의 생산성과 행복에 중요하기 때문에 빌드 속도를 보지 말아야 한다는 것은 아닙니다. CI 빌드 시간과 코드 병합에 필요한 시간 사이에도 상관관계가 있습니다.
번들러를 선택할 때는 번들러가 제공하는 기능을 먼저 살펴보세요. 그런 다음 빌드 속도와 번들 크기 간의 균형을 목표로 하세요. 귀하가 편한 시간에 가장 작은 번들을 생산할 수 있는 번들러를 선택하세요.
프로젝트에서 몇 가지 대표적인 라이브러리를 테스트하십시오. 종속성이 코드베이스의 대부분을 구성하는 경우 이러한 벤치마크에서 볼 수 있는 차이점은 상황에 대한 좋은 예측 변수가 될 수 있습니다.
다음 목록은 JavaScript 번들의 대부분을 구성하는 외부 라이브러리입니다. 내가 작업한 대부분은 아니지만 많은 애플리케이션에서 번들 크기의 대부분을 차지했습니다. 그렇기 때문에 현명하게 선택하고 사용하는 것이 중요합니다.
많은 사람들이 단일 기능을 사용하기 위해 lodash, axios 또는 moment와 같은 라이브러리를 설치하여 애플리케이션이 비대해졌습니다. 이러한 라이브러리는 훌륭하고 역사적으로 중요하지만 인기가 높아짐에 따라 더 가벼운 대안이 만들어졌고 해당 기능 중 일부가 언어 자체에 추가되었습니다.
이를 활용할 수 있습니다. 이러한 라이브러리에 대한 기본 API나 더 새롭고 작은 대안을 나열할 수 있지만 이미 이를 다루는 기사가 많이 있습니다. 그리고 그 밖에도 도서관이 너무 많아서 다 다루기가 불가능할 정도입니다.
그래서 저는 여러분이 사용하는 라이브러리를 살펴보고 이를 제거하거나 네이티브 API나 더 작은 대안으로 대체할 수 있는지 확인하라는 일반적인 조언만 제공하겠습니다. 필요하지 않을 수도 있습니다 * 웹사이트는 시작하기에 좋은 리소스입니다.
대부분의 라이브러리는 기본적으로 크기에 최적화되어 있지 않지만 일부 라이브러리는 특수 설치 경로나 부분 빌드를 제공합니다. 테스트에 포함된 라이브러리 중에서도 Chart.js, Handsontable, ckeditor5는 필요한 부분만 포함하여 라이브러리 크기를 줄이는 방법을 제공합니다. ckeditor5를 예로 들어 보겠습니다.
기본 설치 경로의 번들 크기는 660~800KiB입니다. 그러나 최적화된 설치 경로를 사용하면 번들 크기가 603-653KiB로 줄어들고 Rolldown에서 생성된 번들만 약 750KiB가 됩니다. 이는 번들러에 따라 크기가 7%~23% 감소한 것입니다.
주의해야 할 또 다른 사항은 중복 종속성입니다. 이는 JavaScript 애플리케이션에서 놀랍도록 일반적인 문제입니다. 예를 들어 Bluesky 삽입 위젯에는 두 가지 버전의 zod 유효성 검사 라이브러리가 있습니다. 중복 항목을 제거하면 번들 크기가 ~9% 감소했습니다.
이 문제는 일반적으로 동일한 라이브러리의 서로 다른 두 버전을 가져왔기 때문에 발생하는 것이 아니라 사용자와 외부 라이브러리 중 하나가 동일한 라이브러리에 의존하지만 버전이 다르기 때문에 발생합니다. 이 문제는 의존하는 라이브러리를 업데이트하면 해결될 수 있습니다.
이 모든 것을 염두에 두고 마침내 퍼즐의 마지막 조각인 프로젝트로 이동할 수 있습니다. 번들을 축소하고 성능을 향상시키기 위해 수행할 수 있는 작업은 다음과 같습니다.
첫 번째 단계는 가시성입니다. 번들 안에 무엇이 들어 있는지 이해하지 못한 채 크기를 줄이는 것은 추측 게임이 됩니다. 이를 위해 제가 만든 Sonda라는 번들 분석기와 시각화 도구를 사용할 수 있습니다. 위에서 언급한 대부분의 번들러(Parcel 제외)와 함께 작동하며 번들에 기여하는 개별 파일의 크기를 정확하게 표시합니다.
프로젝트에 설치하고 번들의 일부를 육안으로 검사하는 것부터 시작할 수 있습니다.
번들 안에 무엇이 들어 있는지 잘 이해하고 최적화할 수 있는 부분을 식별한 후에는 그래프 타일을 클릭하여 다음을 확인할 수 있습니다.
Sonda는 중복 종속성에 대해서도 경고하므로 문제의 근본 원인을 빠르게 식별하고 해결할 수 있습니다.
이상적으로는 일회성 검사만 수행하는 것이 아니라 CI 파이프라인의 일부로 지속적인 모니터링을 설정해야 합니다. 특히 대규모 프로젝트에서 시간 경과에 따른 변경 사항을 추적하면 작은 변경 사항이 시간이 지남에 따라 눈덩이처럼 불어나 크게 커지는 것을 방지하는 데 도움이 될 수 있습니다.
가장 빠른 코드는 배송하지 않는 코드입니다. 가능할 때마다:
애플리케이션의 일부를 제거할 수 없는 경우 코드 분할을 시도해 보세요. 코드 분할을 사용하면 필요할 때까지 앱의 특정 부분 로드를 연기하여 초기 로드 시간을 단축할 수 있습니다.
동적 import()를 사용하여 요청 시 모듈을 로드합니다. 예를 들어, 사용자가 버튼을 클릭할 때까지 특정 기능이 필요하지 않다면 그 순간까지 로드를 연기하세요.
최신 프런트엔드 프레임워크는 즉시 지연 로딩을 지원하므로 코드 분할을 워크플로에 통합하는 것이 그 어느 때보다 쉬워졌습니다.
이것은 일반적인 조언이지만 반복할 가치가 있습니다. 다음과 같은 모범 사례를 따르십시오.
웹 속도를 높이는 데 관심이 있거나 단순히 새로운 것을 배우는 데 관심이 있다면 생태계 성과 커뮤니티에 가입하는 것을 고려해 보세요. 우리는 세 가지 주요 영역에 중점을 두고 있습니다:
이 기사를 통해 더 적은 코드로 동일한 기능을 제공할 수 있다는 점을 설명하기를 바랍니다. 관리하지 않으면 번들 크기가 통제할 수 없을 정도로 커질 수 있지만 작은 변경이라도 성능을 크게 향상시킬 수 있습니다.
지금 시작하세요. 번들을 분석하고, 새 도구를 테스트하거나, 대용량 라이브러리를 교체하세요. 그 충격은 당신을 놀라게 할 것입니다.
이 기사가 즐거웠기를 바랍니다. 질문이나 의견이 있거나 특정 주제에 대해 더 자세히 알아보고 싶다면 아래 의견을 통해 알려주시기 바랍니다. JavaScript 성능, 번들링 및 트리 쉐이킹 주제에 대해 더 자세히 알아보려면 여기 또는 BlueSky에서 저를 팔로우하고 e18e 커뮤니티에 가입하세요.
위 내용은 JavaScript 크기를 줄이세요: 번들러 최적화 마스터하기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
