◆ Core Web Vitals 직접 수집하기 · 4편
방문이 드문 블로그의 핵심 웹 지표를 직접 수집하기
공용 관측 인프라를 기준으로 만든 핵심 웹 지표 수집을 개인 블로그로 옮겼다. 방문이 드물어 비어 있던 대시보드를 고치고, 일반 브라우저에 맞춰 수집 시점을 바꿨다. 10월 17일부터 22일까지의 변경 과정과 23일에 확인한 조회 누락, 닷새치 데이터로 판단할 수 있는 범위를 기록했다.
20 POSTS
Page 1
◆ 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가 누락되는 원인을 확인했다.
◆ 코딩 에이전트 모델 교체 실험 · 1편SWE-bench로 코딩 에이전트의 모델을 비교하는 방법
코딩 에이전트의 모델 성능은 어떻게 측정할까?
◆ coldpath 제작기 · 4편번들러는 import를 어떻게 기억하는가
Turbopack 분석 파일의 동기 의존성을 정적 import로 해석한 coldpath의 분류 오류를 추적했다. webpack, Turbopack, Vite, esbuild의 그래프 정보와 산출물을 비교하고, 원래 구문을 판별할 수 있는 단서와 복원할 수 없는 경우를 살펴본다.
◆ number-flow 개선기 · 2편number-flow 성능 개선기: 애니메이션을 합성 스레드로 옮기기
구형 브라우저를 지원하도록 만든 number-flow 포크에서, 모던 브라우저의 애니메이션도 매 프레임 스타일을 재계산하고 있었다. 0.2.0에서 가산 합성의 움직임을 transform과 opacity 키프레임으로 옮긴 과정과 성능 측정, 마스크와 인터럽트에 남은 비용을 기록한다.
Next.js 앱의 Marp 슬라이드를 오프라인에 저장하기
기존 Marp 뷰어를 오프라인에서 실행하려던 접근부터 배포와 네트워크, 발표자 창에서 드러난 문제를 보완해 저장 기능을 완성하기까지의 기록
Rails가 왜 좋았는지는, 만든 사람이 내려놓고 나서야 보였다
10년쯤 전 카카오에서 Rails를 쓰던 주니어가 DHH의 Rails World 2026 키노트를 보고 정리한 생각. Rails의 무대와 DHH의 행보를 짚고, 손코딩 은퇴 선언이 왜 불편하게 남았는지, 아직 판단을 배우는 사람에게 무엇이 빠져 있었는지 키노트 원문을 근거로 따라간다.
떠난 페이지는 죽지 않고 숨는다: Next.js cacheComponents와 React Activity
Next.js 16의 cacheComponents는 떠난 페이지를 언마운트하지 않고 React Activity로 숨긴다. 하얗게 빈 three.js 캔버스를 따라 라우터, React, react-three-fiber의 소스를 읽고 브라우저에서 재현했다.
◆ coldpath 제작기 · 3편소스맵 없이 토스증권의 JavaScript 추적해보기
추석맞이 뻘짓 대작전 3탄: 사랑해요 토스증권
◆ 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 크기와 전체 전송량, 페인트 지표를 따로 비교한 기록이다. 블로그 성능 개선하기 시리즈의 첫 편이다.
『npm Deep Dive』가 2026년 세종도서 학술부문에 선정되었습니다
『npm Deep Dive』가 2026년 세종도서 학술부문에 선정되었습니다. 함께 써주신 분, 만들어주신 분, 읽어주신 분들께 감사드립니다.
『남은 판단은 누가 배우는가』 베타리더 모집이 마감되었습니다
AI가 코드를 쓰는 시대의 개발자와 판단에 대한 에세이입니다. 베타리더 모집과 인터뷰가 모두 마감되었습니다. 지원해 주신 모든 분께 감사드립니다.
여러 웹뷰에서 하나의 웹 운영하기: 환경 분기를 어댑터로 모은 과정
자사 앱과 파트너 앱의 iOS, Android 웹뷰를 지원하며 흩어진 환경 분기를 어댑터로 모았다. 인셋과 브릿지, CSS를 정리한 과정과 SSR 시드, hydration에서 겪은 문제를 기록했다.