웹 성능이란?

웹 성능은 대부분 로딩 성능을 떠올리는 경우가 많습니다. 링크 클릭이나 네비게이션을 통해서 앱이 시작되고, 사용자가 상호작용할 수 있으며, 기본적인 동작을 하기까지의 시간을 의미합니다.

Kakao의 성능 측정

Kakao에서는 두 가지 방식으로 성능을 측정합니다. Synthetic Monitoring은 일정한 환경을 보장하는 실험적 환경에서 성능을 측정하는 방식이고, Real User Monitoring은 실제 사용자가 느끼는 성능을 측정하는 방식입니다.

페이지 로드 이후

서비스에 들어오는 로딩 속도가 중요했던 이전과는 다르게, 서비스에 들어와서 사용자의 상호작용이 많아지면서 로드 이후의 상호작용이 더 중요해졌습니다.

웹 반응성

웹 반응성이란 클릭, 탭, 키 같은 사용자 인터페이스가 상호작용에 반응하는 속도를 말합니다.

웹 반응성 현황

사용자의 **70%**는 일주일에 한번 이상 끔찍한 반응성을 경험하고 있습니다. 반응성이 나쁜 페이지보다 좋은 페이지의 사용량이 2배 이상 높습니다. RAIL 모델의 Response 성능 목표에 따르면, 사용자 입력으로부터 100ms 이내에 반응하면 사용자는 반응이 즉각적이라고 느낍니다.

웹 반응성이 사용자 행동에 미치는 영향
항목비교값 (%/배/ms)
나쁜 반응성 경험 비율7070 %/배/ms
좋은 페이지 사용량 배수200200 %/배/ms
RAIL 목표 응답시간(ms)100100 %/배/ms

웹 반응성 지표

⏱

TBT (Total Blocking Time)

Long Task(50ms+) 중 50ms 초과분의 합. 원활한 인터렉션 지표

👆

INP (Interaction to Next Paint)

사용자 입력 → 화면 변화까지의 시간. 빠른 피드백 지표

📐

CLS (Cumulative Layout Shift)

예기치 않은 레이아웃 이동 점수. 시각적 안정성 지표

TBT(Total Blocking Time)는 원활한 인터렉션을 나타내는 지표입니다. Long Task란 메인 스레드에서 50ms 이상 실행되는 작업을 의미하며, Blocking Time은 Long Task 중 50ms를 제외한 메인 스레드 점유 시간입니다.

INP(Interaction to Next Paint)는 빠른 피드백을 나타내는 지표로, 사용자 입력이 발생하고 화면의 변화가 생길 때까지의 시간을 측정합니다.

CLS(Cumulative Layout Shift)는 시각적 안정성을 나타내는 지표로, 페이지 전체 수명동안 발생하는 예기치 않은 레이아웃 이동 점수를 측정합니다.

웹 반응성 측정 방법 by Lighthouse Userflow

Navigation

단일 페이지의 로드 성능 측정. LCP와 Speed Index와 같은 페이지 로드 성능 점수 제공. 측정 항목: Performance, Accessibility, Best Practice, SEO, PWA

Snapshot

사용자의 인터렉션 후 페이지의 상태 측정. SPA나 복잡한 폼의 접근성 이슈 확인. 측정 항목: Performance, Accessibility, Best Practice, SEO

Timespan

임의의 시간동안 사용자의 인터렉션 측정. 수명이 긴 페이지, SPA에서 성능 개선 포인트 제공. 측정 항목: Performance, Best Practice, SEO

Navigation

Navigation은 단일 페이지의 로드 성능을 측정합니다. LCP와 Speed Index와 같은 페이지 로드 성능 점수를 제공하며, Performance, Accessibility, Best Practice, SEO, PWA 항목을 측정합니다.

Snapshot

Snapshot은 사용자의 인터렉션 후 페이지의 상태를 측정합니다. SPA나 복잡한 폼의 접근성 이슈를 확인하는 데 유용하며, Performance, Accessibility, Best Practice, SEO 항목을 측정합니다.

Timespan

Timespan은 임의의 시간동안 사용자의 인터렉션을 측정합니다. 수명이 긴 페이지나 SPA에서 성능 개선 포인트를 제공하며, Performance, Best Practice, SEO 항목을 측정합니다.

웹 반응성 개선 사례

TBT

화면 전환 시 강제 reflow가 발생하는 문제가 있었습니다. JS 실행 단계에서 아직 계산되지 않은 style이나 layout을 참조하는 경우, 강제로 계산하는 reflow가 실행되면서 실행시간이 길어졌습니다. 이를 해결하기 위해 계산되지 않은 엘리먼트를 참조하지 않도록 전체 과정이 한번 수행된 뒤 참조할 수 있게 requestAnimationFrame과 같은 함수를 사용했습니다.

INP

사용자 입력이 발생했을 때 빠른 피드백을 제공하는 것이 핵심입니다. 오래 걸리는 작업에 대해 로딩 화면을 보여주거나, 동시성 기능을 활용하여 개선할 수 있습니다.

긴급 업데이트

장점

  • 사용자가 직접 상호작용하여 즉각적인 반응 필요
  • 사용자가 즉각 업데이트 되길 기대

고려할 점

  • 렌더링 블로킹 발생 가능

전환 업데이트

장점

  • 화면 UI 전환 시 사용자가 지연을 미리 인지
  • 렌더링 우선순위 적용 및 동시성 활용 가능

고려할 점

  • 별도의 로딩 UI 필요

긴급 업데이트

긴급 업데이트는 사용자가 직접 상호작용하여 즉각적인 반응이 필요한 경우입니다. 사용자가 즉각 업데이트 되길 기대합니다.

전환 업데이트

전환 업데이트는 화면 UI가 전환되는 경우로, 사용자가 업데이트 지연을 미리 인지하는 상황입니다. 이 경우 렌더링 우선순위를 적용하고 동시성을 활용하여 개선할 수 있습니다.

CLS

CLS를 개선하기 위해서는 사용자가 예상할 수 없는 레이아웃을 미리 계산해서 영역을 차지하도록 해야 합니다. 미리 영역에 width/height 값을 적용하거나 이미지의 비율을 설정하여 계산할 수 있으며, 이를 통해 레이아웃 시프트 발생을 저지할 수 있습니다.

참조

https://if.kakao.com/2022/session/75