실행하지 않는 JavaScript를 10MiB까지 늘려봤다
호출하지 않는 함수가 10MiB 들어 있으면 얼마나 손해일까. 바이트가 만든 비용과 코드 형태가 만든 비용을 갈라 855회 측정했다. 미호출 선언은 MiB당 약 21ms로 CPU를 4배 늦춰도 늘지 않았고, 파일을 읽자마자 실행되는 초기화 코드는 MiB당 201ms를 메인 스레드에 얹었다. 실제 라이브러리에서는 import만 해도 모듈 평가가 실행됐다.
20 POSTS
Frontend 1
- ◆ 블로그 성능 개선하기 · 3편
블로그를 고친 뒤 첫 화면을 다시 재봤다
블로그 마이그레이션 뒤 수식 글 LCP가 5.6초로 늘어난 원인을 추적했다. 일반 웹 글꼴을 실제 코드에서 제거하고 다시 빌드하자 수식 글 LCP는 5,650ms에서 2,352ms, FCP는 1,514ms에서 758ms로 줄었다. LCP 대상은 본문 문단에서 배너로 바뀌었다. 수식 전용 글꼴은 쓰는 글리프만 남긴 서브셋으로 바꿔 334KiB에서 26KiB가 됐다. 최초 비교 48회, 원인 대조 15회, 수정 전후 24회, 서브셋 전후 8회의 결과를 기록했다.
- ◆ 블로그 성능 개선하기 · 2편
블로그의 마크다운 파이프라인을 Rust/WASM으로 옮기기
블로그의 remark/rehype 체인을 Rust로 옮기고 WASM으로 빌드해 Next.js 서버에 붙였다. 파싱과 HAST 생성에 이어 Oniguruma 하이라이트, MathML 수식, 이미지 크기와 MDX 속성 처리까지 한 호출로 묶었다. 메모리 전달과 해제, 기존 글의 호환성, WASI와 바이너리 배포를 구성하며 얻은 것과 감수한 비용을 기록했다.
- ◆ 블로그 성능 개선하기 · 1편
Tailwind를 StyleX로 옮기며 다시 따져본 성능
블로그의 Tailwind 4를 StyleX로 옮겼다. 유틸리티만 옮긴 중간 상태에서는 CSS와 FCP가 줄었지만 전체 전송량은 늘었다. 전환 범위를 넓히자 홈 FCP가 59% 느려졌고, 작성 방식을 고친 뒤에도 격차가 남았다. 마지막 개선은 KaTeX 조건부 로딩과 본문 CSS 분리에서 나왔다. CSS 크기와 전체 전송량, 페인트 지표를 따로 비교한 기록이다. 블로그 성능 개선하기 시리즈의 첫 편이다.
여러 웹뷰에서 하나의 웹 운영하기: 환경 분기를 어댑터로 모은 과정
자사 앱과 파트너 앱의 iOS, Android 웹뷰를 지원하며 흩어진 환경 분기를 어댑터로 모았다. 인셋과 브릿지, CSS를 정리한 과정과 SSR 시드, hydration에서 겪은 문제를 기록했다.
외부 SDK를 뜯어서 내 맘대로 다시 만들기: 단, 로직은 한 줄도 건드리지 않고
상수 하나를 import 했는데 번들의 97.7%가 따라왔다. 벤더는 고칠 일정이 미정이라기에, 배포된 소스맵을 뜯어 400개가 넘는 TypeScript 파일을 되찾고 빌드와 엔트리와 의존성을 내 맘대로 갈아엎었다. 로직만 빼고. 그래서 /send가 raw -77.5%. 그런데 어려운 건 그다음이었다. 테스트 1932개가 전부 통과했는데, 그중 몇 개는 아무것도 보고 있지 않았다.
framer-motion 배너에서 프레임드랍 없애기: 두 번의 삽질과 이징 함수
framer-motion으로 만든 배너가 열리는 0.6초 동안 홈 전체가 버벅였다. 원인을 코드로 추정하고, 실측으로 두 번 뒤집히고, 결국 이징 함수 하나로 리플로우를 없애기까지의 기록. 그리고 이 작업이 남긴 것들: 선언과 실행의 간극, 속성이 성능을 결정한다는 원칙, 메커니즘 보존, 계측기를 의심하는 순서, 같음을 곡선으로 증명하는 방법.
number-flow를 구형 브라우저로 이식하기: 다섯 가지 결정과 두 가지 번복
number-flow가 애니메이션을 켜는 최소 버전은 Chrome 125, Safari 17.2다. 이 하한을 Chrome 66과 WebKit 16.4까지 내리는 포크를 만들면서 내린 결정들과, 뒤집게 된 판단 두 가지, 그리고 자동 강등을 포기한 Safari 버그 조사의 기록.
typescript@7을 설치하면 벌어지는 일들: 블로그 모노레포 마이그레이션 기록
pnpm lint가 12분 32초 걸리던 모노레포에 typescript 7.0.2를 넣어봤다. 타입체크는 조용히 지나갔는데 next build가 깨졌고, lint는 크래시했다. eslint와 prettier를 oxlint와 oxfmt로 갈아탄 하루의 연쇄 반응과 전후 실측 기록. 미리 말해두면, 빌드는 빨라지지 않았다.
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 5편오토스케일링은 자동이지만 즉시가 아니다: HPA의 시간을 구간별로 실측한 기록
트래픽을 12배로 올리고 새 파드가 첫 요청을 받기까지 31.5초. 그 31.5초의 내역서를 스톱워치로 뽑았다. 감지 창이 지배하는 구조, 배포 직후 5분 창에서 오토스케일러가 눈을 잃는 조건, 안정화 창의 계단, 메모리 HPA가 Node에서 불발되는 이유, KEDA의 선제 확장까지. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 다섯 번째 편이다.
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 4편파드는 어떻게 종료되는가: 배포 중 에러의 원인과 해결을 실측한 기록
코드를 한 줄도 바꾸지 않은 배포에서도 에러는 샌다. 롤링 배포 중 새는 실패를 유형과 시각까지 태깅해 원인 네 가지를 부검하고, 해법을 하나씩 더해 0으로 만들기까지의 실측 기록이다. Next.js의 종료 코드 원문과 인질 드레인, CrashLoopBackOff의 실제 시간표까지. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 네 번째 편이다.
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 3편트래픽은 어떻게 내 파드에 도착하는가: ClusterIP부터 port-forward까지
Service의 ClusterIP는 어느 기계에도 붙어 있지 않은 IP인데 curl은 어떻게 닿는가. iptables 규칙과 conntrack, EndpointSlice, 클러스터 DNS의 ndots, Gateway, port-forward까지, 요청이 파드에 도착하는 경로 전체를 kind 클러스터에서 직접 열어본 기록이다. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 세 번째 편이다.
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 2편내 Next.js 앱은 어떻게 파드가 되는가: 컨테이너와 파드를 직접 열어본 기록
같은 Next.js 앱인데 이미지 하나는 1.72GB, 하나는 208MB였다. 사라진 1.5GB를 레이어에서 역추적하고, 컨테이너가 격리된 프로세스라는 것을 PID와 cgroup 파일로 직접 확인한다. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 두 번째 편이다.
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 1편프론트엔드 개발자를 위한 쿠버네티스 개념 지도: 파드에서 오토스케일러까지
SSR을 운영하는 프론트엔드 개발자가 마주치는 쿠버네티스 용어와 구조를 실무 흐름 순서로 정리했다. 클러스터의 전체 구조부터 배포, 파드의 상태와 자원, 트래픽 경로, 오토스케일링까지. 시리즈의 첫 편이자 이후 편들의 참조 지도다.
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 6편Node.js 파드는 왜 그 크기인가: NODE_OPTIONS부터 파드 수까지 직접 재본 사이징
같은 워크로드에 GC 튜닝 플래그 한 줄을 붙였더니 peak RSS가 201MB에서 593MB로 뛰었다. 살아있는 데이터는 그대로였다. 왜 그게 당연한 결과인지 V8 New Space를 직접 측정해 역추적하고, 프론트엔드 개발자가 Node.js 파드를 사이징하는 세 축을 정리한다.
프론트엔드는 어디서 왔고, 에이전트 이후 어디로 가는가
층은 왜 쌓였고, 왜 서버로 돌아왔고, 에이전트 이후에도 스택이 남는 이유는 무엇인가. 그리고 스택이 이기는 것과 그 스택을 아는 사람의 가치는 왜 별개인가
React cache() 딥다이브: 소스 코드로 읽는 요청 단위 메모이제이션
React cache() 함수의 모든 이상한 규칙은 30여 줄짜리 구현에서 직접 따라 나온다. dispatcher, getCacheForType, WeakMap/Map 트리를 소스 레벨로 따라가며 요청 단위 메모이제이션의 동작을 끝까지 본다.
오래 쓸 수 있는 패키지는 무엇이 다른가
좋은 패키지는 기능뿐 아니라 의존성, 버전업, 호환성, 릴리즈 정책까지 사용자 친화적이어야 한다.
PR diff에서는 보이지 않는 비용: 우리는 사용자가 받는 코드를 리뷰하고 있지 않다
코드 리뷰가 놓치는 bundle 비용, PR에 어떻게 띄울 것인가.
◆ 디렉티브 딥다이브 · 3편'use cache' 디렉티브 딥다이브: 캐시 경계의 끝까지
"use cache" 한 줄이 만드는 빌드 타임 변환, 캐시 키 직렬화, ResumeDataCache, cacheHandler, 그리고 Cache Components까지