웹 프론트엔드 성능 최적화

1. 웹 사이트 최적화 방법

• 베스트 : 아무것도 하지 않는다.
• 현실적인 선택 : 덜 일한다.

2. 최적화 작업 진행 흐름

• 진단 > 개선 > 테스트 > 진단

1. 진단

• 첫 페이지 왜 이렇게 느림?
  • Core Web Vitals
    • First Contentful Paint
    • Lagest Contentful Paint
    • Cumulative Layout Shift
• 왜 이렇게 늦게 반응함?
  • Core Web Vitals
    • Interaction to Next Paint
• 왜 이렇게 끊김?
  • 애니메이션 동작
• 크롬 개발자도구 - lighthouse
• 
• 크롬 개발자도구 - performance, memory(누수는 없나?)

 

2.1 문제 해결 - 로딩 지연

• HTML Parsing 방해하지 않기
  • script 위치 조정 (body 끝으로 이동)
  • defer/async 속성 활용
• Build를 통한 코드 최적화
  • 코드 압축 (minification) 및 번들링
  • 코드 스플리팅 (Code Splitting)
  • Vite, ESBuild와 같은 최신 빌드 도구 활용
• 클라이언트 동적 렌더링 피하기
  • Server-Side Rendering (SSR)
  • Pre-Rendering
    • 정적인 사이트의 (블로그 등) 사전 렌더링(미리 HTML만들어두기)
    • 예: Vite 기반의 vite-plugin-ssr
    • NEXT.JS의 SSG (Static Site Generation)
• Lazy Loading
  • Lazy Component Loading (Dynamic JS Loading)
  • Image Lazy Loading (loading="lazy")
    • 하지만 LCP영향을 주는 이미지에는 lazy 적용은 안됨.
  • IntersectionObserver API 활용
• HTTP Header의 속성 활용
  • Cache-Control (max-age, no-cache, no-store)
  • Expires (캐시 만료 시간)
  • Last-Modified / If-Modified-Since (마지막 갱신 시간)
  • ETag 활용: 리소스 변경 여부를 서버에서 판단
    • 서버가 리소스를 제공할 때 ETag 값을 생성해 응답 헤더에 포함 (ETag: "abc123")
    • 브라우저는 이후 요청에서 If-None-Match 헤더에 ETag 값을 포함 (If-None-Match: "abc123")
    • 서버는 ETag를 비교 (값이 같으면 리소스가 변경되지 않았으므로 304 Not Modified를 반환)
• 이미지 최적화
  • WebP, AVIF 포맷으로 이미지 변환
  • 기존 폰트 파일을 WOFF2로 변환하여 로딩 속도 개선
    • WOFF2 폰트 활용: WOFF보다 더 작은 크기로 압축 가능

2.2 문제 해결 - 반응 지연

• 메인 스레드 Blocking 방지
  • DOM 수정 최소화 (불필요한 Layout과 Paint 제거 노력)
  • Layout 줄이기
    • Composite 단계에서 동작하도록 GPU 가속 속성 사용
    • 독립적인 레이어 활용(transform, opacity)
    • Video/Canvas 요소 활용
    • transform/opacity 기반 CSS 애니메이션 (Keyframes, Transition)
• 중복 계산 줄이기
  • Memoization 기법
• 네트워크 요청 캐시 전략
  • Service Worker 및 PWA를 활용한 캐싱
    • 참고
  • Cache Header 전략
• Prefetch 및 Preload 활용
  • Preload 사용 :
  • 현재 페이지에서 곧바로 쓰일 핵심 리소스(폰트, 메인 CSS/JS)를 최상위 우선순위로 다운로드

  <link rel="preload" href="/styles/main.css" as="style">
  <link rel="preload" href="/scripts/main.js" as="script">
  

  • Prefetch 사용 :
  • 다음 페이지에서 사용될 리소스를 브라우저가 한가할 때 낮은 우선순위로 미리 다운로드하여 캐시에 저장

  <link rel="prefetch" href="/images/background.jpg">
  

• Speculation Rules API - 개선된 preloading 기법
  • 브라우저가 다음 페이지를 백그라운드에서 미리 실행(Prerender)하게 만드는 최신 표준 API
  • JSON 형태의 규칙을 통해 어떤 링크를 어떤 강도로 준비할지 세밀하게 제어

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/main", "/product/detail"],
      "eagerness": "moderate" 
    }
  ],
  "prefetch": [
    {
      "where": { "href_matches": "/articles/*" },
      "eagerness": "conservative"
    }
  ]
}
</script>

• (참고) 지원되지 않는 브라우저에서는 rel="prefetch" 방식으로 fallback

 

 

성능 관점으로 보는 HTTP의 발전

HTTP 레벨에서의 성능 개선 방법도 알아두면 좋음.

1. HTTP/1.1 (1997년)

• TLS 암호화 통신
• Keep-Alive 기본 제공 (TCP 연결 재사용)
• XMLHttpRequest

---

2. HTTP/1.1의 한계

• 리소스 우선순위 없이 다운로드
• 헤더 크기 증가
• 동시성을 위해 여러 개의 연결(connection) 필요

---

3. HTTP/2.0 (2015년)

• HTTP/2.0의 스트림-프레임 관계
  • 여러 개의 스트림을 동시에 전송 가능
  • 각 스트림은 다수의 프레임으로 구성
    • 예:
      • 스트림 1 → 프레임 A, B, C
      • 스트림 2 → 프레임 X, Y, Z
  • 프레임은 독립적으로 전송되며 고유 ID를 가짐
  • 스트림과 프레임의 독립적 처리를 통해 병렬 데이터 전송 가능
• 기능 개선
  • 다중 요청/응답 처리 (Multiplexing)
  • 헤더 필드 압축 (HPACK)
  • Server Push 지원 (사실상 deprecated)

---

4. HTTP/3 (2020년 ~ 현재 표준)

HTTP/3는 낡은 엔진인 TCP를 버리고, QUIC(퀵) 이라는 새로운 엔진을 장착

• QUIC 프로토콜 기반 (UDP 활용)
  • 연결 지연 최소화 (1-RTT / 0-RTT)
    • 1-RTT(Round-Trip Time):처음 접속할 때 인사와 암호화 설정을 한 번에 끝냄.
      (TCP+TLS 대비 절반 시간)
    • 0-RTT: 재방문 시에는 인사조차 생략하고 바로 데이터를 보냄
  • TCP HOLB(Head-Of-Line Blocking) 문제 해결
    • 여러 리소스를 독립적인 파이프(스트림)로 보내서 한 파이프에서 사고(패킷 유실)가 나도 다른 파이프는 멈추지 않고 그대로 진행
• 네트워크 전환 최적화 (Connection ID)
  • 과거에는 Wi-Fi에서 LTE로 바뀌면 IP가 변해 연결이 끊김.
  • HTTP/3는 고유한 ID를 부여해 사용자가 이동 중에도 끊김 없는 부드러운 연결을 유지
• 보안 내장 (TLS 1.3 기본 탑재)
  • 최신 암호화 표준인 TLS 1.3이 엔진 내부에 일체형으로 설계되어 보안 수립 단계가 훨씬 빠르고 안전