웹 성능 최적화 면접 질문

웹 성능이란 웹사이트가 얼마나 빠르고 효율적으로 로드되고 사용자 요청에 반응하는지를 나타내는 지표입니다. 단순히 페이지가 보이는 속도를 넘어, 사용자가 웹사이트와 상호작용할 때 느끼는 전반적인 경험을 의미하죠.

이것이 사용자 경험 측면에서 매우 중요한 이유는, 느린 웹사이트는 사용자에게 즉각적인 불편함을 주고 이탈을 유발하기 때문입니다. 예를 들어, 페이지 로딩 시간이 길어지면 사용자는 기다리다 지쳐 다른 사이트로 이동할 가능성이 높습니다. 이는 곧 전환율 감소로 이어지죠. 또한, 검색 엔진들은 사용자 경험을 중요하게 여기기 때문에 웹 성능이 SEO 순위에도 직접적인 영향을 미칩니다. TTFB(Time to First Byte)나 렌더링 속도 같은 기술적인 요소들이 UX와 SEO 모두에 큰 영향을 준다고 할 수 있습니다.

웹 페이지 로딩 속도를 측정하는 주요 지표에는 다음과 같은 것들이 있습니다.

• FCP (First Contentful Paint): 브라우저가 페이지에서 처음으로 콘텐츠(텍스트, 이미지 등)를 렌더링하는 데 걸리는 시간을 의미합니다. 사용자가 페이지가 로딩되고 있다는 것을 인지하는 데 중요한 지표입니다.

• LCP (Largest Contentful Paint): 뷰포트 내에서 가장 큰 콘텐츠 요소(이미지, 비디오, 블록 레벨 텍스트 등)가 렌더링되는 시간을 측정합니다. 사용자 경험의 핵심 지표로, 페이지의 주요 콘텐츠가 얼마나 빨리 보이는지를 나타냅니다.

• TTFB (Time to First Byte): 브라우저가 서버로부터 첫 번째 바이트를 받는 데 걸리는 시간입니다. 서버 응답 속도, 네트워크 지연 등을 파악하는 데 유용합니다.

• FID (First Input Delay): 사용자가 페이지와 처음 상호작용할 때(예: 버튼 클릭) 브라우저가 응답하기까지의 지연 시간을 측정합니다. 페이지의 반응성을 나타내는 지표입니다.

• CLS (Cumulative Layout Shift): 페이지 로딩 중 예상치 못한 레이아웃 변경이 발생하는 정도를 측정합니다. 시각적 안정성을 평가하는 데 사용되며, 사용자가 콘텐츠를 읽거나 상호 작용하는 데 방해를 줄 수 있는 요소를 파악합니다.

브라우저 캐싱은 웹 성능 최적화에 아주 중요한 역할을 합니다. 웹 페이지를 처음 방문했을 때 서버에서 받아온 이미지, CSS, JavaScript 같은 정적 리소스를 브라우저가 로컬 저장소에 저장해두는 방식입니다.

다음에 같은 페이지를 방문할 때는 브라우저가 서버에 다시 요청하는 대신, 로컬에 저장된 리소스를 사용하기 때문에 훨씬 빠르게 페이지를 로드할 수 있습니다.

이때 HTTP 헤더가 중요한 역할을 합니다. Cache-Control, Expires 같은 헤더를 통해 브라우저에게 캐싱 정책을 알려줄 수 있습니다. 예를 들어, Cache-Control: max-age=3600이라고 설정하면 1시간 동안 캐시된 리소스를 사용하라는 의미입니다.

만약 캐시가 만료되었다면, 브라우저는 서버에 리소스의 유효성을 검사합니다. ETag나 Last-Modified 헤더를 사용하여 리소스가 변경되었는지 확인하고, 변경되지 않았다면 서버는 304 Not Modified 응답을 보내 브라우저가 캐시된 리소스를 계속 사용하도록 합니다. 이렇게 하면 불필요한 데이터 전송을 줄여 웹 성능을 향상시킬 수 있습니다.

CDN은 웹 성능 향상에 핵심적인 역할을 합니다. 사용자와 물리적으로 가까운 서버에 콘텐츠를 캐싱하여 전달함으로써 네트워크 지연 시간을 줄여줍니다. 예를 들어, 한국 사용자가 미국 서버에 있는 이미지를 요청할 때, CDN은 한국에 있는 서버에서 이미지를 제공하여 훨씬 빠르게 로딩되도록 합니다.

주로 이미지, 비디오, CSS, JavaScript와 같은 정적 콘텐츠를 제공할 때 사용되며, 갑작스러운 트래픽 증가에도 안정적인 서비스를 유지할 수 있도록 대역폭을 효율적으로 관리해줍니다. TTFB(Time To First Byte)를 줄여 사용자 경험을 개선하는 데도 효과적입니다. 글로벌 서비스를 제공하거나, 대규모 트래픽이 예상되는 웹사이트에서 CDN을 사용하는 것이 일반적입니다.

이미지 최적화는 웹 성능 향상에 매우 중요합니다. 몇 가지 방법을 말씀드릴 수 있습니다.

첫째, 이미지 압축입니다. 손실 압축이나 무손실 압축을 통해 이미지 품질을 유지하면서 파일 크기를 줄일 수 있습니다. 장점은 서버 용량을 절약하고 다운로드 시간을 단축시킨다는 점입니다.

둘째, WebP와 같은 최신 이미지 포맷을 사용하는 것입니다. WebP는 JPEG나 PNG보다 압축률이 뛰어나 동일한 품질에서 더 작은 파일 크기를 제공합니다.

셋째, 반응형 이미지를 사용하는 것입니다. srcset 속성을 사용하여 화면 크기에 맞는 이미지를 제공함으로써 불필요한 데이터 낭비를 막을 수 있습니다.

넷째, 지연 로딩(Lazy Loading)을 적용하는 것입니다. 사용자가 실제로 이미지를 보기 전까지는 로딩을 지연시켜 초기 페이지 로딩 속도를 개선할 수 있습니다.

마지막으로, CDN을 활용하여 전 세계 사용자에게 더 빠르게 이미지를 전송할 수 있습니다. CDN은 지리적으로 분산된 서버에 콘텐츠를 캐싱하여 사용자에게 가장 가까운 서버에서 콘텐츠를 제공합니다.

CSS와 JavaScript 파일을 압축하고 번들링하는 것은 웹 성능을 크게 향상시킬 수 있습니다.

압축(Minification)은 파일에서 불필요한 공백, 주석 등을 제거하여 파일 크기를 줄입니다. 이렇게 되면 브라우저가 다운로드해야 할 데이터 양이 줄어들어 로딩 시간이 단축됩니다.

번들링(Bundling)은 여러 개의 CSS 또는 JavaScript 파일을 하나의 파일로 묶는 과정입니다. 웹 페이지가 로드될 때 브라우저는 각 파일에 대해 HTTP 요청을 보내야 하는데, 번들링을 통해 요청 수를 줄여 로딩 속도를 개선할 수 있습니다. HTTP 요청 자체가 오버헤드를 발생시키기 때문입니다.

결론적으로, 압축과 번들링은 파일 크기를 줄이고 HTTP 요청 수를 감소시켜 웹 페이지의 로딩 시간을 단축하고, 대역폭을 절약하며, 캐싱 효율을 높이는 데 기여합니다.

지연 로딩은 웹 페이지 초기 로딩 속도를 개선하기 위한 중요한 기술 중 하나입니다. 사용자가 현재 보고 있는 화면, 즉 뷰포트 안에 들어오기 전까지 이미지나 비디오 같은 리소스들의 로딩을 미루는 방식을 말합니다.

주로 이미지나 비디오, 긴 목록 등 화면 아래쪽에 위치한 콘텐츠에 적용하면 효과적입니다. 사용자가 스크롤을 내려 해당 영역에 접근할 때 리소스를 로드하기 때문에, 초기 페이지 로딩 시간을 단축하고 불필요한 데이터 전송을 줄여 대역폭을 절약할 수 있습니다.

결과적으로 사용자 경험을 향상시키고 웹 페이지 성능을 최적화하는 데 기여합니다. 특히 모바일 환경처럼 네트워크 환경이 좋지 않은 경우에 더욱 효과적입니다.

Critical Rendering Path (CRP)는 브라우저가 HTML, CSS, JavaScript를 파싱하여 화면에 픽셀을 그리는 데 필요한 일련의 단계입니다. 주요 단계는 다음과 같습니다.

1. DOM 트리 구축: HTML을 파싱하여 DOM 트리를 생성합니다.
2. CSSOM 트리 구축: CSS를 파싱하여 CSSOM 트리를 생성합니다.
3. 렌더 트리 구축: DOM 트리와 CSSOM 트리를 결합하여 렌더 트리를 생성합니다. 렌더 트리는 화면에 표시될 노드만 포함합니다.
4. 레이아웃: 렌더 트리를 기반으로 각 노드의 정확한 위치와 크기를 계산합니다.
5. 페인트: 계산된 레이아웃 정보를 사용하여 화면에 픽셀을 그립니다.

CRP를 최적화하는 방법은 다음과 같습니다.

• 렌더링 차단 리소스 제거/최소화: <script> 태그를 async 또는 defer 속성과 함께 사용하거나, CSS를 인라인 스타일로 삽입하여 초기 렌더링을 차단하는 리소스를 줄입니다.
• CSS 최적화: 사용하지 않는 CSS 규칙을 제거하고, CSS 선택자를 간소화하여 CSSOM 트리 구축 시간을 단축합니다.
• 이미지 최적화: 이미지 크기를 줄이고, 적절한 이미지 포맷을 사용합니다.
• 브라우저 캐싱 활용: 정적 자산에 대한 캐싱 정책을 설정하여 반복적인 로딩을 방지합니다.

async와 defer는 <script> 태그에 사용되어 웹 페이지 로딩 성능을 향상시키는 속성입니다. 둘 다 HTML 파싱을 멈추지 않고 스크립트를 다운로드하지만, 실행 시점에 차이가 있습니다.

async 속성은 스크립트가 다운로드되는 즉시 HTML 파싱을 중단하고 실행합니다. 따라서 스크립트 실행 순서가 보장되지 않으며, DOMContentLoaded 이벤트 발생 시점을 늦출 수 있습니다. 주로 페이지 렌더링에 필수적이지 않은 독립적인 스크립트, 예를 들어 광고 스크립트나 분석 스크립트에 사용합니다.

defer 속성은 HTML 파싱이 완료된 후 DOMContentLoaded 이벤트 직전에 스크립트를 실행합니다. 스크립트 순서가 HTML에 나타난 순서대로 보장되며, DOMContentLoaded 이벤트 발생을 지연시키지 않습니다. DOM 조작이나 다른 스크립트에 의존적인 스크립트, 예를 들어 jQuery와 같은 라이브러리에 적합합니다.

간단히 말해, async는 "되는대로 빨리", defer는 "HTML 파싱 끝나면 순서대로" 실행한다고 생각하면 됩니다.

네, 웹 페이지 이미지 성능 최적화 전략에 대해 설명드리겠습니다.

첫째, 적절한 이미지 포맷 선택이 중요합니다. WebP 포맷은 JPEG나 PNG보다 압축률이 뛰어나 화질 손실 없이 파일 크기를 줄일 수 있습니다. 구형 브라우저를 위해 JPEG나 PNG를 함께 제공하는 것도 좋습니다.

둘째, 반응형 이미지를 사용해야 합니다. <picture> 태그나 srcset 속성을 사용하여 화면 크기에 맞는 이미지를 제공하면 불필요한 데이터 전송을 막을 수 있습니다. 작은 화면에서는 작은 이미지를, 큰 화면에서는 큰 이미지를 보여주는 것이죠.

셋째, **지연 로딩 (Lazy Loading)**을 적용할 수 있습니다. 사용자가 스크롤하여 이미지가 화면에 나타날 때 이미지를 로딩하는 방식입니다. 초기 페이지 로딩 속도를 크게 개선할 수 있으며, loading="lazy" 속성을 사용하면 간단하게 구현할 수 있습니다.

이 외에도 이미지 압축 도구를 사용하여 이미지 용량을 줄이거나, CDN을 사용하여 이미지 전송 속도를 높이는 방법도 있습니다.

HTTP 캐싱은 웹 성능 최적화에 매우 중요합니다. 웹 페이지의 리소스를 브라우저나 프록시 서버에 저장해두고, 다음에 동일한 리소스가 필요할 때 서버에 요청하지 않고 캐시된 데이터를 사용함으로써 응답 시간을 단축하고 서버 부하를 줄일 수 있습니다.

Cache-Control 헤더는 캐싱 정책을 정의하는 데 사용됩니다.

• max-age: 리소스가 캐시된 후 유효한 최대 시간(초)을 지정합니다. 예를 들어 max-age=3600은 1시간 동안 캐시를 사용하라는 의미입니다.

• no-cache: 리소스를 캐시해도 되지만, 항상 서버에 재검증(revalidation)을 받아야 합니다. 즉, 캐시된 데이터를 사용하기 전에 서버에 "이 데이터가 아직 유효한가요?"라고 물어보는 것입니다.

• must-revalidate: no-cache와 유사하지만, 캐시 서버가 오프라인 상태일 때 캐시된 데이터를 사용하는 것을 금지합니다. 서버에 연결할 수 없으면 에러를 반환해야 합니다. 예를 들어, 은행 웹사이트의 잔액 정보처럼 항상 최신 상태를 유지해야 하는 데이터에 유용합니다.

Service Worker를 활용한 캐싱은 HTTP 캐싱과 달리 브라우저가 아닌 JavaScript 코드(Service Worker)를 통해 캐싱 전략을 제어한다는 점이 가장 큰 차이점입니다. HTTP 캐싱은 브라우저가 HTTP 헤더를 기반으로 자동으로 캐싱하지만, Service Worker는 개발자가 직접 캐싱 로직을 정의할 수 있어 훨씬 유연합니다.

예를 들어, Cache-First 전략은 캐시에 있는 리소스를 먼저 제공하고, 없으면 네트워크에서 가져와 캐시에 저장합니다. 반대로 Network-First 전략은 네트워크 연결이 가능하면 네트워크에서 가져오고, 실패하면 캐시에서 제공합니다.

Service Worker를 사용하면 웹 애플리케이션의 오프라인 지원을 강화하고, 캐싱 전략을 통해 초기 로딩 속도를 개선하여 사용자 경험을 향상시킬 수 있습니다. Cache Storage API를 사용하여 캐시를 관리하고, 필요에 따라 동적으로 캐시를 업데이트할 수 있습니다.

네, 말씀하신 Reflow와 Repaint는 웹 브라우저 렌더링 과정에서 중요한 개념입니다.

Reflow는 레이아웃 계산을 다시 하는 과정으로, DOM 구조 변경, 요소의 크기나 위치 변경 등이 발생했을 때 일어납니다. Repaint는 이렇게 변경된 레이아웃을 바탕으로 화면에 다시 그리는 과정입니다.

이 두 과정은 웹 성능에 큰 영향을 미칩니다. 특히 Reflow는 비용이 많이 드는 작업이라 자주 발생하면 웹 페이지의 반응성을 떨어뜨릴 수 있습니다.

Reflow와 Repaint를 최소화하기 위해 몇 가지 방법을 사용할 수 있습니다. 예를 들어, DOM 변경을 최소화하고, transform이나 opacity와 같이 Reflow를 발생시키지 않는 속성을 활용하는 것이 좋습니다. 또한, 스타일 변경을 한 번에 묶어서 적용하거나, 레이아웃 정보에 접근하는 코드를 최소화하여 "레이아웃 스래싱"을 방지하는 것도 중요합니다.

웹 페이지 로딩 성능을 개선하기 위해 Critical CSS 기법을 사용합니다. 렌더링을 차단하는 CSS 리소스 때문에 발생하는 문제를 해결하는 방법인데요. 핵심은 초기 화면에 필요한 CSS, 즉 Above-the-fold 영역에 해당하는 스타일만 먼저 로딩하는 겁니다.

이 부분을 HTML에 인라인 스타일로 삽입해서 브라우저가 빠르게 화면을 그릴 수 있도록 합니다. 나머지 CSS는 나중에 로딩하도록 지연시키죠. 이렇게 하면 First Contentful Paint (FCP)를 개선해서 사용자 체감 속도를 높일 수 있습니다.

장점은 초기 로딩 속도가 빨라지고 사용자 경험이 향상된다는 점입니다. 반면에 단점은 Critical CSS를 추출하고 관리하는 과정이 복잡해질 수 있다는 겁니다. CSS가 변경될 때마다 Critical CSS를 업데이트해야 하고, 인라인 스타일이 많아지면 HTML 파일 크기가 커질 수도 있습니다. 하지만 성능 개선 효과가 크기 때문에 잘 활용하면 좋은 기법입니다.

네, Critical Rendering Path (CRP) 최적화는 웹 성능에 매우 중요합니다. 몇 가지 고급 전략과 그 영향, 그리고 병목 현상 해결 방법에 대해 말씀드리겠습니다.

우선, 렌더링 차단 리소스를 최소화해야 합니다. CSS는 <head>에 배치하고, 필요 없는 CSS 규칙은 제거하는 트리 셰이킹을 적용합니다. JavaScript는 async 또는 defer 속성을 사용하여 비동기적으로 로딩하여 DOM 파싱을 막지 않도록 합니다.

CSSOM과 DOM 트리가 합쳐져 렌더 트리를 생성하는 과정에서 병목 현상이 발생할 수 있습니다. Chrome 개발자 도구의 Performance 탭을 사용하여 렌더링 시간을 분석하고, 레이아웃 스래싱이 발생하는지 확인합니다. 레이아웃 스래싱은 JavaScript가 스타일을 변경하고 즉시 레이아웃을 다시 계산하도록 강제할 때 발생합니다. 이를 해결하기 위해 스타일 변경을 일괄 처리하거나, requestAnimationFrame을 사용하여 브라우저가 최적화할 수 있도록 합니다.

리소스 우선순위 지정도 중요합니다. preload 또는 preconnect를 사용하여 중요한 리소스를 미리 로딩하면 렌더링 속도를 향상시킬 수 있습니다. 코드 분할을 통해 초기 로딩에 필요한 코드만 로드하고, 나머지는 필요할 때 로딩하는 것도 좋은 방법입니다.

네, 웹 페이지 로딩 성능을 극대화하기 위한 리소스 힌트 활용 전략에 대해 설명드리겠습니다.

fetchpriority는 이미지나 스크립트 등 리소스의 상대적인 중요도를 브라우저에 알려줍니다. high로 설정하면 즉시 로딩을 시도하고, low는 우선순위를 낮춰 백그라운드 로딩에 적합합니다.

preload는 현재 페이지에 필수적인 리소스를 미리 다운로드하여 렌더링 차단을 최소화합니다. 브라우저는 파싱 과정에서 해당 리소스를 발견하기 전에 미리 요청을 보내므로, Critical Path를 최적화할 수 있습니다.

preconnect는 특정 도메인과의 연결을 미리 설정하여 DNS lookup, TCP handshake, TLS 협상 시간을 단축합니다. 외부 API 서버나 CDN과 같이 자주 사용하는 도메인에 적용하면 효과적입니다.

prefetch는 현재 페이지가 아닌, 다음 페이지에서 필요할 것으로 예상되는 리소스를 미리 다운로드합니다. 사용자가 해당 페이지로 이동할 때 즉시 로딩된 리소스를 활용할 수 있어 사용자 경험을 향상시킵니다.

오용 사례로는, 모든 이미지를 fetchpriority="high"로 설정하는 경우를 들 수 있습니다. 이는 네트워크 병목 현상을 유발하고, 실제로 중요한 리소스의 로딩을 지연시켜 성능 저하를 초래할 수 있습니다. 또한, 필요하지 않은 리소스를 prefetch하는 경우, 불필요한 네트워크 대역폭을 낭비하고 사용자 데이터를 소모할 수 있습니다. 각 힌트의 목적에 맞게 신중하게 사용하는 것이 중요합니다.

네, 면접에서 답변하는 것처럼 설명드리겠습니다.

웹 애플리케이션 성능 최적화를 위해 SSR, CSR, SSG를 비교하면 다음과 같습니다.

SSR은 초기 로딩 속도와 SEO에 유리하지만, 서버 부담이 크고 TTI가 늦어질 수 있습니다. CSR은 사용자 인터랙션이 빠르지만, 초기 로딩이 느리고 SEO에 불리합니다. SSG는 초기 로딩이 빠르고 SEO에 유리하지만, 데이터 변경이 잦은 경우 적합하지 않습니다.

하이브리드 아키텍처는 이들의 장점을 조합합니다. Next.js의 ISR은 SSG 방식으로 빌드하지만, 일정 시간마다 페이지를 재생성하여 데이터 최신성을 유지합니다. React Server Components는 서버에서 렌더링된 컴포넌트를 클라이언트로 전송하여 초기 로딩 속도를 개선하고, 클라이언트 측 JavaScript 번들 크기를 줄입니다.

서비스 특성에 따라 아키텍처를 선택해야 합니다. 예를 들어, SEO가 중요하고 데이터 변경이 적은 블로그는 SSG가 적합합니다. 사용자 인터랙션이 중요하고 데이터 변경이 잦은 웹 앱은 CSR 또는 SSR과 CSR을 조합한 하이브리드 방식이 좋습니다. 쇼핑몰처럼 데이터 변경이 잦지만 SEO도 중요한 서비스는 ISR을 고려할 수 있습니다.

만약 대규모 전자상거래 웹사이트에서 LCP와 INP가 저조하게 측정된다면, 저는 다음과 같은 단계로 접근하여 진단하고 개선하겠습니다.

먼저, LCP 개선을 위해 가장 큰 콘텐츠 요소가 무엇인지 파악하고, 해당 요소의 로딩을 최적화합니다. 이미지 최적화는 기본이고, 필요하다면 CDN을 활용하거나 이미지 포맷을 WebP로 변경하는 것을 고려합니다. 또한, Critical CSS를 적용하여 렌더링을 차단하는 CSS를 최소화하고, 서버 응답 시간을 단축하기 위해 캐싱 전략을 점검합니다.

INP 개선을 위해서는 Lighthouse나 Web Vitals 확장 도구를 사용하여 어떤 상호작용이 가장 느린지 분석합니다. 긴 작업(Long Tasks)을 분할하고, 불필요한 JavaScript 실행을 줄이기 위해 코드 스플리팅을 적용합니다. 이벤트 핸들러 최적화도 중요하며, 디바운싱이나 스로틀링을 사용하여 이벤트 발생 빈도를 조절할 수 있습니다. 서드파티 스크립트는 비동기적으로 로딩하고, 필요하지 않은 스크립트는 제거하거나 지연 로딩하는 것을 고려합니다. 폰트 로딩 시에는 font-display: swap;을 사용하여 텍스트가 보이지 않는 시간을 최소화합니다.

이러한 개선 사항들을 적용한 후에는 지속적으로 성능을 모니터링하고, 필요에 따라 추가적인 최적화를 진행할 것입니다.

네, Service Worker를 활용한 고급 캐싱 전략은 웹 애플리케이션의 성능을 크게 향상시킬 수 있습니다.

먼저, Stale-While-Revalidate는 캐시된 데이터를 즉시 반환하면서 백그라운드에서 네트워크 요청을 통해 캐시를 업데이트하는 방식입니다. 사용자 경험을 빠르게 유지하면서 최신 데이터를 제공하는 데 적합합니다. 예를 들어, 자주 변경되지 않는 뉴스 기사 목록에 적용할 수 있습니다.

Cache-First with Network Fallback은 캐시에 데이터가 있으면 캐시에서 반환하고, 없으면 네트워크 요청을 시도합니다. 네트워크 요청이 실패하면 미리 준비된 오프라인 페이지를 보여줄 수 있습니다. 정적 자산이나 앱의 핵심 기능에 유용합니다.

Background Sync는 네트워크 연결이 끊겼을 때 요청을 큐에 저장하고, 연결이 다시 활성화되면 자동으로 요청을 재시도합니다. 댓글 작성이나 폼 제출과 같이 사용자 입력이 중요한 경우에 적합합니다.

Workbox와 같은 라이브러리를 사용하면 이러한 캐싱 전략을 쉽게 구현하고 관리할 수 있습니다. 캐시 스토리지 관리, 버전 관리, 네트워크 요청 실패 시 폴백 처리 등을 자동화하여 개발 생산성을 높일 수 있습니다. 캐시 무효화는 캐시 이름에 버전을 포함시켜 업데이트하거나, 특정 조건에 따라 캐시를 삭제하는 방식으로 구현할 수 있습니다.

대규모 프론트엔드 프로젝트에서 성능 예산을 설정하고 관리하는 것은 사용자 경험을 최적화하는 데 매우 중요합니다. 저는 다음과 같은 체계적인 접근 방식을 사용합니다.

1. 예산 설정: 핵심 웹 지표(LCP, FID, CLS)와 함께 자바스크립트 번들 크기, 이미지/폰트 크기를 기준으로 예산을 설정합니다. 예를 들어, LCP는 2.5초 이내, 번들 크기는 500KB 이하 등으로 정합니다.

2. CI/CD 통합: Lighthouse CI를 CI/CD 파이프라인에 통합하여 각 빌드마다 성능 테스트를 자동화합니다. Webpack Bundle Analyzer를 통해 번들 크기 변화를 추적하고, 이미지 최적화 도구를 사용하여 이미지 크기를 줄입니다.

3. 모니터링 및 알림: 성능 예산을 초과하는 경우, Slack이나 이메일로 개발팀에 즉시 알림을 보내도록 설정합니다. 성능 회귀가 감지되면 해당 커밋을 빠르게 파악하여 문제를 해결합니다.

이러한 방식으로 성능을 지속적으로 관리하고 개선하여 사용자에게 빠르고 쾌적한 경험을 제공할 수 있습니다.

미디어 기반 웹 서비스 성능 최적화를 위해 다음과 같은 전략을 사용하겠습니다.

1. 반응형 이미지: srcset과 sizes 속성을 활용하여 다양한 화면 크기와 해상도에 최적화된 이미지를 제공합니다. <picture> 태그를 사용하여 브라우저 지원 여부에 따라 WebP나 AVIF 같은 차세대 포맷을 선택적으로 제공할 수 있습니다.

2. 차세대 이미지 포맷: WebP 또는 AVIF 포맷을 사용하여 이미지 크기를 줄이고 품질을 향상시킵니다. CDN의 이미지 변환 서비스를 활용하면 원본 이미지를 다양한 포맷과 크기로 쉽게 변환할 수 있습니다.

3. Adaptive Streaming: HLS 또는 DASH와 같은 Adaptive Streaming 프로토콜을 사용하여 네트워크 환경에 따라 비디오 품질을 동적으로 조절합니다. 이를 통해 사용자 경험 저하 없이 안정적인 비디오 재생을 보장합니다.

4. CLS 최소화: 이미지 로딩 중 레이아웃 시프트를 최소화하기 위해 이미지의 가로/세로 비율을 미리 지정하거나, 플레이스홀더를 사용합니다. loading="lazy" 속성을 사용하여 초기 로딩 속도를 개선하고, decoding="async" 속성을 사용하여 이미지 디코딩이 메인 스레드를 차단하지 않도록 합니다.