💻 개발자 도구 이해와 대역폭 최적화 - Ddingsroom 프로젝트에서의 분석

웹 성능을 개선하고 네트워크 사용량을 줄이는 가장 확실한 방법은 ‘브라우저 개발자 도구(DevTools)’를 제대로 이해하는 것입니다.
이번 글에서는 제가 직접 운영 중인 스터디룸 예약 서비스 ‘Ddingsroom’을 예시로, 크롬 개발자 도구의 Network / Performance / Lighthouse 패널을 중심으로 실제 로딩 과정에서의 병목 지점을 찾고, 폰트 및 이미지 최적화로 대역폭을 줄이는 방법을 정리해보겠습니다.

---

1️⃣ Network 패널 이해하기 (Ddingsroom 로딩 구조 분석)

Network 패널은 웹 페이지가 요청하는 모든 리소스의 네트워크 흐름을 시각적으로 보여주는 도구입니다.
HTML, JS, CSS, 이미지, 폰트 등 어떤 리소스가 얼마만큼의 시간과 대역폭을 사용했는지를 분석할 수 있습니다.

Ddingsroom은 Next.js 기반으로 구성되어 있어,초기 렌더링 시 HTML → CSS → JS → API → 이미지 순으로 리소스가 순차적으로 요청됩니다.

---

주요 항목

• Name: 요청된 파일 이름 (예: index.html, main.js)
• Status: HTTP 응답 코드 (200, 404, 304 등)
• Type: 리소스 타입 (document, script, stylesheet, image 등)
• Initiator: 어떤 코드가 해당 요청을 유발했는지 (예: JS, CSS import)
• Size: 다운로드된 실제 바이트 크기 (압축 전/후)
• Time: 요청~응답까지 걸린 총 시간
• Waterfall: 각 요청의 타이밍 시각화 (병렬 요청 구조 확인 가능)

---

Ddingsroom에서의 활용 포인트

1. 불필요한 요청 찾기
예약 정보와 사용자 정보 API가 중복 호출되는지 점검
2. 304 Not Modified 확인
정적 리소스(layout.css, main-app.js)가 캐싱을 통해 효율적으로 재사용되는지 확인
3. Bundling 점검
webpack.js 파일의 크기가 큰 경우, 코드 스플리팅 필요성 검토
4. Lazy Loading 검증
예약 이미지(스터디룸 사진 등)가 초기 로딩 시 불필요하게 전부 불려오지 않는지 체크

---

⚙️ Ddingsroom 프로젝트 Network 패널

실제 Ddingsroom 프로젝트의 네트워크 탭 화면 캡쳐본입니다.
상단의 Throttling: 3G와 Disable cache를 설정하여 모바일 네트워크 환경을 재현했습니다.
layout.css, webpack.js, main-app.js 등 주요 리소스의 요청 순서를 확인할 수 있고, DOMContentLoaded(5.38s)와 Load(38.86s) 시점을 기준으로 병목 구간을 분석했습니다.

---

2️⃣ Performance 패널 - 렌더링 병목 분석

Performance 패널은 페이지 로딩과 렌더링 과정 전체를 타임라인으로 시각화합니다. Network가 “전송 속도”를 본다면, Performance는 “CPU/렌더링 속도”를 분석하는 패널입니다.

Ddingsroom에서는 로그인 후 AfterLoginBanner나 예약 모달 렌더링 시 JS 연산량이 급증해 메인 스레드의 Task가 길어지는 경우가 있습니다.

---

주요 항목

• Main Thread Activity: JS 실행, 렌더링, 리플로우, 페인트 등 브라우저 내부 작업
• FPS (Frame Per Second): 초당 프레임 — 60fps 유지가 이상적
• Screenshots: 각 시점의 페이지 렌더링 미리보기
• CPU Usage: JavaScript 실행, 레이아웃, 스타일 계산 등의 CPU 부하율
• Bottom-up View: 함수별로 CPU 사용 시간 분석 가능

---

실제 적용 예시

1. 스크롤 시 버벅임
JS Event Listener가 너무 많거나 무거운 연산 확인
2. 리플로우 발생
CSS 속성 변경 시 Layout Trashing 여부 파악
3. LCP(Largest Contentful Paint)개선
이미지 로드 타이밍 및 lazy loading 확인

---

⚙️ Ddingsroom 프로젝트 Performance 측정 결과

아래 결과는 Ddingsroom 로그인 페이지의 초기 로딩 성능을 Chrome DevTools Performance 패널에서 3G 네트워크 환경으로 측정한 수치입니다.

---

항목	측정값	상태	해석
LCP (Largest Contentful Paint)	42.24초	🔴 느림 (Poor)	메인 콘텐츠 표시까지 지나치게 긴 지연 발생
CLS (Cumulative Layout Shift)	0.00	🟢 매우 우수 (Good)	시각적 흔들림 없이 안정적으로 렌더링됨
INP (Interaction to Next Paint)	48ms	🟢 우수 (Good)	버튼 클릭 등 인터랙션 후 반응이 즉시 이루어짐

---

분석

• LCP 지연 원인

  • 초기 로딩 시 div.text-4xl.md:text-5xl.font-bold 요소가 포함된 메인 헤더 영역이 렌더링 지연 발생
  • 이미지, JS 번들, 또는 폰트 로딩이 렌더 블로킹(Render Blocking) 으로 작용했을 가능성 높음
  • 특히, 폰트 요청이 비동기적으로 처리되지 않거나 캐시되지 않은 경우 LCP가 악화될 수 있음

• CLS 0.00 (Good)

  • 모든 요소에 고정된 높이·비율이 적용되어 레이아웃 시프트 없이 안정적인 렌더링이 이루어짐
  • 이는 Tailwind의 aspect-ratio, 고정 height, width 지정 덕분으로 보임

• INP 48ms (Good)

  • 버튼 및 입력 요소의 이벤트 처리 루프가 가볍고,
    JS 메인 스레드의 블로킹 구간이 거의 없음 → 사용자 반응 즉시 반영 가능

---

향후 개선 계획

이번 측정에서 LCP(42.24s) 지표가 성능 병목으로 드러났습니다.
따라서 아래와 같은 단계별 최적화를 진행할 예정입니다.

1. 이미지 로딩 최적화

• next/image 컴포넌트로 모든 정적 이미지 교체
• hero·배너 이미지에 priority 속성 부여, 하단 콘텐츠에는 loading="lazy" 적용
• JPEG → WebP / AVIF 변환 및 CDN 캐싱 도입으로 응답 속도 단축

2. 폰트 로딩 개선

• GmarketSans를 Self-hosted WOFF2 폰트로 전환
• font-display: swap 적용하여 폰트 로딩 중에도 텍스트를 즉시 표시
• <link rel="preload" as="font"> 로 주요 폰트 사전 로드

3. JS 번들 최적화

• Next.js의 dynamic import()를 활용해 비필수 스크립트 지연 로딩
• React.memo 및 useMemo로 렌더링 비용 최소화
• 불필요한 콘솔 로그 및 외부 라이브러리 의존성 정리

4. 캐싱 정책 고도화

• 정적 리소스(/static/*, /fonts/*, /images/*)에
  Cache-Control: public, max-age=31536000, immutable 헤더 적용
• 이후 Cloudflare / Vercel CDN 연동을 통해 전역 엣지 캐시 활성화

---

3️⃣ Lighthouse 패널 - 웹 성능 자동 진단

Lighthouse는 페이지 품질을 종합적으로 분석해주는 자동화 툴입니다.

Performance, Accessibility, Best Practices, SEO, PWA 등 5가지 항목을 점수화해줍니다.

---

Lighthouse 주요 카테고리

• Performance: 페이지 로딩 속도, LCP, CLS, TBT 등 주요 웹 성능 지표
• Accessibility: 대체 텍스트, ARIA 속성, 색 대비 등 접근성 검증
• Best Practices: HTTPS, JS 오류, 콘솔 경고 등 점검
• SEO: 검색엔진 최적화 관련 메타태그, robots.txt 여부
• PWA: Progressive Web App 지원 여부

---

Lighthouse 점수 개선 방안

• 이미지 → WebP 형식으로 변환
• 폰트 → font-display: swap 사용
• JS 번들 → Tree Shaking 적용
• CSS → Critical CSS 인라인 삽입
• 캐시 정책 → Cache-Control, ETag 적극 활용

---

이 화면은 Chrome DevTools의 Lighthouse 탭에서 성능 진단을 시작하기 전, 측정 조건을 설정하는 단계입니다.
분석할 페이지 유형, 디바이스 환경, 그리고 평가 항목(Category)을 지정한 뒤
“Analyze page load” 버튼을 눌러 리포트를 생성합니다.

---

⚙️ Ddingsroom 프로젝트 Lighthouse 탭 성능 진단 결과

항목	점수	상태	해석
Performance	42	🔻 낮음	초기 렌더링(LCP, TTI) 지연 / 이미지 비최적화 / JS 번들 큼
Accessibility	95	✅ 우수	label, alt, 대비도 대부분 충족
Best Practices	71	⚠️ 보통	이미지 크기, HTTPS 리소스 경고 등 일부 개선 필요
SEO	100	🟢 완벽	title / meta / robots 설정 양호

Lighthouse 분석 결과, Ddingsroom은 SEO와 접근성 측면에서 매우 우수한 구조를 보였지만 초기 렌더링 속도와 JS 번들 크기로 인해 Performance 점수가 낮게 측정되었습니다.

향후에는 이미지 WebP 변환, 코드 스플리팅, 폰트 최적화 등을 통해
성능 지표를 42 → 80 이상으로 향상시키는 것을 목표로 하고 있습니다.

---

4️⃣ 폰트 최적화(Font Optimization)

폰트는 눈에 보이지 않지만, 웹 페이지 로딩을 느리게 만드는 주요 요인 중 하나입니다.

---

최적화 방법 5단계

1. WOFF2 형식 사용
TTF/OTF보다 30~50% 용량 절감
2. 서브셋(Subsetting)
실제 사용하는 문자만 포함 (예: 영문 전용, 한글 일부)
3. font-display: swap 적용
폰트 로딩 중 FOUT(Flash of Unstyled Text) 방지

@font-face {
  font-family: 'Pretendard';
  src: url('/fonts/pretendard.woff2') format('woff2');
  font-display: swap;
}

4. Preload / Preconnect 사용

<link rel="preload" href="/fonts/pretendard.woff2" as="font" type="font/woff2" crossorigin>

5. CDN 대신 Self-hosting 고려
Google Fonts보다 직접 호스팅이 빠를 수 있음

---

위 이미지는 브라우저 렌더링 과정에서 CSS와 폰트 로딩이 페이지 표시 속도에 어떤 영향을 미치는지를 보여줍니다.

1. T₀ ~ T₁ (Request → Build DOM)

• 브라우저는 HTML 문서를 요청(GET html)하고 응답을 받아 DOM 트리를 생성합니다.
• 이 단계에서 CSS 파일을 발견하면 추가 네트워크 요청(GET css)을 수행합니다.
• CSS는 렌더링을 차단하는 Render Blocking 리소스로, 응답이 오기 전까지 화면이 그려지지 않습니다.

2. T₁ ~ T₂ (Build CSSOM → Font 요청)

• CSS 응답이 오면 브라우저는 CSSOM(CSS Object Model)을 빌드합니다.
• CSS 내 @font-face 선언이 있으면 폰트를 새로 요청(GET font)하게 됩니다.
• 폰트 응답이 늦을 경우 텍스트는 보이지 않고 FOUT(Flash of Unstyled Text) 또는 FOIT(Flash of Invisible Text) 현상이 발생합니다.
• 이 과정이 blocked text painting으로 표시된 이유입니다.

3. T₂ ~ T₃ (First Paint → Paint Text)

• CSSOM과 DOM이 결합되어 렌더 트리(Render Tree)가 완성되면
  브라우저가 최초로 화면을 그립니다(First Paint).
• 그러나 폰트가 아직 로드되지 않았다면 텍스트는 그려지지 않고,
  폰트 응답 후에야 실제 텍스트가 표시(Paint Text)됩니다.
• 즉, 폰트 로딩이 늦을수록 LCP(Largest Contentful Paint) 지표가 나빠지고 사용자에게는 로딩이 느리게 느껴집니다.

핵심 요약

CSS와 폰트는 렌더링을 지연시키는 주요 원인이므로,
font-display: swap 속성 적용이나 preload로 폰트를 미리 불러오면
First Paint 시점에 텍스트가 빠르게 표시되어 렌더 블로킹 시간을 단축할 수 있습니다.

⚙️ Ddingsroom 프로젝트에의 적용 예시

현재 Ddingsroom은 GmarketSans 시스템 폰트를 로컬 폰트 기반으로 사용하고 있습니다.
이 방식은 사용자 OS(macOS, Windows 등)에 해당 폰트가 설치되어 있을 경우
네트워크 요청 없이 바로 렌더링된다는 장점이 있습니다.
하지만, 로컬에 폰트가 없는 환경에서는 대체 폰트가 적용되며 시각적 일관성이 깨질 수 있습니다.

향후에는 Self-hosting + 최적화된 폰트 서빙 전략을 도입하여
렌더링 안정성과 성능 점수를 동시에 개선할 계획입니다.

5️⃣ 이미지 최적화(Image Optimization)

이미지는 전체 페이지 용량의 60~80%를 차지합니다.
따라서 적절한 포맷, 크기, 로딩 전략이 핵심입니다.

---

이미지 포맷 선택 가이드

목적	추천 포맷	이유
일반 사진	WebP / AVIF	용량 최대 70% 절감
투명 배경	PNG-8 / WebP	투명도 유지
아이콘 / 로고	SVG	벡터 기반, 반응형에 적합
썸네일 / 프리뷰	JPEG / WebP	빠른 로드

---

실제 최적화 기법

1. Responsive Images

<img src="hero-640.webp"
     srcset="hero-1280.webp 1280w, hero-640.webp 640w"
     sizes="(max-width: 768px) 640px, 1280px"
     alt="메인 배너 이미지">

2. Lazy Loading

<img src="banner.webp" loading="lazy" alt="배너 이미지">

3. Next-gen Formats (WebP, AVIF)
Lighthouse에서도 직접 추천됨

4. CDN 이미지 압축 서비스 사용 (Cloudflare, Imgix 등)

---

위 이미지는 CDN(Content Delivery Network) 이 원본 서버(Origin Server)와 사용자(User) 사이에서 어떻게 이미지나 정적 리소스를 빠르고 안정적으로 전달하는지를 보여줍니다.

---

작동 원리 요약

1. 사용자 요청(Request)

• 사용자가 이미지를 요청하면 브라우저는 먼저 CDN 서버(엣지 서버) 로 요청을 보냅니다.
• CDN은 전 세계 여러 지역에 분산되어 있으며, 사용자의 물리적 위치와 가장 가까운 서버가 응답합니다.

2. CDN 캐시(Cache) 확인

• CDN은 동일한 이미지 요청이 들어올 때마다 자신의 캐시 스토리지를 먼저 확인합니다.
• 캐시에 파일이 있다면 원본 서버에 재요청하지 않고 즉시 응답(Response) 합니다.
• 이렇게 하면 네트워크 지연(latency)이 줄고, 트래픽 비용도 절감됩니다.

3. 원본 서버(Origin Server) 요청

• 만약 CDN 캐시에 이미지가 없거나 만료되었다면,
  CDN은 원본 서버에 직접 요청을 보냅니다.
• 이후 받은 응답을 캐시에 저장해, 다음 요청 시 빠르게 서빙할 수 있게 합니다.

4. 서버 장애 시의 이점

• 이미지처럼 변경이 드문 리소스는 CDN 캐시 내에 유지되기 때문에,
  원본 서버가 일시적으로 다운되더라도 CDN이 캐시된 파일을 그대로 전달할 수 있습니다.
• 즉, 사용자는 서비스 장애를 거의 느끼지 못합니다.

---

⚙️ Ddingsroom 프로젝트에의 적용 예시

현재 Ddingsroom의 정적 이미지(/public/static/images/*)는 로컬에서 직접 서빙되고 있습니다.
향후에는 Cloudflare Images / AWS CloudFront / Vercel Image Optimization 같은 CDN을 활용하여 개선을 목표로 하고 있습니다.

---

👀 마치며

솔직히, 지금까지는 “기능이 돌아가면 됐다”고 생각한 적이 많았습니다. 하지만 Ddingsroom은 실제로 학생들이 매일 접속하는 운영 서비스입니다. 1초의 지연, 한 번의 깜빡임도 사용성의 피로로 돌아올 수 있습니다.
개발자 도구와 Lighthouse로 직접 분석해보니, 이미지·폰트·JS 번들이 성능에 미치는 영향을 구체적으로 확인할 수 있었습니다.

이번 점검을 통해 배운 건, 성능 최적화는 ‘추가 작업’이 아니라 ‘사용자 경험의 기본’이라는 점입니다.
앞으로는 다음과 같은 방향으로 개선을 이어갈 계획입니다.

• 이미지 → WebP 변환, lazy 로딩, CDN 캐싱

• 폰트 → woff2 self-hosting, preload, font-display: swap

• 코드 → dynamic import, Tree Shaking 적용