◆ number-flow 개선기 · 4편
number-flow를 에이전트에게 맡기면 어디까지 고칠까
코딩 에이전트 다섯 개가 고친 number-flow와 내 포크 v0.2.1을 다시 비교해보기. 글꼴에 따라 달라진 성능 보고, 작성자를 가린 코드 리뷰, 마스크 기본값을 유지하기로 한 후속 실험
20 POSTS
Web-performance 1
◆ number-flow 개선기 · 3편number-flow 갱신 경로의 강제 동기 레이아웃 줄이기
number-flow의 값을 바꿀 때마다 스타일과 레이아웃을 여러 번 다시 계산하던 문제. 0.2.1에서 DOM을 읽고 쓰는 순서를 바꾸며 확인한 성능 변화와 남은 비용
성능 개선에서 기법은 짧았고 판단은 길었다: 준비, 관측, 대응, 검증, 측정
성능 개선 기법을 고르기 전에 무엇을 먼저 해야 할까. 지원 범위와 의존성 정리, 측정, 우선순위 결정, 원인이 남의 코드나 인프라에 있을 때의 대응, 회귀 방지, 결과 보고로 이어지는 실무의 순서
◆ Core Web Vitals 직접 수집하기 · 4편방문이 드문 블로그의 핵심 웹 지표를 직접 수집하기
공용 관측 인프라에 맞춰 만든 핵심 웹 지표 수집 구성을 개인 블로그로 옮기기. 방문이 드물어 비어 있던 대시보드와 일반 브라우저에 맞지 않던 수집 시점을 고치며 찾은 조회 누락의 원인, 닷새치 데이터로 판단할 수 있는 범위
◆ Core Web Vitals 직접 수집하기 · 3편앱 웹뷰의 핵심 웹 지표를 공용 관측 인프라로 보내기
앱 웹뷰에서 측정한 핵심 웹 지표를 공용 관측 인프라로 보낼 때 일부 값이 누락되는 문제. 웹뷰의 이탈 이벤트부터 tail sampling, 누적 변환, Tempo 조회까지 재현 환경에서 확인하고, 수집 코드를 바꿔 해결할 수 있는 범위 가늠해보기
◆ Core Web Vitals 직접 수집하기 · 2편페이지를 떠나는 순간 핵심 웹 지표를 보내기
페이지를 떠날 때 CLS와 INP가 누락되는 원인을 OTel JS의 전송 방식과 flush 순서에서 찾기
◆ Core Web Vitals 직접 수집하기 · 1편web-vitals는 언제 핵심 웹 지표를 보고하는가
web-vitals 6.2.3의 지표별 보고 조건과, 클릭 직후 페이지를 떠날 때 INP가 누락되는 원인
◆ number-flow 개선기 · 2편number-flow 성능 개선기: 애니메이션을 합성 스레드로 옮기기
구형 브라우저를 지원하려고 만든 number-flow 포크에서, 모던 브라우저에서도 매 프레임 스타일을 다시 계산하던 애니메이션. 0.2.0에서 가산 합성으로 만들던 움직임을 transform과 opacity 키프레임으로 옮긴 과정과, 마스크와 인터럽트에 남은 비용
◆ coldpath 제작기 · 3편소스맵 없이 토스증권의 JavaScript 추적해보기
추석맞이 뻘짓 대작전 3탄: 사랑해요 토스증권
◆ coldpath 제작기 · 2편V8 커버리지와 소스맵으로 번들 분석기 만들기
추석맞이 뻘짓 대작전 2탄: 여러차례 삽질에 막힌 V8 커버리지 분석기 제작기.
◆ coldpath 제작기 · 1편블로그의 JavaScript가 언제 실행되는지 추적해보기
추석맞이 뻘짓 대작전 1탄: 내 블로그 부터 살펴보기
실행하지 않는 JavaScript를 10MiB까지 늘려봤다
호출하지 않는 함수가 10MiB 들어 있으면 얼마나 손해일까. 파일 크기에서 오는 비용과 코드 형태에서 오는 비용을 나눠 855회 측정한 결과, 호출하지 않는 선언은 MiB당 약 21ms, 파일을 읽자마자 실행되는 초기화 코드는 MiB당 201ms. 실제 라이브러리에서 import만으로 실행되는 모듈 평가까지 확인해보기
- ◆ 블로그 성능 개선하기 · 3편
블로그를 고친 뒤 첫 화면을 다시 재봤다
블로그 마이그레이션 뒤 5.6초까지 늘어난 수식 글의 LCP. 일반 웹 글꼴을 코드에서 제거해 LCP를 2.4초로 줄이고, 수식 전용 글꼴은 쓰는 글리프만 남겨 334KiB에서 26KiB로 줄이기
◆ 블로그 성능 개선하기 · 2편블로그의 마크다운 파이프라인을 Rust/WASM으로 옮기기
블로그의 remark/rehype 체인을 Rust로 옮기고 WASM으로 빌드해 Next.js 서버에서 호출하기. 파싱, HAST 생성, Oniguruma 하이라이트, MathML 수식, 이미지 크기와 MDX 속성 처리를 한 번의 호출로 끝내는 구조. 메모리 전달과 해제, 기존 글과의 호환, WASI 바이너리 배포를 구성하며 얻은 것과 감수한 비용
- ◆ 블로그 성능 개선하기 · 1편
Tailwind를 StyleX로 옮기며 다시 따져본 성능
블로그의 Tailwind 4를 StyleX로 옮기기. 유틸리티만 옮겼을 때 CSS 크기와 FCP는 줄었지만 전체 전송량은 늘어난 중간 단계와, 전환 범위를 넓히자 59% 느려진 홈 FCP. 작성 방식을 고친 뒤에도 남은 격차를 줄인 방법은 KaTeX 조건부 로딩과 본문 CSS 분리
외부 SDK를 뜯어서 내 맘대로 다시 만들기: 단, 로직은 한 줄도 건드리지 않고
상수 하나를 import 했더니 번들의 97.7%가 따라온 벤더 SDK. 수정 일정이 미정이라 배포된 소스맵에서 TypeScript 파일 400여 개를 되찾고, 로직은 그대로 둔 채 빌드, 엔트리, 의존성을 다시 구성해 /send의 raw 크기를 77.5% 줄이기. 테스트 1932개가 모두 통과했는데도 몇 개는 아무것도 검사하지 않고 있던 상황에서, 바꾼 SDK가 원래와 같게 동작하는지 어디까지 확인할 수 있는지 따져보기
◆ 서비스 워커 캐싱 딥다이브 · 3편서비스 워커 경유 비용 실측: GA4가 답하지 못한 대조군을 랩에서 만들기
2편에서 워커 경유 비용으로 남겨 둔 500ms 확인하기. 대조군이 될 하드 리로드가 하루 한 건도 안 돼 Playwright와 셰이핑 프록시로 직접 만든 대조군에서 잰 워커 경유 비용은 내비게이션당 2ms. 글을 클릭할 때 늘어난 시간 대부분은 워커가 배경에서 글 HTML을 저장하며 같은 회선을 나눠 쓴 결과이고, 랩과 실사용자 데이터가 어긋난 원인은 103 Early Hints 때문에 달라진 측정 정의
◆ 서비스 워커 캐싱 딥다이브 · 2편서비스 워커 캐싱 적용기: App Router의 함정들과 GA4 실측
이 블로그(Next.js App Router)를 오프라인에서도 열리게 만들기. 방금 읽은 글이 열리지 않던 첫 배포와 이미지가 전부 깨진 두 번째 배포를 거쳐 소프트 내비게이션, 프리페치, next/image의 문제를 하나씩 고친 과정. GA4 실사용자 데이터로 확인한 결과는 평균 634ms 빨라진 재방문자 FCP와 평균 525ms 느려진 TTFB
framer-motion 배너에서 프레임드랍 없애기: 두 번의 삽질과 이징 함수
framer-motion으로 만든 배너가 열리는 0.6초 동안 버벅인 홈 화면. 코드를 읽고 세운 추정이 실측에서 두 번 뒤집힌 끝에 이징 함수 하나로 리플로우를 없앤 과정
◆ 서비스 워커 캐싱 딥다이브 · 1편서비스 워커 캐싱의 동작 원리: 프록시, 라이프사이클, 다섯 가지 전략
『프런트엔드 성능 최적화 Deep Dive』의 캐시 장에 다 싣지 못한 서비스 워커 이야기. 캐시가 왜 오래된 채로 남는지, 배포한 뒤에도 왜 옛 버전이 보이는지, 무엇을 어떤 전략으로 저장할지, 정말 써야 하는지 따져보고, 104KB짜리 opaque 응답이 저장 용량에는 6.6MB로 집계되는 현상까지 측정해보기