◆ coldpath 제작기 · 3편
소스맵 없이 토스증권의 JavaScript 추적해보기
추석맞이 뻘짓 대작전 3탄: 사랑해요 토스증권
20 POSTS
Web-performance 1
◆ coldpath 제작기 · 2편V8 커버리지와 소스맵으로 번들 분석기 만들기
추석맞이 뻘짓 대작전 2탄: 여러차례 삽질에 막힌 V8 커버리지 분석기 제작기.
◆ coldpath 제작기 · 1편블로그의 JavaScript가 언제 실행되는지 추적해보기
추석맞이 뻘짓 대작전 1탄: 내 블로그 부터 살펴보기
실행하지 않는 JavaScript를 10MiB까지 늘려봤다
호출하지 않는 함수가 10MiB 들어 있으면 얼마나 손해일까. 바이트가 만든 비용과 코드 형태가 만든 비용을 갈라 855회 측정했다. 미호출 선언은 MiB당 약 21ms로 CPU를 4배 늦춰도 늘지 않았고, 파일을 읽자마자 실행되는 초기화 코드는 MiB당 201ms를 메인 스레드에 얹었다. 실제 라이브러리에서는 import만 해도 모듈 평가가 실행됐다.
- ◆ 블로그 성능 개선하기 · 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 크기와 전체 전송량, 페인트 지표를 따로 비교한 기록이다. 블로그 성능 개선하기 시리즈의 첫 편이다.
외부 SDK를 뜯어서 내 맘대로 다시 만들기: 단, 로직은 한 줄도 건드리지 않고
상수 하나를 import 했는데 번들의 97.7%가 따라왔다. 벤더는 고칠 일정이 미정이라기에, 배포된 소스맵을 뜯어 400개가 넘는 TypeScript 파일을 되찾고 빌드와 엔트리와 의존성을 내 맘대로 갈아엎었다. 로직만 빼고. 그래서 /send가 raw -77.5%. 그런데 어려운 건 그다음이었다. 테스트 1932개가 전부 통과했는데, 그중 몇 개는 아무것도 보고 있지 않았다.
◆ 서비스 워커 캐싱 딥다이브 · 3편서비스 워커 경유 비용 실측: GA4가 답하지 못한 대조군을 랩에서 만들기
2편 끝에 남긴 "워커 경유 비용 500ms"를 확정하려 했지만, 대조군이 되는 하드 리로드는 하루 한 건이 안 됐다. 그래서 Playwright와 셰이핑 프록시로 대조군을 직접 만들어 재 보니 내비게이션에서 워커 비용은 2ms였고, 비용은 지연이 아니라 글 하나를 클릭할 때마다 배경에서 더 받는 바이트 쪽에 있었다. 랩과 실사용자 데이터 사이에 남겨 둔 간극은 글을 다 쓰고 나서야 103 Early Hints가 만든 측정 정의 차이였다는 것을 알았다. 서비스 워커 캐싱 딥다이브 시리즈의 세 번째 편이다.
◆ 서비스 워커 캐싱 딥다이브 · 2편서비스 워커 캐싱 적용기: App Router의 함정들과 GA4 실측
1편의 일반론을 들고 이 블로그(Next.js App Router)를 오프라인에서도 열리게 만들었다. 첫 배포에서는 방금 읽은 글이 오프라인에서 안 열렸고, 두 번째 배포에서는 글은 열리는데 이미지가 전부 깨졌다. 소프트 내비게이션과 프리페치, next/image가 만든 함정들을 하나씩 고쳐 배포한 연대기와, 그 결과를 GA4 실사용자 데이터로 정산한 기록이다. 재방문자 FCP는 평균 634ms 좋아졌고, TTFB는 평균 525ms 나빠졌다. 서비스 워커 캐싱 딥다이브 시리즈의 두 번째 편이다.
framer-motion 배너에서 프레임드랍 없애기: 두 번의 삽질과 이징 함수
framer-motion으로 만든 배너가 열리는 0.6초 동안 홈 전체가 버벅였다. 원인을 코드로 추정하고, 실측으로 두 번 뒤집히고, 결국 이징 함수 하나로 리플로우를 없애기까지의 기록. 그리고 이 작업이 남긴 것들: 선언과 실행의 간극, 속성이 성능을 결정한다는 원칙, 메커니즘 보존, 계측기를 의심하는 순서, 같음을 곡선으로 증명하는 방법.
◆ 서비스 워커 캐싱 딥다이브 · 1편서비스 워커 캐싱의 동작 원리: 프록시, 라이프사이클, 다섯 가지 전략
서비스 워커는 사이트와 네트워크 사이에 선 프로그래밍 가능한 프록시다. 어디에 서 있는가, 캐시는 왜 썩는가, 배포했는데 왜 옛 버전이 보이는가, 무엇을 어떤 전략으로 담는가, 그래서 이걸 써야 하는가. 실무에서 마주치는 다섯 개의 질문을 붙잡고, opaque 응답이 104KB에서 6.6MB로 집계되는 실측과 상태 전이의 세부까지 내려간다. 『프런트엔드 성능 최적화 Deep Dive』의 캐시 장에서 못 다한 일반론이다. 서비스 워커 캐싱 딥다이브 시리즈의 첫 편이다.
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 5편오토스케일링은 자동이지만 즉시가 아니다: HPA의 시간을 구간별로 실측한 기록
트래픽을 12배로 올리고 새 파드가 첫 요청을 받기까지 31.5초. 그 31.5초의 내역서를 스톱워치로 뽑았다. 감지 창이 지배하는 구조, 배포 직후 5분 창에서 오토스케일러가 눈을 잃는 조건, 안정화 창의 계단, 메모리 HPA가 Node에서 불발되는 이유, KEDA의 선제 확장까지. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 다섯 번째 편이다.
『프런트엔드 성능 최적화 Deep Dive』가 출간되었습니다.
🙇🏻♂️
PR diff에서는 보이지 않는 비용: 우리는 사용자가 받는 코드를 리뷰하고 있지 않다
코드 리뷰가 놓치는 bundle 비용, PR에 어떻게 띄울 것인가.
◆ 디렉티브 딥다이브 · 3편'use cache' 디렉티브 딥다이브: 캐시 경계의 끝까지
"use cache" 한 줄이 만드는 빌드 타임 변환, 캐시 키 직렬화, ResumeDataCache, cacheHandler, 그리고 Cache Components까지
◆ 디렉티브 딥다이브 · 1편'use client' 디렉티브 딥다이브: 클라이언트 경계의 끝까지
"use client" 한 줄이 만드는 모듈 경계, 빌드 타임 변환, Flight 직렬화, 그리고 성능까지
◆ Next.js의 현주소 · 4편Next.js의 성능은 충분히 빠른가
벤치마크가 말해주는 불편한 진실
◆ Next.js의 현주소 · 1편Next.js Edge Runtime의 흥망성쇠
Edge Middleware 야 잘 살고 있니?
Infinite Scroll의 몰락 — Google은 왜 무한 스크롤을 걷어냈는가
무한 스크롤이 UX, 성능, 접근성, 그리고 법률의 관점에서 어떻게 재평가되고 있는지 살펴본다