DEVOCEAN

1. 시작하는 글

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

웹 프론트엔드 성능 최적화 측정은 어떻게 해야 할까요? 어떤 방법, 어떤 도구로 측정을 해야 하고, 측정 지표를 보고 어떤 식으로 개선을 해야할까요?

아마 웹 프론트엔드 성능 최적화 경험이 없으신 분이나 경험이 적으신 분은 기존에 알고 있는 방법이 맞는 건지 의문을 가지실 수 있습니다.

이번 포스팅에서는 웹 성능 측정 도구에 대해 몇개 소개해드리고 현업에서 웹 프론트엔드 성능 최적화 하는 방법에 대해서 이야기 해보려고 합니다.

이전 포스팅에서는 웹 프론트엔드 성능 최적화를 왜 해야하는지에 대해 공유 드렸었습니다. 만약 궁금하신 분들은 아래 링크를 따라가 보세요.

https://devocean.sk.com/search/techBoardDetail.do?ID=164863

그리고 다가올 웹 성능 지표에 대해서 소개해드렸습니다. 구글에서 사용하는 측정 도구들은 언급 드렸던 성능 지표를 기반으로 웹 사이트의 성능을 측정합니다.

아래 소개드릴 예정인 측정 방법들 또한 제가 사용했던 방법으로 구글의 성능 측정 기반으로 성능을 측정합니다.

https://devocean.sk.com/search/techBoardDetail.do?ID=165334

이번 글에서는 먼저 소개해드렸던 지표들을 가지고 성능 측정 툴에서 어떻게 측정되는지 설명드리고자 합니다.

이 글을 읽으시면 웹 개발을 하시면서, 로컬 개발 환경에서는 웹 프론트엔드 성능 측정하시는 방법을 아실 수 있으리라 생각됩니다.

2. 웹 성능 측정 도구

본격적으로 웹 성능 측정 방법에 대해서 이야기 하기 전에 다양한 웹 프론트엔드 성능 측정방법에 대해 살펴보도록 하겠습니다.

구글 측정 도구에 대해 먼저 살펴보도록 하겠습니다.

성능 측정 도구는 다양한데 측정에 대한 목적에 맞게 사용하시면 좋을 것 같습니다. 제가 사용했던 측정 방법에서는 다음 장에 설명 드리도록 하겠습니다.

Search Console은 웹 사이트의 검색 엔진 최적화(SEO)와 성능 모니터링을 위한 플랫폼입니다.

SEO에 대한 분석을 해주고, 웹 트래픽에 대한 모니터링을 해줍니다.

구글의 Page Speed Insights는 실제 사이트 데이터를 확인할 수 있는 유용한 사이트입니다.

Lighthouse와 마찬가지로 구글에서 정한 중요한 웹 성능 지표인 LCP, CLS, FID 등을 보여줍니다.

아래 링크로 들어가면 성능 측정이 가능합니다.

https://pagespeed.web.dev/?hl=ko

아래와 같이 리포트 결과를 볼 수 있고, 성능 측정하고 보완해야할 내용은 lighthouse와 비슷하게 결과를 리포팅해줍니다.

Google Page Speed Insights는 아래처럼 지난 28일간 방문자들의 실제 데이터를 기반으로 측정합니다. 브라우저는 크롬 브라우저 사용자만 측정이 가능합니다.

Chrome UX Report 같은 경우는 origin 레벨이라 모든 페이지 url의 방문자를 페이지 구분 없이 결과를 보여줍니다.

그래서 다양한 사용자의 전체적인 사용자 경험 및 웹 성능 지표를 확인할 수 있지만 특정 페이지에 대한 리포트는 아닙니다.

Web Vitals js는 설치하면 구글 크롬 브라우저 외에 서비스의 MS edge, Safari 등 타켓 브라우저에 맞게 웹 프론트엔드 성능 측정이 가능합니다.

이 도구, 라이브러리를 이용하려면 성능 측정하는 환경에서 Javascript를 실행시킬 수 있어야 합니다.

이 라이브러리를 통해 Safari, MS Edge 등의 데이터도 잘 확인할 수 있습니다.

구글의 성능 측정 도구 외에도 Akamai 등 다양한 도구들이 존재합니다. 그 중 GTmetrix와 Pingdom에 대해서는 다음 포스팅에서 한번 소개해드리겠습니다.

3. 웹 성능 측정하는 방법

이 방법은 필자의 팀이나 제가 아는 개발자들이 사용했던 방법으로 다른 방법이 있다면 댓글로 공유해주셔도 좋을 것 같습니다.

성능 측정하는 방법은 다양하기 때문입니다.

1) 로컬 개발

로컬 개발시에는 서버 접근이 public망에서 당연히 불가 하기 떄문에 크롬 브라우저에 lighthouse를 적극 활용했습니다.

lighthouse는 직접 node package로 인스톨하여 측정이 필요한 방법도 있습니다.

그러나 로컬 개발시에는 크롬 브라우저의 개발자 도구를 이용해서 로컬에서의 측정이 가능합니다.

(1) 측정 방법

• 크롬 개발자 도구를 켭니다. (단축키 - Windows : F12, Mac : alt + cmd + i)

• Lighthouse 탭에서 측정하고자 하는 해상도(Device)에 따라 Mobile인지 Desktop인지를 선택하고,

  Categories에서 Performance를 선택하고 위에 'Anazyze page load'를 클릭하면 해당 웹페이지 측정이 가능합니다.

  
  

(2) 측정 내용 해석 및 적용

위의 측정방법에서 측정을 하면 사이트마다 편차가 있긴 하지만 수십초 정도가 지나면 결과가 나옵니다.

아래가 리포트 첫 화면인데, 구글에서의 기준 성능 점수를 확인할 수 있고,

구글의 성능 지표인 First Conteentful Paint(FCP), Largest Contentful Paint(LCP), Total Blocking Time(TBT), Cumulative Layout Shift(CLS), Speed Index(SI)에 대한 점수를 확인 할 수 있습니다.

바로 아래에는 '추천'과 '진단'이라는 항목이 나오는데요. 바로 측정한 사이트에 대한 개선할 여지가 있는 내용을 확인 할 수 있습니다.

추천 사항(Recommendations)에서는 Lighthouse에서 제공하는 실 건의사항으로 실질적으로 성능 개선에 도움을 많이 주는 항목입니다.

이미지 최적화, Javascript, CSS 줄이기 등 실질적인 내용을 제안합니다. 그러나 항목 별로 각각 적용 했을 때 개선 수치는 세부 내용에 따라 편차가 존재합니다.

진단정보(Diagnostics)는 잠재적 문제 또는 개선 기회에 대한 내용으로 위 추천 사항과는 성격이 좀 다릅니다. 비교적 추천항목보다 적용시 성능적 개선을 떨어질 수 있습니다.

추천사항처럼 구체적이지는 않지만 특정 문제를 이해하는데 도움을 줄 수는 있습니다.

아래는 추천 항목에서 나온 첫 번째 가이드입니다. 현재 사이트에서는 png, jpg 포멧을 사용하는데 차세대 이미지 포멧인 WebP, AVIF 같은 이미지 확장 포멧을 사용하라는 내용입니다.

물론 여기 나오는 가이드가 커버하는 서비스마다 호환이 안 될 수도 있기 때문에 크로스브라우징 이슈는 없는지도 잘 확인해봐야 합니다.

아래는 진단(Digontics)에 대한 부분에서 첫 항목에 대한 내용입니다. DOM 크기가가 크다는 내용입니다.

아래 내용처럼 DOM이 크면 아무래도 네트워크 비용도 커질 수 있는데요. 이 점은 디자인 측면과 마크업을 개선할 수 있는지 확인해봐야 합니다.

만약 이미지 스프라이트(사이트에서 활용하는 이미지 모음집) 같은 걸 사용하면 DOM크기에 악영향을 줄 수도 있습니다.

참고로 구글에서 DOM트리는 body요소에 800개 이상이 있으면 경고하고, 1400개 이상이면 오류라고 표시합니다.

측정 대상 사이트에서는 DOM트리같은 성능 이슈보다는 해당 페이지에 다양한 콘텐츠를 보여주는데 집중한 것으로 보입니다.

사실, 한국처럼 네트워크 좋은 국가에서는 DOM크기 성능 이슈가 Error로 나와도 실제 사용성에는 별 영향을 안미칠 수도 있습니다.

(3) 알면 좋은 점

첫 번째, Lighthouse로 측정하면 점수가 시시각각 다를 수 있습니다.

사이트마다 이유는 다르겠지만, 네트워크 측면에서 인터넷 트래픽에 따른 라우팅의 변경이 있을 수도 있습니다.

그리고 성능 측정하는 하드웨어 및 서버 상황에 따라 측정 결과가 다르게 나올 수 있습니다.

A/B테스트 중인 사이트의 경우는 측정시기마다 다를 수도 있고, 3rd party의 script나 3rd party API에 따라 웹 사이트 측정에 영향을 줄 수 있습니다.

심지어는 로컬이나 서버 측정 경우에도 바이러스 백신 SW가 동작함에 따라 성능 측정에 영향을 줄 수 있습니다.

경험상 말씀드리면 성능 점수보다는 측정 항목 및 개선점에 중점을 두는게 좋습니다.

두 번째, 한가지 팁은 측정시 크롬 시크릿모드에서 측정을 권장드립니다.

왜냐하면 일반 크롬 브라우저에서 성능 테스트를 했을 경우에 크롬 브라우저 플러그인 등 확장 기능들이 있으면 성능 측정하는데 지연이 될 수 있습니다.

아마 같은 url이라도 크롬브라우저 일반모드와 시크릿모드에서 성능 측정했을 때 수치들이 다른 것을 확인하실 수 있을 겁니다.

우리나라에서 가장 많이 사용하는 네이버 사이트를 측정했습니다.

아래 보시는것처럼 Device는 모바일로 측정했고, Categories는 Performance로 선택했습니다.

아래가 크롬 브라우저 일반 모드로 측정한 결과입니다.

일반 모드에서 측정결과, 성능 점수는 35점이고, FCP 15.7초, LCP는 40초, TBT는 880ms, SI는 18초가 나온 걸 보실 수 있습니다.

아래는 일반 모드에서 성능 측정한 테스트 환경과 결과로 14개 Audit이 통과했습니다.

시크릿 모드에서 측정결과, 성능 점수는 42점이고, FCP 15.5초, LCP는 38.7초, TBT는 520ms, SI는 21초가 나온 걸 보실 수 있습니다.

아래는 시크릿모드에서 성능 측정한 테스트환경과 결과로 15개 Audit이 통과했습니다.

보시는 것처럼 일반 모드와 시크릿 모드일 때 결과가 다릅니다.

Lighthouse가 측정시기에 따라 여러가지 요인에 따라 결과가 다를 수 있다고 말씀드렸는데요.

이렇게 때문에 일반 모드보다는 시크릿 모드에서 측정하는 방법이 좀 더 정확했습니다.

2) 개발, 운영 개발

개발이나 운영 환경 public망에서 접근이 가능한 경우에는 WebPageTest라는 서비스를 활용했습니다.

구글이 만든 사이트는 google page speed insight고 필자도 여러번 측정한 경험이 있습니다.

그러나 28일 실데이터가 부족할 땐는 실시간 데이터 확인이 어려운 점이 존재했습니다.

개인적으로는 Google Page Speed Inshgts나 Lighthouse보다는 WebPagetest가 Visualization 측면에서도 좋고 다양한 기능이 있는 점이 좋았습니다.

WebPageTest는 다음번에 자세히 소개해드리도록 하겠습니다.

마치는 글

지난 시간에 이어 이번에는 웹 성능 측정 도구에는 어떠한 것들이 있고, 로컬 개발시 Lighthouse를 어떻게 사용하는지, 사용하는데 알면 좋은 점들에 대해 포스팅 했습니다.

다음 시간에는 서비스 배포 이후 사용하면 좋은 성능 측정 도구에 대해 설명해드리도록 하겠습니다.

WebPageTest에 대해서는 좀 더 상세히 설명 드릴 예정이고, GTMetrix와 Pingdom이라는 성능 측정 도구에 대해서도 소개해드리도록 하겠습니다.

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

Reference)

https://developer.chrome.com/ko/docs/lighthouse/performance

https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md