◆ ESSAY
주말에 집구석에 혼자 오래있을 일이 있어서, 생각난 김에 블로그를 개편했습니다. 이 전에는 hexo 기반으로 만들어진 블로그를 작업했는데, hexo 생태계가 관리가 잘 안되고 있는 건지 플러그인이나 기능들이 제대로 동작을 안하더군요.
wordpress -> ??? -> github pages -> hexo -> gatsby 까지 벌써 개편만 한 다섯번 쯤 한거 같네요. 이제 그만 하겠습니다.
정적 사이트 생성기로 괜찮은게 뭐가 있나 알아보던 차에, 회사에서도 Gatsby를 쓰고 있길래 gatsby로 변경해보았습니다.
info changed file at /Users/jayg/work/private/yceffort-blog/content/blog/2019/12/30/renewal-blog.md
success createPages - 0.204s
success createPages - 0.159s
success write out requires - 0.008s
success run queries - 5.169s - 125/125 24.18/s
success run queries - 0.058s - 3/3 51.45/s
success run queries - 0.023s - 1/1 44.27/s
[== ] 0.724 s 9/88 10% run queries
이제 왠만한 기능은 다 구현했고, 몇가지만 더 작업하면 된다.
호출하지 않는 함수가 10MiB 들어 있으면 얼마나 손해일까. 바이트가 만든 비용과 코드 형태가 만든 비용을 갈라 855회 측정했다. 미호출 선언은 MiB당 약 21ms로 CPU를 4배 늦춰도 늘지 않았고, 파일을 읽자마자 실행되는 초기화 코드는 MiB당 201ms를 메인 스레드에 얹었다. 실제 라이브러리에서는 import만 해도 모듈 평가가 실행됐다.
블로그 마이그레이션 뒤 수식 글 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 크기와 전체 전송량, 페인트 지표를 따로 비교한 기록이다. 블로그 성능 개선하기 시리즈의 첫 편이다.