TTV와 TTI 차이
웹 성능을 공부하다 보면 TTV와 TTI라는 표현을 만난다.
둘 다 사용자가 느끼는 속도와 관련이 있지만 같은 의미는 아니다.
TTV는 보통 Time to View로 설명한다.
사용자가 화면에서 의미 있는 콘텐츠를 보기 시작하는 시점을 말할 때 쓰인다.
TTI는 Time to Interactive다.
페이지가 보여지는 것을 넘어 사용자가 클릭, 입력, 탭 같은 동작을 할 수 있는 상태가 되는 시점을 말한다.
초보자 기준으로는 이렇게 구분하면 된다.
보이는 속도는 TTV에 가깝다.
눌렀을 때 반응하는 속도는 TTI에 가깝다.
TTV의 기준
TTV는 표준화된 단일 Web API 지표라기보다 경험을 설명하는 표현에 가깝다.
사용자가 빈 화면이 아니라 실제 콘텐츠를 보기 시작하는 시점을 말할 때 사용한다.
예를 들어 블로그 글 페이지를 연다고 해보자.
상단 헤더와 글 제목이 먼저 보이고, 나머지 이미지가 조금 늦게 로드될 수 있다.
이때 사용자는 이미 페이지가 열렸다고 느낄 수 있다.
이 감각은 First Contentful Paint, Largest Contentful Paint 같은 지표와 연결해서 보는 편이 좋다.
FCP는 첫 텍스트나 이미지 같은 콘텐츠가 화면에 처음 그려지는 시점을 본다.
LCP는 뷰포트 안의 가장 큰 주요 콘텐츠가 그려지는 시점을 본다.
그래서 TTV를 엄밀히 측정해야 한다면 서비스의 기준을 정해야 한다.
글 제목이 보이면 볼 수 있다고 할지, 대표 이미지까지 보여야 볼 수 있다고 할지 정해야 한다.
TTI의 기준
TTI는 Time to Interactive의 약자다.
페이지가 사용자 입력에 안정적으로 반응할 수 있는 시점을 설명하는 지표다.
예를 들어 화면은 이미 보이는데 버튼을 눌러도 아무 반응이 없다면 사용자는 페이지가 느리다고 느낀다.
JavaScript를 아직 다운로드하거나 실행하는 중이라면 이런 일이 생길 수 있다.
TTI는 이런 상황을 설명하기 위해 사용됐다.
페이지가 보이는 것과 실제로 사용할 수 있는 것은 다르기 때문이다.
다만 TTI는 요즘 성능 관리의 중심 지표로 쓰기에는 한계가 있다.
Lighthouse에서도 TTI는 과거에 중요하게 다뤄졌지만, 현재 사용자 상호작용 품질을 볼 때는 INP를 더 직접적으로 보는 흐름이다.
FCP와 LCP의 관계
FCP는 First Contentful Paint다.
사용자가 페이지에 진입한 뒤 텍스트, 이미지, SVG, canvas 같은 콘텐츠가 처음 화면에 렌더링되는 시점을 측정한다.
페이지 요청 -> HTML 수신 -> 첫 텍스트나 이미지 표시FCP가 빠르면 사용자는 “무언가 뜨고 있다”고 느낀다.
하지만 FCP만 빠르다고 해서 중요한 콘텐츠가 다 보였다는 뜻은 아니다.
LCP는 Largest Contentful Paint다.
뷰포트 안에서 가장 큰 주요 콘텐츠가 렌더링되는 시점을 측정한다.
블로그라면 제목, 대표 이미지, 본문 첫 영역 같은 것이 영향을 줄 수 있다.
첫 콘텐츠 표시 -> 주요 콘텐츠 표시TTV를 실제 지표로 연결한다면 FCP와 LCP를 함께 보는 편이 좋다.
FCP는 첫 신호이고, LCP는 주요 콘텐츠가 보이는 시점에 더 가깝다.
INP의 관계
INP는 Interaction to Next Paint다.
사용자의 클릭, 탭, 키보드 입력 같은 상호작용에 페이지가 얼마나 빨리 시각적으로 반응하는지 본다.
Core Web Vitals에서 현재 상호작용 품질을 볼 때는 INP가 중요하다.
web.dev 문서 기준으로 INP는 안정적인 Core Web Vital이며, 페이지 생명주기 동안 발생한 상호작용 지연을 관찰한다.
TTI가 “언제부터 상호작용 가능해지는가”에 가까운 지표라면, INP는 “실제 상호작용들이 얼마나 빨리 반응하는가”에 가깝다.
그래서 최신 성능 개선에서는 TTI만 보기보다 INP를 함께 보는 편이 더 실용적이다.
예를 들어 초기 로딩 후 버튼을 눌렀는데 화면 반응이 600ms 뒤에 나타난다면 INP가 나빠질 수 있다.
사용자는 페이지가 이미 보이는 상태에서도 답답함을 느낀다.
TTV와 TTI의 차이
TTV와 TTI는 사용자가 느끼는 두 순간을 나눠서 설명한다.
| 구분 | 관심사 | 관련 지표 |
|---|---|---|
| TTV | 화면에서 콘텐츠를 볼 수 있는 시점 | FCP, LCP |
| TTI | 페이지를 조작할 수 있는 시점 | TTI, INP, TBT |
- 관심사
- 화면에서 콘텐츠를 볼 수 있는 시점
- 관련 지표
- FCP, LCP
- 관심사
- 페이지를 조작할 수 있는 시점
- 관련 지표
- TTI, INP, TBT
TTV가 빠르면 사용자는 빈 화면을 오래 보지 않는다.
TTI가 빠르면 사용자는 버튼이나 입력창을 눌렀을 때 바로 반응을 얻는다.
둘 중 하나만 좋아서는 충분하지 않다.
화면은 빨리 보이지만 클릭이 안 되면 답답하다.
반대로 상호작용 준비는 빨라도 화면이 늦게 뜨면 첫인상이 나쁘다.
개선 방향
TTV를 개선하려면 먼저 화면에 필요한 리소스를 빨리 가져오고 렌더링해야 한다.
서버 응답 시간을 줄이고, 렌더링을 막는 CSS와 JavaScript를 줄이고, 핵심 이미지를 최적화하는 방식이 도움이 된다.
HTML 응답 빠르게 만들기
중요 CSS 우선 처리
초기 JavaScript 줄이기
대표 이미지 최적화TTI와 INP를 개선하려면 JavaScript 실행 시간을 줄이는 것이 중요하다.
큰 번들을 나누고, 필요 없는 코드를 늦게 불러오고, 긴 작업을 쪼개는 식으로 메인 스레드가 오래 막히지 않게 해야 한다.
초기 번들 줄이기
코드 스플리팅
긴 task 쪼개기
이벤트 핸들러 가볍게 유지
불필요한 hydration 줄이기Next.js나 Nuxt 같은 프레임워크를 쓴다면 서버 렌더링, 이미지 최적화, 라우트 단위 코드 분리 같은 기능도 함께 본다.
성능 지표는 하나의 숫자보다 병목을 찾기 위한 단서로 보는 편이 좋다.
측정 도구
가장 쉽게 시작하려면 PageSpeed Insights나 Lighthouse를 사용한다.
PageSpeed Insights는 실제 사용자 데이터가 있으면 field data를 보여주고, Lighthouse는 실험실 환경에서 진단 정보를 제공한다.
Chrome DevTools Performance 패널도 유용하다.
초기 로딩 중 어떤 JavaScript가 오래 실행되는지, 어떤 작업이 렌더링을 막는지 확인할 수 있다.
실제 서비스에서는 field data가 중요하다.
사용자의 기기, 네트워크, 브라우저 상태가 다르기 때문이다.
web-vitals 라이브러리를 사용하면 FCP, LCP, INP 같은 지표를 JavaScript로 수집하는 흐름을 만들 수 있다.
정리
TTV는 사용자가 콘텐츠를 보기 시작하는 시점에 가깝다.
실제 측정에서는 FCP와 LCP를 함께 보면 좋다.
TTI는 사용자가 페이지를 조작할 수 있는 시점에 가깝다.
현대적인 상호작용 품질 관리는 TTI만 보기보다 INP를 함께 보는 편이 좋다.
웹 성능을 볼 때는 “보이는가”와 “반응하는가”를 나눠서 생각한다.
화면이 빨리 보이는 것과 사용자가 바로 조작할 수 있는 것은 다른 문제다.
참고 자료
