GRIND.LEARN,REPEAT.

다른 사이트가 아니라 이 블로그를 직접 고쳐가며 남긴 실측 기록. 스타일 전송량, 빌드 시간, 렌더를 막는 자원을 하나씩 붙잡고 전후를 같은 조건에서 재봤다

『프런트엔드 성능 최적화 Deep Dive』의 캐시 장에서 못 다한 세 번째 캐시 레이어. 프록시와 라이프사이클과 전략의 일반론부터, Next.js 블로그에 직접 적용하고 GA4로 실측한 기록까지

링크 미리보기 서버를 짓는다면 무엇을 먼저 정해야 하는가. 런타임 선택의 근거부터 SSRF, 인코딩, 캐시 스탬피드까지 원리로 따라가고, 그렇게 쓴 코드를 전부 돌려본 기록

SSR을 운영하는 프론트엔드 개발자가 쿠버네티스를 블랙박스로 두지 않기 위해, kind 클러스터에서 직접 열어보고 실측한 기록

AI가 코드를 대신 쓰는 시대에 개발자에게 남는 것은 무엇인지, 판단과 책임이라는 축으로 따져본 에세이

블로그 마이그레이션 뒤 수식 글 LCP가 5.6초로 늘어난 원인을 추적했다. 일반 웹 글꼴을 실제 코드에서 제거하고 다시 빌드하자 수식 글 LCP는 5,650ms에서 2,352ms, FCP는 1,514ms에서 758ms로 줄었다. LCP 대상은 본문 문단에서 배너로 바뀌었다. 수식 전용 글꼴은 쓰는 글리프만 남긴 서브셋으로 바꿔 334KiB에서 26KiB가 됐다. 최초 비교 48회, 원인 대조 15회, 수정 전후 24회, 서브셋 전후 8회의 결과를 기록했다.

블로그의 remark/rehype 체인을 Rust로 옮기고 WASM으로 빌드해 Next.js 서버에 붙였다. 파싱과 HAST 생성에 이어 Oniguruma 하이라이트, MathML 수식, 이미지 크기와 MDX 속성 처리까지 한 호출로 묶었다. 메모리 전달과 해제, 기존 글의 호환성, WASI와 바이너리 배포를 구성하며 얻은 것과 감수한 비용을 기록했다.

블로그의 Tailwind 4를 StyleX로 옮겼다. 유틸리티만 옮긴 중간 상태에서는 CSS와 FCP가 줄었지만 전체 전송량은 늘었다. 전환 범위를 넓히자 홈 FCP가 59% 느려졌고, 작성 방식을 고친 뒤에도 격차가 남았다. 마지막 개선은 KaTeX 조건부 로딩과 본문 CSS 분리에서 나왔다. CSS 크기와 전체 전송량, 페인트 지표를 따로 비교한 기록이다. 블로그 성능 개선하기 시리즈의 첫 편이다.

『npm Deep Dive』가 2026년 세종도서 학술부문에 선정되었습니다. 함께 써주신 분, 만들어주신 분, 읽어주신 분들께 감사드립니다.

AI가 코드를 쓰는 시대의 개발자와 판단에 대한 에세이입니다. 초고를 읽고 의견을 주실 베타리더와, AI와 함께 일하는 경험을 들려주실 인터뷰이를 각각 찾습니다. 둘 다 9월 30일까지 모집합니다.

markdownlint-cli2를 Rust로 옮겨 블로그 저장소의 진단 264,114건을 바이트 단위로 맞췄다. 규칙 51개를 옮긴 커밋은 하루에 몰렸지만, 교체해 쓸 도구를 완성하는 일은 보름 동안 이어졌다. 37배 빠른 파서를 포기하고, 성능 측정의 오판을 고치고, 적대 리뷰에서 호환 차이 11건을 더 찾은 기록이다.

상수 하나를 import 했는데 번들의 97.7%가 따라왔다. 벤더는 고칠 일정이 미정이라기에, 배포된 소스맵을 뜯어 400개가 넘는 TypeScript 파일을 되찾고 빌드와 엔트리와 의존성을 내 맘대로 갈아엎었다. 로직만 빼고. 그래서 /send가 raw -77.5%. 그런데 어려운 건 그다음이었다. 테스트 1932개가 전부 통과했는데, 그중 몇 개는 아무것도 보고 있지 않았다.

2편 끝에 남긴 "워커 경유 비용 500ms"를 확정하려 했지만, 대조군이 되는 하드 리로드는 하루 한 건이 안 됐다. 그래서 Playwright와 셰이핑 프록시로 대조군을 직접 만들어 재 보니 내비게이션에서 워커 비용은 2ms였고, 비용은 지연이 아니라 글 하나를 클릭할 때마다 배경에서 더 받는 바이트 쪽에 있었다. 랩과 실사용자 데이터 사이에 남겨 둔 간극은 글을 다 쓰고 나서야 103 Early Hints가 만든 측정 정의 차이였다는 것을 알았다. 서비스 워커 캐싱 딥다이브 시리즈의 세 번째 편이다.