웹사이트는 얼마나 빨라야 할까요?

기업은 항상 웹 및 모바일 앱의 속도와 성능을 개선하는 데 관심이 있습니다. 그리고 대부분의 기업은 클라우드로 이동하는 데 이미 시간, 노력 및 비용을 투자했습니다. 또한, 팀들이 소프트웨어를 배포하는 방식을 근본적으로 바꾸고, 더 빠르게 확장하기 위해 쿠버네티스를 사용하는 경우도 있습니다. 팀들은 이미 엄청난 복잡성에 직면하고 있기 때문에, "얼마나 빨라야 하는가?”라는 웹 성능에 대한 피할 수 없는 질문에는 최대한 간단한 답을 듣길 원합니다. 

대답은 보통 "상황에 따라 다르다"라는 것입니다. 

물론, 이런 대답을 원하지는 않았을 것입니다. 안타깝게도, 업타임은쉽게정량화할수있지만, 페이지성능을 명확하게 정의할 수 있는 단일한 지표는 없습니다.

조사에 따르면 "속도는 빠를수록 좋습니다.” 컴퓨웨어(Compuware)의 웹 성능 사업부에 근무하는 고메즈(Gomez)에 따르면, 사용자의 40%가 3초 동안 기다리게 되면 사이트를 이탈하는 것으로 나타났습니다. 월마트(Walmart)는 페이지 속도를 100ms까지 개선하면 수익이 1% 증가한다는 사실을 발견했습니다. 

속도는 물론 중요한 요소이지만, 동적인 페이지 경험의 일부일뿐입니다. 고객들은 여러 다른 버전의 웹 브라우저와 디바이스 (신규 및 기존)를 사용해, 다양한 속도의 네트워크에서 사이트를 탐색합니다. 사람마다 허용할 수 있는 속도와 성과가 다릅니다. 다행인 것은, 최적화 프로세스를 안내해주는 몇 가지 일반적인 규칙과 데이터가 존재한다는 겁니다. 

"상황에 따라 다르다.”라는 말은 그리 명쾌한 답은 아니지만, 웹 페이지의 기본 사항과 고객 만족도를 탐색하고, 디지털 비즈니스 전반에서 성능 중심의 문화를 조성할 수 있는 좋은 기회가 될 수 있습니다. 

다음은 페이지 속도와 성능에 풀스택 옵저버빌리티(관찰성)를 사용하는 뉴렐릭의 접근 방식과 따라야 할 몇 가지 일반적인 규칙, 디지털 자산의 지속적인 관리를 위해대시보드를 생성하는 단계별 가이드입니다.

페이지 성능을 정의하는 단일한 지표는 없습니다. 수년 동안 페이지 로드 시간(window.onload)을 엔드유저의 성능을 측정하고 보고하기 위한 포괄적인 지표로 사용해 왔습니다. 이 지표는 웹 1.0 버전에서는 유용했지만, 최신 페이지를 이해하려고 하는 경우 오해의 소지가 있습니다.

성능을 보다 정확하게 측정하려면, 페이지가 제공하는 경험을 사용자가 인식하는 방법이 반영된 지표를 캡처하는 것이 좋습니다. 사용자 중심으로 인지된 성능 지표는 사이트 소유자가 시각적 콘텐츠 속도, 사용자의 상호 작용에 대한 페이지의 반응 속도, 페이지 로드 시 원할한 경험을 생성하는 방법 같은 페이지 경험의 주요 구성 요소를 이해하는 데 도움이 됩니다.

Google의 핵심 웹 필수 요소

성능을 선택하고 벤치마킹하려면, Google의 핵심 웹 필수 요소(Core Web Vitals)로 표준화할 것을 권합니다. Google은 페이지 상태를 정의하는 데 LCP(Largest Contentful Paint), FID(First Input Delay) 및 CLS(Cumulative Layout Shift)의 세 가지 측정 요소를 권장합니다. 'Good(우수)', ‘Needs Improvement(개선 필요)', ‘Poor(나쁨)'으로, 각 측정치에는 상응하는 등급이 함께 표시됩니다.

각 측정치에 대해, 사용자의 75 백분위 수에서 'Good', ‘Needs Improvement’ 및 ‘Poor'의 권장 임계값은 다음과 같습니다. 뉴렐릭의 PageViewTiming 이벤트를 사용해 이를 위한 대시보드를 만드는 방법은 다음과 같습니다.

뉴렐릭은 기업 데이터가 핵심입니다. 뉴렐릭의 실시간 사용자 모니터링(Real User Monitoring) 에이전트는 총 8가지 이벤트 유형을 제공하며, 각 이벤트에는 JavaScript 오류, 싱글 페이지 애플리케이션(SPA) 페이지의 세부 정보, AJAX 요청, 분산 추적의 범위, 지역별 성능을 측정 및 벤치마킹하고 알람을 생성하는 데 도움이 되는 십여 가지 속성이 있습니다. 특히, 로드 타이밍 데이터의 경우, 두 가지 주요 이벤트 유형인 PageViewTiming 이벤트와 BrowserInteraction이 있습니다.

두 가지 모두에 동일한 기본 속성 세트가 존재하지만, BrowserInteraction에는 AJAX 응답 시간 및 경로 변경이 포함된 추가 기능이 있습니다.

PageViewTiming 이벤트를 사용해 세 가지 핵심 웹 필수 요소를 모두 대시보드에 포함시키고, 페이지 성능을 시각화해 보겠습니다.

지금까지 실제 사용자 데이터(필드 데이터)에 대해 이야기를 했습니다. 랩 데이터는 최적의 성능을 이해하고 배포하기 전에 성능 저하를 찾아내 제거하는 데 도움이 됩니다.

신세틱(synthetic) 모니터에서 수집된 랩 데이터는 데브옵스 프로세스 전체에서 페이지 성능을 최적화하는 데 유용합니다. 사용자의 상호 작용을 시뮬레이션하고 피드백을 측정하기 위해, 사전 정의된 조건 세트(일반적으로 고속 네트워크, 특정 브라우저 또는 디바이스)를 사용하고 있기 때문에, 이를 랩(실험실) 데이터라고 합니다. 

신세틱 모니터는 운영 환경으로 릴리스하기 전에 레이턴시와 오류를 찾을 수 있으므로, 성능을 조율하는 데 도움이 됩니다. 또한 개발자 중심의 신세틱 솔루션은 JavaScript를 사용해 모든 페이지 구성 요소와 종속성을 완전히 다시 구성할 수 있는 기능을 제공하기 때문에, 사이트 운영자는 업타임 이외에도 기능과 성능의 상태를 이해할 수 있습니다.

최신 웹 페이지는 정보를 전달하기 위해 API와 서드 파티에 크게 의존합니다. 신세틱의 스크립트된 API 모니터는 업타임을 넘어, 요청/응답 시간, 연결 시간 및 페이로드 크기에 대한 정보까지 표시해줍니다. 이를 통해 API가 가동 중인지, 빠른지, 유효한 결과를 반환하는지를 확인할 수 있습니다.

New Relic One은 각 모니터의 ‘리소스’ 섹션에 서드파티 성능을 자동으로 표시하며, 사용자는 NRQL 을 활용해 성능 이상치를 추가로 구분할 수 있습니다. 

성능을 추가로 조율하기 위해, 웹 개발자는 Long Tasks, 전송된 바이트(페이지 가중치), 페이지 리소스 성능 및 각 모니터링 결과에 대한 리소스 워터폴 차트에 액세스합니다. 

성능 문화를 조성하고 싶다면, 먼저 페이지 경험의 몇 가지 핵심 구성 요소를 측정해야 합니다.

특히 복잡한 백엔드 서비스와 인프라를 관리하는 경우 "상황에 따라 다르다"는 답이 만족스럽지는 않겠지만, 이는 사이트가 엔드유저에게 어떤 영향을 미치고 어떻게 온라인 만족도를 높일 수 있는지를 이해할 수 있는 기회가 될 수 있습니다. 

"얼마나 빨라야 하는가"라는 질문 또한 보다 명확한 목표를 세우고, 엔지니어링 팀과 마케팅 팀이 서로 이해를 증진해 더 나은 비즈니스 결과를 얻는데 도움이 될 수 있습니다.

Google의 핵심 웹 필수 요소에 맞춰 대시보드를 설정하고 임계값에 대한 지침을 따르길 권합니다. 모니터 몇 개를 만들어 경쟁업체와 비교해 시각적 콘텐츠(FP, FCP)가 얼마나 빨리 표시되는지를 이해하고, 최소 20% 더 빠른 것을 목표로 삼아야 합니다. API와 서드파티가 페이지 성능에 미치는 영향을 이해해야 합니다. 뉴렐릭과 Google Lighthouse 같은 우수한 tool을 사용해, 성능의 병목 지점을 찾고 성공적인 배포를 보장해야 합니다.

웹 성능은 페이지 성능 여정의 어느 단계에서든 과학이자 예술이라는 것을 기억해야 합니다. 웹 브라우저에서 시간의 조각들을 조사하고 인간 행동을 탐구하기 때문입니다. 그러나 측정하지 않은 것을 개선할 수 없다는 사실을 기억하는 것이 가장 중요합니다. 지금 바로 시작하시기 바랍니다. 고객이 기다리고 있습니다.

(너무 오래 기다리게 하면 안됩니다.)

뉴렐릭이 APM, Infrastructure Monitoring, Logs in Context 등이 포함된 풀스택 옵저버빌리티(Full-Stack Observability) 제품을 통해 어떻게 엔드유저들에게 웹 및 애플리케이션 기능과 더 나은 경험을 제공하는지 확인하십시오.

지금 newrelic.com/kr/platform/full-stack-observability에서 무료로 가입하십시오.