품질 기반: 서비스 성능을 최적화하여 고객의 디지털 경험 개선

이 가이드는 고객 경험을 이해, 측정 및 개선하기 위한 고품질 기반을 구축하는 과정을 안내합니다. 이것은 관찰 가능성 성숙도에 대한 시리즈 의 일부입니다.

개요

디지털 고객 경험은 모든 디지털 접점에서 최종 사용자의 경험을 의미합니다. 사용자 경험에 영향을 미치는 4가지 핵심 요소는 다음과 같습니다.

가용성: 도달할 수 있습니까?
성능: 사용할 수 있을 정도로 성능이 좋은가?
콘텐츠 품질: 사용자가 필요로 하는 것이 있고 찾을 수 있습니까?
제품 및 콘텐츠 관련성: 사용자가 관심을 갖는 내용이 있습니까?

디지털 고객 경험에는 웹, 모바일 및 IoT가 포함됩니다. 이 가이드의 첫 번째 버전은 최종 사용자 웹 경험을 측정하는 데 중점을 두고 있습니다.

이 품질 기반 가이드는 디지털 고객 경험을 의미 있는 방식으로 이해하는 데 도움이 되는 표준 사례를 만드는 방법에 관한 것입니다. 이 구현 가이드는 다음과 같은 도움이 될 것입니다.

다음과 관련된 고객 경험을 살펴보십시오.
- 검색 및 로그인과 같은 전역 기능
- 사업분야
- 지역
비즈니스 이해 관계자에게 관심 있는 사항에 대해 다시 보고합니다.
당신이 하는 일을 우선시하라
반복 가능한 연습 만들기

요망되는 결과

최종 사용자 경험에 더 잘 부합하는 방식으로 성과를 측정하고 개선하여 고객 참여 및 유지를 개선합니다.

핵심 성과 지표

이 가이드는 다음 KPI를 측정합니다.

이 KPI는 사용자가 애플리케이션 또는 해당 페이지에 액세스할 수 있는지 여부를 측정합니다.

목표: 가동 시간 및 가용성 향상

임계값:

< 99% 경고
< 95% 중요
99% 또는 "2 9s"는 직원 응용 프로그램이나 하위 페이지의 경우에도 가용성의 좋은 최소 표준입니다. 이러한 기본 임계값을 대시보드에 구성합니다. 애플리케이션에 대한 기대에 더 잘 맞도록 이를 쉽게 변경할 수 있습니다.

이 KPI는 Core Web Vitals 의 일부입니다. LCP(Large Contentful Paint)는 사용자가 새 페이지로 이동한 후 가장 큰 이미지를 로드하는 데 걸리는 시간을 측정합니다.

목표:

모든 페이지 또는 최소한 가장 중요한 페이지의 75% 백분위수에 대해 LCP를 2.5초 이상으로 줄이십시오.
임계값:
경고: > 2.5초
크리티컬: > 4.0초
LCP 임계값은 Google 팀에서 정의합니다. 임계값과 그 이면의 지원 논리는 Google의 web.dev 사이트에서 찾을 수 있습니다.

이 KPI는 Core Web Vitals 의 일부입니다. 브라우저가 이벤트 처리를 시작할 때 사용자 상호작용(예: 링크 클릭 또는 텍스트 입력) 사이의 시간을 추적하여 페이지의 상호작용성을 측정합니다.

목표: 모든 페이지 또는 최소한 가장 중요한 페이지의 75% 백분위수에 대해 FID를 100밀리초 이상으로 줄이십시오.

임계값:

경고: > 100밀리초
중요: > 300밀리초
FID 임계값은 Google 팀에서 정의합니다. 임계값과 그 이면의 지원 논리는 Google의 web.dev 사이트에서 찾을 수 있습니다.

이 KPI는 Core Web Vitals 의 일부입니다. 렌더링하는 동안 페이지 레이아웃이 얼마나 이동하는지 측정합니다.

목표: 모든 페이지 또는 최소한 가장 중요한 페이지의 75% 백분위수에 대해 0.1 이하의 점수를 유지합니다.

임계값:

경고: > 0.1점
크리티컬: > 0.25점
CLS 임계값은 Google 팀에서 정의합니다. 임계값과 그 이면의 지원 논리는 Google의 web.dev 사이트에서 찾을 수 있습니다.

이 KPI는 탐색 시작(사용자가 링크 클릭)부터 서버로부터 응답의 첫 번째 바이트를 수신하는 브라우저까지의 시간을 측정합니다. Google은 TTFB를 핵심 성능 향상에 부차적인 것으로 간주합니다. 보다 완전한 그림을 위해 측정하는 것이 좋습니다. 변경 사항이 서버 측에서 발생했는지 클라이언트 측에서 발생했는지에 대한 질문에 답하기 때문에 LCP의 변경 사항을 확인하면 드러날 수 있습니다.

목표: CDN, 네트워크 및 서비스 성능을 개선하여 첫 번째 바이트까지 시간을 단축합니다.

임계값:

경고 > 0.5초
크리티컬 > 1.0초
Google과 Search Engine People이라는 조직에 따르면 500밀리초는 동적 콘텐츠가 있는 페이지에 적절한 TTFB입니다. 이 검색 엔진 사람들 게시물 에서 이러한 권장 사항에 대한 언급을 찾을 수 있습니다.

느린 AJAX 호출은 사용자가 아무 일도 일어나지 않거나 페이지가 손상된 것처럼 느끼게 할 수 있습니다. 응답 시간이 충분히 느리면 사용자는 여정을 포기할 수도 있습니다.

목표: AJAX 응답 시간을 측정하고 개선합니다.

임계값:

경고 > 2초
크리티컬 > 2.5초
이러한 임계값은 다양한 산업 분야의 고객과의 경험에서 비롯됩니다.

HTTP 오류(또는 HTTP 4xx 및 5xx 응답)는 백엔드 호출이 성공하지 못한 경우 발생합니다.

목표: HTTP 오류율을 측정하고 줄여 고객이 목적을 위해 사이트를 방문할 수 있도록 합니다.

임계값:

경고 < 99% 요청 성공
중요 < 97%의 요청이 성공함
이러한 임계값은 다양한 산업 분야의 고객과의 경험에서 비롯됩니다.
우리는 모든 AJAX 요청이 사용자가 달성하고 그에 따라 처리하려는 것과 연관되어 있다고 가정했습니다. 사용자는 종종 실패한 작업을 다시 시도하기 때문에 경고와 위험 임계값 사이에 공간을 허용했습니다.
측정 중인 AJAX 요청이 사용자 여정의 중요한 부분인 경우 99.5% 또는 99.9%와 같이 더 높은 성공률을 목표로 하는 것이 좋습니다.
AJAX 요청이 로그인 요청과 연결된 경우 4xx 응답 코드를 5xx 응답 코드에서 분리하고 4xx 응답에 대해 훨씬 더 낮은 임계값을 설정합니다. 합리적인 임계값을 결정하기 위해 과거 응답 코드 비율을 살펴볼 수 있습니다.

이 KPI는 페이지 보기당 JavaScript 오류 수를 측정합니다.

목표:

수집을 조정하거나 필터링을 사용하여 추적되는 관련 없는 JavaScript 오류를 제거합니다.
고객 성과에 영향을 미치는 JavaScript 오류를 줄입니다.
임계값:
경고: > 페이지 보기당 5% 오류
치명적: > 페이지 조회당 10% 오류
이러한 임계값은 다양한 산업 분야의 고객과의 경험에서 비롯됩니다.

각 KPI에 대해 임계값을 정의했습니다. 하나는 경고 상태이고 다른 하나는 위험 상태입니다. 이러한 값이 어디에서 왔는지 또는 응용 프로그램에 적용해야 하는지 어떻게 확신할 수 있는지 물을 수 있습니다. 우리의 임계값은 Google(Core Web Vitals의 경우와 같이) 또는 수많은 고객 및 애플리케이션에 대한 경험을 기반으로 권장하는 임계값입니다. 서로 달라야 한다고 강하게 느끼면 조정할 수 있지만 애플리케이션별로가 아니라 조직 수준에서 이 작업을 수행해야 합니다.

이 품질 기반 가이드는 애플리케이션에서 사용자 유지, 전환 및 만족도를 최적화하기 위해 개선해야 할 부분을 식별하는 데 도움이 됩니다. 물건이 어디에 있는지보다 어디로 가야 하는지가 더 중요합니다.

또한 앞으로 측정해야 할 사항을 보여줍니다. 이를 사용하여 서비스 수준 목표(SLO) (서비스 수준 대시보드에서)를 정의하고 이에 대해 경고할 수 있습니다.

전제 조건

필요한 지식

다음과 같은 기본 지식이 있어야 합니다.

필수 설치 및 구성

모든 페이지에 설치된 Browser Pro 에이전트 버전
단일 페이지 애플리케이션을 위한 SPA 활성화
구성된 합성 모니터:
- 익명 사용자용으로 구성된 Ping 모니터
- 로그인 흐름에 대해 구성된 스크립팅된 합성 검사
- 사용자에게 적용 가능한 모든 지역에서 테스트 하도록 모니터를 구성해야 합니다.
- 각 도메인 및 각 로그인 흐름에 대해 모니터를 구성해야 합니다.
평균 스프린트의 2배 이상인 브라우저 이벤트에 대한 데이터 보존

현재 상태 설정

현재 상태를 설정하려면:

계측 페이지 검토
브라우저 URL 그룹화 확인
데이터를 분류하는 방법 이해
품질 기반 대시보드 가져오기
각 대시보드 페이지의 현재 성능 캡처

이러한 단계는 아래에 더 자세히 설명되어 있습니다.

계측 페이지 검토

브라우저 앱과 페이지를 검토하여 New Relic에 보고할 것으로 예상되는 모든 것이 실제로 그렇게 하고 있는지 확인하십시오. 브라우저 모니터링 UI에서 페이지 보기 탭을 검토하거나 다음 쿼리를 실행하여 이를 수행할 수 있습니다.

SELECT uniques(pageUrl) from PageView LIMIT MAX

요청 또는 고객 ID가 포함된 URL을 필터링해야 할 수 있습니다.

브라우저 URL 그룹화 확인

NRQL을 통해 쿼리할 때 New Relic UI와 집계 수준에서 사용자 경험 성능을 측정할 수 있도록 브라우저 세그먼트가 올바르게 캡처되었는지 확인합니다.

세그먼트는 URL의 두 / 사이 또는 도메인 이름의 . 사이의 텍스트입니다. 예를 들어 URL website.com/product/widget-name 에서 세그먼트는 다음과 같습니다.

website
.com
product
widget-name

세그먼트가 많은 URL이 많은 경우 URL이 축약되어 website.com/product/widget-name 가 website.com/ 또는 website.com/product/ 가 될 수 있습니다. 이 예에서 첫 번째 요약 URL은 특별히 유용하지 않지만 두 번째 URL은 제품에 대한 고객 경험 데이터를 집계하는 유용한 방법일 수 있습니다.

구성을 조정해야 하는지 여부가 확실하지 않습니까? 도움이 되도록 세그먼트 허용 목록 조사 대시보드 를 가져오세요.

추가할 세그먼트를 식별했으면 브라우저의 세그먼트 허용 목록을 사용하여 추가할 수 있습니다.

데이터를 분류하는 방법 이해

고객 경험 데이터를 다양한 세그먼트로 나누어 이해하고 실행 가능하게 만드세요. 이 경우 세그먼트는 데이터 그룹을 나타냅니다. 세그먼트 허용 목록 에서와 같이 URL 섹션을 참조하지 않습니다.

다음 진술을 고려하십시오.

대부분의 사용자는 첫 번째 입력 지연이 3초 이상 지연되는 것을 경험합니다.
평균적으로 가장 큰 콘텐츠가 포함된 페인트까지 2초가 소요됩니다.
지난 주 페이지뷰는 100만 회였습니다.

비교 대상:

미국, 캐나다 및 EMEA의 대부분의 사용자는 첫 번째 입력 지연이 2초 이상 지연됩니다. 말레이시아 및 인도네시아 사용자는 4초를 경험합니다. 우리는 이것을 조사하고 있습니다.
자동차 보험을 구입하는 고객은 일반적으로 가장 큰 내용의 페인트를 1초 동안 봅니다. 주택 보험의 경우 4초입니다.
지난 주 모바일 브라우저 앱의 페이지 조회수는 700,000회였으며 데스크톱의 경우 300,000회였습니다. 모바일 경험을 최적화하고 있는지 확인합시다.

일반적인 세분화에는 사용자 경험을 다음 범주로 분류하는 작업이 포함됩니다.

분절	안내
지역/위치	기본: 국가별로 그룹화합니다. 브라우저 이벤트에는 요청의 국가 코드가 자동으로 포함되므로 추가로 분류하기 위해 수행할 필요가 없습니다. 고급: 브라우저 모니터링에서 사용자 지정 속성 을 사용하여 고유한 지역 속성을 생성하여 지역 그룹이 지역 SLO 그룹과 일치하도록 합니다. `countryCode` 의 패싯 관련 속성: `regionCode` `city` `asnLatitude` `asnLongitude`
장치	다음을 이해할 수 있도록 성과 및 참여 장치 유형을 분류합니다. 데스크톱 대 모바일 브라우저 사용자의 일반적인 분석 데스크탑 vs 모바일 브라우저 사용자 경험 `deviceType` 의 패싯 관련 속성: `userAgentName` `userAgentOS` `userAgentVersion`
제품/사업부	이 시나리오에서 제품은 조직에서 제공하는 별도의 비즈니스 또는 서비스입니다. 산업 및 해당 제품의 몇 가지 예: 자동차 보험과 주택 보험을 모두 판매하는 보험 회사 여러 스트리밍 서비스 또는 채널을 보유한 미디어 회사 렌터카 및 호텔 예약을 제공하는 여행사 기본: 제품별 실적 분류: `pageUrl` 의 패싯: New Relic에서 여러 제품이 하나의 브라우저 앱으로 그룹화될 때 이 접근 방식을 사용합니다. `appName` 에 의한 패싯: 각 제품이 별도의 웹 앱으로 계측되는 경우 이 접근 방식을 사용합니다. `appName` 및 패싯으로 그룹화: 하나의 제품을 지원하는 브라우저에 여러 앱이 있는 경우 이 접근 방식을 사용합니다. 고급: 사용자 정의 속성을 사용하여 브라우저 페이지에 제품 오퍼링을 사용자 정의 속성으로 추가 합니다 .
환경	계측 중 또는 이후에 브라우저 앱의 환경을 지정하는 명명 규칙을 따르십시오. 잘 명명된 브라우저 앱은 제품 및/또는 기능과 환경을 지정합니다. 예: `account-management.prod` `hotels-book.prod` `car-insurance.uat` 앱 명명 규칙을 사용하여 환경을 지정하면 UI와 대시보드 모두에서 데이터 필터링을 지원합니다. 자세한 내용은 브라우저 앱의 이름을 바꾸는 방법에 대한 설명서를 참조하세요.
팀	어떤 조직에서는 단일 팀이 여러 제품을 지원하는 반면, 다른 조직에서는 제품이 여러 팀에서 지원할 수 있을 만큼 충분히 큽니다. New Relic의 브라우저 앱 이름(예: `account-management.prod.unicorn-squad` )에 팀 이름을 추가하거나 사용자 정의 속성 을 사용하여 고객 경험 또는 참여에 대한 팀 성과를 보고합니다.

품질 기반 대시보드 가져오기

이 단계에서는 고객 경험을 측정하고 개선하는 데 사용할 대시보드를 만듭니다. 이것을하기 위해:

품질 기반 빠른 시작 으로 이동합니다.
빠른 시작의 지침에 따라 대시보드를 다운로드하고 데이터 분할 계획에 맞게 대시보드를 사용자 지정합니다.
대시보드를 팀이 아닌 LOB(Line of Business) 또는 고객 대상 제품에 맞게 조정해야 합니다. 이렇게 하면 가장 영향력 있는 곳에 최적화 시간을 할애할 수 있습니다.

각 대시보드 페이지의 현재 성능 캡처

품질 기반 GitHub README 의 지침을 따르세요.
이전 단계의 대시보드를 사용하여 각 비즈니스 라인의 전체 성과를 이해합니다. 해당하는 경우 필터를 적용하여 지역 또는 기기 전반의 성능을 확인하세요. 값이 목표 아래로 떨어지고 중요한 경우 개선 대상으로 시트에 추가하십시오. 추적 가치의 예:
- 추적할 가치가 없음: 미국에서 보험을 판매하는 회사는 말레이시아에서만 실적이 저조하다는 것을 알았습니다.
- 추적할 가치: 미국에서 보험을 판매하는 회사는 미국의 모바일 사용자와 관련하여 실적이 저조하다는 것을 알았습니다.

개선 프로세스

이 프로세스를 개선하는 데 관련된 주요 단계는 다음과 같습니다.

작업 계획
개선할 KPI 결정
목표 KPI 개선
페이지 로드 성능 향상
AJAX 응답 시간 개선
AJAX 오류율 개선
자바스크립트 오류 개선

이러한 단계는 아래에 더 자세히 설명되어 있습니다.

작업 계획

성능 향상을 위한 전담 이니셔티브가 있든, 지속적인 유지 관리로 분류하든, 모든 스프린트가 끝날 때 진행 상황을 추적해야 합니다.

개선할 KPI 결정

이제 여러 비즈니스 라인에서 사용자 경험이 어떤 모습인지 알게 되었습니다. 어디를 개선해야 할까요?

비즈니스 우선 순위부터 시작하십시오. 명확한 비즈니스 지침이 있거나 그 위에 있는 고위 관리자에게 액세스할 수 있는 경우 조직에 가장 중요한 것에 집중해야 합니다. 예를 들어, 회사에서 최근에 LOB(Line of Business)와 관련된 새로운 이니셔티브를 시작했지만 UI와 연결된 KPI가 목표보다 낮다고 가정해 보겠습니다. 이것은 처음에 시간을 집중해야 하는 곳입니다.
다음으로, 각 비즈니스 라인에 대한 KPI에 중점을 둡니다.
마지막으로 장치, 지역 등으로 각 비즈니스 라인을 필터링하여 특정 지역이나 장치에 추가 초점이 필요한지 확인합니다.

목표 KPI 개선

진행 상황을 추적하려면 새 대시보드를 만들거나 기존 대시보드에 새 페이지를 추가하고 이름을 Quality Foundation KPI Improvement 로 지정합니다. 자세한 내용은 웹 가동 시간 개선 을 참조하십시오.

페이지 로드 성능 향상

목표 KPI 값을 충족하지 않는 특정 페이지로 초점을 좁힙니다.

품질 기반 대시보드에서 범위를 벗어난 각 페이지 로드 KPI 결과에 대해 COMPARE WITH 절을 제거하고 FACET pageUrl/targetGroupedUrl LIMIT MAX 을 추가하여 어떤 페이지가 실적이 저조한지 찾습니다.

결과가 많은 경우 targetGroupedUrl 을 사용합니다. 예를 들어 고객 ID가 URL의 일부인 경우입니다. 그렇지 않으면 pageUrl 을 사용합니다.

원래 대시보드 쿼리:

FROM PageViewTiming SELECT percentile(largestContentfulPaint, 75) WHERE appName ='WebPortal' AND pageUrl LIKE '%phone%' SINCE 1 week AGO COMPARE WITH 1 week AGO

문제 페이지를 식별하는 새로운 쿼리:

FROM PageViewTiming SELECT percentile(largestContentfulPaint, 75) WHERE appName ='WebPortal' AND pageUrl LIKE '%phone%' FACET targetGroupedUrl LIMIT MAX

개선할 페이지를 식별했으면페이지 로드 성능 개선 의 지침을 참조하세요.

AJAX 응답 시간 개선

다음 단계를 사용하여 느린 요청을 찾습니다.

대시보드에서 AJAX 기간 위젯으로 이동합니다.
쿼리를 본 다음 쿼리 빌더에서 엽니다.
쿼리 끝에 facet requestUrl LIMIT MAX 을 추가합니다.
쿼리를 실행합니다.
결과를 테이블로 보고 KPI 개선 대시보드에 LOB - AjaxResponseTimes 으)로 저장합니다.
timeToSettle > 2.5초로 요청을 개선하는 데 집중하세요.

응답 시간을 개선하려면 New Relic의 권장 모범 사례를 사용하십시오. AJAX 문제 해결 팁 을 참조하십시오.

AJAX 오류율 개선

실패한 요청 찾기:

Dashboards > Query builder 이동합니다.

다음 쿼리를 입력하고 실행합니다.

FROM AjaxRequest 
SELECT percentage(count(*), WHERE httpResponseCode >= 400) 
WHERE httpResponseCode >= 200 AND <Ajax Request filter>
SINCE 1 week AGO facet pageUrl, appName

결과를 테이블로 보고 KPI 개선 대시보드에 LOB - Pages with AjaxErrors 으)로 저장합니다.

가장 문제가 많은 페이지에 대해 쿼리를 다시 실행하여 실패한 요청을 찾습니다.

FROM AjaxRequest 
SELECT percentage(count(*), WHERE httpResponseCode >= 400) 
WHERE httpResponseCode >= 200 AND pageUrl=PROBLEMATIC_PAGE AND appName = YOUR_APP_NAME <Ajax Request filter> 
SINCE 1 week AGO facet requestUrl

응답 시간을 개선하려면 New Relic의 권장 모범 사례를 사용하십시오. AJAX 문제 해결 팁 을 참조하십시오.

자바스크립트 오류 개선

가장 일반적인 실패 찾기:

Dashboards > Query builder 이동합니다.

다음 쿼리를 입력하고 실행합니다.

FROM JavaScriptError 
SELECT count(errorClass) 
SINCE 1 week AGO WHERE <PageView filter>  
FACET transactionName, errorClass, errorMessage, domain

결과를 테이블로 보고 KPI 개선 대시보드에 LOB - Javascript Errors 으)로 저장합니다.
이 정보를 사용하여 해결해야 할 오류를 파악하십시오. 해결이 필요한 오류를 해결하려면 New Relic의 권장 모범 사례를 사용하십시오. JavaScript 오류 페이지: 오류 감지 및 분석을 참조 하십시오.
가치를 추가하지 않는 타사 오류를 제거합니다.

잡음이 있지만 예상대로 작동하는 타사 JavaScript를 사용 중일 수 있습니다. 다음과 같은 몇 가지 접근 방식을 취할 수 있습니다.

자바스크립트 오류/페이지뷰 비율 위젯에서 도메인 이름을 제거하고 자체 위젯으로 추가하면 예기치 않은 변경 사항을 볼 수 있습니다. Baseline NRQL 경고를 사용하여 이에 대해 경고할 수 있습니다.
드롭 필터 를 사용하여 JavaScript 오류를 삭제하십시오. 오류 볼륨이 데이터 수집에 상당한 영향을 미치는 경우에만 이 옵션을 사용하십시오. 드롭 필터에서 최대한 구체적으로 작성하십시오.

결론

채택할 모범 사례:

각 스프린트가 끝날 때 성능 메트릭(이 문서에서 품질 기반 KPI로 공유)을 다시 살펴보세요.
개발자 스프린트에 성능 개선 사항을 통합합니다.
지원하는 비즈니스 라인 및 기타 내부 이해 관계자와 메트릭을 공개적으로 공유하십시오.
고객 경험 SLO를 정의합니다.
품질 기반 KPI의 비즈니스 크리티컬 하락 에 대한 경고를 생성합니다.

가치 실현

이 프로세스가 끝나면 다음을 수행해야 합니다.

엔지니어와 비즈니스가 이해할 수 있도록 유형적이고 실행 가능하며 쉬운 방식으로 최종 사용자 경험을 이해하십시오.
릴리스가 최종 사용자에게 어떤 영향을 미치는지 파악하십시오.
서비스, 인프라 또는 네트워크 수준 이벤트가 고객에게 미치는 영향을 파악합니다.
백엔드 서비스로 인한 지연 문제가 있는 경우 확인하세요.
함께 일할 수 있도록 비즈니스 소유자와 공통 언어를 만들었거나 만들 경로에 있습니다. 이것은 새로운 프로젝트에 대한 인정과 후원을 위한 새로운 길을 열 수 있습니다.

사용자의 편의를 위해 제공되는 기계 번역입니다.

품질 기반: 서비스 성능을 최적화하여 고객의 디지털 경험 개선

개요

요망되는 결과

핵심 성과 지표

유효성

가장 큰 함량이 있는 페인트(LCP)

첫 번째 입력 지연(FID)

누적 레이아웃 이동(CLS)

첫 번째 바이트까지의 시간(TTFB)

AJAX 응답 시간

HTTP 오류율

자바스크립트 오류율

전제 조건

필요한 지식

필수 설치 및 구성

현재 상태 설정

계측 페이지 검토

브라우저 URL 그룹화 확인

데이터를 분류하는 방법 이해

품질 기반 대시보드 가져오기

각 대시보드 페이지의 현재 성능 캡처

개선 프로세스

작업 계획

개선할 KPI 결정

목표 KPI 개선

페이지 로드 성능 향상

AJAX 응답 시간 개선

AJAX 오류율 개선

자바스크립트 오류 개선

결론