웹 성능측정 방법

목표

이번 글에서는 WebPageTest로 웹 페이지를 진단하는 방법에 대해 알아보자.

WebPageTest란?

WebPageTest - Website Performance and Optimization Test

 

WebPageTest는 세계 여러 위치에서 웹 사이트 로딩 속도를 테스트할 수 있는 무료 서비스이다. 실제 유선망이나 모바일 망의 네트워크, 다양한 기기, 브라우저를 세계 곳곳에 설치하여 사용자 환경에서 테스트할 수 있는 서비스이다.

기본 사용법

기본 옵션

1. URL: 테스트하려는 웹사이트 주소를 입력한다.
2. Test Location: 테스트하고자 하는 지역을 선택할 수 있다.
3. Browser: 테스트하고자 하는 브라우저 종류를 선택할 수 있다.

추가 옵션

1. Connection: 테스트에 사용할 네트워크 종류를 선택한다.
2. Number of Tests to Run: 동일 조건으로 몇 회 테스트할 건지 선택한다.
   등 이 존재한다.

고급 사용법

모바일 사이트 성능 측정하기

모바일 트랙픽이 PC의 트래픽을 넘어선 지금 모바일 기기를 사용해 성능을 측정할 수 있다. Browser 항목에서 테스트할 모바일 기기를 선택하고 Advanced Settings -> Connection 항목에서 원하는 모바일 네트워크 환경을 선택한 후 테스트를 진행하면 된다. 해당 테스트는 특정 지역에서만 가능하여 한국에 호스팅하고 있는 웹 사이트들을 측정할 때는 Chromium Emulator 사용해야 한다.

Advanced Settings -> Chromium Emulator를 사용해 원하는 모바일 기기를 선택한다. Test Setting에서 적절한 모바일 네트워크를 선택하여 테스트를 할 수 있다. 모바일 네트워크 환경은 실제 모바일 네트워크 제공이 아니라 인위적으로 해당 대역폭을 사용하는 방식이다.

네트워크를 3G, LTE로 변화시켜 테스트를 진행해 볼 수 있다는 점이 흥미로웠다.

스크립트 활용하기

스크립트는 매우 유용하게 사용될 수 있다. 직접 URL를 입력해 접근하는 방법도 있지만, 사실 사용자가 일반적으로 URL에 원하는 페이지에 진입할까? 좀 더 사용자 측면에서 접근해서 테스트할 수 있는 방법이라고 생각한다. 한번 작성한 스크립트를 확인해보자.

* 스푸밍: Spoofing(스푸핑) 다른 사람의 컴퓨터 시스템에 접근할 목적으로 IP주소를 변조한 후 합법적인 사용자인 것처럼 위장하여 시스템에 접근함으로써 나중에 IP주소에 대한 추적을 피하는 해킹 기법의 일종이다.

1. 경로 변경 시 성능 측정

logData    0
navigate   https://test.com/
navigate   https://test.com/prime

logData    1
navigate    https://test.com/enterprise

navigate는 이동하고자 하는 URL을 입력하면 해당 페이지로 이동한다. 처음 test 메인 페이지로 이동 후 다음 prime 페이지로 이동한다. 마지막으로 enterprise 페이지로 이동한 결과가 기록된다.

logData값이 1인 경우에만 측정 결과를 보여준다.

2. 로그인 시 테스트 방법

로그인 후 집입 가능 화면이 존재하는데, 이때 테스트를 진행하기 위해 필수적인 것 같아 해당 스크립트를 작성해봤다.

logData       0
navigate      https://test.com/
exec    document.querySelector("[data-ga-action='click on login_/']").click()
exec    $("form input[type=email]").val("");
exec    $("form input[type=password]").val("");
clickAndWait    id=loginBtn
logData       1
navigate    https://test.com/

다음은 인증 후 메인 페이지로 이동하는 스크립트이다. 로그인 모달을 띄우고 email과 password를 입력한다. 그리고 로그인 버튼을 클릭 후 마지막으로 메인페이지로 이동하는 것이다.

최적화 진단 요소

다음은 결과 화면에서 노출되는 최적화 진단 요소에 대해 알아보자.

First Byte Time

HTTP 요청을 했을 때 처음 byte가 브라우저에 도달하여 프로세싱을 시작되는 시간을 뜻한다. 구체적으로 First Byte Time은 브라우저의 요청 준비 시간, 서버 처리시간과 네트워크 지연시간을 포함하지만 DNS 처리 TLS HandShake 같은 TCP 연결 시간은 포함하지 않는다. First Byte Time이 느린 경우는 서버의 처리 시간이 오래 걸렸다고 의심해 봐야 한다.

결과를 Waterfall view를 통해서 First Byte Time 시각적으로 확인할 수 있다. 연결 상태, 밝고, 어두운 음영의 바는 리소스 유형을 나타내는데, 밝은 음영은 브라우저가 리소스를 요청한 지점을 나타내고, 어두운 음영은 리소스가 실제로 다운로드되는 지점이다.

위에서 First Byte Time은 0.250s인데, Waterfall View를 클릭해보면 Request Start 항목이 존재하는데 이는 리소스 유형 바에 밝은 부분이 시작하는 시간이다. 0.009s이고 Time to First Byte가 0.241s 서로 더하면 0.250s가 된다.

정리하면 서버 처리에서 주로 시간이 소요되었다는 것을 알 수 있다. 구글에서는 200ms 미만의 Time to First Byte를 제안한다.

* Time to First Byte - 초기 요청에서 서버로의 첫 번째 비트가 브라우저에 도달하는 데 걸리는 시간을 측정한다.

Keep-alive Enabled

Keep-Alive 브라우저와 서버 간의 연결이 열린 상태로 유지되어 단일 연결을 통해 여러 파일을 전송할 수 있도록 하는 HTTP 해더 라고 한다. Keep-Alive 해더라 없다면 각 파일을 요청 수신하는 과정을 반복한다... 그러니 Keep-alive 활성화는 성능 향상을 보일 수밖에 없다.

WebPageTest에서는 간단하게 표현한다.

Use persistent connections (keep alive): 100/100

Compress Transfer

압축 전송은 gzip으로 정적 파일을 압축하여 전송하는 기법이라고 한다. 콘텐츠를 압축하면 트래픽 자원을 아끼고 사이트 속도도 향상할 수 있다고 한다. 다음은 테스트한 결과이며 B라는 점수를 받았다.

Use gzip compression for transferring compressable responses: 89/100
2,241.5 KB total in compressible text, target size = 1,994.9 KB - potential savings = 246.6 KB

FAILED - (173.1 KB, compressed = 46.8 KB - savings of 126.4 KB) - https://assets.ubembed.com/universalscript/releases/v0.179.1/bundle.js
FAILED - (72.3 KB, compressed = 8.9 KB - savings of 63.4 KB) - https://test/api/header/v2/directories
FAILED - (33.6 KB, compressed = 10.0 KB - savings of 23.6 KB) - https://test/Util/fingerprint.min.js
FAILED - (24.7 KB, compressed = 4.3 KB - savings of 20.5 KB) - https://test/main-themes
FAILED - (13.6 KB, compressed = 6.5 KB - savings of 7.0 KB) - https://cdn.megadata.co.kr/js/socialLink/social_sns_config_min.js
FAILED - (7.2 KB, compressed = 2.9 KB - savings of 4.4 KB) - https://test/Track.js
FAILED - (2.0 KB, compressed = 0.6 KB - savings of 1.4 KB) - https://test/mssg/common

압축 가능한 전체 2,241.5KB 중에서 목표로 1,994.9KB까지 압축할 수 있다는 것 의미하는 것 같다. 그래서 잠제적인 절약은 246.6KB를 더 할 수 있다고 설명하는 것 같다. 아래는 압축 가능한 파일이지만 실패한 항목들을 나열한 것이다. 실패한 항목들은 기존 용량과 압축했을 때 용량 그래서 절약한 용량이 어느 정도인지 나타 난다. 246.6KB 만 더 노력해서 압축하면 되겠구나.라는 생각이 들었다. 이 부분은 nginx와 같은 웹 서버에서 간단한 설정을 통해서 사용할 수 있다고 한다.

Compress Images

이미지는 많은 트래픽을 유발하여 로딩 지연을 발생시킨다고 한다. 이미지 압축은 사람의 눈에 띄지 않게 이미지 품질을 낮추고 파일 크기를 최소화하는 작업이라고 한다. 파일 크기를 줄이면 웹페이지에서 다운로드하는데 필요한 시간을 줄여준다. 아래는 Compress Images 테스트 결과이다.

Compress Images: 90/100
1,148.5 KB total in images, target size = 1,029.3 KB - potential savings = 119.2 KB

FAILED - (133.8 KB, compressed = 49.9 KB - savings of 83.9 KB) - https://this-is-test/assets/images/curated_contents/test.jpg
WARNING - (56.0 KB, compressed = 29.4 KB - savings of 26.6 KB) - https://intro/categories/test.jpg
WARNING - (36.8 KB, compressed = 31.6 KB - savings of 5.1 KB) - https://this-is-test/intro/categories/category_2_235.jpg
WARNING - (25.0 KB, compressed = 21.6 KB - savings of 3.4 KB) - https://this-is-test/intro/categories/category_2_236.jpg

Cache static content

이 항목은 브라우저 캐시가 적용돼 시 않은 리소스 목록들이 나타난다. 아래는 Cache static content 결과이다.

Leverage browser caching of static assets: 21/100
FAILED - (No max-age or expires) - https://d2v80xjmx68n4w.cloudfront.net/gigs/OG37M1621911347.jpg
FAILED - (No max-age or expires) - https://d2v80xjmx68n4w.cloudfront.net/assets/images/curated_contents/mpoRw_curated_content_item_main_desktop_663.jpg
FAILED - (No max-age or expires) - https://d2v80xjmx68n4w.cloudfront.net/gigs/AnlTn1612161746.jpg
FAILED - (No max-age or expires) - https://d2v80xjmx68n4w.cloudfront.net/gigs/KEPO71611756612.png
FAILED - (No max-age or expires) - https://d2v80xjmx68n4w.cloudfront.net/gigs/B4P8V1618758331.jpg
FAILED - (No max-age or expires) - https://d2v80xjmx68n4w.cloudfront.net/gigs/Q5LLb1607927633.jpg
FAILED - (No max-age or expires) - https://d2v80xjmx68n4w.cloudfront.net/gigs/4h7xN1632894861.jpg

이러한 정적 파일들은 자주 바뀌지 않기 때문에 캐시를 하게 되면 일정기간 동안 또는 새로운 파일로 바뀌지 않는 이상 클라이언트의 브라우저 내에 다운로드 된 파일을 로딩할 수 있다. 브라우저 내에서 캐시 기간은 응답 헤더의 Cache-Control: max를 이용해 설정한다고 하는데, 대부분 웹서버에서 간단히 설정 가능한 부분이다.

Effective use of CDN

CDN(콘텐츠 전송 네트워크)은 지리적으로 분산된 여러 개의 서버입니다. 웹 콘텐츠를 사용자와 가까운 곳에서 전송함으로써 전송 속도를 높입니다. 전 세계 데이터센터는 파일 복사본을 임시로 저장하는 프로세스인 캐싱을 사용합니다. 따라서 사용자는 가까운 서버를 통해 웹 활성화 디바이스 또는 브라우저에서 인터넷 콘텐츠에 빠르게 접속할 수 있습니다.

다음은 CDN 결과이다.

Use a CDN for all static assets: 91/100
FAILED - https://test.com/img/ic/ic_arrow_to_left_white_@x2.png
FAILED - https://test.com/fonts/slick.woff
FAILED - https://test.com/img/gig_list/ic_desktop_gig_list_bookmarks.png
FAILED - https://test.com/img/gig_list/img_desktop_company.png
FAILED - https://stats.pusher.com/timeline/v2/jsonp/1?session=MTg5ODgwMzk%3D&bundle=MQ%3D%3D&key=OWU1YWI2NDA4MTQ3M2IwZGE5Njg%3D&lib=anM%3D&version=My4wLjA%3D&cluster=YXAx&features=WyJ3cyJd&timeline=W3siaW5zdGFuY2VzIjoxLCJ0aW1lc3RhbXAiOjE2Mzc0NjY3ODc1OTB9LHsic3RhdGUiOiJjb25uZWN0aW5nIiwidGltZXN0YW1wIjoxNjM3NDY2Nzg3NTkxfSx7ImNpZCI6MSwidHJhbnNwb3J0Ijoid3NzIiwidGltZXN0YW1wIjoxNjM3NDY2Nzg3NTkxfSx7ImNpZCI6MSwic3RhdGUiOiJpbml0aWFsaXplZCIsInRpbWVzdGFtcCI6MTYzNzQ2Njc4NzU5MX0seyJjaWQiOjEsInN0YXRlIjoiY29ubmVjdGluZyIsInRpbWVzdGFtcCI6MTYzNzQ2Njc4NzU5NX0seyJjaWQiOjEsInN0YXRlIjoib3BlbiIsInRpbWVzdGFtcCI6MTYzNzQ2Njc4ODI2Nn0seyJzdGF0ZSI6ImNvbm5lY3RlZCIsInBhcmFtcyI6eyJzb2NrZXRfaWQiOiIxMjc3OS4zODU4ODczMyJ9LCJ0aW1lc3RhbXAiOjE2Mzc0NjY3ODgzMzh9XQ%3D%3D

CDN's Used:
googleads.g.doubleclick.net : Google
www.facebook.com : Facebook
www.google-analytics.com : Google
test.com :
www.google.com : Google

CDN을 사용하고 있는, 아니면 사용하고 있지 않은 모든 자산들을 나타낸다.

추가 측정 항목

start Render

화면에 무언가가 처음 표시되는 순간이다.

speed index

speed index는 페이지에 콘텐츠가 시각적으로 얼마나 빨리 채워지는지 측정한다. speed index 지표가 왜 생겨났을까?

우리는 웹 페이지가 얼마나 빠른지 측정하기 위해서 주로 onLoad 이벤트에 도달할 때까지 시간으로 측정(모든 정적 페이지 콘텐츠가 적재된 상태)을 할 수 있다고 한다. 하지만 실제 사용자 경험에 대해서는 좋은 지표가 아니다. 왜냐면 표시되지 않거나 화면 밖에서(스크롤해야지 볼 수 있는 화면) 콘텐츠도 로드되어야 onLoad 이벤트에 도달하게 된다. 따라서 실제 사용자 눈에는 이미 렌더링이 된 것 같은데, 나머지 콘텐츠도 렌더링 해야 하기 때문에 시간은 늘어난다. 이러한 결함이 있기 때문에 speed index 지표가 생겨났다.

speed index는 보이는 페이지 로딩을 시각적 진행률을 취하고 콘텐츠가 얼마나 빨리 페인팅되는지 계산한다. WebPagetest에서는 브라우저가 로딩되는 페이지의 비디오를 캡처하고 각 비디오 프레임을 검사한다고 한다.

한마디로 화면에 콘텐츠가 얼마나 빨리 그려지는지를 확인할 수 있는 지표이다.  

 

First Contentful Paint(FCP)

웹사이트의 FCP는 브라우저가 페이지의 첫 번째 DOM 요소를 렌더링할 때입니다. 여기에는 이미지, 캔버스 요소(흰색이 아님) 또는 텍스트가 포함된다.  FCP는 사용자가 페이지 변경 사항의 일부이며 이것은 헤더 표시줄이나 배경 이미지 등으로 제공된다. 이 요소는 서버에서 렌더링되거나 로드되는 첫 번째 요소가 아닐 수 있지만 사용자가 볼 수 있는 첫 번째 요소이므로 사이트의 UX에 가장 중요하다고 한다.

좋은 점수는 0 ~ 1.8s 사이이다.

 

Largest Contentful Paint(LCP)

LCP는 웹사이트가 사용자에게 가장 큰 콘텐츠를 화면에 표시하는 데 걸리는 시간 측정하는 것이다. 해당 콘텐츠는 다음과 같다.

• Images.
• Image tags.
• Video thumbnails.
• Background images with CSS.
• Text elements, such as paragraphs, headings, and lists.

그런데 왜 이 지표가 중요할까? 구글에서 말하길 LCP는 SEO와 밀접한 관계가 있다고 한다. LCP는 페이지 로딩 시간과 관련 있기 때문에 Google이 결과 페이지에서 사이트를 분석하고 순위를 매기는 방식에 자연스럽게 영향을 미친다고 한다.

우수한 사용자 경험을 제공하려면 LCP는 2.5초 이하여야 한다고 한다. 

Cumulative Layout Shift(CLS)

CLS 사용자가 예상치 못한 레이아웃 이동을 경험하는 빈도를 수량화하므로 시각적 안정성을 측정할 때 사용하며, CLS가 낮으면 우수한 사용자 경험을 보장하는 데 도움이 되는 지표이다. 좋은 CLS 점수는 0.1 이하여야 한다고 한다.

Total Blocking Time(TBT)

총 차단 시간(TBT) 메트릭은 메인 스레드가 입력 응답을 막을 만큼 오래 차단되었을 때 First Contentful Paint(FCP)와 Time to Interactive(TTI) 사이 총 시간을 측정한다. 메인 스레드에서 50밀리초(ms) 이상 실행되는 작업, 즉 긴 작업이 있을 때마다 메인 스레드는 "차단"된 것으로 간주되는데, "차단"되었다고 하는 이유는 브라우저가 진행 중인 작업을 중단할 수 없기 때문이다. 따라서 사용자가 긴 작업 중 페이지와 상호 작용한 경우 브라우저는 일단 해당 작업이 끝나기까지 기다린 후에야 응답할 수 있다. 긴 작업으로 인해 대화형 기능이 얼마나 심각한 영향을 받았는지 보여준다.

TBT는 FCP와 TTI 사이에서 일어나는 작업을 측정한다. TTI(Time To Interactive)는 페이지가 완전히 상호 작호 할 수 있는 데까지의 걸리는 시간을 알려준다. 300ms 미만의 TBT가 좋은 점수라고 한다.

Document Complete

브라우저의 OnLoad 이벤트가 발생한 시점이며 일반적으로 모든 정적 페이지 콘텐츠가 적재된 상태이다.

*OnLoad - 모든 정적 페이지 콘텐츠가 적재된 후 script를 실행하기 위한 이벤트이다.

Fully Loaded

OnLoad 이벤트 발생하면 로드된 JS가 실행되면서 부가 콘텐츠를 가져올 수 있기 때문에 Document Complete 이후에도 페이지는 동적으로 변화할 수 있다. 따라서 변화의 시점이 모두 끝난 시간을 측정하기 위한 지표라고 할 수 있다.

구글의 웹 최적화 기술 적용하기

Lighthouse 란

구글에서 개발한 Lighthouse는 웹 페이지의 성능 지표를 비롯한 항목들을 검사하고 개선할 수 있도록 도움을 주는 오픈 소스 형태의 자동화 도구이다. Lighthouse는 현재 웹 페이지에 적용된 내용을 분석하고 그에 대한 메트릭스 점수를 알려주며 점수가 낮은 항목은 사용자가 개선 작업을 할 수 있도록 개선 사항을 알려주는 방식이다.

대표적인 지표 6가지

First Contentful paint, Speed index, Lagest Contentful Paint, Time to Interactive, Total Blocking Time, Cumulative Layout Shift 가 있다.이지표는 WebpageTest에도 존재하는 지표들이다.

Lighthouse는 웹 페이지 검사를 진행하여 얻은 각 성능 메트릭 점수를 가중치와 곱한 후, 모든 결과를 합하여 0 - 100 사이 점수를 반환한다.

사용방법

Node.js 개발한 커멘트 라인 도구를 테스트 PC에 설치하고 사용하는 방법, 크롬 개발자 도구에 설치된 Lighthouse 도구 사용, extension을 이용해 사용하는 방법이 있는데, 필자는 크롬 개발자 도구에 설치된 Lighthouse 도구를 사용해 보겠다.

결과

아래는 테스트 결과 화면 중 일부이다.

1. performance(성능): 웹 페이지가 얼마나 빠르게 로딩되는지에 대한 지표
2. Accessiblity(접근성): 사용자가 얼마나 쉽게 웹 페이지의 기능들을 사용할 수 있는지에 대한 지표
3. Best Practice: 웹 페이지 제작 시 일반적인 기능들이 얼마나 적용되었는지에 대한 지표
4. SEO(검색 엔진 최적화): 검색 엔진에 의해 검색될 수 있도록 웹 페이지 구조를 만들었는지에 대한 지표
5. Progressive Web App: PWA 관점에 확인한 지표

실습

1. 페이지 이동

1. next -> vue
2. vue -> next
3. next -> next