V8 커버리지와 소스맵으로 번들 분석기 만들기
추석맞이 뻘짓 대작전 2탄: 여러차례 삽질에 막힌 V8 커버리지 분석기 제작기.
추석맞이 뻘짓 대작전 2탄: 여러차례 삽질에 막힌 V8 커버리지 분석기 제작기.
추석맞이 뻘짓 대작전 1탄: 내 블로그 부터 살펴보기
호출하지 않는 함수가 10MiB 들어 있으면 얼마나 손해일까. 바이트가 만든 비용과 코드 형태가 만든 비용을 갈라 855회 측정했다. 미호출 선언은 MiB당 약 21ms로 CPU를 4배 늦춰도 늘지 않았고, 파일을 읽자마자 실행되는 초기화 코드는 MiB당 201ms를 메인 스레드에 얹었다. 실제 라이브러리에서는 import만 해도 모듈 평가가 실행됐다.
상수 하나를 import 했는데 번들의 97.7%가 따라왔다. 벤더는 고칠 일정이 미정이라기에, 배포된 소스맵을 뜯어 400개가 넘는 TypeScript 파일을 되찾고 빌드와 엔트리와 의존성을 내 맘대로 갈아엎었다. 로직만 빼고. 그래서 /send가 raw -77.5%. 그런데 어려운 건 그다음이었다. 테스트 1932개가 전부 통과했는데, 그중 몇 개는 아무것도 보고 있지 않았다.
Next.js 16 turbopack 프로덕션 빌드에서 모듈 스코프 싱글톤이 런타임에 두 개가 됐다. 같은 동기 구간에서 조건 판정이 뒤집히고, 응답이 도착해도 타임아웃이 나는 증상을 번들 산출물로 추적한 기록. scope hoisting의 부분 병합, 순환 import, 이미 고쳐져 있던 upstream 버그, 그리고 뒤늦게 돌린 단일 변수 실험까지.
코드 리뷰가 놓치는 bundle 비용, PR에 어떻게 띄울 것인가.
"use client" 한 줄이 만드는 모듈 경계, 빌드 타임 변환, Flight 직렬화, 그리고 성능까지
관심 가져주셔서 감사합니다. 🙇🏻♂️
관심 가져주셔서 감사합니다. 🎉
알지만 왠지 선뜻 내키지 않는 최적화, 이유가 무엇일까 🤔
트리쉐이킹은 직접 해드세요 제발
계속 찍먹만 해보는 중
자바스크립트 성능에 중요한 건 번들크기 만은 아니다. 근데 개발 하느라 이것도 잘 못챙기고 있는듯.
근데 쓰는게 뭔가 더 안정적인 기분이야
자바스크립트 아키텍쳐의 게임체인저라고 하는데, 과연 그렇게 될 수 있을까?
오늘 배운 토막(?) 상식
[Make use of long-term caching](https://developers.google.com/web/fundamentals/performance/webpack/use-long-term-caching)을 번역한 글입니다. 앱 로딩 속도를 향상시킬 수 있는 방법 중 ...
[How CommonJS is making your bundles larger](https://web.dev/commonjs-larger-bundles/) 를 번역 & 요약한 글입니다. ```toc tight: true, from-heading: 2 to-heading: 3 ``` **요약: 웹 애플리케이션을 확실하게 최적화해서 번들링하기 위해서는, C...
[Case Study: Analyzing Notion app performance](https://3perf.com/blog/notion/)를 제멋대로 요약한 글입니다. 왠만하면 저 글을 참고하세요. ```toc tight: true, from-heading: 2 to-heading: 3 ``` ## 자바스크립트의 비용 보통 `로딩 속도`를 이야기하면...