[Vue.js] 프론트엔드 프로젝트 성능 측정 01 - 💡Lighthouse

성능 측정을 진행하며 작성한 기록용 글입니다.
정보 요약은 게시글 하단에서 확인 가능합니다.

 

안녕하세용!

하나의 프로젝트가 끝나면 해야할 것이 있습니다..
바로바로...

성능 측정!

저는 지난 프로젝트에서 프론트엔드를 맡아서 했기 때문에 프론트엔드 성능 측정을 진행해보겠습니다.
지난 프로젝트에 대한 간단한 설명글은

[Django + Vue.js] 1. AI API 기반 도서 추천 및 실시간 모임 서비스 앱 <BOOKLUV> - 프로젝트 명세서 및 주

여기서 확인이 가능합니닷

 

제가 성능 측정은 처음이라서 이것 저것 찾아보았는데요?
프론트엔드에서 성능 측정 방식으로 크게 알려진 "WhiteBox"로 해보려고 합니다.

WhiteBox란
코드 내부의 구조를 살펴보면서 성능을 분석하는 방식으로,
코드 효율성, 알고리즘, 렌더링 과정, 메모리 누수 등을 측정해서 최적화해가는 것인데요.
보통 많이 사용하는 툴들은
구글 크롬 개발자 도구 Lighthouse, Chrome DevTools (Performance Tab), web-vitals 등등이 있는데
이번 글에서는 lighthouse로 진행한 성능 측정 과정에 대해 글을 써보려고 합니다.
(그럼 제가 다음 글엔 web-vitals로 한걸 쓰겠죠? ㅎㅎ)

Lighthouse는 비교하자면 '실험실 점수'라고 저의 gpt가 비유를 해주더라구요.
그래서 프론트 성능 측정 첫 단계로 lighthouse로 진행해서 최적화하며 성능 개선을 진행해보고
그 다음으로 web-vitals로 실사용 데이터를 보려고 합니다.

 

시작 전에 여차저차 설명이 많았는데
이제 진짜 lighthouse로 성능 측정을 해보도록 하죠.

우선 저는 배포한 사이트를 크롬으로 켰습니다.

왜냐하면 배포를 했기 때문에 로컬 빌드 파일 말고 배포 사이트에서 성능 측정 진행했어요 (당연한 말)

- 개발자도구 f12 열어서 lighthouse 선택
- mode: navigation
- device: desktop 으로 해두고 analyze page load 클릭!

하면 이제 lighthouse로 성능 측정이 뚜뚜뚜 돌아갑니다..

요렇게..

 

보통 측정할 때는 여러번 진행한 후 측정값 평균으로 점수를 본다고 하더라구요.
그래서 3번 측정했어요.

1차

 

 

2차

 

3차

 

 

3번 다 값이 똑같은데?

 

1,2,3차 똑같은 75점인것을 보니 평균 안내련다 그냥 1차로 나왔던 값으로 진행해야겠네요 ^^
성능 측정 처음 해봐서 사실 긴장했는데
Performance 75점이라니?
흠흠 조금만 수정하면 되겠다는 생각이 드네요ㅎ 뭘 수정해야할지 아직 모르겟지만? 

lighthouse에서 중점적으로 봐야할 것은

* Performance 점수
* LCP / CLS / INP (또는 TBT)
* Diagnostics에서 “크게 지적되는 항목 3개”

이렇게 3가지

이제 성능 측정을 해보았으니 개선하려 가야합니다.
개발환경으로 ㄱㄱ

 

로컬에서 다음과 같이 진행합니다.

frontend 폴더로 이동 후 npm 설치 진행!

 

rollup-plugin-visualizer 설치해서
번들 사이즈를 줄이는것부터 시작함
(전체 점수가 높지 않기 때문에 번들 사이즈부터 줄여나가는 것을 추천한다고..)


그리고 vite.config.js 파일에 이렇게 추가해줍니다.

이렇게 하고 npm run build!
그러면 dist/stats.html이 브라우저에 자동으로 열리고

 

두둥..
이렇게 나옵니도!

여기서

- “큰 덩어리 top 5” (네모 젤 큰거 5개)
- 라우트/페이지가 분리(코드 스플리팅) 되어 있는지
- 같은 라이브러리가 중복으로 들어가는지

확인해보는데


우선 젤 많이 잡아먹는 5개를 살펴보니까
유독 swiper, router 이녀석들이 눈에 띄어보이네요
왜냐하면 개발할때 전~혀 신경안쓰고 기본 구조 만들고 메인 페이지에 슬라이더 띄울 때 만든 페이지라서
문제가 될거라고 생각을 전혀 못했기 때문이죠..

오른쪽 저게 뭐여

 

위에서 오른쪽 사진을 보면 
src/views/...로 시작하는 파일들이 엄청나게 찍혀있고,
components/...로 되어있는 파일들도 막 찍혀있네요.

저게 router에서 저만큼 import 불러오는걸 보여주는데 저게 왜 문제냐??

제가 코드를 쓸 때 lazy import문으로 안써서 지금
모든 views가 초기 bundle(assets/index-어쩌구저쩌구.js) 안에 들어있는 상황입니다..!

즉, 지금 최적화 1순위는:

라우터를 lazy import로 바꿔서 “초기 번들에서 views를 빼는 것”

입니다요...

그래서 수정합니다

component: () => import("@/~~"),
이런 식으로 전부 수정 진행...


그리고 다시 빌드해서 개선되었는지 다시 확인해보면...!

오호라?

이렇게 나오는데
왼쪽에 알록달록한 assets/~~ 파일들이 더 늘어난것을 보니 줄긴 줄었습니다. 
(이 때 성능 측정 했는데 몇점인지 기억 안나는 것을 보니 점수에는 개선이 없었나봅니다 ㅋ)

근데 지금 또 보이는 큰 문제점이 있습니다..
swiper 저녀석 여전히 너무 크네요...! (당연함 아직 개선 안했음)
swiper는 제가 메인 페이지에서 슬라이더를 구현하기 위해서 사용했던 아이인데요..

HomeView.vue에서 저 친구도 lazy하게 수정해주었습니다..
근데 이렇게 해도 점수와 시간이 확 줄진 않았어요 후후... (그래서 lighthouse 캡처 안햇어요)


사실 슬라이더 저건 정말 생각지도 못했던 부분이라 
gpt와 의논 + 구글링해가며 방법들을 막 찾아보았습니다..
그래서 일단 메인 슬라이더 이미지 확장자들을 png에서 webp로 바꿔주었습니다
몰랐는데 webp로 바꿔주는게 크기 덜 잡아먹는거엿네요..

png를 webp로 확장자 수정해주었고 
swiper도 lazy하게 불러와야해서
첫 슬라이드 이미지를 제외한 나머지 슬라이드들은 lazy하게 불러오는 코드들로 수정해주었습니다!

이제 다시 빌드해서 확인해보겟습니다..

Performance 3점 오름 어 그래

근데 지금 콘솔에서 확인하면
여전히 슬라이더 이미지 4개가 한꺼번에 실려와서
js에서 슬라이더 이동할때마다 다음 슬라이더 이미지를 화면에 가져오도록 코드 수정을 해주었어요..

그리고...

슬라이더 이미지가 계속 4개가 메인에 한꺼번에 불러지는 것을 해결하기 위해
여러번 코드들을 뒤엎으며 수정했는데요..

이러쿵저러쿵해서 결론적으로 수정한 방안은 
1) 첫번째 메인 페이지에서 첫 슬라이더 이미지를 최상위 index.html에 링크로 먼저 박아두고

2) 슬라이더 컴포넌트 코드에는 public/slide1.webp을 따로 저장한 첫 슬라이더 이미지를 가져와서 
불러오는 방향으로 갔습니다..
(중간에 수정하면서 css 날려먹어서
울면서(눈물 인증 불가) 깃허브 뒤져서 긁어옴)

수많은 빌드 dist 파일 끝에 결국...

performance 점수가 갑자기 98로 나왓습니다..!!!!

LCP가 1.0s로 4에서 1로 확 줄었답니다
감동적이네요...



근데 제가 지금까지 측정을 일반 크롬탭에서 했거든요?
원래 시크릿창에서 해야하는데 시크릿창은 카카오 로그인한 상태에서 안되길래 안했는데
혹시나 싶어 시크릿탭에서도 한번 해봣더니...

99 뭐임?

 

아 진작에 시크릿탭으로 할걸 ;;

Best Practices도 96 나와서 이제 SEO를 올려봐야겟어요...

지금 SEO는 robot.txt가 없어서 에러가 여러개 뜨는 상황이었는데 
robots.txt가 뭔지? 왜 필요한지 모르겠더라구요?
그래서 찾아보니

"웹사이트에 웹 크롤러 같은 로봇들의 접근을 제어하기 위한 규약" 이라고 하네요..
권고 사항이고 필수/의무 까진 아니지만 있으면 좋으니 public/robots.txt로 추가해보도록 하겠습니다..

User-agent: *
Allow: /

Sitemap: https://배포주소/sitemap.xml

 

그리고 sitemap.xml도 있으면 점수가 더 오를까 싶어서 추가해봅니다

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url><loc>https://배포주소/</loc></url>
  <url><loc>https://배포주소/kluvtalk</loc></url>
  <url><loc>https://배포주소/board</loc></url>
  <url><loc>https://배포주소/ai</loc></url>
  <url><loc>https://배포주소/login</loc></url>
  <url><loc>https://배포주소/signup</loc></url>
  <url><loc>https://배포주소/mypage</loc></url>
</urlset>

그리고 index.html에 head 태그 안에도 조금 추가해주었는데요?

드래그 한 부분을 넣어주면 조금 더 안정적으로 인식할 수 있다고 해서 넣었어요.
사실 빠르게 코드 써내려가다보니
title이나 기본 description 설정하는 부분들은
엄청 기본적인건데 놓치고 갔다는게 약간 아쉬운 부분이었네용..

이제 다시 빌드하고 배포해서 성능 측정을 다시 해보겠습니다..

 

 

 

 "헐"

 

 

해냈습니다 ㅎ


저것만 저렇게 개선했는데 확 개선된다는 것이 너무 신기했구요..


근데 지금은 메인페이지만 성능 측정 후 개선한거라 다른 주요 페이지들도 측정해볼 필요가 있어요..
이 프로젝트는 모임 생성 -> 실시간 모임 채팅 기능으로 이어지는 프로젝트였기 때문에
/kluvtalk (모임 페이지 메인), /alarm (모임 진행 직전, 진행 중 알려주는 알람 페이지),
/kluvtalk/chat/ (실시간 채팅 페이지)
이렇게 3개를 더 측정해보았습니다!

근데 카카오 api 로그인 구현을 하면서 시크릿 창 안에서는 무슨 일인지 카카오 로그인이 안되어서...
로그인 후 진행하는 페이지인 채팅은 일반 창에서 하고 나머지는 시크릿에서 측정해보니
Best Practices만 73점이고 전반적으로 점수가 높게 유지가 되고 있었습니다!
Best Practices만 73인 이유는 csrf 설정 때문에 그런거였는데,
여기는 건들 수 없는 구역이라 (이미 플젝 끝났고 로그인을 다시 손댈 시간이 없..어요 ㅠㅠ)
시크릿 탭에서는 다 90 이상으로 점수 짱짱하게 나오는 것으로 만족^^합니다^^

 

아무튼 그래서 이렇게 lighthouse로 측정을 대략 해보면서 성능 개선을 해보았는데요? 
측정을 하면서 글을 같이 작성하다보니 조금 길어졌네요
요약하자면

💡Lighthouse 성능 측정 결과

요렇게 lighthouse로 성능 최적화를 해보았다.. 입니다! 


간단한 후기는
성능 개선을 처음 해보았는데 정말 생각지도 못하는 부분에서 개선을 진행해줘야 하는 것이 신기했습니다..
왜냐하면 이 프로젝트는 개발 기간이 일주일밖에 없어서 사실 컴포넌트를 나누는 것부터
코드들이 대체적으로 하드코딩식이라
손댈 게 정말 많겠군.. 싶어서 성능 최적화하는걸 미루고 있었거든요 ㅎ
근데 메인 페이지에서 슬라이더와 lazy import 요 두개가 개선해야 할 부분이었다는게 놀라웟습니다..
앞으로는 개발을 하면서 중간마다 lighthouse로 측정해보면 좋을 것 같다는 생각이 들었습니다.
불필요하게 불러진 css들도 확인할 겸.. 이미지 크기 등등 로딩 확인도 해야하는 것이 프론트의 당연한 일이니까용...

처음이라 당연히 헤매면서 했는데
개선된 결과를 가져가니 과정이 재밌었고 뿌듯하네욤
근데 아직

성능 측정 다 안끝남요

 

이젠 2단계로 넘어가야 함돠
1단계 lighthouse는 실험실로 테스트해본거라면
제가 다음으로 진행할 2단계 web-vitals는 실제 사용자 데이터를 체크해봐야 합니다!

 

일단 lighthouse 측정은 여기서 마치도록 하고 
다음 글에서는 web-vitals로 측정 후 개선해보는 내용을 써보겠습니다.

여기까지 긴 글 읽어주셔서 감사합니다.
궁금한 점은 댓글로 물어봐주시면 아는 선에서 답변해보도록 하겠습니다.
그럼 이만 저는 다음 글에서 뵙겠습니다! 🫡