'부하 테스트(Load Testing)'라는 말을 들으면 대부분은 백엔드를 떠올린다. 서버가 얼마나 많은 요청을 동시에 감당할 수 있을까? 몇 명까지 무너지지 않고 버틸 수 있을까? 이 질문에 답하는 것이 전통적인 의미의 부하 테스트다.
하지만 프론트엔드에서는 이 개념이 다르게 작동한다. 하나의 사용자가 웹 페이지를 마주했을 때 브라우저는 얼마나 빠르고 안정적으로 반응하는가를 묻는다. 이는 엄밀히 말하면 성능 테스트(Performance Testing)에 더 가깝다.
결국 프론트엔드에서는 이런 질문을 던져야 한다. “사용자는 기다릴 수 있을까?”
1. 왜 중요할까?
좋은 사용자 경험이란 단지 기능이 잘 작동하는 것이 아니다. 빠르고, 매끄럽고, 기다리지 않게 하는 것. 속도는 기능모다 먼저 체감된다. 사용자가 떠나는 이유는 종종 '느려서'이지, ‘망가져서'가 아니다.
사용자 경험
웹 사이트가 빠르다는 것은, 곧 '쾌적하다’는 뜻이다. 사람은 기다림에 관대하지 않다. 버튼을 눌렀는데 반응이 없거나, 화면에 늦게 뜨면 사용자는 기능을 이해하기도 전에 이탈한다. 한국처럼 네트워크 환경이 좋은 나라에서는 보통 2초 정도까지는 기다린다고 한다. 반면, 네트워크 환경이 좋지 않은 국가에서는 3초 정도가 일반적이라고 한다.
검색 엔진 최적화(SEO)
Google은 속도를 점수화한다. 콘텐츠의 품질만 평가하지 않는다. Core Web Vitals라는 기준을 통해 '얼마나 빠르게', ‘얼마나 안정적으로’ 보여주는지를 검색 랭킹 요소로 반영한다. 특히 LCP(로딩), CLS(레이아웃 안정성), INP(반응 속도) 점수는 직접적으로 SEO 지표에 포함된다.
전환율 증가
속도는 매출이다. Amazon은 100ms의 로딩 지연이 매출을 1% 감소시킨다고 밝혔다. Google의 리서치에 따르면 로딩 속도가 1초에서 3초로 늘어나면 이탈 활륙일 32% 증가한다. 특히 커머스나 결제 중심 서비스에서는, 딜레이는 곧 손실이다.
기술 부채
성능 문제는 쌓인다. 그리고 나중에는 고치기 어렵다. 렌더링 병목, 무거운 컴포넌트, 비효율적인 리소스 로딩. 이 모든 것이 초기 대응이 늦어지면 유지보수 비용으로 돌아온다. 성능 테스트는 코드 품질을 지키는 첫 방어선이다.
2. 무엇을 측정해야 할까?
모든 성능은 결국 숫자로 드러난다. 하지만 어떤 숫자를 봐야 하는지는 분명해야 한다. Google은 이를 Core Web Vitals(CWV)라는 이름으로 정의했다. 단순히 빠른가가 아니라, 사용자에게 빠르게 느껴지는가를 기준으로.
Core Web Vitals
- LCP (Largest Contentful Paint): 가장 큰 콘텐츠(텍스트 혹은 이미지)가 화면에 보일 때까지 걸리는 시간. 2.5초 이내면 이상적이다.
- INP (Interaction to Next Paint): 사용자가 클릭하거나 입력했을 때 시각적 반응이 나타나기까지의 시간. 200ms 이내가 목표다. 기존의 FID(First Input Delay)를 대체한 새로운 기준이다.
- CLS (Cumulative Layout Shift): 로딩 중 발생하는 예기치 않은 레이아웃 변경의 총량. 0.1 이하가 안정적이다.
기타 지표
- FCP (First Contentful Paint): 페이지에 첫 콘텐츠가 등장하기까지의 시간
- TTFB (Time to First Byte): 서버에서 첫 바이트를 받기까지의 시간
- TTI (Time to Interactive): 사용자가 상호작용 가능한 상태가 될 때까지의 시간
- TBT (Total Blocking Time): TTI 전까지 사용자가 아무것도 할 수 없는 시간의 총합
3. 어떻게 측정할까?
구글은 여러가지 웹 페이지 성능을 측정할 수 있는 다양한 도구들을 제공하고 있다. 각 도구는 조금씩 다르지만 공통적으로 Core Web Vitals(LCP, INP/FID, CLS)를 측정할 수 있다. 이외에도 서드파티 툴도 있다.
4. 어떻게 최적화할까?
➊ LCP 최적화: 가장 먼저, 가장 빠르게
- HTML에서 바로 보이게 하라. LCP 리소스는 HTML에 직접 포함되어야 한다. 브라우저는 HTML을 먼저 파싱하므로,
에 src 또는 srcset을 명시하라.
- 우선순위를 확보하라. LCP 이미지는 가장 먼저 다운로드돼야 한다. fetchpriority="high"를 선언하라.
외부 CSS/JS에 포함된 경우 를 사용해 미리 요청하라.
- TTFB를 줄여라. LCP 이전에 HTML이 빨리 와야 한다. CDN을 통해 사용자 가까이에 콘텐츠를 배포하라.
실전 가이드
- 태그에 src 또는 srcset 명시
→ 이미지를 HTML 내에서 직접 선언하라. 브라우저가 빠르게 인식하고 로드한다. - SSR(Server-Side Rendering) 선호
→ CSR보다 HTML과 이미지가 더 빨리 도착한다. 구조적으로 유리하다. - 외부 CSS/JS에서 로드되는 이미지
→ 를 사용해 사전 로딩하라. 의존 리소스에 묻히지 않게 하라. - fetchpriority="high" 속성 추가
→ 브라우저에게 “이건 중요하다”고 알려라. 우선순위가 달라진다. - loading="lazy"는 LCP 이미지에 절대 금지
→ Lazy loading은 LCP를 지연시킨다. 가장 먼저 보여야 할 것에 ‘게으름’을 허락하지 마라.
사례 비교
- LCP 이미지보다 CSS, JS가 먼저 불린다.
- 브라우저는 중요한 이미지를 나중에야 찾는다.
- 병목 구간이 생긴다. 사용자는 빈 화면을 본다.
- HTML에 직접 선언된 이미지가 첫 번째 리소스로 로드된다.
- 렌더링 경로가 단순해진다.
- 사용자에게 더 빠르게, 더 확실하게 보여준다.
➋ CLS 최적화: 레이아웃 흔들림을 없애라
- 모든 콘텐츠는 명시적인 크기를 가져야 한다. 이미지, 배너, 폰트 로딩 등 가로·세로 크기를 고정하지 않으면 CLS가 발생한다.
- 레이아웃에 영향을 주는 CSS 애니메이션은 피하라. height, width, top, left 변화는 브라우저 재배치를 유발한다. 트랜지션 시 transform, opacity를 사용하라.
- bfcache (Back/Forward Cache)에 적합하도록 페이지 구조를 단순화하라. 세션 복원을 방해하지 않아야 한다. 레이아웃 안정성이 높을수록 캐시에 적합하다.
실전 가이드
- width, height 속성을 반드시 지정하라. 레이아웃 공간을 미리 계산할 수 있도록 한다.
- aspect-ratio 속성으로 고정된 비율을 설정하라. 특히 반응형 이미지에 유용하다.
- min-height를 지정해 예측 가능한 레이아웃을 확보하라.예상치 못한 점프 현상을 방지할 수 있다.
사례 비교
- Before: 이미지나 배너가 늦게 로드되어, 기존 콘텐츠를 밀어낸다. 사용자 경험을 망친다. CLS 점수가 나빠진다.
- After: 공간을 미리 예약한다. 이미지가 늦게 떠도 위치는 그대로다. 레이아웃은 안정적이다. 사용자 경험도 개선된다.
➌ FID 최적화: 입력에 즉시 응답하라
- 긴 작업은 쪼개라. 50ms 넘는 작업은 사용자 입력을 막는다. 태스크는 작을수록 좋다.
- 불필요한 자바스크립트를 제거하라. 쓰이지 않는 JS는 빌드에서 제거하고, 코드 스플리팅을 통해 필요한 순간에만 로드하라.
- 무거운 렌더링을 피하라. 크고 복잡한 DOM은 렌더링 비용이 크다. 구조를 단순화하라.
실전 가이드
- 긴 작업은 작은 단위로 나누고, 필요 시 requestIdleCallback 또는 setTimeout으로 나눠 실행하라.
- 메인 스레드에 양보하라. yielding 전략은 응답성을 높인다.
- DevTools의 Coverage 탭으로 사용하지 않는 JS를 확인하라.
- 코드 스플리팅을 통해 초기에 필요한 코드만 로딩하라.
- 불필요한 태그는 주기적으로 정리하라. SEO, 메타 태그, 스니펫 삽입 코드 등이 대표적이다.
- requestAnimationFrame()은 오직 시각적 작업에만 사용하라.
- DOM의 깊이와 크기를 제한하라. 작고 평평한 DOM이 빠르다.
- Before: 하나의 큰 태스크가 UI 스레드를 독점한다. 사용자는 클릭해도 반응이 없다.
- After: 태스크가 잘게 나뉘어 실행된다. 사용자는 즉시 반응을 체감한다.
Reference
23년 6월 Tech 세미나 - 웹 프론트엔드 성능 최적화 방법 및 적용 사례
웹 프론트엔드 개발자가 웹 성능 최적화를 해야 하는 이유