성능은 결국 체감이다

처음엔 성능 최적화를 하면

번들 크기
React memo
Reflow
tree shaking

같은 기술적인 것들만 계속 보게 됐다.

근데 실제 서비스를 만들다 보니
사용자는 그런 걸 전혀 모른다는 걸 느꼈다.

심지어 회사사람들도....

사용자가 느끼는 건 결국 두 가지였다.

"언제 화면이 보이기 시작하나?"
"언제 메인 콘텐츠를 볼 수 있나?"

그리고 그걸 측정하는 대표적인 지표가:

FCP
LCP

였다.

FCP (First Contentful Paint)

FCP는 브라우저가 처음으로 의미 있는 콘텐츠를 화면에 그리는 시점이다.

예를 들어:

텍스트
이미지
SVG
canvas

같은 실제 콘텐츠가 처음 나타나는 순간을 의미한다.

실제 사용자 입장에서 중요한 건

완전히 로딩됐는가

보다

"화면이 언제부터 보이기 시작하냐"

라고 한다

로딩은 아직 덜 끝났어도
skeleton UI나 텍스트가 먼저 보이면

사용자는 훨씬 빠르다고 느낀다.

CSR 앱에서 특히 체감이 컸다

React CSR만 사용했을 때 가장 많이 느꼈던 문제도 이거였다.

빈 화면
→ JS 다운로드
→ JS 실행
→ React hydration
→ 화면 등장

특히 번들이 커질수록

하얀 화면 유지 시간

이 길어진다.

모바일 저사양 기기에선 훨씬 심하다.

처음엔

"요즘 인터넷 빠른데 괜찮지 않나?"

싶었는데,

실제로는 네트워크보다:

JS 파싱
JS 실행
hydration

비용이 꽤 컸다.

Next.js SSR의 FCP

처음엔 SSR의 장점을 SEO 정도로만 생각했다.

근데 실제론 FCP 체감 차이가 꽤 크다.

SSR은

서버에서 HTML 생성
→ 브라우저가 바로 렌더링 가능

이라서 최소한 콘텐츠는 빨리 보인다.

즉

"빈 화면"

시간을 줄여준다.

이게 생각보다 UX에 엄청 중요했다.

FCP가 느려지는 대표 원인

큰 JS 번들
render blocking CSS
느린 TTFB
폰트 로딩
hydration 비용

전부 연결되어 있었다.

폰트 하나 때문에 텍스트가 안 보일 수도 있다

처음엔 폰트 최적화를 거의 신경 안 썼다.

근데 웹폰트 로딩 중:

텍스트 invisible

상태가 발생할 수 있다는 걸 알고 놀랐다.

그래서:

font-display: swap;

이 중요했다.

완벽한 폰트보다 일단 보이는것! 이 UX에 더 중요하다는 걸 느꼈다.

LCP (Largest Contentful Paint)

LCP는 화면에서 가장 큰 콘텐츠가 완전히 렌더링되는 시점이다.

보통은:

hero image
메인 배너
큰 텍스트 블록

같은 요소가 된다.

즉 FCP가

"뭔가 보이기 시작"

이라면,

LCP는

"메인 콘텐츠가 거의 다 보임"

에 가깝다.

실제로 사용자는 LCP를 더 강하게 체감한다

사람은 “뭔가 보이는 것”보다
“메인 콘텐츠가 준비됐는지”를 더 중요하게 느낀다는 점이었다.

예를 들어

헤더 먼저 뜸
작은 텍스트 먼저 뜸

보다,

메인 이미지
메인 상품
메인 콘텐츠

가 언제 뜨는지가 체감 속도에 훨씬 큰 영향을 준다.

그래서 LCP가 Core Web Vitals에서 굉장히 중요하게 취급된다.

Next.js에서 이미지 하나가 성능을 망치는 순간

왜 next/image를 써야하는지 이해가 되었다.

<Image />

가 일반 img보다 불편해 보였다.

근데 실제론:

lazy loading
responsive image
크기 최적화
포맷 최적화

를 자동 처리한다.

특히 width/height 강제하는 이유도 좋았다.

단순 타입 제한이 아니라 CLS 방지까지 연결 되어 있었다.

preload의 의미

예전엔:

<link rel="preload">

를 그냥 “미리 다운로드” 정도로 생각했다.

근데 LCP를 공부하면서 중요성이 보였다.

브라우저는 기본적으로:

HTML 파싱
→ CSS 발견
→ JS 발견
→ 이미지 발견

순서로 리소스를 찾는다.

즉 hero image를 늦게 발견할 수도 있다.

근데 preload를 쓰면:

<link rel="preload" as="image" href="main.jpg" />

브라우저에게:

"이거 중요하니까 먼저 받아"

라고 알려주는 셈이다.

lazy loading도 무조건 좋은 건 아니었다

처음엔:

"lazy loading 많이 할수록 좋겠네?"

라고 생각했다.

근데 LCP 요소까지 lazy loading 걸면
오히려 메인 콘텐츠가 늦어진다.

즉:

화면 밖 → lazy
첫 화면 핵심 콘텐츠 → 즉시 로딩

구분이 중요했다.

결국 성능은 “얼마나 빨리 신뢰를 주는가”

FCP와 LCP를 공부하면서 가장 크게 느낀 건

사용자는 실제 완료 시간보다
“언제부터 사용할 수 있다고 느끼는가”에 더 민감하다는 점이었다.

그래서 지금은 성능을 볼 때도:

번들 크기
hydration
이미지 크기
SSR
preload
lazy loading

을 전부:

"사용자가 언제 화면을 신뢰하기 시작하는가"

관점으로 보게 된다.

그 순간부터 Lighthouse 숫자도 단순 점수가 아니라,
실제 UX 지표처럼 느끼는것 같다.

FCP, LCP