H-4: 웹 성능 측정 ② — 조건을 바꿔 재고, 사용자에게서 모읍니다

안녕하세요, 홍순구 튜터입니다.

지난 시간에 우리는 지표 세 개를 갈라놓고 두 개만 채웠습니다.

 LCP   1068 ms    통과
 INP      ?
 CLS   0.0000     통과  (밀림을 고쳤습니다)

오늘은 저 빈칸부터 채웁니다. 재는 코드는 이미 있어서 몇 줄만 더하면 되고 실제로 십 분이면 붙는데, 막상 붙이고 새로고침하면 이렇게 나와요.

[성능] 사진 다 옴 — LCP 1068ms · INP 아직 없음 · CLS 0.0000 · 사진 10/10

여전히 비어 있죠. 새로고침을 몇 번 더 해도 똑같습니다. 코드가 잘못된 게 아니에요. 이 값은 우리가 기다린다고 생기는 종류가 아닙니다.

오늘은 여기서 출발해서 같은 앱을 조건만 바꿔가며 재보면, 같은 화면인데 숫자가 다섯 배 차이 나는 것을 보게 되실 거예요. 마지막에는 우리 노트북을 떠나서 실제 사용자들이 겪는 숫자도 모으기 시작합니다.

 오늘의 여정

 1. 눌러야 생기는 값        아직 없음  ->  32ms
 2. 그 시간은 어디로         기다림 / 우리 코드 / 그리기
 3. 느린 기기에서는          32  ->  112ms
 4. 조건을 통째로 바꾸면      1.1s  ->  4.9s
 5. 그 점수의 정체           79점, 그런데 INP 가 없다
 6. 사용자에게서 모은다       0  ->  1
 7. 봉투를 열어본다          범인을 이름으로 지목
 8. 그 값                   +61 kB, 40 kB/방문

💡 오늘 수업의 핵심 — "같은 앱인데 재는 조건이 다르면 숫자가 다섯 배 갈립니다. 어느 쪽도 거짓말이 아니에요"

🎯 학습 목표

• 사용자가 눌러야만 생기는 지표를 직접 재고, 그 시간이 어디에서 쓰였는지 세 칸으로 갈라 읽습니다.
• 같은 앱을 조건만 바꿔 재서 숫자가 어떻게 달라지는지 확인하고, 흉내 낸 조건이 알려줄 수 있는 것과 원리적으로 알려줄 수 없는 것을 구분합니다.
• 우리 화면의 숫자를 넘어 실제 사용자에게서 속도를 모으기 시작하고, 그 대가가 얼마인지 숫자로 답합니다.

Step 1: "INP는 누가 눌러야 나옵니다"

앞의 둘과 셋째는 성격이 다릅니다

지난 시간에 우리가 LCP와 CLS를 어떻게 얻었는지 떠올려볼게요. 우리는 브라우저에게 물어보기만 했습니다. 관찰자를 하나 붙이고 "가장 큰 것이 그려지면 알려줘", "뭔가 밀리면 알려줘"라고 해두면 브라우저가 알아서 기록해뒀다가 넘겨줬어요.

INP는 그렇지 않습니다.

 LCP  화면을 그리다 보면 저절로 생긴다
 CLS  화면이 움직이면 저절로 생긴다
 INP  아무도 안 누르면 영원히 안 생긴다

INP는 Interaction to Next Paint, 우리말로 하면 "누른 뒤 다음 그림까지"입니다. 사용자가 뭔가를 눌러야 시작되는 값이라 아무도 안 누른 화면에는 잴 것이 없는데, 그래서 우리가 지금까지 아무리 새로고침을 해도 칸이 안 채워졌던 거예요.

브라우저에게 무엇을 물어봐야 하나

LCP는 largest-contentful-paint, CLS는 layout-shift였죠. 상호작용은 event입니다.

// apps/web-spa/src/lib/h3-vitals.ts

  if (canObserve('event')) {
    const inpObserver = new PerformanceObserver((list) => {
      for (const entry of list.getEntries()) {
        const eventEntry = entry as PerformanceEntry & { interactionId?: number };

        // 스크롤처럼 사용자가 답을 기다리지 않는 것도 event 로 들어온다.
        // 브라우저가 그런 것에는 interactionId 를 0 으로 줘서 갈라준다.
        if (!eventEntry.interactionId) {
          continue;
        }

        const previous = interactions.get(eventEntry.interactionId) ?? 0;
        interactions.set(eventEntry.interactionId, Math.max(previous, entry.duration));
      }

      state.inp = worstInteraction(interactions);
      state.interactions = interactions.size;
      report({ ...state, shifts: [...state.shifts] });
    });

    inpObserver.observe(options);
    observers.push(inpObserver);
  }

interactions라는 Map이 하나 보이시죠. 왜 그냥 배열에 쌓지 않고 번호를 키로 묶는지가 이 Step의 핵심입니다.

한 번 눌렀는데 줄이 여러 개 찍힙니다

앱을 띄우고 하트를 두 번만 눌러보세요. 콘솔에 이렇게 나옵니다.

[성능] 재는 중 — LCP 1068ms · INP 16ms (상호작용 2건) · CLS 0.0000 · 사진 10/10
[성능] 재는 중 — LCP 1068ms · INP 16ms (상호작용 2건) · CLS 0.0000 · 사진 10/10
[성능] 재는 중 — LCP 1068ms · INP 24ms (상호작용 2건) · CLS 0.0000 · 사진 10/10
[성능] 재는 중 — LCP 1068ms · INP 24ms (상호작용 3건) · CLS 0.0000 · 사진 10/10
[성능] 재는 중 — LCP 1068ms · INP 24ms (상호작용 3건) · CLS 0.0000 · 사진 10/10

두 번 눌렀는데 줄은 다섯 개인데, 괄호 안의 숫자를 보시면 2에서 3으로 한 번만 늘었습니다.

이유는 하트를 한 번 누르면 브라우저가 이벤트를 세 개 만들기 때문입니다. 손가락이 내려갈 때 pointerdown, 떼어질 때 pointerup, 그리고 click. 셋을 따로 세면 한 번 누른 것이 세 번으로 보이겠죠.

브라우저는 이 셋에 같은 interactionId를 붙여줘서, 우리는 그 번호로 묶어 "이건 한 번이야"라고 셀 수 있어요. 셋 중에서는 가장 오래 걸린 것을 그 상호작용의 시간으로 치는데, 사용자가 기다린 시간은 셋을 더한 값이 아니라 누른 순간부터 화면이 답할 때까지의 한 덩어리니까요.

여럿 중에 무엇이 답인가

열 번 눌렀으면 값이 열 개 나옵니다. 그중 무엇을 INP라고 부를까요?

function worstInteraction(durations: Map<number, number>): number | null {
  if (durations.size === 0) {
    return null;
  }

  const sorted = [...durations.values()].sort((a, b) => b - a);
  const index = Math.min(sorted.length - 1, Math.floor(sorted.length / 50));

  return sorted[index];
}

내림차순으로 정렬한 다음 Math.floor(길이 / 50) 번째를 고릅니다. 열 번 눌렀으면 floor(10 / 50)이 0 이니까 가장 나쁜 하나가 곧 INP예요.

왜 평균이 아니라 최악일까요? 사용자가 앱을 쓰다가 아홉 번은 즉각 반응했고 한 번 크게 버벅였다면, 기억에 남는 것은 그 한 번입니다. 평균을 내면 그 한 번이 아홉 번에 희석돼서 사라져버려요.

그렇다면 / 50은 뭘까요. 오래 쓰는 사람일수록 딸꾹질을 한 번쯤 만날 확률이 높습니다. 그 한 번으로 앱 전체를 판정하면 억울하니까, 상호작용이 50건 늘어날 때마다 가장 나쁜 것을 하나씩 걷어내주는 겁니다. 우리처럼 몇 번 안 눌렀으면 걷어낼 것이 없고요.

⚠️ 그래서 한 번 재고 끝내면 안 됩니다

이 정의 때문에 재미있는 일이 생깁니다. 저는 우리 앱을 같은 방법으로 열다섯 번 재봤는데, 열네 번은 32ms 근처였고 한 번은 248ms가 나왔어요.

그 회차의 상호작용 열 개를 늘어놓으면 이렇습니다.

 248  32  24  24  24  24  24  24  24  24
  ^
  이 하나가 INP 를 정한다

아홉 개는 멀쩡한데 하나가 튀었고, 정의상 그 하나가 답이 됩니다. 앱이 갑자기 나빠진 게 아니라 그 순간 브라우저가 다른 일에 잠깐 붙들렸던 거예요.

여기서 배울 것은 두 가지입니다. 하나는 INP 는 한 번 재고 "우리 앱은 32ms"라고 말하면 안 된다는 것. 다른 하나는, 그래서 진짜 답은 우리 노트북에서 몇 번 재보는 게 아니라 많은 사용자에게서 모으는 것이라는 겁니다. 그건 Step 6에서 합니다.

⚠️ 0이 아니라 "아직 없음"입니다

아직 아무도 안 눌렀을 때 우리 코드는 null을 돌려줍니다. 0이 아니에요.

이게 왜 중요한지는 지난 시간에 이미 겪으셨습니다. CLS가 0으로 나왔을 때 그게 "안 밀렸다"인지 "사진이 안 와서 잴 게 없었다"인지 구별이 안 됐죠. 여기서도 똑같습니다.

 INP 0ms        ->  "우와 엄청 빠르다"
 INP 아직 없음   ->  "아직 아무도 안 눌렀구나"

0으로 두면 아무도 안 써본 화면이 세상에서 가장 빠른 화면으로 보고됩니다. 잰 적이 없는 것과 빠른 것은 다릅니다.

⚠️ 타입이 브라우저를 못 따라온 곳

위 코드에서 observe(options)라고 변수를 넘긴 게 눈에 걸리셨을 수 있습니다. 보통은 이렇게 쓰죠.

inpObserver.observe({ type: 'event', buffered: true, durationThreshold: 16 });

이대로 쓰면 타입 검사가 막습니다.

error TS2353: Object literal may only specify known properties,
and 'durationThreshold' does not exist in type 'PerformanceObserverInit'.

브라우저는 이 옵션을 분명히 받는데 타입 정의에는 아직 없어서 생기는 어긋남이라, 받는 모양을 우리가 한 번 적어주고 변수로 넘깁니다.

interface EventObserverInit extends PerformanceObserverInit {
  durationThreshold: number;
}

const options: EventObserverInit = { type: 'event', buffered: true, durationThreshold: 16 };

as로 억지로 통과시킬 수도 있지만, 이렇게 해두면 오타도 잡히고 값이 숫자인지도 검사됩니다. 도구가 아직 모르는 것을 우리가 알려주는 쪽이 낫습니다.

💡 한 줄 정리

INP는 브라우저가 알아서 기록해두는 값이 아니라 누군가 눌러야 생기는 값이고, 한 번 누를 때 나오는 여러 이벤트를 interactionId로 묶은 뒤 그중 가장 나쁜 하나를 답으로 삼기 때문에 한 번 재고 끝내면 안 됩니다.

Step 2: "그 시간은 어디서 쓰였을까요"

24ms 를 알았다고 고칠 데를 아는 건 아닙니다

지난 시간에 CLS가 0.2214라는 것만으로는 아무것도 못 했던 것을 기억하시죠. 무엇이 밀렸는지 목록을 받고 나서야 사진에 닿을 수 있었습니다.

INP도 똑같습니다. "24ms 걸렸다"는 것만으로는 무엇을 고쳐야 할지 알 수 없고, 그 24ms 가 어디에서 쓰였는지를 봐야 합니다.

다행히 브라우저는 그 내역도 함께 줍니다. 누른 뒤 화면이 답할 때까지는 세 단계로 갈립니다.

 눌렀다 ─────> 우리 코드가 시작 ─────> 우리 코드가 끝 ─────> 화면에 그려짐

        (1)                   (2)                    (3)

• (1) 기다림 — 눌렀는데 브라우저가 다른 일을 하고 있어서 우리 코드를 아직 시작 못 한 시간
• (2) 우리 코드 — 우리가 붙인 onClick 같은 처리가 실제로 도는 시간
• (3) 그리기 — 그 결과를 화면에 그려서 눈에 닿기까지

세 칸을 계산합니다

브라우저가 주는 엔트리에는 시각이 여럿 들어 있습니다. 그것들을 빼면 세 칸이 나와요.

// apps/web-spa/src/lib/h3-vitals.ts

        interactions.set(eventEntry.interactionId, {
          duration: entry.duration,
          // 눌렀는데 브라우저가 다른 일을 하고 있어서 기다린 시간
          inputDelay: eventEntry.processingStart - entry.startTime,
          // 우리가 붙인 처리 코드가 도는 시간
          processing: eventEntry.processingEnd - eventEntry.processingStart,
          // 그 결과가 화면에 그려지기까지
          presentation: entry.startTime + entry.duration - eventEntry.processingEnd,
        });

startTime이 누른 시각, processingStart와 processingEnd가 우리 코드의 시작과 끝, 그리고 startTime + duration이 화면이 답한 시각입니다. 빼기 세 번이면 끝이에요.

한 가지 더 손봐야 했습니다. 전에는 상호작용마다 숫자 하나(가장 긴 시간)만 기억했는데, 이제 그 시간의 내역까지 들고 있어야 하니 기억하는 것이 기록 하나로 바뀝니다.

function worstInteraction(records: Map<number, InteractionRecord>): InteractionRecord | null {
  if (records.size === 0) {
    return null;
  }

  const sorted = [...records.values()].sort((a, b) => b.duration - a.duration);
  const index = Math.min(sorted.length - 1, Math.floor(sorted.length / 50));

  return sorted[index];
}

고르는 규칙은 그대로고, 고른 뒤에 내역이 딸려온다는 것만 달라졌습니다.

⚠️ 평균이 아니라 그 한 번의 내역입니다

여기서 실수하기 쉬운 곳이 있어요. 상호작용이 열 개면 내역도 열 개인데, 그걸 평균 내면 안 됩니다.

INP는 최악의 한 번이었죠. 그럼 우리가 알고 싶은 것도 그 최악의 한 번이 어디에서 시간을 썼는지입니다. 나머지 아홉 번은 멀쩡했으니 평균에 섞으면 범인이 희석돼요.

그래서 위 코드는 고른 기록의 내역을 그대로 씁니다.

재봅니다

다시 하트를 누르면 줄이 하나 더 붙습니다.

[성능] 재는 중 — LCP 1108ms · INP 24ms (상호작용 1건) · CLS 0.0000 · 사진 10/10
         ↳ 기다림 5.7ms · 우리 코드 0.9ms · 그리기 17.4ms

세 칸을 더해보시면 5.7 + 0.9 + 17.4 = 24.0으로 정확히 INP와 같은데, 어디가 큰지도 바로 보이시죠. 그리기가 17.4ms 로 압도적이고, 우리가 쓴 코드는 0.9ms 입니다.

이게 무슨 뜻일까요. 우리가 좋아요 버튼에 붙인 코드는 상태를 하나 뒤집고 서버에 요청을 보내는 게 전부입니다. 그 일 자체는 1ms 도 안 걸려요. 시간의 대부분은 브라우저가 바뀐 화면을 실제로 그려서 모니터에 내보내는 데 쓰입니다.

💡 한 줄 정리

INP는 기다림 · 우리 코드 · 그리기 세 칸으로 갈리고, 우리 앱은 거의 전부가 마지막 칸입니다. 갈라서 봐야 "우리 코드를 고쳐야 하는가"와 "원래 그만큼 걸리는가"를 구별할 수 있습니다.

Step 3: "느린 기기에서는 어떨까요"

우리 노트북은 사용자의 기기가 아닙니다

지금까지 잰 숫자는 전부 우리 개발용 컴퓨터에서 나왔는데, 우리 사용자 중에는 몇 년 된 휴대폰으로 지하철에서 접속하는 사람도 있어요.

그 사람의 INP도 32ms 일까요?

직접 확인해볼 수 있습니다. 개발자 도구의 Performance 탭을 열면 톱니바퀴 아이콘 옆에 CPU라는 항목이 있고, 거기서 4x slowdown 같은 것을 고를 수 있어요. 브라우저가 일부러 느리게 도는 겁니다.

⚠️ 조이기는 화면이 다 뜬 다음에 거세요. 처음부터 걸어두면 페이지가 뜨는 것 자체가 느려져서, 우리가 재려는 것(누른 뒤의 반응)이 아니라 다른 것을 재게 됩니다.

배율을 올려가며 재봤습니다

각 배율에서 다섯 번씩, 회차마다 하트를 열 번 누른 결과입니다.

 CPU      INP        기다림      우리 코드       그리기
 1배      32 ms      0.1~0.7    0.0~0.1     31.3~31.8
 4배      32 ms      1.6~2.4    0.0~0.1     29.6~30.4
 10배     56 ms      5.0~11.0   0.0~0.9     46.3~53.0
 20배    112 ms      7.6~21.5   0.0~4.5    86.0~112.1

먼저 눈에 띄는 것은 4배까지는 거의 안 변한다는 겁니다. 32ms 그대로예요.

10배, 20배로 가면 늘어나기 시작하지만, 20배에서도 112ms 고 기준은 200ms 죠. 우리 앱은 스무 배 느린 기기에서도 INP를 통과합니다.

왜 이렇게 잘 버틸까요

세 칸으로 갈라 두길 잘했습니다. 이유가 표에 그대로 보이거든요.

「우리 코드」 칸을 보세요. 어느 배율에서도 0.0~4.5ms 입니다. 20배로 조여도 그렇습니다.

CPU를 20배 느리게 만들면 계산하는 일은 20배 느려지는데, 우리 코드가 하는 계산이 원래 0.1ms 어치밖에 없어서 20배가 되어도 2ms 예요. 늘어날 것이 없는 겁니다.

늘어나는 것은 그리기입니다. 31 → 30 → 50 → 100ms 로 배율을 따라가죠. 화면을 계산하고 칠하는 일은 진짜로 CPU를 쓰는 일이니까요.

 CPU 를 20배 조이면

 우리 코드    0.1ms  ->    2ms      (원래 할 일이 없다)
 그리기      31ms   ->  100ms      (진짜로 계산하는 일이다)

그러니 "우리 앱은 느린 기기에서도 잘 반응한다"는 결론은 맞지만, 그 이유는 우리가 최적화를 잘해서가 아니라 버튼이 하는 일이 원래 가벼워서입니다. 만약 좋아요 버튼이 누를 때마다 목록 전체를 다시 정렬하는 코드를 갖고 있었다면 이 표는 완전히 달랐을 거예요.

💡 한 줄 정리

CPU를 조여가며 재면 어느 칸이 진짜 계산이고 어느 칸이 기다림인지 갈립니다. 우리 앱은 20배에서도 통과하는데, 그 이유는 우리 코드가 빨라서가 아니라 할 일이 거의 없어서입니다.

Step 4: "조건을 통째로 바꿔서 재봅니다"

CPU만 조이는 걸로는 부족합니다

방금은 CPU 한 가지만 바꿨는데, 지하철에서 휴대폰으로 접속하는 사람은 CPU만 느린 게 아니에요. 인터넷도 느리고, 화면도 작습니다.

이 조건들을 한꺼번에 흉내 내주는 도구가 있습니다. 개발자 도구에 들어 있는 Lighthouse예요. 지난 시간 질문 토글에서 이름만 짚고 넘어갔던 그 도구입니다.

Lighthouse는 "느린 휴대폰 + 느린 인터넷"이라는 정해진 조건을 가정하고 우리 페이지를 처음부터 다시 불러온 뒤, 그 조건에서 나온 숫자로 점수를 매겨줘요.

터미널에서도 돌릴 수 있습니다.

npx lighthouse http://localhost:4173/ \
  --only-categories=performance \
  --form-factor=mobile \
  --throttling.cpuSlowdownMultiplier=4 \
  --throttling.rttMs=150 \
  --throttling.throughputKbps=1638 \
  --view

CPU 4배, 왕복 지연 150ms, 대역폭 약 1.6Mbps. 대충 몇 년 된 안드로이드 폰이 조금 느린 모바일 네트워크에 붙어 있는 상황입니다.

같은 앱인데 숫자가 다섯 배 갈립니다

우리가 직접 잰 값과 Lighthouse가 준 값을 나란히 놓아볼게요.

                우리가 잰 값        Lighthouse
 LCP            1.1 초             4.9 초
 CLS            0.0000            0
 INP            32 ms             (없음)

LCP가 1.1초에서 4.9초로 뜁니다. 기준이 2.5초니까 한쪽은 여유 있게 통과고 다른 쪽은 확실한 실패예요.

⚠️ 이 4.9초는 제 노트북에서 잰 값이고, 돌릴 때마다 4.7~5.2초 사이를 오갑니다. 우리 피드 사진을 바깥 사진 서비스에서 받아오는데 그쪽 응답이 매번 조금씩 다르기 때문이에요. 여러분 화면에서는 조금 다른 숫자가 나올 겁니다. 중요한 건 정확한 값이 아니라 네다섯 배 차이가 난다는 쪽입니다.

어느 쪽이 맞는 숫자일까요

학생분들이 여기서 가장 많이 묻는 질문입니다. 답은 둘 다 맞다예요.

우리가 잰 1.1초는 이 노트북에서 실제로 벌어진 일입니다. 거짓이 아니에요. Lighthouse의 4.9초는 저 조건이었다면 벌어졌을 일입니다. 이것도 거짓이 아닙니다.

두 숫자가 다른 이유는 앱이 달라서가 아니라 조건이 달라서라, 이 둘에는 이름이 따로 있습니다.

 우리가 직접 재는 것        실험실에서 재는 것
 Lighthouse 가 재는 것      정해진 조건을 흉내 낸 것

 실제 사용자에게서 모으는 것  현장에서 오는 것
                          Step 6 에서 시작합니다

실험실 값은 조건이 고정돼 있어서 비교하기 좋습니다. 고치기 전과 고친 뒤를 재면 코드가 좋아졌는지 나빠졌는지가 깨끗하게 갈려요. 대신 그 조건이 우리 사용자의 조건이라는 보장은 없습니다.

현장 값은 진짜 사용자의 숫자라 반박할 수 없습니다. 대신 사람마다 기기도 네트워크도 달라서 왜 나빠졌는지 짚기가 어려워요.

💡 한 줄 정리

같은 앱을 같은 순간에 재도 조건이 다르면 LCP가 1.1초로도 4.9초로도 나옵니다. 둘 다 참이고, 실험실 값은 변화를 재기에 좋고 현장 값은 무엇을 고칠지 정하기에 좋습니다.

Step 5: "그 점수는 무엇을 본 숫자일까요"

79점이 나왔습니다

Lighthouse를 돌리면 큰 동그라미 안에 점수가 뜹니다. 우리 앱은 이렇습니다.

 성능 점수   79 ~ 81

돌릴 때마다 한두 점씩 오르내리는데, LCP가 사진 도착 시각에 달려 있어서 그렇습니다.

다만 "79점"이라는 숫자 하나만 보면 아무것도 알 수 없습니다. 무엇을 보고 매긴 점수인지를 알아야 해요.

점수는 다섯 항목의 가중 평균입니다

Lighthouse의 성능 점수는 이렇게 만들어집니다.

 항목                          가중치
 FCP  첫 글자가 뜬 시각           10
 LCP  가장 큰 것이 뜬 시각         25
 TBT  총 차단 시간                30
 CLS  화면이 밀린 정도             25
 SI   화면이 채워지는 속도          10
                              ----
                              100

우리 앱의 각 항목은 이렇게 나왔습니다.

 FCP   2.1 초      0.81 점
 LCP   4.9 초      0.29 점      <- 여기가 깎인다
 TBT   0 ms        1.00 점      <- 만점
 CLS   0           1.00 점      <- 만점
 SI    2.2 초      0.99 점

깎이는 데가 LCP 하나라는 게 분명히 보이죠.

지난 시간에 우리가 한 일이 여기 찍혀 있습니다

재미있는 것을 보여드릴게요. 지난 시간에 사진 크기를 알려주기 전 상태로 되돌려서 같은 측정을 돌려봤습니다.

              고치기 전       고친 뒤
 성능 점수      66            80
 FCP          2.1 초        2.1 초
 LCP          4.9 초        4.9 초
 TBT          0 ms          0 ms
 CLS          0.289         0
 SI           2.2 초        2.2 초

움직인 칸이 정확히 하나입니다. 나머지 넷은 소수점까지 같아요.

CLS가 0.289에서 0이 되면서 그 항목 점수가 0.41에서 1.00이 됐고, 가중치가 25 니까 대략 14점이 올랐습니다. 66에서 80 으로요.

지난 시간에 우리가 고친 것은 코드 두 줄이었는데, 그 두 줄이 점수 14점이고 그 14점이 어디서 왔는지가 표에서 한눈에 갈립니다.

⚠️ 그런데 저 다섯 항목에 INP가 없습니다

다시 가중치 표를 보세요.

 FCP  10  ·  LCP  25  ·  TBT  30  ·  CLS  25  ·  SI  10

우리가 오늘 앞의 세 Step을 통째로 써서 잰 INP가 점수에 안 들어갑니다.

Lighthouse 안에 INP 관련 항목이 아예 없는 건 아니에요. inp-breakdown-insight라는 참고 항목이 있는데, 가중치가 0이라 점수에는 영향을 주지 않아요.

왜 그럴까요. Step 1의 이야기가 그대로 답입니다. INP 는 누가 눌러야 생기는 값인데, Lighthouse는 페이지를 열어보기만 하고 아무것도 안 누릅니다. 없는 값으로 점수를 매길 수는 없죠.

이건 Lighthouse가 게을러서가 아니라 원리적으로 못 하는 일입니다. 사용자가 무엇을 어떤 순서로 누를지 도구가 알 수 없으니까요.

⚠️⚠️ 그런데 TBT는 만점입니다

여기가 오늘 가장 조심해야 할 곳입니다.

TBT는 Total Blocking Time, 페이지가 뜨는 동안 브라우저가 다른 일에 붙들려 있던 시간의 합입니다. 우리 앱은 0ms 로 만점이고, 가중치는 다섯 항목 중 가장 큰 30이에요.

TBT가 만점이면 흔히 이렇게 읽습니다. "반응성 문제는 없구나."

그렇게 읽으면 안 됩니다. TBT와 INP는 다른 것을 잽니다.

 TBT   페이지가 뜨는 동안 브라우저가 붙들려 있던 시간
       -> 아무도 안 눌러도 잴 수 있다
       -> 첫 화면이 뜨는 몇 초 동안만 본다

 INP   누른 뒤 화면이 답할 때까지
       -> 눌러야만 잴 수 있다
       -> 사용자가 그 화면에 머무는 내내 본다

TBT가 0 인데 INP가 나쁜 앱은 얼마든지 있을 수 있습니다. 첫 화면은 가볍게 뜨는데 버튼을 누르면 무거운 계산이 도는 앱이 그렇죠. 그런 앱을 Lighthouse로 재면 높은 점수가 나옵니다.

이 문장을 기억해두시면 좋겠어요. Lighthouse 100점을 받고도 실제 사용자의 INP는 기준 미달일 수 있습니다. 저 점수는 아무도 안 누른 화면을 재서 매긴 값이라, 그게 가능한 이유를 우리는 지금 정확히 압니다.

💡 한 줄 정리

성능 점수는 다섯 항목의 가중 평균이고 거기에 INP는 없습니다. 가중치가 가장 큰 TBT가 만점이어도 그것은 반응성이 좋다는 뜻이 아니에요 — 아무도 안 누른 화면을 잰 값이기 때문입니다.

Step 6: "그래서 사용자에게서 모읍니다"

지난 시간에 남겨둔 한 줄

오류를 밖으로 내보내기 시작하던 시간에, 우리는 설정 파일에 이런 줄을 하나 두고 지나갔습니다.

// apps/web-spa/src/lib/monitoring.ts

    // 오류만 본다. 속도를 재는 일은 나중에 따로 다룬다.
    tracesSampleRate: 0,

그 "나중"이 오늘입니다.

tracesSampleRate는 속도 정보를 몇 번에 한 번 보낼까를 정하는 값입니다. 0은 아예 안 보낸다는 뜻이라, 지금까지 우리 오류 수집 서비스에는 오류만 쌓였습니다.

두 가지를 바꿉니다

// apps/web-spa/src/lib/monitoring.ts
const TRACES_SAMPLE_RATE = 1;

export function startMonitoring(): void {
  Sentry.init({
    dsn: DSN,

    // 속도도 함께 본다. 우리 화면에서 재던 것을 이제 사용자에게서 모은다.
    tracesSampleRate: TRACES_SAMPLE_RATE,

    integrations: [
      Sentry.reactRouterBrowserTracingIntegration({
        useEffect,
        useLocation,
        useNavigationType,
        createRoutesFromChildren,
        matchRoutes,
      }),
    ],

    environment: import.meta.env.DEV ? 'development' : 'production',
  });
}

하나는 tracesSampleRate를 1로 올린 것. 1은 전부 보낸다는 뜻이라 연습할 때 쓰는 값이에요. 실무에서는 이 값을 훨씬 낮춥니다. 왜 그런지는 Step 8에서 숫자로 보여드릴게요.

다른 하나는 통합을 하나 붙인 것입니다. 우리가 쓰는 라우터에게 "주소가 바뀌면 알려줘"라고 부탁하는 코드인데, 이게 있어야 어느 화면의 숫자인지 갈라서 볼 수 있어요. 라우터가 쓰는 함수 다섯 개를 그대로 넘겨주면 됩니다.

⚠️ 이름이 비슷한 것이 둘 있습니다

검색해보시면 reactRouterV7BrowserTracingIntegration이라는 이름도 나올 거예요. 버전 번호가 붙어 있죠.

그쪽은 더 이상 권장되지 않는 이름이라, 설치된 꾸러미의 타입 정의를 열어보면 이렇게 적혀 있어요.

@deprecated Use `reactRouterBrowserTracingIntegration` instead.

버전 접미사가 없는 쪽이 후계이고, 설명에 "React Router v6+"라고 적혀 있습니다. 우리가 쓰는 8.3.0도 여기 들어가요.

이런 갈림을 만날 때는 검색 결과보다 설치된 꾸러미의 타입 정의를 먼저 열어보세요. 검색 결과는 예전 글이 위에 올라와 있는 경우가 많은데, 우리 node_modules 안에 있는 것은 지금 우리가 실제로 쓰는 그 버전이거든요.

진짜로 오는지 확인합니다

연습용 수집 서비스를 띄우고 앱을 열어보면 이런 줄이 찍힙니다.

[속도받음] 39,021 B · 2164be853dc8482789fedfd927f22b54
          transaction — FCP 124 · LCP 1080
[받음] 505 B · (id 없음)
          session

[속도받음]이 뜨면 성공입니다. 우리 화면에서 콘솔로만 보던 숫자가 이제 밖으로 나가기 시작했어요.

💡 한 줄 정리

설정 한 줄과 통합 하나로 우리 화면의 숫자가 실제 사용자의 숫자가 되고, 그 과정에서 로그 문구가 코드보다 늦게 늙는다는 것도 함께 보셨어요.

Step 7: "봉투를 열어봅니다"

숫자만 오는 게 아닙니다

방금 온 39 kB 짜리 봉투를 열어보겠습니다. 안에는 이런 것들이 들어 있어요.

 measurements
   fp    64 ms      fcp  124 ms      lcp  1080 ms
   ttfb  2.8 ms     connection.rtt   150 ms

여기까지는 예상하신 대로라, 우리가 콘솔에서 보던 값이 그대로 실려 왔어요.

다만 그 옆에 이런 것이 함께 옵니다.

 lcp.element     img.w-full.cursor-pointer[alt="jaehoon 의 게시물"]
 lcp.url         https://picsum.photos/seed/post1/640/640
 lcp.size        220900
 lcp.loadTime    1053.1

LCP 가 1080ms 라는 것만 말해주는 게 아니라, 그 1080ms 를 만든 것이 무엇인지 CSS 선택자로 지목해줍니다. 어느 사진인지 주소까지 알려주고요.

지난 시간에 우리가 밀림의 범인을 찾을 때 목록을 보고 거슬러 올라가야 했던 것을 생각하면, 이건 꽤 친절한 셈입니다.

기기 조건도 함께 옵니다.

 deviceMemory              32 GB
 hardwareConcurrency       14
 effectiveConnectionType   4g

이게 왜 중요할까요. 나중에 "우리 LCP가 나쁘다"는 보고를 받았을 때, 그게 모든 사용자의 문제인지 특정 기기의 문제인지를 이 값들로 갈라볼 수 있기 때문입니다. Step 3에서 CPU를 조여가며 봤던 것을 실제 사용자 데이터로 하는 셈이에요.

⚠️ 그런데 CLS가 없습니다

봉투를 아무리 뒤져도 cls라는 항목이 없어요. 우리가 지난 시간에 그렇게 공들여 고친 그 값인데요.

버그가 아닙니다. 고쳐서 0이 됐기 때문에 보낼 것이 없는 겁니다. 밀린 것이 하나도 없으면 실을 것도 없죠.

확인해볼 방법은 있습니다. 지난 시간 과제에서 아직 안 고친 화면을 하나 남겨뒀거든요.

안 고친 화면의 봉투는 다릅니다

게시물 상세 화면(/p/1)을 열고 봉투를 받아보면 이렇게 옵니다.

[속도받음] 19,075 B · 5e3c1999711d4cb3aabc98b5146038a3
          transaction — FCP 540 · LCP 1092 · CLS 0.0485

CLS가 0.0485로 찍혀 있는데, 안을 열어보면 범인도 함께 옵니다.

 cls.source.1   div.px-(--card-spacing)

지난 시간 과제에서 이 화면의 CLS를 재보고 고치라고 말씀드렸는데, 혹시 안 하셨다면 우리가 만든 수집 장치가 그걸 그대로 찾아낸 겁니다.

이게 현장 데이터의 성격을 잘 보여줍니다. 우리는 홈 화면만 열심히 재고 "다 고쳤다" 고 생각했는데, 사용자들은 홈만 보는 게 아니죠. 상세 화면도 열고 탐색 화면도 엽니다. 우리가 안 재본 화면에서 무슨 일이 벌어지는지는 사용자에게서 모아야만 알 수 있습니다.

⚠️ INP는 다른 봉투로 옵니다

한 가지 더 있습니다. 하트를 눌러도 봉투가 안 옵니다. 여섯 번을 눌러도 조용해요.

그러다 화면을 떠나는 순간 작은 봉투가 하나 날아갑니다.

 1,057 B · span
   measurements.inp = 24.00

왜 이렇게 할까요. INP는 사용자가 더 누르면 더 나빠질 수 있는 값이라, 화면에 머무는 동안은 중간값을 확정할 수가 없습니다. 누를 때마다 보내면 봉투가 수십 개가 되기도 해서, 진짜 마지막 값을 아는 순간인 사용자가 그 화면을 떠나는 순간에 한 번만 보냅니다.

라이브러리가 이 판단을 대신 해주고 있는 겁니다.

💡 한 줄 정리

봉투는 숫자만 싣지 않고 범인을 CSS 선택자로 지목하고 기기 조건까지 함께 보내며, 우리가 안 재본 화면에서 무슨 일이 벌어지는지도 알려줘요 — 지난 시간 과제로 남겨둔 화면이 그대로 찍혀 올라왔습니다.

Step 8: "그 값은 얼마일까요"

공짜가 아닙니다

여기까지 오면 "그럼 다 켜두면 되겠네" 싶으실 텐데, 값을 먼저 보고 정하는 게 좋습니다. 우리가 오늘 배운 것이 정확히 그거잖아요. 재보고 나서 정하기.

세 가지 값이 있습니다.

첫째, 번들이 커집니다

추적 기능을 켜기 전과 후의 빌드 결과입니다.

 켜기 전    621.53 kB   (gzip 201.12 kB)
 켠 뒤      683.01 kB   (gzip 221.72 kB)
            -----------
 늘어난 것   +61.48 kB

61 kB는 적은 양이 아닙니다. 우리 앱 전체의 10% 예요. 게다가 이건 모든 사용자가 매번 받아가는 파일입니다.

이게 실제로 느려짐으로 이어질까요. 재봤습니다.

              켜기 전        켠 뒤
 성능 점수      79~81         78~79
 FCP           2.1 초        2.3 초
 LCP           4.7~5.1 초    4.9~5.2 초

⚠️ 점수만 보면 헷갈립니다. 79가 양쪽에 다 있거든요. 저도 처음에 한 번씩만 재고 "80에서 79로 떨어졌다" 고 쓸 뻔했는데, 여러 번 재보니 그냥 오차 범위 안이었습니다.

겹치지 않고 갈리는 것은 FCP입니다. 켜기 전에는 다섯 번 다 2.1초, 켠 뒤에는 네 번 다 2.3초예요. 첫 글자가 0.2초 늦게 뜹니다.

이게 61 kB의 값입니다. "점수 한두 점"이 아니라 "첫 글자 0.2초"로 말하는 게 정확해요.

둘째, 방문마다 데이터를 보냅니다

한 번 방문할 때 나가는 봉투를 전부 세어봤습니다.

 약 39,000 B    화면이 뜰 때 (pageload)
     1,057 B    화면을 떠날 때 (INP)
       505 B    세션
       137 B    그 밖
 -------------
 약 40 kB / 방문

⚠️ 이 39 kB는 홈 화면을 네 번 재서 나온 값(38,909 ~ 39,116 B)입니다. 고정된 숫자가 아니에요. 사진이 늦게 도착해서 일부가 봉투에 못 실린 회차에는 27,419 B까지 내려갔습니다. 그러니 "우리 앱은 방문당 40 kB"라고 외우기보다 여러분 앱에서 직접 재보시는 편이 낫습니다.

방문자가 하루 만 명이면 400 MB입니다. 이건 우리 서버 쪽 비용이기도 하고, 사용자의 데이터 요금 이기도 해요. 지하철에서 데이터를 아껴 쓰는 사람에게 우리가 성능을 재느라 40 kB를 쓰게 하는 셈입니다.

셋째, 그래서 전부 안 보냅니다

여기서 tracesSampleRate가 다시 나옵니다. 이 값을 낮추면 일부만 보내요.

 tracesSampleRate: 1      30번 열어서 30번 보냄  (100%)
 tracesSampleRate: 0.1    30번 열어서  4번 보냄  ( 13%)

0.1은 "열 번에 한 번쯤"이라는 뜻이고, 실제로 30번 중 4번이 나갔습니다. 확률이라 정확히 3번은 아니에요.

성능 데이터는 오류와 달리 일부만 모아도 됩니다. 오류는 한 건이 곧 한 명의 망가진 화면이라 놓치면 안 되지만, 속도는 통계니까요. 천 명의 숫자로도 만 명의 경향은 충분히 보입니다.

⚠️ 다만 샘플링이 모든 걸 줄여주지는 않습니다. 위 측정에서 속도 봉투는 30개에서 4개로 줄었는데 세션 봉투는 그대로 매번 나갔습니다. 505 B 짜리는 어차피 매번 나가요. 줄어드는 건 39 kB 짜리 쪽입니다.

우리 앱은 연습용이라 1로 둡니다. 여러분이 봉투를 직접 봐야 하니까요. 실무에서는 0.1 쯤에서 시작해서, 숫자가 흔들리지 않을 만큼만 올리는 게 보통입니다.

💡 한 줄 정리

사용자에게서 모으는 일에는 번들 61 kB · 첫 글자 0.2초 · 방문당 40 kB라는 값이 붙습니다. 그래서 전부 보내지 않고 일부만 보내는데, 그 비율을 정하는 것은 설정이 아니라 무엇을 알고 싶은지에 대한 결정이에요.

마무리

오늘 배운 핵심 세 가지

💡 하나. 어떤 값은 기다린다고 생기지 않습니다. LCP와 CLS는 브라우저가 알아서 기록해두지만 INP는 누가 눌러야 생겨요. 그래서 재는 방법 자체가 다르고, 아무도 안 누른 화면의 INP는 0이 아니라 "없음"입니다. 이 구별을 안 해두면 안 써본 화면이 가장 빠른 화면으로 보고됩니다.

💡 둘. 같은 앱이 조건에 따라 다섯 배 다르게 나옵니다. 우리 노트북에서 1.1초인 LCP가 모바일 조건을 흉내 내면 4.9초예요. 둘 다 참이고, 실험실 값은 변화를 재기에 좋고 현장 값은 무엇을 고칠지 정하기에 좋습니다. 한쪽만 보면 반드시 놓치는 게 생겨요.

💡 셋. 점수가 좋다고 사용자가 만족하는 건 아닙니다. 성능 점수의 다섯 항목에 INP는 아예 없고, 가중치가 가장 큰 TBT는 만점이어도 반응성과는 다른 것을 잽니다. 아무도 안 누른 화면을 잰 값으로는 누른 뒤의 경험을 알 수 없어요.

다음 시간 예고

오늘 마지막에 번들이 621 kB에서 683 kB가 됐습니다. 재려고 켠 도구가 앱을 조금 무겁게 만든 거죠. 사실 Lighthouse는 아까부터 우리에게 뭔가를 계속 말하고 있었는데, 점수 화면을 아래로 내려보면 이런 항목이 있어요.

 unused-javascript      Est savings of 95 KiB

받아는 갔는데 안 쓰는 자바스크립트가 95 KiB 나 된다는 뜻입니다. 우리 번들의 14% 쯤이에요.

이걸 어떻게 찾아내고 어떻게 잘라내는지, 그리고 어디까지 잘라야 하는지를 다루는 시간이 커리큘럼에 따로 준비돼 있습니다. 오늘 우리가 만든 측정 장치가 그때 그대로 쓰여요 — 자르기 전과 후를 재서 정말 좋아졌는지 확인해야 하니까요.

그 시간까지 가지 않으시더라도, 오늘 배운 것만으로 할 수 있는 일이 이미 많습니다. 재고, 조건을 바꿔 재고, 사용자에게서 모으는 것. 이 셋이면 "우리 앱 좀 느린 것 같아요"라는 말에 숫자로 답할 수 있어요.

과제

[구현] 다른 화면의 INP를 재보세요

오늘 우리가 INP를 잰 것은 홈 화면의 좋아요 버튼인데, 우리 앱에는 누를 수 있는 게 더 있어요.

탐색 화면(/explore)에는 태그를 고르는 단추들이 있습니다. C-8에서 이 단추들을 다룬 적이 있죠. 그때 우리는 단추 하나를 누르면 모든 태그 단추가 다시 그려진다는 것을 확인했습니다.

• 탐색 화면을 열고 태그 단추를 열 번쯤 눌러서 INP와 세 칸 내역을 적어보세요.
• 홈 화면의 좋아요 버튼과 견주면 어느 칸이 다른가요?
• C-8에서 잰 "다시 그려진 횟수"와 오늘 잰 "그리기 시간"은 같은 것을 말하고 있나요, 다른 것을 말하고 있나요?

⚠️ 두 화면을 옮겨 다니지 말고 각 주소를 직접 열어서 재세요. 로그인 클릭도 상호작용에 섞이니 상호작용 건수를 함께 보셔야 합니다.

[구현] 샘플링을 낮춰보세요

monitoring.ts의 TRACES_SAMPLE_RATE를 0.1로 바꾸고 빌드한 뒤, 화면을 스무 번쯤 새로고침해보세요.

• 속도 봉투가 몇 개나 왔나요? 기대한 수와 맞나요?
• 세션 봉투는 몇 개 왔나요? 속도 봉투와 같은 비율로 줄었나요?
• 오류도 함께 줄어드는지 확인해보세요. (오류를 하나 일으키는 방법은 지난 시간들에서 해보셨습니다.)

⚠️ 확인이 끝나면 되돌려주세요. 마지막 항목의 답이 왜 그런지 생각해보시면, 오류와 속도를 다르게 다루는 이유가 보이실 겁니다.

[탐구] 재는 문턱을 바꿔보세요

h3-vitals.ts의 durationThreshold를 16에서 40으로 바꾸고 하트를 여러 번 눌러보세요.

• 콘솔에 무엇이 찍히나요?
• 그 화면만 보고 "우리 앱이 빠르다"와 "설정이 잘못됐다"를 구별할 수 있나요?
• 구별하려면 무엇을 함께 봐야 할까요? 지금 우리 코드가 이미 찍고 있는 것 중에 답이 있습니다.
• 반대로 문턱을 낮출 수는 없을까요? 0을 넣고 돌려서 무슨 일이 생기는지도 확인해보세요.

⚠️ 마지막 항목에서 예상과 다른 결과가 나올 겁니다. 왜 그런지 규격 문서에서 durationThreshold를 찾아보시면 한 줄로 적혀 있어요.

[탐구] 봉투가 안 고친 화면을 찾아냅니다

Step 7에서 상세 화면(/p/1)의 봉투에 cls.source.1이 실려 온 것을 봤습니다. 지난 시간 과제로 남겨둔 그 화면이죠.

• 그 화면을 지난 시간 방법대로 고치고, 다시 봉투를 받아보세요. cls 항목이 어떻게 되나요?
• 이번에는 탐색 화면(/explore)의 봉투도 받아보세요. 무엇이 실려 있고 무엇이 없나요?
• 세 화면의 봉투 크기가 서로 다릅니다. 왜 다를까요? 봉투 안의 spans 개수를 세어보시면 힌트가 됩니다.

⚠️ 마지막 항목이 이 과제의 핵심입니다. 봉투 크기가 화면마다 다르다는 것은 Step 8에서 계산한 "방문당 40 kB"가 사실은 무엇에 대한 숫자였는지를 다시 생각하게 만듭니다.

생각해볼 주제

1. 첫 배포와 첫 데이터 사이

오늘 우리는 사용자에게서 속도를 모으기 시작했는데, 이 장치가 실제로 값을 하려면 배포가 되고 사람들이 들어와야 하죠.

새 기능을 만들어서 배포하는 날을 생각해보세요. 그날 우리에게는 실험실 값밖에 없습니다. 현장 값은 며칠 뒤에나 쌓여요.

이 며칠 동안 성능 문제를 어떻게 다뤄야 할까요? 배포 전에 실험실 값만으로 판단하는 것과, 배포하고 현장 값을 기다리는 것 사이에서 무엇을 기준으로 정할지 이야기해봅시다.

2. 나쁜 숫자를 받았는데 재현이 안 될 때

현장 데이터에서 INP가 아주 나쁜 사용자가 몇 명 보인다고 해봅시다. 그런데 우리 노트북에서는 아무리 눌러도 재현이 안 되고, Step 3처럼 CPU를 20배로 조여도 안 나와요.

우리가 오늘 본 것 중에 이 상황을 설명할 수 있는 것들이 있습니다. INP가 어떻게 정해지는지, 그리고 봉투에 무엇이 함께 실려 오는지를 떠올려보세요.

이 사용자들에게 실제로 무슨 일이 일어났을 가능성이 있는지 몇 가지 떠올려보고, 각각을 확인하려면 무엇을 더 모아야 할지 이야기해봅시다.

3. 재는 일이 대상을 바꿉니다

Step 8에서 우리는 재는 도구를 켰더니 첫 글자가 0.2초 늦게 떴다는 것을 확인했습니다. 재는 행위 자체가 재려는 대상을 바꾼 겁니다.

그렇다면 우리가 지금 보고 있는 현장 숫자는 "우리 앱의 속도" 일까요, 아니면 "측정 장치가 달린 우리 앱의 속도" 일까요?

이 어긋남이 실제로 문제가 되는 경우와 무시해도 되는 경우를 갈라보시고, 이 문제를 줄이려면 어떤 방법이 있을지 각각이 대신 무엇을 포기하는지도 함께 이야기해봅시다.