[우아한테크코스] 모락팀의 성능 최적화, 왜 해야해?

안녕하세요, 모락 프론트엔드팀의 위니입니다.
프로젝트 4차 요구사항에는 '성능 리포트를 공유한다.'라는 문항이 있었습니다.

성능 리포트...? 그게 뭔데... 그거 꼭 해야해? 🤔

솔직하게 말하면 성능 리포트를 공유하라는 요구사항을 보고 가장 먼저 든 생각은 '이게 뭐지? 이거 꼭 해야해?' 였습니다.
그런데, 결론적으로 성능 리포트를 작성하고 공부하는 과정에서 성능 최적화 작업은 프론트엔드 개발자가 반드시 고려해야하는 사항 이라는 것을 배울 수 있었습니다.
모락의 프론트엔드팀에서는 다음 순서로 성능 리포트를 작성했습니다.

0. 왜 성능 측정을 하는가?
1. 성능 관리 대상 설정
2. 성능 예산 세우기
3. 측정하고 개선 포인트 찾기

위에 작성한 순서대로 작성한 모락팀의 성능 리포트를 공유해보고자 합니다.

0. 왜 성능 측정을 하는가?

성능을 측정하기에 앞서, 왜 성능 측정을 해야하는지에 대해 생각해봤습니다. '성능 측정'이라는 개념 자체가 낯설었기 때문에, 우리 프로젝트에 무작정 성능 측정을 하기 전에, 도대체 왜 성능 측정을 해야하는지 생각하는 과정이 필요했습니다.

성능 최적화를 해야하는 이유는?

웹이 복잡해지면서, 다양한 기능 및 잦은 서버 통신으로 인해 로딩 기간이 길어지게 되었어요.
로딩 시간이 너무 길어지게되면 사용자는 이탈하게되고, 서비스 매출이 떨어지게됩니다.
이때, 개발자가 할 수 있는 가장 좋은 방법이 성능 최적화입니다! 🥳
성능 최적화로 엄청난 결과를 낸 핀터레스트의 사례를 볼까요?

pinterest는 서비스 이용 고객 중 단 1%만 가입을 했을 만큼, 굉장히 느린 속도로 사용자들을 답답하게 했습니다. 성능 개선 전 핀터레스트 웹 로딩 시간은 23초였다고 해요. 듣기만해도 답답하지 않나요 😓
이를 인지한 핀터레스트는 3개월동안 로딩 성능 최적화 작업을 진행했고, 결과적으로 위와같은 사업 지표 개선을 이뤄낼 수 있었습니다. (5분 이상 사용자가 40%가 늘었고, 이로 인한 광고수익이 44%가 늘어났다고 하니 엄청난 결과죠?)

이처럼, 성능 최적화를 통해 사용성을 높힐 수 있고, 이는 자연스럽게 사업 지표의 개선으로 나타납니다.
프론트엔드 개발자에게 성능 최적화 작업은 굉장히 중요한 작업임을 알 수 있어요~

'모락 서비스에서' 성능 최적화를 해야하는 이유는?

그렇다면, 우리 모락 프로젝트에서 성능 최적화를 해야하는 이유는 무엇일까요?
어차피 우리 서비스는 돈 버는 서비스도 아니고, 사업 지표 개선도 필요없는데...🤑 성능 최적화 작업을 꼭 해야할까요?
우리는 좋은 서비스를 만들기 위해서 모였습니다. 물론 이 프로젝트를 통해서 성능 최적화를 해서 사용성을 높히고 돈을 더 많이 벌 수 있는 것은 아니지만, 사용성을 고려하는 것은 프론트엔드 개발자에게 반드시 필요한 자질입니다.
그렇기 때문에, 작은 서비스를 만들고 있지만 사용성을 고려하는 것은 필수적이라는 것이죠.

왜 성능 최적화가 필요한지는 충분히 납득이 됐습니다. 그럼 왜 '우리 서비스에서' 성능 개선을 해야할까요?

정리하자면, 성능 최적화는 우리 서비스의 목표를 이루기 위해 필수적입니다.
우리의 서비스의 목표는, 모임에서 불편한 것들을 서비스 사용자들이 ‘빠르게’ 할 수 있도록 도와준다. 입니다. 즉, 빠른 속도가 서비스를 사용하는 사용자들에게 매우 매우 중요한 요소라는 것이죠! ⚡️
그래서 우리 서비스는 속도를 높히는 성능 최적화를 중심으로, 작업을 진행하기로 했어요.

1. 성능 관리 대상 설정하기

성능 개선을 하기 전에, 성능 관리 대상을 설정해야겠죠?
저희는 최소한 주요 서비스 로직에서만큼은 최소한의 성능이 보장되어야한다고 생각했습니다.
성능 관리 대상과 성능 측정 환경은 다음과 같습니다.

성능 관리 대상

아래 성능 관리 대상은 주요 서비스 로직입니다.
빠르게 주요 서비스 로직을 사용할 수 있게 성능 최적화를 진행함으로써, 사용성을 높히려고 합니다.

• 로그인
• 그룹 생성 및 참가
• 투표하기
• 약속잡기

성능 측정 환경

성능 측정 환경은 '서비스 특성상 어떤 환경의 사용자 경험이 더 중요한지?'를 고려했습니다.
현재 모락 서비스는 데스크탑을 기준으로 개발되었기 때문에, 데스크탑을 기준으로 성능을 측정합니다. (추후 모바일 버전을 추가할 시, 모바일도 함께 측정 할 예정입니다.)
추가로, 성능 측정 환경은 항상 동일해야합니다. 환경에 따라 같은 페이지를 측정하더라도 다른 결과가 나타날 수 있기 때문입니다.
이에따라 정리한 성능 측정 환경은 다음과 같습니다.

• 크롬 시크릿 모드 (확장 프로그램 비활성화 확인)
• 데스크탑 기준
• 맥북 (위니)
• 네트워크
  • woowanet.join (항상 동일한 네트워크)

2. 성능 측정 지표

성능 관리 대상을 정했으니, 이제 성능을 측정할 지표를 정해야합니다.
성능 측정 지표란, '어떤 것을 측정할 것인지?' 에 대한 지표입니다. 크게 4가지 (정량 기반 지표, 시간 기반 지표, 렌더링 지표, 규칙 기반 지표)가 있는데요 우리 프로젝트는 앞서 이야기했던 것 처럼 속도가 매우 중요한 서비스이기 때문에 시간 기반 지표를 선택했습니다.
시간 기반 지표란, 브라우저상에서 성능에 관련된 이벤트들이 일어나기까지의 시간들을 측정해, 사용자 입장에서 체감되는 성능 수치의 한곗값을 설정하는 것입니다.
시간 기반 지표에는 여러개가 있지만, 우리 프로젝트에서는 아래의 네가지 (FCP, LCP, TTI, TBT)를 측정하고자 합니다.

FCP (First Contentful Paint)

최초 콘텐츠풀 페인트(FCP) 메트릭은 페이지가 로드되기 시작한 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링될 때까지의 시간을 측정합니다.

왜 첫 콘텐츠가 보여지는 시간을 측정을 해야하고, 이를 높히는 것이 좋을까요?
사용자가 빠르게 첫 컨텐츠를 보는 시간을 최대한 줄여야, 사용자가 이탈할 확률이 적습니다.
모락은 속도가 중요한 서비스이기 때문에, 조금이라도 첫 컨텐츠 로드가 늦어버리면 싫증을 느끼고 이탈할 확률이 큽니다. 따라서 FCP를 줄이는 작업은 유의미합니다.

LCP (Largest Contentful Paint)

페이지가 처음으로 로드를 시작한 시점을 기준으로 뷰포트 내에 있는 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간을 보고합니다.

즉, 페이지가 얼마나 빠르게 로딩되는가? 입니다.

주요 콘텐츠는 왜 빠르게 보여야할까요?

• 주요 콘텐츠가 뭔지 모르는 사용자가 들어왔을 때, 빠르게 주요 기능을 파악할 수 있도록 해야하고,
• 주요 컨텐츠가 빠르게 보이면, 그만큼 사용자가 빠르게 우리의 서비스를 사용할 수 있는 것이기 때문에, 사용자 경험이 좋아질 것입니다.

TTI (Time to Interactive)

완전히 상호 작용 가능하게 되는 데 걸리는 시간, 즉
‘완전히 인터랙션이 가능한 화면이 나오는데 걸리는 시간’

우리 서비스는 사용자들과의 상호작용이 많습니다.

- 투표 생성 form
- 약속잡기 생성 form
- 투표 진행
- 약속잡기 진행
- 그룹 생성 참가등등

그렇기 때문에, 최대한 빠르게 해당 상호작용들이 가능하도록 만드는 게 중요합니다. 화면은 다 나왔는데, 상호작용이 안된다면, 사용성이 너무 떨어져서 재방문 하지 않겠죠 🥲 따라서, TTI를 측정하는 것은 유의미합니다.

FID (First Input Delay) 를 TBT(Total Blocking Time)을 통해 측정

FID는 사용자가 페이지와 처음 상호 작용할 때(예: 링크를 클릭하거나 버튼을 탭하거나 사용자 지정 JavaScript 기반 컨트롤을 사용할 때)부터 해당 상호 작용에 대한 응답으로 브라우저가 실제로 이벤트 핸들러 처리를 시작하기까지의 시간을 측정합니다
즉, “인터랙션을 했을 때, 얼마나 빠르게 응답이 오는가?”
모락 서비스는 사용자와의 상호작용이 많은 만큼, 인터랙션을 했을 때 얼마나 빠르게 응답이 오는지도 매우 중요합니다.
따라서, 인터랙션을 했을 때 얼마나 빠르게 응답이 오는지 측정하는 FID를 선택했으나, FID는 실제 사용자가 필요한 측정이기 때문에 FID의 성능과 비례하는 TBT를 선택했습니다. TBT를 측정하면, FID의 성능을 어느정도 유추할 수 있습니다.

정리

위 지표에 따라 정리한 모락 서비스의 성능 최적화 목표는 아래와 같습니다. 더 구체적인 수치상 목표는 이후 업데이트 예정입니다.

- TTI, FCP 사이의 간극을 줄여준다.
- FCP와 LCP 사이의 간극을 줄여준다. 최대한 FCP를 앞당겨서 사용자들이 로딩이 되고 있다는 것을 인지시키고 (이탈률 하락), FCP와 LCP의 간격을 최대한 줄임으로써, 사용자들이 최대한 빠르게 우리의 서비스를 이용하게 하는 것을 목표로 하면 좋을 것 같다.

3. 성능 측정 도구 (lightHouse)

LightHouse는, 크롬에서 제공하는 성능 측정 도구입니다. 또한, 우리가 원하는 측정인 시간 기반 지표들을 이 lighthouse를 통해 쉽게 측정할 수 있어요.
이 lightHouse는 개발자 도구에 내장되어있기 때문에, 매우 쉽고 빠르게 성능을 측정할 수 있답니다.
성능 측정이 편해야 자주 측정을 할 수 있고, 자주 측정을 하면서 계속해서 성능을 개선할 수 있을 것입니다. 그래서, 빠르고 편리하게 성능을 측정할 수 있는 도구인 ‘lightHouse’를 사용하기로 결정했습니다 (땅땅👩🏻‍⚖️)

마무리

지금까지 정리한 모락 프론트엔드의 성능 리포트입니다. 실제 성능을 측정하고 개선하는 과정에서 더 좋은 방향으로 수정될 수 있고, 만약 수정 사항이 있으면 블로그에도 업데이트 하도록 하겠습니다.
앞으로 프로젝트를 진행하며, 성능 리포트에 따라 주기적으로 성능 측정을 해서, 성능 개선을 할 예정입니다.
성능 개선 일지를 블로그에 포스팅 할 예정이니, 모락의 성능 최적화를 응원해주세요 😄

---

참고 자료

• https://web.dev/
• https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk?hl=ko
• https://www.youtube.com/watch?v=cpE1dwJgS4c