웹 사이트 속도 측정 방법(feat 쇼핑몰 주요 페이지 속도 측정 방법)

2. 웹개발/개발 주저리

웹 사이트 속도 측정 방법(feat 쇼핑몰 주요 페이지 속도 측정 방법)

갓대희 2023. 12. 2. 20:53

안녕하세요. 갓대희 입니다. 이번 포스팅은 [ 웹 사이트 속도 측정 방법(feat 쇼핑몰 주요 페이지 속도 측정 방법)에 대한 고찰 ] 하려 한다. : )

페이지 로딩에 대한 중요성과 관련하여서는 이전 글에서도 언급하였지만 한번만 더 확인하고 넘어 가자.

- 조금더 자세한 내용을 확인하고자 하면 다음글을 훑어 보는것도 좋을 것 같다.

2023.11.04 - [2. 웹개발/개발 주저리] - Front-End 모니터링 툴 Rum(Real User Mornitoring) 도입에 대한 고찰(1) - 개요(용어, 목적)

웹 성능과 비즈니스의 상관 관계에 대한 내용을 살펴보자.

- 웹사이트 로드 시간이 1초 증가될 때마다 사용자 수가 10% 감소(BBC)
- 웹사이트 로드 시간이 1초 감소할 때마다 서비스 전환율 2% 증가(Walmart)
- 모바일 사이트 로드 시간이 3초 이상 소요될 경우 53%의 사용자가 이탈(Google)
- 사용자 인지 대기 시간(perceived wait times) 40% 감소시 사용자 수 15% 증가(Pinterest)

이때문에 어떠한 기준을 갖고 어떻게 개선하면 좋을지 하여 Core "Web Vital" 이라는 것을 발표 하였다.

Core Web Vitals

- 구글에서는 발표한 사용자 경험을 판단하는 중요한 Core 지표 3가지. (하기에 조금더 상세히 표현)

https://support.google.com/webmasters/answer/9205520?hl=ko

- Chrome의 DevRel 에서는 Web Vitals라는 사이트를 운영중이다.

https://web.dev/

1) LCP(Largest Contentful Pain - 최대 콘텐츠 렌더링 시간 )

- 상세 내용 : https://web.dev/articles/lcp?hl=ko#what_is_lcp

- 가장 큰 콘텐츠가 표시되기까지 걸린 시간을 뜻한다.

1) 2.5초 이하 : 좋음, 양호함

2) 2.5초 이상, 4.0초 이하 : 개선 필요

3) 4.0 이상 : 나쁨

2) FID(First Input Delay - 최초 입력 반응 시간)

- 상세내용 : https://web.dev/articles/fid?hl=ko

- 사용자가 최초로 웹과 상호작용이 가능하기까지 걸린 시간을 말한다. 즉, 사용자가 어떤 버튼이나 링크를 눌렀을 때 이벤트 처리가 시작될 수 있는 시점이라고 볼 수 있다.

1) 0.1초 이하 : 좋음, 양호함

2) 0.1초 이상, 0.3초 이하 : 개선 필요

3) 0.4초 이상 : 나쁨

※ 2024년 3월부터는 FID가 INP로 대체 된다고 한다. 아주 간단 살펴보고 넘어가자.

INP : Interaction to Next Paint

https://web.dev/articles/inp?hl=ko

- 사용자가 페이지를 방문하는 전체 기간에 발생하는 모든 클릭, 탭, 키보드 상호작용의 지연 시간을 관찰하여 사용자 상호작용에 대한 페이지의 전반적인 응답성을 평가하는 측정항목.

응답성이 낮거나 좋은 경우의 예입니다. 왼쪽의 장기 작업은 아코디언이 열리지 않도록 차단합니다. 이 경우 사용자는 환경이 중단되었다고 생각하고 여러 번 클릭합니다. 기본 스레드가 따라잡을 때 지연된 입력을 처리하므로 아코디언이 예기치 않게 열리고 닫힙니다.

1) 0.2초 이하 : 좋음, 양호함

2) 0.2초 이상, 0.5초 이하 : 개선 필요

3) 0.5초 이상 : 나쁨

3) CLS(Cumulative Layout Shift - 누적 레이아웃 이동 수)

- 상세내용 : https://web.dev/articles/cls?hl=ko

- 위 영상은 안좋은 CLS와 관련된 안좋은 경험에 대한 예시이다.

"No, go back " 버튼을 클릭하려고 했지만, 갑자기 상단에 팁이 생성되며 레이아웃이 이동되었고, 의도치 않게 "Yes, place my order" 버튼이 클릭된 것을 볼 수 있다.

- 즉, 사용자가 예측하지 못한(혹은 의도하지 않은) 화면의 움직임 지표라고 볼 수 있다.

1) 0.1초 이하 : 좋음, 양호함

2) 0.1초 이상, 0.25초 이하 : 개선 필요

3) 0.25초 이상 : 나쁨

4) 그리고 그 지표와 비즈니스 상관 관계에 대해서도 다음과 발표 하였다.

1) 코어 웹 바이탈 기준점을 충족하면 사용자가 페이지 로드를 중단할 가능성이 24% 더 낮았다.
2) 최대 콘텐츠 렌더링 시간(LCP)이 100ms 감소할 때마다 Farfetch의 웹 전환율은 1.3% 증가다.
3) Yahoo! 재팬의 레이아웃 변경 횟수(CLS)가 0.2 감소하자 세션당 페이지 조회수가 15% 증가했고, 세션 시간은 13% 늘었으며, 이탈률은 1.72%포인트 감소했다.
4) Netzwelt에서 코어 웹 바이탈을 개선한 결과 광고 수익이 18%, 페이지 조회수가 27% 증가했다.
5) CLS를 1.65에서 0으로 낮춘 redBus는 전 세계적으로 도메인 순위가 크게 상승했다.

속도 개선을 하기위해

속도 측정부터 어떻게 하면 잘 할 수 있을지, 검토하고 고민했던 내용들을 기록 해보보려고 한다.

0. 들어가기 앞서

불과 몇년에는 직접 사람이 주요 페이지를 속도를 측정하며, 레포팅을 하였던 시절도 있었다.

ex) 각각 쇼핑몰을 직접 담당자들이 초시계를 켜 놓고 속도 측정한 결과

사람이 직접 손과 눈으로 측정 했지만 생각보다 엄청난 신뢰도있는 결과라고 생각하였는데,

그때도 기준이 명확했기 때문에 가능했던 것 같다.

( 추억과 감상에 젖어 들자면 이때 마이 페이지 속도개선을 목표로 하였고 결과적으로

경쟁사 20여군데 중 가장 빠르게 만들었을때 생각보다 재밌고 만족스러운 업무였던것으로 기억한다.

정말 오랜만에, Front 업무도 손을뗀 마당에.. ㅎㅎ 속도 측정에 대해 고민하게될 날이 오다니 나름 재밌기도 하다. )

성능 측정의 기준

웹 성능을 측정하고 분석 및 모니터링하는 방식에 대해 이전 글에서 언급 하였던 방법 중 크게 2가지 방법을 고민 하면 될 것 같다.

※ 참고

2023.11.04 - [2. 웹개발/개발 주저리] - Front-End 모니터링 툴 Rum(Real User Mornitoring) 도입에 대한 고찰(1) - 개요(용어, 목적)

첫번째 방법 - Real User Monitoring

두번째 방법 - Synthetic Monitoring

이중 난 Synthetic Monitoring 방식으로 개선 목표와 측정 기준으로 잡아보려고 한다.

( 물론 Real User Monitoring 방식도 참고하고 활용은 할 생각이지만, 실제 속도 측정시에는 Synthetic Monitoring 방식으로 해야한다고 생각한다. )

왜 이런 기준을 세우게 되었는지 남겨보려고 한다. (다른 의견들이 있으시다면 꼭 댓글로 의견 주시면 너무 좋을 것 같다.)

▶ Real User Monitoring

- 실제 사람이 측정하고 상세 분석을 하려고 하면 여러 환경적인 요인에 영향을 많이 받는다.

ex1) 네트워크 속도

- 특히 회사 사내에서 네트워크망은 불안정 할 수 있으며 속도가 낮을 수 있다.

1) 오전 사용자들이 많았을 때	2) 오후 점심시간 한가할 즈음

- 동일한 시점에 내 모바일 환경에서 속도 측정했을떄

3) 오전 사용자들이 많았을 때 (때마침 LTE 모드)	4) 오후 점심시간 한가할 즈음 ( 자동으로 5G 전환)

- 위의 경우 3번(LTE 모드로 잡혔을 때)과 4번(5G 모드로 잡혔을 때) 케이스에서는 큰 차이를 느낄 수 없지만

1번(2Mbps)과 2번(17Mbps)간의 체감 속도는 확연하게 다르다.

ex2) 브라우저 환경

1) 브라우저의 크기를 매번 동일하게 측정해야 하는데 다르게 설정하는 실수가 있을 수 있다.

이미지 : https://velog.io/@ken1204/viewport%EB%9E%80

예시1	예시2

- 위의 경우 예시1, 예시2의 vieport 설정이 달라 LCP 측정 뿐만아니라 여러 측정 기준들이 확연히 다른 점수로 측정될 것 이다.

2) 캐시 여부

- 측정을 시도하는 시점의 브라우저에서 캐시 적용 여부가 다른 경우, 설정하는 경우에서도 속도 차이가 발생 할 수 있다.

ex3) 장치, OS 환경

- 테스트를 하는 기기 or PC에서 현재 작업중인 별도의 Process들에따라 OS 성능이 달라 질 수 있다

- 이 경우 기존 기기 자체의 성능, performance가 다를 수 있어 성능 측정에 차이가 발생할 수 있다.

즉, 직접 성능 테스트를 진행하는

Real User Monitoring의 방식 관점에서는 이러한 기준과, 환경을 최대한 유지시켜주지 않는 이상

"성능 테스트 결과 자체에 신뢰도가 낮아질 수 있다." 고 나는 생각한다.

( 즉, 성능 테스트를 하는 사람의 배경 지식, 노력, 장비의 상태가 매우 중요 하다. )

ex4) 실제 고객의 입장에서 동일한 페이지의 성능 측정 기준을 살펴 보아도 크게 차이나는것을 볼 수 있다.

( 물론 안좋았던 고객의 여러가지 조건, 상황등을 분석해볼 수 있기 때문에 이를 통해서 개선 포인트를 잡을 수도 있다. )

- 하기는 실제 동일한 상품상세 페이지의 LCP, FCP, FID 등 주요 수치가 널뛰는 것을 볼 수 있다.

ex) 위의 동일한 URL 기준으로 좋은 점수 / 안좋은 점수를 받은 실제 고객의 환경적 요인을 간단히 비교해보자.


Heap Size
OS 및 Browser 스펙
이미지 다운로드속도	동일한 이미지 기준 약 0.2초	동일한 이미지 기준 약 1초


connect, TLS/SSL 문

ex) google 성능 측정 도구를 통한 합산

- RUM 기반에서 성능 측정시에는 다음과 같이 고객의 기기 스펙, 네트워크 환경에 따라 다를 수 있다.

※ 이 때문에 나는 두번째 방식인 Synthetic 기반의 성능 테스트를 기준으로 잡고자 한다.

▶ Synthetic Monitoring

- 지속적인 성능 측정의 관점에서 RUM과 다르게 일정한 테스트 환경을 지정할 수 있다.

( 특수한 상황, 테스트 환경의 변동성을 최소화 할 수 있다. )

1) 지리적 위치 선택

- 물론 이렇게 하기 위해 보통 가상머신을 사용하기 때문에 국내에서만 서비스를 하는 경우 해당 가상머신(테스트를 스행할 기기 라고 볼수 있다.) 지리적 위치가 중요하다.

( 즉, 원하는 지리적 위치를 제공하는 테스트룸, 테스트 업체를 선택 해야한다. )

ex) EC2 / 서울 리전

2) 테스트 할 기기 및 브라우저 선택

ex) Android / Galaxy S8

3) 네트워크 속도 설정

ex) 대중적으로 많이 사용하고(5G는 잘 터지지 않으니) LTE 환경을 기준으로 잡았다.

※ Light 하우스는 "Slow 4G" (예전엔 "Fast 3G"로 불렀음)을 기본 테스트 설정으로 하고 있다.

https://github.com/GoogleChrome/lighthouse/blob/main/core/config/constants.js

4) 테스트 횟수 설정

ex) 1회 수행으로 결과를 잡기엔 신뢰도가 낮다. 결과의 편차 확인을 위해 3회로 설정.

※ 실제 테스트를 수행 해보자.

▶ 위에서 언급한것과 같이 mobile용 사이트를 pc브라우저, mobile 브라우저로 테스트 하였을때의 차이점부터 살펴보자.1) PC 브라우저

테스트 브라우저에서 로드되었을때의 Capture 파일	첫 화면이 나오기까지 걸린 시간 측정

- pc브라우저에서의 테스트 요약 정보

2) Mobile 브라우저

테스트 브라우저에서 로드되었을때의 Capture 파일	첫 화면이 나오기까지 걸린 시간 측정

- mobile브라우저에서의 테스트 요약 정보

- LCP의 측면에서 PC브라우저가 유리 할 수 밖에 없었다. (잘못된 측정 방법에서 발생할 수 있는 케이스)

▶ 사람이 실제로 하는 것보다 객과적이고 유사한 성능 수치를 확인 할 수 있다.

▶ 렌더링 차단, blocking 요소 확인

- 해당 스크립트들은 비동기, 지연로딩, inline 삽입 등의 개선등을 고민해볼 수 있다. 특히 타사 요청이 페이지 렌더링을 차단하고 있어 속도가 느려지고 있다면 개발자들의 입장에서는 보수적으로 적용해야하지 않을까?

( 외부 스크립트로 인해 억울하게 백화 페이지를 겪은적도 있다. )

- 제외 또는 "preconnect", "preload"검토, "블록 스크립트" 여부도 확인.

https://sc.11h11m.net/s/E6766.js
/mobile/js/jquery-1.10.1.min.js?version=0121d75
/mobile/js/UserScriptConf.js?version=0121d75
/mobile/js/swiper.min.js?version=0121d75
/mobile/js/jquery.lazyload.js?version=0121d75
/mobile/js/xtractor-ebm.js?version=0121d75
/mobile/js/lb4lf.js?version=0121d75
https://t1.daumcdn.net/adfit/static/kp.js
https://image.cauly.co.kr/script/caulytracker.js
https://www.googleadservices.com/pagead/conversion.js
/file/WAS/display/Planning/plan_design/js/planCommon.v2.js
/wcslog.js
/analytics.js
https://static.tagmanager.toast.com/tag/view/1172

- 메인 쓰레드 차단이 약 1.4초 있었다고 분석하여준다.

91ms: https://www.googletagmanager.com/gtag/js?id=G-K1ZGHLS8PP
54ms: https://linkback.contentsfeed.com/src/20231202/lb4lf.min.js
545ms: https://cdn.megadata.co.kr/dist/prod/enp_tracker_self_hosted.min.js
3496ms: https://static.lfmall.co.kr/mobile/static/js/main.460c5181.js
56ms: https://connect.facebook.net/signals/config/1638196123170386?v=2.9.138&r=stable&domain=m.lfmall.co.kr
51ms: https://www.googletagmanager.com/gtm.js?id=GTM-KJ96TGZ>m_auth=>m_preview=>m_cookies_win=x
104ms: https://static.lfmall.co.kr/mobile/static/js/6437.42e30ab1.chunk.js
553ms: https://repo.whatap-browser-agent.io/rum/prod/v1/whatap-browser-agent.js
113ms: https://astg.widerplanet.com/delivery/wpc.php?v=1&ver=4.0&r=1&md=bs&ga=1imlo55-1mtfvar-1-1&ty=Home&ti=17479&device=mobile&charset=UTF-8&tc=1701503143263&loc= https%3A%2F%2Fm.lfmall.co.kr%2Fapp%2Fproduct%2FHSJU3D9C1BK
125ms: https://www.googletagmanager.com/gtag/js?id=AW-1032690246&l=dataLayer&cx=c

- gtag는 gtm 완전 전환 후 제거 할 수 있을 것 같다.

- main.js는 profiling을 통해 번들 크기를 줄이는 방법을 검토 해보면 좋을 것 같다.

- 몇가지 광고 스크립트는 마케팅과 협의가 필요하며, whatap-browser-agent 관련해서는 해당 업체에 문의 해볼 수 있을 것 같다.

- 메인 쓰레드의 처리내역을 살펴 보며 개선 포인트를 가져갈 수도 있다.