Base

프론트엔드 웹 성능 최적화

은선은 2024. 5. 22. 15:25

성능 측정이 필요한 이유

지연 속도가 늘어날 수록 사이트 이탈률이 급격히 증가하고, 구매 전환율 역시 감소

검색 엔진 최적화에도 영향을 줌

 

 

웹 성능 측정 기준치

Google의 Web Vitals는 웹 페이지의 사용자 경험을 측정하고 개선하는 데 중요한 핵심 성능 지표(Core Web Vitals)를 제공합니다. Core Web Vitals는 웹 페이지의 성능, 반응성, 시각적 안정성을 평가하는 주요 지표로 구성되어 있습니다. 현재 Google은 세 가지 주요 지표(볼드처리된 것)를 Core Web Vitals로 정의하고 있습니다.

1. First Contentful Paint (FCP)

  • 설명: 사용자가 처음으로 페이지 콘텐츠(텍스트, 이미지 등)를 볼 수 있는 시점.
  • 권장 기준치: 1.8초 이하

2. Largest Contentful Paint (LCP)

  • 설명: 페이지의 가장 큰 콘텐츠 요소(이미지 또는 텍스트 블록)가 로드되어 보이는 시점.
  • 권장 기준치: 2.5초 이하

3. First Input Delay (FID)

  • 설명: 사용자가 페이지와 처음 상호작용(버튼 클릭 등)했을 때, 브라우저가 그 상호작용을 처리하는 데 걸리는 시간.
  • 권장 기준치: 100밀리초 이하

4. Interaction to Next Paint(INP) : 24년 3월 FID를 대체

  • 설명: 사용자의 상호작용 후 다음 화면 업데이트까지의 시간
  • 권장 기준치: 200ms 이하 (Good)

5. Time to Interactive (TTI)

  • 설명: 페이지가 완전히 인터랙티브하게 된 시점. 사용자가 입력을 제공할 수 있고, 페이지가 이에 응답하는 시간.
  • 권장 기준치: 5초 이하

6. Total Blocking Time (TBT)

  • 설명: FCP와 TTI 사이의 총 시간 동안 메인 스레드가 차단된 시간.
  • 권장 기준치: 300밀리초 이하

7. Cumulative Layout Shift (CLS)

  • 설명: 페이지 로드 중 예상치 못한 레이아웃 변화의 누적 점수. 안정적인 레이아웃을 유지하는 것이 중요.
  • 권장 기준치: 0.1 이하

8. Speed Index

  • 설명: 페이지 콘텐츠가 얼마나 빠르게 시각적으로 표시되는지 측정.
  • 권장 기준치: 3.4초 이하

9. First Meaningful Paint (FMP)

  • 설명: 사용자가 페이지의 주요 콘텐츠를 볼 수 있는 시점.
  • 권장 기준치: 2초 이하

10. Page Load Time

  • 설명: 페이지가 완전히 로드되는 데 걸리는 시간.
  • 권장 기준치: 3초 이하

11. Time to First Byte (TTFB)

  • 설명: 브라우저가 서버로부터 첫 번째 바이트를 받는 데 걸리는 시간.
  • 권장 기준치: 0.8초 이하

성공 사례

핀터레스트 > 성능 최적화 > 대기시간 40% 감소, SEO 트래픽 15% 증가, 가입 전환률 15% 증가

 

프론트엔드에서 측정해야 할 성능

1. 로딩 시간

로딩 속도를 측정하는 기준 세가지

FCP(First Contentful Paint) 첫 요소가 로드 될 때까지 걸리는 시간 (스태틱 요소)

FMP(First Meaningful Paint) 사용자에게 의미있는 첫 요소가 로드될 때까지 걸리는 시간 (로딩바)

LCP(Largest Contentful Paint) 주요 콘텐츠가 로드될 때까지 걸리는 시간 (데이터 콘텐츠)

 

구글이 제시하는 기준에 따르면

LCP가 ~2.s 미만이면 좋음, 2.5s ~ 4s 이면 개선 필요함, 4~ 이면 형편 없음

2. 렌더 시간

60: 사람이 자연스럽다고 느끼는 초 당 화면 수

1s/60 = 약 16ms (한 화면이 그려지는 시간이 약 16ms 미만이어야 눈에 자연스럽게 느껴짐)

 

브라우저 렌더링 과정

 

브라우저 렌더링 과정은 웹 페이지를 사용자가 볼 수 있는 형태로 변환하는 일련의 단계로 구성됩니다.

이 과정은 html, css, javascript와 같은 웹 자원을 해석하고 화면에 렌더링하는 과정입니다.

다음은 브라우저 렌더링 과정의 주요 단계입니다.

 

1. HTML 파싱

브라우저는 HTML 문서를 위에서 아래로 읽고, 이를 파싱하여 DOM(Document Object Model) 트리를 생성합니다. DOM 트리는 HTML 문서의 구조를 계층적으로 나타내며, 각 HTML 태그는 DOM 트리의 노드가 됩니다.

 

2. CSS 파싱

브라우저는 CSS 파일을 다운로드하고 이를 파싱하여 CSSOM(CSS Object Model) 트리를 생성합니다. CSSOM 트리는 CSS 규칙과 스타일 정보를 계층적으로 나타냅니다.

 

3. JavaScript 실행

JavaScript 파일은 HTML 파싱 과정에서 script 태그를 만날 때마다 로드되고 실행됩니다. JavaScript는 DOM과 CSSOM에 접근하고 이를 수정할 수 있습니다. 이 과정에서 DOM과 CSSOM 트리가 변경될 수 있습니다. async나 defer 속성이 없는 script 태그는 HTML 파싱을 차단할 수 있습니다.

 

4. DOM과 CSSOM 결합

브라우저는 DOM 트리와 CSSOM 트리를 결합하여 렌더 트리(Render Tree)를 생성합니다. 렌더 트리는 각 DOM 노드에 적용될 스타일을 포함하며, 실제 화면에 렌더링할 노드만 포함됩니다. 예를 들어, display: none 스타일이 적용된 요소는 렌더 트리에 포함되지 않습니다.

 

5. 레이아웃 (Layout, Reflow)

렌더 트리의 각 노드가 화면의 정확한 위치와 크기를 계산하는 과정입니다. 이를 레이아웃 또는 리플로우(reflow)라고 합니다. 브라우저는 뷰포트(viewport) 내에서 각 요소의 위치와 크기를 결정합니다.

 

6. 페인팅 (Painting)

계산된 레이아웃을 기반으로 렌더 트리의 각 노드가 픽셀로 변환되어 화면에 그려지는 과정입니다. 이 과정을 페인팅 또는 렌더링이라고 합니다. 브라우저는 각 요소의 스타일을 적용하여 화면에 그립니다.

 

7. 합성 (Compositing)

복잡한 웹 페이지에서는 여러 레이어가 사용될 수 있습니다. 합성 단계에서는 이 레이어들이 결합되어 최종 화면을 구성합니다. 레이어는 주로 CSS 속성(transform, opacity, will-change 등)에 의해 생성되며, 이를 통해 성능을 최적화할 수 있습니다.

 

전체 과정 요약

  1. HTML 파싱 -> DOM 트리 생성
  2. CSS 파싱 -> CSSOM 트리 생성
  3. JavaScript 실행 -> DOM 및 CSSOM 수정 가능
  4. DOM 및 CSSOM 결합 -> 렌더 트리 생성
  5. 레이아웃 (Reflow) -> 요소의 위치와 크기 계산
  6. 페인팅 -> 렌더 트리를 픽셀로 변환
  7. 합성 (Compositing) -> 여러 레이어 결합

이 과정이 반복되면서 사용자가 웹 페이지와 상호작용할 때마다 브라우저는 DOM과 CSSOM을 다시 계산하고, 레이아웃과 페인팅 단계를 거쳐 화면을 업데이트합니다.

최적화된 렌더링을 위해 불필요한 레이아웃과 페인팅을 최소화하는 것이 중요합니다.

 

 

 

3. 메모리 누수

프로그램이 더 이상 필요하지 않은 메모리를 해제하지 않아서 사용 가능한 메모리가 점점 줄어드는 현상.

 

성능 측정 방법

  1. 개발자 도구
    • 퍼포먼스, 네트워크, 메모리 탭 이용
  2. Google Lighthouse
    • 기능: 웹 페이지의 성능, 접근성, SEO 등을 종합적으로 분석하고 개선점을 제안하는 자동화 도구. 크롬 개발자 도구에 내장되어 있으며, 독립적인 CLI 도구로도 사용할 수 있습니다.
  3. Google PageSpeed Insights
    • URL: https://pagespeed.web.dev/
    • 기능: 웹 페이지의 모바일 및 데스크톱 성능을 분석하고 구체적인 개선 사항을 제공합니다. Lighthouse 기반으로 작동합니다.
  4. WebPageTest
    • URL: https://www.webpagetest.org/
    • 기능: 다양한 브라우저와 위치에서 웹 페이지의 성능을 테스트하고 상세한 보고서를 제공합니다. 페이지 로드 시간, 첫 번째 바이트 시간, 렌더링 시간 등을 분석합니다.
  5. GTmetrix
    • URL: https://gtmetrix.com/
    • 기능: 웹 페이지의 성능을 분석하고 상세한 보고서를 제공합니다. Google Lighthouse와 자체 성능 진단 도구를 사용하여 성능 점수와 개선 사항을 제안합니다.
  6. Pingdom
    • URL: https://www.pingdom.com/
    • 기능: 웹 페이지의 로딩 속도를 테스트하고, 성능 분석 보고서를 제공합니다. 각 리소스의 로딩 시간을 상세히 분석하여 병목 현상을 찾아줍니다.
  7. Yellow Lab Tools
    • URL: https://yellowlab.tools/
    • 기능: 웹 페이지의 성능, 코드 품질, 접근성을 분석하는 도구입니다. 렌더링 차단 리소스, 자바스크립트 복잡성, CSS 성능 등을 평가합니다.
  8. Dareboost
    • URL: https://www.dareboost.com/en
    • 기능: 웹 페이지의 성능, 품질, SEO, 보안 등을 종합적으로 분석합니다. 사용자 정의 보고서를 생성하고, 다양한 성능 개선 조치를 제안합니다.
  9. Nuxt.js Performance Module
    • 설명: Nuxt.js 애플리케이션의 성능을 모니터링하고 개선할 수 있는 모듈입니다.
    • 사용법: Nuxt.js 프로젝트에 @nuxtjs/pwa 모듈을 설치하고 설정하여 성능을 모니터링합니다.
  10. 모니터링 도구
  • 설명: 네트워크 로딩 속도, AJAX 요청 속도, 자바스크립트 에러 등을 모니터링
  • 종류: 제니퍼 프론트, 뉴렐릭

 

성능 최적화 방법

1. LCP 개선

서버 응답 시간 개선 - 가까운 CDN으로 라우팅

리소스 요청 최적화

이미지 최적화 - 이미지 사이즈 조정 및 압축, 반응형 이미지 사용, 이미지 지연 로딩

css 축소

지연

즉시 처리

 

2. FID 개선

사용하지 않는 자바스크립트 분리

자바스크립트 실행 시간 단축

웹 작업자 사용

 

3. CLS 개선

이미지 크기 설정

광고를 위한 고정 공간 확보

동적 컨텐츠 대응

FOUT.FOIT를 유발하는 웹 글꼴 대응

 

1. 코드 최적화

JavaScript

  • 비동기 로딩: async와 defer를 사용하여 스크립트를 비동기로 로드하여 페이지 렌더링을 차단하지 않도록 합니다.
  • 코드 스플리팅: Webpack과 같은 번들러를 사용하여 코드를 필요한 부분만 로드하도록 분할합니다.
  • 불필요한 라이브러리 제거: 사용하지 않는 코드와 라이브러리를 제거하여 번들 크기를 줄입니다.
  • 최소화(minify)와 압축: 코드와 파일을 최소화하고 gzip 등의 압축을 사용합니다.

CSS

  • 최소화와 압축: CSS 파일을 최소화하고 gzip 압축을 사용합니다.
  • 사용하지 않는 CSS 제거: PurgeCSS와 같은 도구를 사용하여 사용되지 않는 CSS를 제거합니다.
  • Critical CSS: 주요 스타일을 인라인하여 초기 렌더링 속도를 높입니다.

2. 이미지 최적화

  • 이미지 포맷 최적화: WebP와 같은 최신 포맷을 사용하여 이미지 크기를 줄입니다.
  • 이미지 크기 조정: 실제로 필요한 크기의 이미지만 로드합니다.
  • Lazy Loading: 페이지 로딩 시점에 이미지를 지연 로딩하여 초기 로드 시간을 단축합니다.

3. 폰트 최적화

  • 폰트 서브셋(subset): 필요한 글리프만 포함된 폰트를 사용하여 폰트 파일 크기를 줄입니다.
  • 폰트 디스플레이 설정: font-display: swap을 사용하여 폰트 로딩 중에도 텍스트가 보이도록 합니다.

4. 네트워크 최적화

  • HTTP/2 사용: HTTP/2를 사용하여 다중 요청을 병렬로 처리합니다.
  • CDN 사용: 콘텐츠 전달 네트워크(CDN)를 사용하여 정적 파일의 전송 속도를 높입니다.
  • 캐싱: 브라우저 캐싱을 설정하여 재방문 시 리소스 로드를 최소화합니다.

5. 페이지 로딩 최적화

  • Critical Rendering Path 최적화: 중요한 콘텐츠가 빨리 렌더링되도록 합니다.
  • Preload, Prefetch 사용: 자주 사용하는 리소스를 미리 로드하거나 예측하여 로드합니다.
  • Lazy Loading: 이미지, 비디오, iframe 등의 리소스를 지연 로딩하여 초기 로딩 속도를 개선합니다.

6. 성능 측정 도구 활용

  • Lighthouse: 구글의 Lighthouse를 사용하여 페이지 성능을 측정하고 개선점을 찾습니다.
  • WebPageTest: 다양한 환경에서 페이지 성능을 테스트합니다.
  • Chrome DevTools: 크롬 개발자 도구를 사용하여 성능 병목 현상을 분석합니다.

7. 리소스 최적화

  • Third-party 스크립트 관리: 외부 스크립트의 로딩 시간을 최적화하고, 필요하지 않은 경우 로드를 지연시킵니다.
  • 서비스 워커: 오프라인 지원 및 캐싱을 통해 웹 애플리케이션 성능을 개선합니다.

 

성능 측정 시 고려할 점

1. 서비스에 맞는 성능 개선 요소에 집중

현재 상황과 서비스의 성격에 맞게 개선하고자 하는 요소를 정하는 것이 중요

 

넷플릭스: 사용자와의 인터랙션이 많음, 스트리밍 서비스 > 키 입력 반응 속도, 메모리 관리 중요

위키피디아: 정보 제공 > 정보과 화면이 로드되는 속도, CPU 소요 시간

 

2. 기본 환경에서 측정

확장프로그램과 같이 성능에 영향을 미치는 요소는 측정 정확도에 영향을 줄 수 있으므로 제거된 환경에서 측정할 것.

 

크롬 개발자도구를 이용하는 경우 시크릿 모드 사용

 

3. 타겟 사용자 환경에 맞춰 데이터 수집

일반적으로 모바일은 웹에 비해 성능이 4~5배 낮다고 함.

모바일과 웹을 구분하여 타겟하고자 하는 환경에 맞춰 데이터를 수집해야함.

 

Lighthouse

 

serve images in next-gen formats: 차세대 형식을 사용해 이미지 제공하기

WebP 확장자 사용하기

<picture>
    <source srcset="image.webp" type="image/webp">
    <source srcset="image.jpg" type="image/jpeg">
    <img src="image.jpg" alt="A description of the image">
  </picture>

 

PNG: 무손실 압축을 사용하여, 최고 품질 이미지를 제공하지만 다른 형식에 비해 크기가 훨씬 큼.

JPEG: 손실 압축을 사용하며, png에 비해 용량이 작음.

WebP: jpeg보다 더 나은 압축과 더 많은 기능을 제공. 구글에서 2010년 발표.

AVIF: WebP와 유사하게 높은 압축률. AOMedia에서 2019년 발표.

 

 

 

properly size images: 이미지 크기 적절하게 사용하기

반응형 이미지 제공하기

<img
  src="small.jpg"
  srcset="small.jpg 480w, medium.jpg 800w, large.jpg 1200w"
  sizes="(max-width: 600px) 480px, (max-width: 1200px) 800px, 1200px"
  alt="Responsive Image Example">

 

 

 

 

 

참조

https://www.youtube.com/watch?v=A6J74xLWqYg&t=2s

https://www.youtube.com/watch?v=IRj9vKBy9CA

https://www.youtube.com/watch?v=INPldifIEXE