웹 성능 극대화: Performance Observer API 심층 분석

오늘날 빠르게 변화하는 디지털 세계에서 웹 성능은 사치가 아닌 필수 사항입니다. 느리거나 응답하지 않는 웹사이트는 사용자 불만을 야기하고 이탈률을 높이며 매출, 광고 수익 또는 사용자 참여와 같은 비즈니스 목표에 직접적인 부정적인 영향을 미칠 수 있습니다. 수년 동안 개발자는 일반적으로 초기 페이지 로드 중에 특정 시점에서 성능을 측정하는 도구에 의존해 왔습니다. 유용하지만 이러한 접근 방식은 중요한 부분을 놓치고 있습니다. 즉, 사용자가 페이지와 상호 작용할 때의 전체적인 경험입니다. 런타임 성능 모니터링이 필요한 이유이며, 가장 강력한 도구는 Performance Observer API입니다.

기존 방법은 종종 performance.getEntries()와 같은 함수를 사용하여 성능 데이터를 폴링하는 것을 포함합니다. 이는 비효율적이고 폴링 사이에 발생하는 중요한 이벤트를 놓치기 쉬우며 측정하려는 성능 오버헤드를 추가할 수도 있습니다. Performance Observer API는 발생하는 성능 이벤트를 구독하는 비동기식 저오버헤드 메커니즘을 제공하여 이 프로세스를 혁신합니다. 이 가이드에서는 핵심 웹 지표를 모니터링하고, 병목 현상을 식별하고, 궁극적으로 전 세계 사용자를 위해 더 빠르고 즐거운 웹 경험을 구축할 수 있도록 이 필수 API에 대한 심층적인 분석을 제공합니다.

Performance Observer API란 무엇입니까?

핵심적으로 Performance Observer API는 성능 측정 이벤트(성능 항목이라고 함)를 관찰하고 수집하는 방법을 제공하는 인터페이스입니다. 브라우저 내에서 성능 관련 활동을 위한 전용 리스너라고 생각하십시오. 브라우저에 "아직 아무 일도 일어나지 않았습니까?"라고 능동적으로 묻는 대신 브라우저는 "새로운 성능 이벤트가 발생했습니다! 자세한 내용은 다음과 같습니다."라고 사전에 알려줍니다.

이는 관찰자 패턴을 통해 달성됩니다. 관찰자 인스턴스를 만들고 관심 있는 성능 이벤트 유형(예: 큰 페인트, 사용자 입력, 레이아웃 변경)을 알려주고 콜백 함수를 제공합니다. 지정된 유형의 새 이벤트가 브라우저의 성능 타임라인에 기록될 때마다 새 항목 목록과 함께 콜백 함수가 호출됩니다. 이 비동기식 푸시 기반 모델은 performance.getEntries()를 반복적으로 호출하는 기존의 풀 기반 모델보다 훨씬 효율적이고 안정적입니다.

기존 방식 대 새로운 방식

Performance Observer의 혁신을 이해하기 위해 두 가지 접근 방식을 비교해 보겠습니다.

• 기존 방식(폴링): setTimeout 또는 requestAnimationFrame을 사용하여 performance.getEntriesByName('my-metric')을 주기적으로 호출하여 메트릭이 기록되었는지 확인할 수 있습니다. 너무 늦게 확인하여 이벤트를 놓치거나 너무 자주 확인하여 CPU 주기를 낭비할 수 있으므로 문제가 있습니다. 항목을 정기적으로 지우지 않으면 브라우저의 성능 버퍼를 채울 위험도 있습니다.
• 새로운 방식(관찰): PerformanceObserver를 한 번 설정합니다. 최소한의 리소스를 소비하면서 백그라운드에서 조용히 대기합니다. 페이지 로드 후 1밀리초든 사용자 세션에 들어간 지 10분이든 관련 성능 항목이 기록되는 즉시 코드로 알림이 전송됩니다. 이렇게 하면 이벤트를 놓치지 않고 모니터링 코드가 최대한 효율적으로 작동합니다.

Performance Observer를 사용해야 하는 이유

Performance Observer API를 개발 워크플로에 통합하면 전 세계적으로 도달하려는 최신 웹 애플리케이션에 중요한 여러 가지 이점을 얻을 수 있습니다.

• 비침해적 모니터링: 관찰자의 콜백은 일반적으로 유휴 기간 동안 실행되므로 성능 모니터링 코드가 사용자 경험을 방해하거나 기본 스레드를 차단하지 않습니다. 가볍고 성능에 미미한 영향을 미치도록 설계되었습니다.
• 종합적인 런타임 데이터: 웹은 역동적입니다. 성능 문제는 로드 시간에만 발생하는 것이 아닙니다. 사용자는 복잡한 애니메이션을 트리거하거나 스크롤하여 더 많은 콘텐츠를 로드하거나 초기 페이지가 정착된 후에도 무거운 구성 요소와 상호 작용할 수 있습니다. Performance Observer는 이러한 런타임 이벤트를 캡처하여 전체 사용자 세션에 대한 완벽한 그림을 제공합니다.
• 미래 보장 및 표준화: 성능 데이터 수집을 위한 W3C 권장 표준입니다. 새로운 성능 메트릭과 API는 이를 통합하도록 설계되어 프로젝트에 지속 가능하고 미래 지향적인 선택이 됩니다.
• 실사용자 모니터링(RUM)의 기반: 다양한 국가, 장치 및 네트워크 조건에서 사용자를 위한 사이트 성능을 진정으로 이해하려면 실제 세션의 데이터가 필요합니다. Performance Observer는 강력한 RUM 솔루션을 구축하기 위한 이상적인 도구이며 중요한 메트릭을 수집하여 집계 및 분석을 위해 분석 서비스로 보낼 수 있습니다.
• 경쟁 조건 제거: 폴링을 사용하면 기록되기 전에 성능 항목에 액세스하려고 할 수 있습니다. 관찰자 모델은 항목을 사용할 수 있게 된 후에만 코드가 실행되므로 이러한 경쟁 조건을 완전히 제거합니다.

시작하기: Performance Observer의 기본 사항

API 사용은 간단합니다. 프로세스에는 관찰자 만들기, 콜백 정의 및 관찰자에게 감시할 항목 알리기라는 세 가지 주요 단계가 포함됩니다.

1. 콜백을 사용하여 관찰자 만들기

먼저 콜백 함수를 전달하여 PerformanceObserver 객체를 인스턴스화합니다. 이 함수는 새 항목이 감지될 때마다 실행됩니다.

const observer = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log('Entry Type:', entry.entryType); console.log('Entry Name:', entry.name); console.log('Start Time:', entry.startTime); console.log('Duration:', entry.duration); } });

콜백은 PerformanceObserverEntryList 객체를 받습니다. 이 목록에서 getEntries() 메서드를 호출하여 새로 관찰된 모든 성능 항목의 배열을 가져올 수 있습니다.

2. 특정 항목 유형 관찰

관찰자는 감시할 항목을 알려줄 때까지 아무것도 하지 않습니다. .observe() 메서드를 사용하여 이를 수행합니다. 이 메서드는 관심 있는 성능 항목 유형을 나타내는 문자열 배열인 entryTypes 속성(또는 일부 최신 경우에는 단일 유형의 경우 type)이 있는 객체를 사용합니다.

// 두 가지 유형의 항목 관찰 시작 observer.observe({ entryTypes: ['mark', 'measure'] });

가장 일반적인 항목 유형은 다음과 같습니다.

• 'resource': 스크립트, 이미지 및 스타일시트와 같은 자산에 대한 네트워크 요청에 대한 세부 정보.
• 'paint': 첫 번째 페인트 및 첫 번째 콘텐츠 페인트의 타이밍.
• 'largest-contentful-paint': 인지된 로드 속도에 대한 핵심 웹 지표.
• 'layout-shift': 시각적 안정성에 대한 핵심 웹 지표.
• 'first-input': First Input Delay 핵심 웹 지표에 사용되는 첫 번째 사용자 상호 작용에 대한 정보.
• 'longtask': 응답성을 떨어뜨릴 수 있는 50밀리초보다 오래 걸리는 기본 스레드의 작업을 식별합니다.
• 'mark' & 'measure': 사용자 타이밍 API를 사용하여 자신의 코드에서 정의하는 사용자 지정 마커 및 측정값.

3. 관찰자 중지

더 이상 데이터를 수집할 필요가 없을 때 리소스를 확보하기 위해 관찰자의 연결을 끊는 것이 좋습니다.

observer.disconnect();

실제 사용 사례: 핵심 웹 지표 모니터링

핵심 웹 지표는 Google이 웹페이지의 전반적인 사용자 경험에서 중요하다고 간주하는 특정 요소 집합입니다. 이를 모니터링하는 것은 Performance Observer API의 가장 강력한 응용 프로그램 중 하나입니다. 각 항목을 측정하는 방법을 살펴보겠습니다.

Largest Contentful Paint(LCP) 모니터링

LCP는 로딩 성능을 측정합니다. 주요 콘텐츠가 로드되었을 가능성이 있는 페이지 로드 타임라인의 지점을 표시합니다. 좋은 LCP 점수는 2.5초 이하입니다.

LCP 요소는 페이지가 로드될 때 변경될 수 있습니다. 처음에는 제목이 LCP 요소일 수 있지만 나중에 더 큰 이미지가 로드되어 새 LCP 요소가 될 수 있습니다. 이것이 Performance Observer가 완벽한 이유입니다. 렌더링될 때마다 잠재적인 각 LCP 후보에 대해 알려줍니다.

// LCP를 관찰하고 최종 값 기록 let lcpValue = 0; const lcpObserver = new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); // 마지막 항목은 최신 LCP 후보입니다. const lastEntry = entries[entries.length - 1]; lcpValue = lastEntry.startTime; console.log(`LCP updated: ${lcpValue.toFixed(2)}ms`, lastEntry.element); }); lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true }); // 사용자 상호 작용 후에는 관찰자의 연결을 끊는 것이 좋습니다. // 상호 작용으로 인해 새로운 LCP 후보가 디스패치되지 않을 수 있기 때문입니다. // window.addEventListener('beforeunload', () => lcpObserver.disconnect());

buffered: true의 사용에 주목하십시오. 이는 observe() 메서드가 호출되기 *전에* 기록된 항목을 포함하도록 관찰자에게 지시하는 중요한 옵션입니다. 이렇게 하면 초기 LCP 이벤트를 놓치지 않습니다.

First Input Delay(FID) 및 Interaction to Next Paint(INP) 모니터링

이러한 메트릭은 상호 작용성을 측정합니다. 페이지와 처음 상호 작용하려고 할 때 사용자의 경험을 정량화합니다.

First Input Delay(FID)는 사용자가 페이지와 처음 상호 작용하는 시간(예: 버튼 클릭)부터 브라우저가 해당 상호 작용에 대한 응답으로 이벤트 처리기 처리를 실제로 시작할 수 있는 시간까지 측정합니다. 좋은 FID는 100밀리초 이하입니다.

Interaction to Next Paint(INP)는 2024년 3월에 핵심 웹 지표로 FID를 대체한 새롭고 포괄적인 메트릭입니다. FID는 *첫 번째* 상호 작용의 *지연*만 측정하는 반면 INP는 페이지 수명 주기 전반에 걸쳐 *모든* 사용자 상호 작용의 *총 대기 시간*을 평가하여 최악의 항목을 보고합니다. 이렇게 하면 전반적인 응답성에 대한 더 나은 그림을 얻을 수 있습니다. 좋은 INP는 200밀리초 이하입니다.

'first-input' 항목 유형을 사용하여 FID를 모니터링할 수 있습니다.

// FID 관찰 const fidObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { const fid = entry.processingStart - entry.startTime; console.log(`FID: ${fid.toFixed(2)}ms`); // 첫 번째 입력이 보고된 후 연결 끊기 fidObserver.disconnect(); } }); fidObserver.observe({ type: 'first-input', buffered: true });

INP 모니터링은 이벤트의 전체 지속 시간을 살펴보므로 약간 더 복잡합니다. 'event' 항목 유형을 관찰하고 지속 시간을 계산하여 가장 긴 항목을 추적합니다.

// 단순화된 INP 모니터링 예제 let worstInp = 0; const inpObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // INP는 이벤트의 지속 시간입니다. const inp = entry.duration; // 현재 최악의 것보다 더 긴 상호 작용만 신경 씁니다. if (inp > worstInp) { worstInp = inp; console.log(`New worst INP: ${worstInp.toFixed(2)}ms`); } } }); inpObserver.observe({ type: 'event', durationThreshold: 16, buffered: true }); // durationThreshold는 매우 짧고 중요하지 않은 이벤트일 가능성이 높은 이벤트를 필터링하는 데 도움이 됩니다.

Cumulative Layout Shift(CLS) 모니터링

CLS는 시각적 안정성을 측정합니다. 사용자가 예기치 않은 레이아웃 변경을 얼마나 자주 경험하는지 정량화하는 데 도움이 됩니다. 콘텐츠가 경고 없이 페이지에서 이동하는 짜증나는 경험입니다. 좋은 CLS 점수는 0.1 이하입니다.

점수는 모든 개별 레이아웃 변경 점수의 집계입니다. Performance Observer는 각 변경 사항이 발생할 때 보고하므로 여기에서 필수적입니다.

// 총 CLS 점수 관찰 및 계산 let clsScore = 0; const clsObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // 사용자 입력으로 인해 발생한 변경 사항은 계산하지 않으려고 합니다. if (!entry.hadRecentInput) { clsScore += entry.value; console.log(`Current CLS score: ${clsScore.toFixed(4)}`); } } }); clsObserver.observe({ type: 'layout-shift', buffered: true });

hadRecentInput 속성은 중요합니다. 메뉴를 확장하는 버튼 클릭과 같이 사용자 작업에 대한 응답으로 발생하는 합법적인 레이아웃 변경 사항을 필터링하는 데 도움이 됩니다. 이는 CLS 점수에 포함되어서는 안 됩니다.

핵심 웹 지표를 넘어: 다른 강력한 항목 유형

핵심 웹 지표는 훌륭한 출발점이지만 Performance Observer는 훨씬 더 많은 것을 모니터링할 수 있습니다. 몇 가지 다른 매우 유용한 항목 유형은 다음과 같습니다.

Long Tasks(`longtask`) 추적

Long Tasks API는 기본 스레드를 50밀리초 이상 차지하는 작업을 노출합니다. 기본 스레드가 사용 중인 동안 페이지가 사용자 입력에 응답할 수 없어 느리거나 고정된 환경이 발생하므로 문제가 있습니다. 이러한 작업을 식별하는 것은 INP를 개선하는 데 중요합니다.

// 긴 작업 관찰 const longTaskObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log(`Long Task Detected: ${entry.duration.toFixed(2)}ms`); // 'attribution' 속성은 때때로 긴 작업을 유발한 요인을 알려줄 수 있습니다. console.log('Attribution:', entry.attribution); } }); longTaskObserver.observe({ type: 'longtask', buffered: true });

리소스 타이밍 분석(`resource`)

자산이 로드되는 방식을 이해하는 것은 성능 튜닝의 기본입니다. 'resource' 항목 유형은 DNS 조회, TCP 연결 및 콘텐츠 다운로드 시간을 포함하여 페이지의 모든 리소스에 대한 자세한 네트워크 타이밍 데이터를 제공합니다.

// 리소스 타이밍 관찰 const resourceObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // 로드 속도가 느린 이미지를 찾아보겠습니다. if (entry.initiatorType === 'img' && entry.duration > 500) { console.warn(`Slow image detected: ${entry.name}`, `Duration: ${entry.duration.toFixed(2)}ms`); } } }); // 이 스크립트가 실행되기 전에 로드된 자산을 캡처하려면 // 'buffered: true'를 사용하는 것이 거의 항상 필요합니다. resourceObserver.observe({ type: 'resource', buffered: true });

사용자 지정 성능 마크 측정(`mark` 및 `measure`)

경우에 따라 애플리케이션별 논리의 성능을 측정해야 할 수 있습니다. 사용자 타이밍 API를 사용하면 사용자 지정 타임스탬프를 만들고 타임스탬프 간의 기간을 측정할 수 있습니다.

• performance.mark('start-operation'): 'start-operation'이라는 타임스탬프를 만듭니다.
• performance.mark('end-operation'): 다른 타임스탬프를 만듭니다.
• performance.measure('my-operation', 'start-operation', 'end-operation'): 두 마크 간의 측정값을 만듭니다.

Performance Observer는 JavaScript 프레임워크의 구성 요소 렌더링 시간 또는 중요한 API 호출 및 후속 데이터 처리 기간과 같은 항목에 대한 타이밍 데이터를 수집하는 데 적합한 이러한 사용자 지정 'mark' 및 'measure' 항목을 수신할 수 있습니다.

// 애플리케이션 코드에서: performance.mark('start-data-processing'); // ... 몇 가지 복잡한 데이터 처리 ... performance.mark('end-data-processing'); performance.measure('data-processing-duration', 'start-data-processing', 'end-data-processing'); // 모니터링 스크립트에서: const customObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntriesByName('data-processing-duration')) { console.log(`Custom Measurement '${entry.name}': ${entry.duration.toFixed(2)}ms`); } }); customObserver.observe({ entryTypes: ['measure'] });

고급 개념 및 모범 사례

전문적인 프로덕션 환경에서 Performance Observer API를 효과적으로 사용하려면 다음 모범 사례를 고려하십시오.

• 항상 `buffered: true`를 고려하십시오.: 페이지 로드 초기에 발생할 수 있는 항목 유형(예: 'resource', 'paint' 또는 'largest-contentful-paint')의 경우 버퍼링된 플래그를 사용하는 것이 누락을 방지하는 데 필수적입니다.
• 브라우저 지원 확인: 최신 브라우저에서 널리 지원되지만 사용하기 전에 항상 존재 여부를 확인하는 것이 좋습니다. 특정 브라우저에서 지원되는 항목 유형을 확인할 수도 있습니다.
• if ('PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes.includes('longtask')) { // 긴 작업에 PerformanceObserver를 안전하게 사용할 수 있습니다. }
• 분석 서비스로 데이터 보내기: 콘솔에 데이터를 로깅하는 것은 개발에 적합하지만 실제 모니터링의 경우 이 데이터를 집계해야 합니다. 클라이언트에서 이 원격 분석을 보내는 가장 좋은 방법은 navigator.sendBeacon() API를 사용하는 것입니다. 서버에 소량의 데이터를 보내도록 설계된 비차단 메커니즘이며 페이지가 언로드되는 경우에도 안정적으로 작동합니다.
• 관심사별로 관찰자 그룹화: 여러 항목 유형에 대해 단일 관찰자를 사용할 수 있지만 다른 관심사에 대해 별도의 관찰자를 만드는 것이 더 깔끔합니다(예: 핵심 웹 지표, 리소스 타이밍, 사용자 지정 메트릭에 대해 하나씩). 이렇게 하면 코드 가독성과 유지 관리성이 향상됩니다.
• 성능 오버헤드 이해: API는 오버헤드가 매우 낮도록 설계되었습니다. 그러나 과도한 계산을 수행하는 매우 복잡한 콜백 함수는 성능에 잠재적으로 영향을 미칠 수 있습니다. 관찰자 콜백을 간결하고 효율적으로 유지하십시오. 모든 과도한 처리를 웹 작업자로 연기하거나 원시 데이터를 백엔드로 보내 처리하십시오.

결론: 성능 우선 문화 구축

Performance Observer API는 단순한 도구 그 이상입니다. 웹 성능에 접근하는 방식을 근본적으로 바꿉니다. 반응적이고 일회성 측정에서 전 세계 사용자의 진정한 역동적인 경험을 반영하는 사전 예방적이고 지속적인 모니터링으로 우리를 이동시킵니다. 핵심 웹 지표, 긴 작업, 리소스 타이밍 및 사용자 지정 메트릭을 캡처하는 안정적이고 효율적인 방법을 제공함으로써 개발자는 상당수의 사용자에게 영향을 미치기 전에 성능 병목 현상을 식별하고 해결할 수 있습니다.

Performance Observer API를 채택하는 것은 모든 개발 팀에서 성능 우선 문화를 구축하기 위한 중요한 단계입니다. 중요한 사항을 측정할 수 있다면 중요한 사항을 개선할 수 있습니다. 지금 바로 이러한 관찰자를 프로젝트에 통합하십시오. 전 세계 어디에 있든 사용자는 더 빠르고 원활하며 즐거운 경험에 감사할 것입니다.