DEVOCEAN

시작하는 글

안녕하세요 웹 프론트엔드 개발자 Felix입니다.

웹 프론트엔드 성능 측정 방법 및 Tips에 대한 내용으로 세 번째 글을 작성합니다.

이전 글을 안 읽어보셨다면 필요하시면 한번 보시는 것도 좋을 것 같습니다. 본 글은 라이브 성능 개선에 초점을뒀습니다.

이전 글의 내용은 아래와 같습니다.

1. 웹 프론트엔드 성능 측정 방법 및 Tips(1) : 웹 성능 측정 도구들과 웹 성능을 측정하는 방법 중 Chrome 브라우저의 Lighthouse를 사용하는 방법 : 웹 프론트엔드 성능 측정 방법 및 Tips(1) 로 이동하기

2. 웹 프론트엔드 성능 측정 방법 및 Tips(2) : WebPageTest에 대한 소개 : 웹 프론트엔드 성능 측정 방법 및 Tips(2) 로 이동하기

구글에서 사용하는 측정 도구들은 이전 블로그에서 언급 드렸던 성능 지표를 기반으로 웹 사이트의 성능을 측정합니다. 이 수치들이 웹 프론트엔드 성능 측정시 범용적으로 사용하는 수치입니다. WebPageTest 또한 구글 성능 지표들을 기반으로 성능 점수를 측정합니다.

본 포스팅을 읽으시면 WebPageTest를 통해 실제 라이브 서비스 중인 웹 서비스의 성능을 측정하고 개선할 수 있으리라 생각이 듭니다.

WebPageTest(웹 페이지 테스트) 란?

먼저 WebPageTest를 간단히 소개하려고 합니다.

WebPageTest는 오픈소스 성능 측정 툴이지만 웹 페이지 스피드 인사이트(https://pagespeed.web.dev/) 보다 다양한 환경에서 측정이 가능하고 웹 성능 측정 관점에서 여러가지의 지표 정보를 제공합니다.

Google Page Speed Insight도 성능 측정시 유용하게 사용되는 툴 중에 하나이지만, 필자는 WebPageTest가 다음과 같은 장점이 있다고 생각합니다. 첫째, 타겟 환경을 지정해서 측정할 수 있다는점, 두번째는 결과 측정 리포트가 인지하기 쉽다. 세번째는 심층 결과리포트가 뛰어나다는점이고, 네번째는 무료도구지만 다양한 기능을 제공하고 있고, 유료 과금을 하면 추가적인 유용한 정보 등도 제공이 가능합니다.

위 특징 관련해서는 이전 포스팅인 '웹 프론트엔드 성능 측정 방법 및 Tips(2)' : WebPageTest에 대한 소개(웹 프론트엔드 성능 측정 방법 및 Tips(2) 로 이동하기)에서 좀 더 자세히 확인하실 수 있습니다.

웹 페이지 테스트 Tips

이제, 필자가 WebPageTest를 라이브 환경을 실제로 성능 측정하여 분석한 방법과 이를 토대로 개선 내용에 대해서 소개하려고 하는데요.

먼저, WebPageTest 측정 방법을 인지하시면 좋을 것 같은데요.

이전 포스팅에서 WebPageTest 측정 방법을 공유하였지만, 독자 분들의 편의 상 이전 글에서 ctrl + c, ctrl +v 하여 아래 측정 방법을 작성했습니다.

WebPageTest 측정 방법 : Quick Guide

WebPageTest를 이용한 웹 사이트 성능 측정은 매우 간단합니다.

WebPageTest (https://www.webpagetest.org/) 사이트에 접속하여 측정하고자 하는 url을 넣고 테스트를 실행하면 됩니다.

url 입력 후 아래 노란색 버튼의 ‘Start Test’를 클릭하면 됩니다.

웹 성능 측정 시작을 알리는 노란 버튼을 클릭하면 실시간으로 테스트가 됨을 확인할 수 있습니다.

보통 1분 내로 아래와 같이 측정하고자 하는 사이트의 웹 성능 측정에 대한 결과를 확인할 수가 있습니다.

*WebPageTest 분석 방법 & Tips

WebPageTest 결과 분석방법은 다양하지만 필자가 유용하게 사용했었던 몇 가지를 공유하려고 합니다.

이번에는 참고로 대중적인 네이버 웹사이트 모바일 타겟으로 테스트해봤습니다.

첫번째는 Filmstrip View에 대해 이야기하려고 합니다.

Page Performance Metrics에 있는 Plot Full Reports 버튼을 클릭하면 보기 쉬운 리포트 정보를 볼 수가 있습니다.

Filmstrip View가 나오는데요. 아래처럼 테스트 환경에서 시간의 흐름에 따라 어떤 뷰가 노출 되는지 측정이 가능합니다. 시간 흐름에 따라 html, js, css, image 등 다양한 파일들이 어느 시점에 다운로드를 시작했는지 알 수 있고요.

아래 파트의 5,6번째 요소가 rendering blocking 요소라는 것을 확인 할 수도 있습니다. 물론 이런 것들을 개선 해야 한다고 인지가 가능하겠죠?

아래처럼 Visual적인 요소가 언제 작업이 완료되었는지 확인도 가능합니다.

중요한 UI작업, Load time, CPU가 많이 사용되는 시간, 85%, 90%, 90% 시각적 요소의 완료시간 등의 확인도 가능합니다.

Layout Shift(화면 렌더링시 화면 레이아웃의 움직임) 에 대한 시점과 정도 또한 시간 그래프에서 확인이 가능합니다.

장점 & Tips: Filmstrip View를 통해 전체적인 프로세스 점검을 한 눈에 파악이 가능합니다. rendering blocking 요소를 없애면 렌더링 시간을 줄일 수 있습니다. 네이버의 경우는 다르지만, 개발을 오래 하다보면 쓸데 없이 javascript, css를 로드하는 경우도 있는데 이러한 경우도 표시가 됩니다.

CLS는 Web CoreVital (구글의 웹 성능지표) 점수의 25%의 가중치를 갖고 있는데요. 해당 CLS에 대해 보완점에 대해 파악이 가능합니다. 위의 경우와 더불어 CLS 개선도 다른 개선건들에 비해는 어렵지 않게 개선가능한 경우가 많았고, 해당 부분을 개선하면 향상된 웹 성능 수치를 쉽게 확인 할 수 있었습니다.

두번째는 Video of Page loading Process 분석 방법에 대해 이야기하고자 합니다.

결과 리포트 첫화면 에서 스크롤을 내리면 위처럼 Individual Runs가 나오고 여기서 Watch Video를 클릭하면 시간대별 녹화된 영상을 확인 할 수가 있습니다.

저 개인적으로는 시각적인 UI, UX 요소들이 사용성에 큰 영향을 미친다고 생각합니다. 우리나라 사람들의 시선은 위에서 아래, 왼쪽에서 오른쪽을 보지만 요소들이 노출되는게 순서가 사용성에 영향을 준다고 생각합니다.

Video of Page loading Process는 실제 보여지는 화면을 녹화되어서 확인이 가능한데요. 아래는 네이버 화면의 첫 홈화면인데 위에 header부분의 아이콘이 먼저 뜨고 아래 검색 영역이 노출되거나 혹은 전부 같이 노출되는게 자연스러울 것 같은데요.

실제로는 테스트 영상 녹화 화면에서는 header부분이 검색 부분보다 0.3초정도 늦게 노출되고 있습니다.

우리나라 같이 네트워크 환경이 좋은데서는 0.1초 차이도 안나서 사용성에 문제는 전혀 없겠지만 네트워크가 안좋은 글로벌 서비스 환경에서는 UX적으로 보완이 필요한 요소가 될 수도 있을 것 같습니다.

위에서 보는 것처럼 실제 녹화된 영상을 통해 개발된 웹페이지가 사용자에게 요소별로 어떤 순서로 노출되는지 확인이 가능합니다.

장점 & tips : 위 기능이 유용한 이유는 실제 브라우저에서 이러한 요소들을 디버깅하거나 하면서 일일이 확인을 하고자 한다면 굉장히 많은 시간이 걸릴 수 있습니다. 그리고 화면을 녹화하려면 당연히 다른 녹화도구가 필요할텐데 webpagetest를 사용한다면 측정에 많은 시간 절약이 가능합니다.

세번째는 Waterfall View를 제공한다는 점입니다.

Individual Run 부분에서 Waterfall 아래 이미지를 클릭하면 아래 화면으로 이동이 됩니다.

아래 리포트에서 보이듯이 Render Blocking 요소뿐만 아니라 insecure request 부분 또한 확인이 가능하여 개선점을 찾을 수 있습니다.

CLS(Layout Shift)뿐만 아니라, LCP(Largest Contentful Paint) 등 다양한 요소의 소요시간 및 시점도 확인이 가능합니다.

Waterfall View의 아래부분에서는 콘텐츠의 우선순위, 여러 요소들의 요청시간, 걸리는 시간 등 다양한 요소들의 시간 또한 파악이 가능합니다.

장점 & Tips : 전체적으로 사이트에서 어떠한 요소들이 불러와지는지 확인이 가능하고 이를 토대로 불필요한 요소들은 제거하고, 문제가 되는 부분들을 개선할 수 있습니다. 이 리포트를 통해 비효율적인 요소를 인지하고 제거하는 것만으로 웹사이트 렌더링 시간에 크게 영향을 줄 수 있습니다. 몇년간 운영중인 웹사이트의 경우는 개선 요소가 많이 파악될 수도 있습니다.

네번째는 Opportunities & Experiments 에 대해 설명하고자 합니다.

Opportunities & Experiments는 lighthouse나 page speed insights에서도 동일하게 나오는 개선 포인트들이 표출될 수는 있습니다. 그러나 해당 부분을 개선했을 때 어떤 영향이 있을지 확인하고 싶을 수 있는데요. WebPageTest의 Experiments를 통해서 실제 코드 개선 없이 효과를 예측할 수 있습니다.

Original과 Experiment 비교를 통해서 어떠한 수치들이 좋아질 것인지 확인이 가능합니다.

아래 화면에서는 영상 시뮬레이션을 통해 14.5초 시점에 가운데 영역을 아래보다 먼저 띄우는 점을 볼 수가 있고요. 이 점은 experiment 버전에서 layout shift가 0이 되었음을 확인 할 수 있습니다.

뿐만 아니라, 위 experiment를 통해 실험실 시도에서는 original보다 UI 요소들이 0.5초 먼저 뜨는 것도 확인 할 수가 있습니다.

장점 & Tips : Webpagetest의 experiment 기능을 통해서 다양한 개선 방식 중 어떤 것이 효과적일지 코드 개선없이 어느정도 가늠할 수 있어서 개발하는 입장에서는 효과 예측이 가능하여 개선 효과를 파악하는데 도움을 줄 수 있을 것 같습니다.

다섯번째는 Web Page Test는 다양한 기능이 많습니다.

Web Vital이나 Optimization 등 다양한 Option을 통해서 여러 결과들 확인이 가능합니다.

Web Core Vital 수치 확인이 가능한데요. 테스트 데이터를 통한 성능 지표도 파악이 가능하지만 실제 데이터를 통해서 확인도 가능합니다. Page Speed Insight 같은 경우는 실 운영 데이터를 보려면 28일 기간동안에 일정 수의 유저가 실제 방문해야지 Real World Data 확인이 가능한데, WebPageTest는 PageSpeed Insight보다 적은 수의 데이터로도 성능 지표 확인이 가능합니다.

Optimization 옵션에서도 보안 및 압축 등 다양한 지표에 대해 웹 성능 최적화 결과를 기반으로 개선이 필요한 요소들 확인이 가능합니다.

마치는 글

이번 시간에는 필자가 실제 사용해본 경험을 바탕으로 WebPageTest 사용법에 대해 좀 더 자세히 말씀드렸는데요. WebPageTest 이 기능이 정말 많은데, 실제 사용하면서 필자가 느꼈던 유용한 기능들에 대해 소개 해드리면서, 간단한 팁도 같이 공유 드렸습니다.

웹 프론트엔드 성능 측정하시는 분들에게 조금 이나마 도움이 되셨으면 좋겠습니다.

아마 실제적인 개선 내용에 대해 부족하다고 느끼시는 분들도 있을 것 같은데요.

작년에 온라인 Tech 세미나에서 WebPageTest를 사용해 실제 운영중인 웹서비스를 분석하고 개선했던 내용을 발표한 적이 있는데요. 실제 개선한 내용에 대해서는 이 링크를 통해서 보시면 좋을 것 같습니다.

• Tech 세미나 - 웹 프론트엔드 성능 최적화 방법 및 적용 사례

  *위 Tech 세미나 중 실제 성능 개선 내용 시작 부분

혹시 궁금한 점들이 있으면 메시지나 댓글로 질문 주시면 답변 드리도록 하겠습니다.

긴 글 읽어주셔서 감사합니다.