블로그 서비스 최적화

웹 성능 최적화의 출발점은 감이 아니라 숫자야. "느린 것 같은데"가 아니라 측정부터 시작해야 하거든.

Chrome DevTools에 내장된 Lighthouse를 돌리면 Performance, Accessibility, Best Practices, SEO 네 가지 카테고리 점수가 나와. 여기서 Performance 탭에 집중하면 되는데, 핵심 지표들이 있어. **FCP(First Contentful Paint)**는 첫 콘텐츠가 화면에 그려지는 시간, **LCP(Largest Contentful Paint)**는 가장 큰 콘텐츠가 그려지는 시간, **TTI(Time to Interactive)**는 사용자가 상호작용 가능해지는 시간이야. Lighthouse는 점수만 주는 게 아니라 Opportunities와 Diagnostics 섹션에서 구체적으로 뭘 고쳐야 하는지 알려줘. 참고로 Lighthouse 돌릴 때는 시크릿 모드에서 해야 해. 브라우저 확장 프로그램이 결과에 영향을 줄 수 있거든.

Lighthouse를 돌려보면 높은 확률로 "Properly size images"가 뜨는데, 화면에 120x120으로 보여주는 이미지를 원본 1200x1200 그대로 내려보내고 있는 게 원인이야. 해결은 간단해 — 보여줄 크기의 2배 정도로 리사이징하면 돼. Retina 디스플레이 대응 때문에 2배. CDN의 이미지 리사이징 기능을 쓰면 URL 파라미터로 ?width=240&height=240 이런 식으로 지정할 수 있어서 더 편하지.

Performance 탭에서 CPU 차트가 긴 노란 블록으로 가득 차 있으면 자바스크립트 실행이 병목이라는 뜻이야. Bottom-Up 탭에서 어떤 함수가 가장 오래 걸리는지 확인하고, 그 함수를 열어보면 비효율적인 로직이 숨어 있거든. 정규식 대신 substring 같은 단순 문자열 연산으로 바꾸거나, 불필요한 반복을 제거하거나, 결과를 캐싱하는 식으로 해결할 수 있어. 핵심은 추측하지 말고 측정해서 찾아라는 거야. 개발자가 "여기가 느릴 것 같은데"라고 생각하는 곳이 실제 병목이 아닌 경우가 많거든.

SPA의 고질적인 문제도 있어. 메인 페이지를 열었을 뿐인데 글 상세 페이지, 댓글 컴포넌트, 에디터까지 전부 한 번에 로드되는 거지. **코드 분할(Code Splitting)**은 번들을 여러 조각으로 쪼개는 거고, **지연 로딩(Lazy Loading)**은 그 조각을 필요할 때 가져오는 거야. React에서는 React.lazy()로 컴포넌트를 동적 import하고 Suspense로 로딩 중 fallback UI를 표시하면 돼.

const DetailPage = React.lazy(() => import('./pages/DetailPage'));

<Suspense fallback={<Loading />}>
  <DetailPage />
</Suspense>

webpack의 Bundle Analyzer로 번들 구성을 시각화하면 어떤 모듈이 얼마나 차지하는지 한눈에 보여. 큰 덩어리부터 분할 대상으로 잡으면 됨.

마지막으로 텍스트 압축. 네트워크 탭에서 Response Headers를 보면 Content-Encoding 헤더가 있는데, 여기에 gzip이나 br(Brotli)이 안 붙어 있으면 텍스트 압축이 안 되고 있다는 뜻이야. HTML, CSS, JS 같은 텍스트 기반 리소스는 압축하면 크기가 50~80% 줄어들거든. Gzip은 가장 범용적이고, Brotli는 Google이 만든 알고리즘으로 Gzip보다 20~30% 더 잘 압축돼. 서버 설정 한 줄이면 되는 건데 안 하고 있는 경우가 의외로 많아.

---

정리

1장 읽고 기억할 거 세 가지:

1. 측정 먼저, 최적화는 그 다음. Lighthouse와 Performance 탭이 알려주는 숫자를 기반으로 움직여야 한다
2. 이미지와 번들 사이즈가 가장 큰 적. 대부분의 웹 성능 문제는 이 두 가지에서 시작된다
3. 작은 변경으로 큰 효과. 이미지 리사이징, 코드 분할, 텍스트 압축 — 코드 몇 줄이면 되는 최적화가 체감 성능을 확 바꾼다