OH SU JINFrontend Engineer

외부 서비스운영 중Core Web Vitals

dd-da

숙소·여행 정보를 나누는 커뮤니티형 서비스.

담당
프론트엔드 전담 · 성능 진단·최적화, SEO 기반 구축, 도메인 이전
팀
백엔드 1 · 프론트 1(본인)
기간
2026.03 – 2026.08

커뮤니티형 서비스의 프론트 성능과 SEO를 전담했다. Lighthouse Performance 49에 LCP가 99.6초로 찍혔는데 TBT도 서버 응답도 멀쩡했다 — 메인스레드 문제도 레이아웃 시프트도 아닌 순수 대역폭 문제였다. 배경 이미지 한 장이 13.3MB였다.

스택
Next.jsApp RouterTypeScriptjotaiCloudFrontnext/image

주요 작업

  • 13.3MB짜리 SVG — 확장자는 벡터, 내용물은 4096×2730 JPEG

    • background.svg가 13,957,754바이트였다.
    • SVG 태그 자체는 787바이트고 나머지 전부가 base64로 박힌 JPEG였다.
    • 게다가 pattern matrix 탓에 원본의 오른쪽 55% × 위쪽 47%만 화면에 남는 구조였다.
    • 페이지 총 전송 20.30MB 중 13.6MB, 즉 67%가 이 한 장이었다.
    • 이것이 대역폭을 독점해 LCP 요소인 배너 이미지 요청이 17초 늦게 시작되고 페인트가 68초 밀렸다.
    • 디자인이 바뀌는 안(단색 + 패턴 타일)은 폐기하고, 원본 SVG의 렌더 결과를 그대로 구워 픽셀을 유지한 채 38.7KB WebP로 대체했다.
  • CDN에 이미지 변환 기능이 없다는 것을 실측으로 확인

    • 쿼리스트링(?w=640, ?format=webp)과 Accept 헤더 협상을 전부 시도했지만 모두 원본 745,761B PNG가 그대로 왔다.
    • CDN 레벨 변환이 불가능함을 확인한 뒤 next/image 경로로 돌려 39,500B WebP를 받아냈다 — 19분의 1이다.
    • 기본 폭을 1080으로 잡은 근거는, 이미지 4종 중 3종이 이미 640px 이하라 축소 자체가 없고 나머지 하나만 1120→1080(3.6%)이라 화질 손실이 사실상 0이었기 때문이다.
  • 로컬에서 보이지 않는 개선을 구분했다

    • 로컬 측정에선 배경 교체 후에도 Performance가 50→49로 동일했다.
    • 대역폭 절감이 본질인 최적화라 loopback에서는 드러나지 않는다.
    • 다만 LCP Load Delay·Load Time이 정확히 절반으로 줄어 대역폭 경합 완화는 직접 확인됐고, 확정 효과를 '−9.95MB 전송 바이트'로 기록한 뒤 배포본 재측정으로 검증했다.
  • 도메인 이전과 색인 — ISR 캐시는 배포로 지워지지 않는다

    • 도메인을 옮기며 리다이렉트·sitemap·robots를 전환하고 검색엔진 사이트 이전을 성사시켰다.
    • 이 과정에서 SEO 메타 값을 고쳐 배포해도 ISR 캐시 때문에 옛 값이 계속 나가는 함정을 만났고, 재검증 호출을 배포 절차에 넣었다.
페이지 총 전송량
20.30MB1.54MB−92%
Lighthouse Performance
4977+28
CLS
0.5460.000
레이아웃 시프트 완전 제거
배경 이미지
13.3MB38.7KB−99.7%
SVG 안에 base64 JPEG → WebP
LCP Load Delay
7.0s3.7s−47%
CDN 이미지
745KB PNG39.5KB WebP1/19
sitemap
1,260 URL
robots·canonical·lastmod 규격 충족