FE 레벨4 성능 리포트 | 2023.09.07

[woowapark]

• 성능 리포트 작성 가이드에 따라 현재 우리 서비스의 성능을 측정하고 분석합니다. 작성한 성능 리포트는 코멘트에 첨부해 주세요.
• 다른 팀의 성능 리포트를 보고 서로 피드백 해주어도 좋습니다.

[2yunseong]

Stamp Crush

우리 서비스에서 지속적으로 성능을 관리해야 하는 핵심 영역

• 고객모드의 쿠폰 목록 페이지
  • 사장모드보다 사용자 수가 많고, 다수의 인터랙션과 정보가 존재하는 페이지이기 때문입니다.

성능 테스트 환경 (profile)

클라이언트

• 모바일
• Fast 3G
• CPU throttling : 6x slowdown

측정 대상으로 선정한 성능 지표와 성능 예산

성능지표

• 렌더링 지표
• 시간 기반 지표
• 규칙 기반 지표

성능예산

• LCP 3초 이내
• LightHouse 85점 이상
• Layout Shift 없이 애니메이션이 일어나야 한다.

측정한 현재 지표와 성능 개선이 필요한 지점

Lighthouse Performance Report

## ### 번들링 사이즈
bundle.js 882KB

성능 개선이 필요한 지점

• bundle.js 크기
• lighthouse 점수 개선
  • LCP 속도 개선

많은 피드백 부탁드립니다 🥹🥹

[WaiNaat]

피움🌱

서비스의 핵심 영역

• 리마인더, 타임라인
  • 피움의 핵심인 ‘기록’을 담당하는 두 부분이라 핵심이라 판단했어요.
• 메인, 반려 식물 목록, 반려 식물 상세
  • 사용자들이 자주 방문할 것이라는 예상이 들어서 중요하다고 생각했어요.
• 식물 후기 모아보기
  • 현재 구현 중인 기능이에요
  • 타인의 기록을 참고하고 어느 정도의 소통을 제공한다는 점에서 중요하다고 생각했어요

성능 지표와 예산

• Lighthouse
  • FCP 1.8초 미만
  • LCP 2.5초 미만
  • TBT 200밀리초 미만
  • Speed Index 3.4초 미만
  • 수치는 chrome developers의 lighthouse 문서에서 green(fast) 등급 기준을 참고했어요.
• 리마인더와 타임라인에서 이미 렌더링 되어있는 요소들은 리렌더링 최소화

현재 상황

	FCP	LCP	TBT	Speed Index
리마인더	1.6	5.3	80	1.6
타임라인	1.5	10.4	210	1.5
메인	9.4	9.8	0	9.4
반려 식물 목록	1.7	5.6	170	1.8
반려 식물 상세	1.5	5.3	220	1.6
식물 후기	-	-	-	-

(참새 컴퓨터의 brave 브라우저에서 lighthouse로 측정했습니다)

성능 개선 계획

• bundle.js 크기 줄이기 (현재 455kB)
• 구글 웹 폰트 용량 줄이기 (현재 약 1MB)
• 이미지 최적화 (현재 작은 사진이 필요한 곳에서도 원본을 받아옴)
• SVG-in-JS 방식으로 된 아이콘 개선
• 리마인더와 타임라인 렌더링 개선

Lighthouse로 여러 페이지를 분석해 본 결과 공통적으로 나타나는 문제점들이 있어서 이 부분을 개선하면 전반적인 성능 개선이 가능할 것으로 기대됩니다.

cc. @bassyu @hozzijeong

[NaveOWO]

🐘 코끼리끼리 🐘

---

서비스의 핵심영역

• 🐘 로드맵 리스트 : 사용자들이 관심있는 분야의 로드맵을 보여줄 수 있어요.
• 🐘 골룸 리스트 : 사용자들이 참여할 로드랩들에 대한 골룸을 보여줄 수 있어요.
• 🐘 대시보드 : 사용자들이 골룸에 참여하면서 공동의 목표를 이루는 공간이에요.

---

측정 대상으로 선정한 성능 지표와 성능 예산

<측정대상>

• 🐘 fast3G
• 🐘 no CPU throttling
• 🐘 no cache

<성능지표 & 성능에산> ( 메인페이지 )

• 🚨 FCP (현재 : 0.72s, 목표 : 1,000ms 미만)
• 🚨 LCP (현재 : 0.72s, 목표 : 1,000ms 미만)
• 🚨 TBT (현재 : 0ms, 목표 : 200ms)
• 🚨 CLS (현재 : 0.002, 묙표 : 0.1미만)

---

성능개선이 필요한 지점

• 🚨 대시보드 페이지 : 이미지를 적정 ratio를 맞춰서 스타일링 & 이미지 포맷 변환 필요. (현재 LCP 2.1s -> 2s 미만으로 개선 필요)
• 🚨 대시보드 페이지 : static assets의 cache정책이 존재하지 않음.
• 🚨 모든 페이지 : 모든 이미지에 width & height값 지정 필요.
• 🚨 index.html : meta 스크립트 작성 필요. ( seo )

[inyeong-kang]

보투게더 팀의 성능 리포트 및 개선 계획

번들 사이즈

현재 bundle.js : 791.kB

LightHouse

모바일 (비회원)

현재 [votogether.com](http://votogether.com) 에 대한 Lighthouse report 결과, Performance: 76, Accessibility: 78, SEO: 85 이며 FCP는 1.0s, LCP는 5.8s 이다.

모바일 (회원)

데스크탑 (비회원)

데스크탑(회원)

<img width="887" alt="desktop_회원" src="https://github.com/woowacourse/retrospective/assets/81199414/a14091b8-61f8-4e34-b7fc-2622f7d94c87"

WebpageTest 에서 파리에서 fast 3g

Performance 탭

동작: 홈에서 필터링을 전체로 설정 후 스크롤을 내렸음

회원

비회원

성능 개선 계획

번들 사이즈 용량 줄이기

bundle.js 줄이기 위해, webpack을 이용한 code splitting 등을 사용해볼 예정이다.

또 사용되지 않는 코드는 tree shaking 등으로 제거해볼 예정이다.

tanstack-query의 캐시 활용하기 & 불필요한 API 요청 줄이기

tanstack-query의 useQuery에서 cacheTime를 활용해본다.

기능별 API 를 요청할 때 cacheTime을 다르게 해보고, Network 탭에서 API 요청 횟수를 확인해본다.

LCP (Largest Contentful Paint)

LCP 저하의 원인인 느린 서버 응답 시간, js 및 css의 렌더 블로킹, 느린 리소스 로딩 시간, CSR 등에 대해 조사해본다.

필요한 최소한의 JavaScript를 다운로드하여 사용자에게 제공하도록 한다.

차단하는 JavaScript의 양을 줄이면 렌더링 속도가 빨라지게 하여 LCP가 향상시킨다.

이미지 최적화

게시글 저장 시, 서버에 이미지를 전송할 때 이미지를 압축하여 보낸다.

이미지 포맷 변경 등 이미지 파일 크기를 최적화한다.

구체적인 달성 목표

• 모바일 기준으로 메인 홈(게시글 목록 조회)페이지를 Lighthouse로 검사했을 때, Performance가 90점 이상 나오도록 한다.
• Fast 3g 환경, 파리에서 접속했을 때 LCP 를 5.5s 이하가 되도록 한다.
• 번들 사이즈를 600kb 으로 줄인다.

[HyeryongChoi]

🐕 집사의 고민🚶‍♀️

서비스 핵심 영역

• 식품 리스트 페이지(Home)
  • 식품 리스트 페이지는 사용자가 우리 서비스에 접속할 때 가장 먼저 보게되는 페이지로 우리 서비스의 현관문 역할을 하는 중요한 페이지입니다.
  • 페이지가 느리게 로딩된다면 사용자는 서비스에 아무것도 없는 것처럼 느낄 수 있으며 사용자의 페이지 이탈 가능성이 높아집니다.
  • 식품 상세 페이지에서 사용되는 식품 이미지는 식품 리스트의 썸네일과 동일한 이미지입니다. 이는 식품 리스트 페이지를 통해 캐싱되므로 식품 리스트의 빠른 로딩이 중요합니다.

성능 지표와 예산

• Lighthouse(green(fast) 등급 기준 참고)
  • Performance ≥ 95
  • FCP < 1.8s
  • LCP < 2.5s
  • TBT < 0.2s
  • Speed Index < 3.4s

성능 테스트 환경

• 모바일 디바이스
• Fast 3G
• CPU throttling: 6x slowdown
• 첵스 PC, 크롬 시크릿모드

현재 상황

• js 번들 사이즈: 463kb
• Performance: 74점
• LCP: 10.3s

성능 개선 계획

• 소스코드 크기 줄이기
  • tree shaking
  • 코드 분할
  • js, css 코드 경량화
• static assets의 캐시 정책 설정
  • 브라우저 캐시 max-age 1년
• 이미지 최적화
  • static > webp, 퀄리티 조정
• 이미지 width & height 값 지정
• 폰트 최적화

[jeongwusi]

요즘카페팀 성능 리포트

자세한 내용은 링크를 통해 확인하실 수 있습니다. 🙇🏻

[Creative-Lee]

S-HOOK 팀의 성능 개선 리포트

우리 서비스에서 지속적으로 성능을 관리해야 하는 핵심 영역

Youtube 플레이어가 여러개 존재하는 듣기 페이지

측정 대상으로 선정한 성능 지표와 성능 예산

성능 지표: 라이트 하우스(규칙 기반 지표)

성능 개선 계획

Youtube 모듈 로드 관련 계획

목표 지표

라이트 하우스 기준 Total blocking Time 지표 600ms 이하 (moderate 등급 이상으로 개선)

CLS 개선

이미지와 아이콘에 정적인 size를 부여해서 Layout이 변경되는 것을 막는다.

[turtle601]

셀럽잇

자세한 내용은 링크를 통해 확인하실 수 있습니다. 👍

[dladncks1217]

행록

우리 서비스에서 지속적으로 성능을 관리해야 하는 핵심 영역

여행을 관리하는 페이지

측정 대상으로 선정한 성능 지표와 성능 예산

성능 지표: 라이트 하우스(규칙 기반 지표)

개선 계획

성능 테스트 환경
Fast 3G
CPU throttling: 6x slowdown
⬇️
Performance ≥ 95

✅ FCP (현재 : 0.6s, 목표 : 1,000ms 미만)
✅ LCP (현재 : 8.5s, 목표 : 2,000ms 미만)
✅ TBT (현재 : 210ms, 목표 : 200ms)
✅ CLS (현재 : 0, 묙표 : 0)

1. 소스코드 줄이기

• 코드 스플리팅
• 중복코드 제거
• tree shaking

2. 이미지 로드 속도 개선

• 이미지 리소스 응답 시 Cache-Control 헤더 추가
• 이미지 용량 최적화

3. 번들파일 로드 속도 개선

• CDN 사용(cloudfront), 캐시 정책은 cloudfront, s3메타데이터 모두 지정.
• 번들파일 압축 (Nginx 사용 유지 시 Nginx gzip압축 설정, s3 + cloudfront + acm 사용 시 cloudfront 정책 사용)

[GC-Park]

괜찮을지도 성능 리포트

현재 상황

성능 관리 대상 설정하기

• 괜찮을지도팀의 성능 관리 대상은 메인 페이지와 지도 조회 페이지입니다.
  • 메인 페이지와 지도 조회 페이지는 저희 서비스의 컨텐츠를 소비하러 오는 사용자들이 가장 오래 상주해있는 페이지로서 성능 관리가 필수입니다.
  • 페이지 로딩 시간이 2.7초가 넘어가면 사용자 이탈률이 눈에 띄게 급증하는 현상이 나타난다고 합니다. 따라서 메인 페이지에 나타나는 콘텐츠들과 지도의 빠른 로딩이 중요합니다.

성능 측정 환경

모바일과 데스크탑을 모두 대상으로 합니다. 대신, 데스크탑 환경 퍼스트이기 때문에 데스크탑 성능을 우선시 하겠습니다.

• 데스크탑 : 아이크 PC, woowanet.join 네트워크
• 휴대폰 : 아이크 PC 데스크탑 모바일 환경 전환, woowanet.join 네트워크
• 네트워크 환경이 좋지 않을 때 : CPU throttling: 6x slowdown, Fast 3G, [woowajoin.net](http://woowajoin.net)

성능 측정 지표 및 예산

괜찮을지도에서는 아래와 같이 성능 측정 지표 및 예산을 설정하였습니다.

정량 기반 지표 (Quantity-based Metrics)

• 자바스크립트 리소스 크기 합계:
  • 메인 페이지에서 불러오는 번들 사이즈가 400KB 이하여야 합니다. → 현재 번들 사이즈의 20%를 개선한 지표입니다.
  • 지도 로딩을 사용자 인지 소요시간(50ms)에 로딩 하도록 한다.

시간 기반 지표 (Timing-based Metrics)

• TTI (Time to Interactive):
  • 3G Fast로 접속하였을 때 TTI가 2.7초 이하여야 합니다.

렌더링 지표 (Rendering Metrics)

• LCP (Largest Contentful Paint):

  • LCP는 페이지에서 핵심 요소의 콘텐츠 로딩 속도를 측정합니다.

    일반적으로 페이지에서 가장 큰 영역으로 해당 영역에 있는 이미지, 영상, 텍스트 부분 등 요소의 렌더링 성능을 기반으로 측정 됩니다.

    웹 페이지에서 가장 의미 있고 사용자가 접하는 가장 중요한 첫 요소이기 때문에 해당 영역이 늦게 나타나면 페이지 이탈률이 자연스레 늘어날 수 밖에 없기 때문에 중요합니다

  • 성능 예산: LCP는 2.7초 이내로 유지되어야 합니다.

• CLS (Cumulative Layout Shift):

  • CLS는 페이지 방문자의 시각적인 안정성을 측정합니다.

    CLS는 사용자에게 웹 페이지가 표시되고 최종적으로 변화되는 정도를 측정한 수치입니다.

  • 성능 예산: CLS는 0.1 이하여야 합니다.

  • partially rendering 최소화

규칙 기반 지표 (Rule-based Metrics)

• Lighthouse (CI):
  • 모든 페이지의 Lighthouse 성능 점수는 95점 이상이어야 합니다.

성능 측정 도구

Lighthouse (CI)

괜찮을지도는 **Lighthouse**를 활용하여 성능을 측정합니다. Lighthouse 를 사용하면 개발자 도구 탭을 통해 쉽게 사용 가능합니다.

추가적으로 명확한 성능 개선 방법을 제안하는 부분을 이용해 개선할 수 있습니다.

WebPageTest

**WebPageTest**는 리소스를 불러오는 순서나 시간에 따른 화면 상태를 자세히 볼 수 있어 유용한 도구입니다. **WebPageTest**를 활용하여 사이트의 병목을 발견하고 개선하려고 합니다.

• Paris EC2 Fast 3G

Chrome Devtools

**Chrome Devtools**에는 Network Throttling, CPU Throttling 기능을 제공합니다. 이를 통해 열악한 환경을 시뮬레이션하고 테스트할 수 있습니다.

[gyeongza]

바톤팀 성능 리포트

1. 우리 서비스에서 지속적으로 성능을 관리해야 하는 핵심 영역

• 리뷰 게시글 목록 조회 및 검색 기능.
• 리뷰이가 올린 리뷰 요청글을 통해 소통하는 사이트이기 때문에 게시글 성능이 서비스의 중요한 역할을 합니다.

2. 측정 대상으로 선정한 성능 지표와 성능 예산

• 측정 환경 - PageSpeed

• 메인 페이지 성능 점수 95점 이상
• LCP 점수 800ms 미만
• 사용하는 폰트 스타일만 import
• 메인 페이지의 Layout Shift 제거 (헤더, 게시글 상세조회 시 코드 보러가기 버튼 아이콘)

3. 측정한 현재 지표와 성능 개선이 필요한 지점

• 모바일 → 반응형 디자인 적용(데스크탑을 대상 서비스이지만 모바일에서 확인 가능하도록 변경)
• LCP 최적화 → 폰트 사이즈 압축

• 코드 스플리팅 적용
• 깃허브 프로필 이미지를 받아올 때 사용하는 사이즈로 변경

[nlom0218]

📖 하루 스터디 성능 리포트

자세한 내용은 아래 링크에서 확인할 수 있습니다 😁
하루 스터디 성능 리포트

[xodms0309]

🥄 펀잇 성능 리포트

🚀 1단계 - 성능 관리 대상 설정하기

우리 서비스에서 지속적으로 성능을 관리해야 하는 대상 설정하기

• 기능적으로 가장 핵심이 되는 요구사항은 무엇인가요?
  • 리뷰 및 꿀조합 작성 (이미지 업로드)
  • 이미지 로딩

→ 서비스에 이미지가 많고 중요한 부분을 차지하기 때문에 설정

• 서비스 특성상 어떤 환경에서의 사용자 경험이 더 중요한가요? (모바일/데스크탑)
  • 모바일

🚀 2단계 - 성능 예산 세우기

측정할 성능 지표 정하고 성능 예산 세우기

• 어떤 지표들(metrics)을 사용하기로 했고, 왜 이 지표를 선정했나요?
  • 정량 기반 지표(quantity based metrics)
    • 카테고리 api 요청 캐싱: 카테고리 api를 홈화면에서 계속 불러오는데 변할 가능성이 거의 없어서 캐싱을 하면 좋겠다고 생각함
  • 시간 기반 지표(timing based metrics / milestone metrics)
    • TBT: 사진을 폼에 업로드 할 때 걸리는 시간을 축소시키고자 함
    • LCP: 우리 서비스의 LCP는 이미지라서 이미지 최적화를 하면 LCP가 줄어들 것이라고 예상됨
    • CLS: Layout Shift가 일어나면 네트워크 상황이 좋지 않으면 버벅거릴 수 있기 때문에
  • 규칙 기반 지표(rule based metrics)
    • Lighthouse: 사용자가 없어도 분석할 수 있고, 일관된 환경에서 페이지를 빠르게 분석할 수 있음
• 측정 환경
  • device: 모바일
  • Network throttling speed: 3G Fast
  • CPU throttling: x4 throttling
• 우리 서비스의 성능 예산에는 어떤 것들이 있나요?
  • lighthouse 85점 이상
  • 리뷰 업로드 페이지의 TBT(Total Blocking Time) 300ms 미만
  • CLS 0.1 미만

🚀 3단계 - 측정하고 개선 포인트 찾기

측정하기

lighthouse

개선포인트

• 메인 화면에서 불러오는 사진의 용량을 줄인다.
• 이미지 업로드 속도를 향상시킨다.
• 번들 사이즈를 줄이고 코드 스플리팅을 한다. (현재 447KB)
• Layout Shift를 없앤다.
  • 컨텐츠 로딩 전 후의 간극을 없앤다. (로딩 UI 적용)

[hafnium1923]

우리 서비스에서 지속적으로 성능을 관리해야 하는 핵심 영역

• 모아보기 페이지 (팀 캘린더 + 통합 캘린더 + 팀 피드 + 공유 링크 목록)
  • 서비스의 모든 기능을 한 페이지에서 간편하게 사용할 수 있도록 제공한다. 여러 기능을 제공하는 만큼 부하가 가장 크게 발생할 것으로 예상되므로, 지속적인 성능 관리가 필요하다.
  • 팀플 시에 사용되는 서비스 특성 상 데스크톱에서 주로 작업(자료 조사, 발표 준비 등)하므로, 데스크톱에서의 성능을 우선적으로 최적화한다.

측정 대상

• 팀바팀 서비스 모아보기 페이지

측정 환경

• OS : Windows 11
• Browser : Chrome

성능 지표 선정 및 이유

• Lighthouse - FCP, LCP, Speed Index, TBT
  • 로딩 속도 개선을 통해 사용자 이탈 및 UX 저하를 방지
  • 모아보기 페이지에서 제공하는 다양한 컨텐츠와 기능들을 사용자가 최대한 빠르게 접할 수 있도록 개선하기 위해 해당 지표 선정
• 렌더링
  • 모아보기 페이지는 일정 CRUD, 피드 CRUD, 링크 CRUD 등 인터랙션 요소가 다양하고, 핵심 기능들을 제공하고 있음
  • 따라서 인터랙션과 직접적으로 연관된 부분만 리렌더링하도록 최적화할 필요가 있음

성능 예산

• Lighthouse GOOD 기준으로 개선

  • Lighthouse 성능 점수 ≥ 90
  • FCP < 1.8s
  • LCP < 2.5s
  • Speed Index
  • TBT < 200ms

• 자바스크립트 번들 사이즈 < 600kb

측정한 현재 지표와 성능 개선이 필요한 지점

최적화 전 성능 측정.pdf

• Lighthouse

  • Simulated throttling (default)
    

• 자바스크립트 번들 사이즈 - 902kb

성능 개선 계획

• FCP, LCP, Speed Index
  • Font preload 및 최적화
  • 리소스 압축(gzip, brotli)
  • 캐시 정책 수립
    • 변화가 잦지 않은 리소스인 서비스 로고, placeholder 이미지에 max-age=31536000 적용
  • 자바스크립트 번들 최적화
    • Tree Shaking
    • Code Splitting
    • JS minify
• 렌더링
  • 사용자 인터랙션과 직접적으로 연관된 컴포넌트만 리렌더링되도록 개선 필요

[kyw0716]

카페인 팀 성능 리포트

우리 서비스에서 지속적으로 성능을 관리해야 하는 핵심 영역

• 지도 기반 충전소 마커 조회 기능
• 충전소 아이디 기반 충전소 리스트 조회 기능

6만개의 충전소 정보와 23만개의 충전기 데이터를 다뤄 요청 수가 많아질수록 서버의 부담이 커지기 때문에 해당 요청을 발생시키는 기능들을 최적화해야 된다고 판단했습니다.

성능 지표와 성능 예산

서버의 성능이 페이지 성능의 거의 대부분을 차지하고 있기 때문에 불필요한 요청의 수를 줄이는 것을 주된 측정 기준으로 정했습니다.

측정한 현재 지표와 성능 개선이 필요한 지점

현재 지도의 중심이 이동하거나 지도의 크기 변화가 발생할 때 이미 가지고 있는 정보임에도 중심 이동, 크기 변화가 발생하면 무조건 요청이 발생합니다.

현재 마커를 렌더링하기 위해 받아온 충전소 아이디를 한꺼번에 서버에 요청해서 리스트를 받아오고 있는데 리스트 컴포넌트에서는 최대 4개의 충전소 정보만을 보여주고 있으므로 현재 사용자에게 보여지고 있지 않은 리스트에 대해서도 요청이 발생하고 있습니다.

개선 계획

• viewport의 크기만큼 요청하던 기존 방식에서 조금 더 큰 영역을 요청하는 방식으로 변경한다.
• viewport가 움직였을 때 처음 요청했던 영역을 벗어나지 않는다면 새로운 요청을 발생 시키지 않는다.
• 지도의 줌 레벨이 변경되었을 때 처음 요청했던 영역을 벗어나지 않는다면 새로운 요청을 발생 시키지 않는다.
• 마커를 렌더링 할 때 받아온 충전소 아이디가 많다면 리스트를 렌더링 할 때 10개씩 나누어 요청을 발생시킨다.
• 이미 요청을 했던 리스트 정보를 캐싱해두고 viewport가 움직이거나, 줌 레벨이 변경되었을 때 이미 캐싱되어 있던 리스트들에 대해서는 추가적인 요청을 발생시키지 않는다. (실시간성 데이터가 없기 때문에 캐싱 데이터를 이용해도 무방하다고 판단함)

[nangkyeonglim]

동글 팀 성능 리포트

동글 성능 리포트 링크를 통해 확인해주세요!