Replies: 12 comments 1 reply
-
리뷰미: 팀 성능 리포트 |
Beta Was this translation helpful? Give feedback.
-
코드잽 : 팀 성능 리포트1단계 - 성능 관리 대상 설정하기
2단계 - 성능 예산 세우기1. 정량 기반 지표
2. 시간 기반 지표
3. 렌더링 지표
4. 규칙 기반 지표
3단계 - 측정하고 개선 포인트 찾기
성능 측정 환경 및 결과
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
투룻 팀 성능 리포트1단계 - 성능 관리 대상 설정하기우리 서비스에서 가장 핵심이 되는 영역
핵심 영역에 대한 페이지
서비스 특성상 어떤 환경에서의 사용자 경험이 더 중요한가요? (모바일/데스크탑)모바일 first이므로 모바일로 진행 2단계 - 성능 예산 세우기 계획정량 기반 지표
시간 기반 지표
성능 테스트 환경
렌더링 기반 지표
규칙 기반 지표
3단계 - 측정하고 개선 포인트 찾기성능 측정측정 방법
측정 결과
개선 방향
|
Beta Was this translation helpful? Give feedback.
-
👑 행동대장 성능개선 리포트1. 우리 서비스에서 지속적으로 성능을 관리해야 하는 핵심 영역
2. 측정 대상으로 선정한 성능 지표와 성능 예산모든 지표는 모바일 환경과 관리 페이지를 대상으로 한다.
3. 측정한 현재 지표와 성능 개선이 필요한 지점 |
Beta Was this translation helpful? Give feedback.
-
🍑TEAM momo 모모 성능 개선 레포트🍑🚀 1단계 - 성능 관리 대상 설정하기우리 서비스에서 지속적으로 성능을 관리해야 하는 대상 설정하기
Q. 서비스 특성상 어떤 환경에서의 사용자 경험이 더 중요한가요? (모바일/데스크탑)언제 어디서든 쉽게 사용할 수 있다는 것이 서비스의 목적이기 때문에 주 사용 타겟층은 모바일입니다. 또한, 노트북보다 휴대폰을 가지고 있는 사람의 비율이 월등히 높고 판단했습니다. 따라서, 모바일 환경을 기준으로 성능을 측정하기로 결정했습니다.
Q. 기능적으로 가장 핵심이 되는 요구사항은 무엇인가요?팀 모모는 서비스 핵심 영역이 어떤 영역인지에 대해서 의견을 나누고 아래와 같이 결론 지었습니다. 약속 주최자, 참여자 모두 자주 방문하게 되기 때문에 가장 트래픽이 많다고 예상되는 약속 현황 조회 페이지에 모모 서비스의 핵심 기능이 몰려있다고 할 수 있습니다. 해당 페이지에서 제공하는 기능들에 대한 성능을 측정해 보기로 했습니다. 약속 현황 조회 페이지 약속 현황 조회 페이지에서 모모 서비스가 제공해 주는 핵심 기능은 다음과 같습니다. 약속 현황 조회 페이지 기능 목록저희 서비스는 위에서도 확인할 수 있듯, 측정 환경은 미션에서 사용했던 1. 드래그로 시간을 선택하는 기능report-2.movslowdown x 6, fast 4G 환경에서 측정하니 드래그를 할 때, 드롭된 프레임과 일부 드롭된 프레임 모두 확인할 수 있다. 해당 부분을 개선해 보기로 했습니다. 드롭된 프레임은 약속 시간 현황을 조회하다가 등록을 하기 위해 편집 아이콘 버튼 눌렀을 때 발생합니다. 또한, 시간을 등록/수정할 때 부분 렌더링된 프레임이 발생합니다.
2. 툴팁 UI를 활용해서 약속 시간 현황을 보는 기능전체 약속 참여자들의 일정을 조회하는 경우 툴팁 UI를 활용해서 보여주고 있습니다. 툴팁 UI는 개선할 필요가 없다고 판단했습니다. 이유는 다음과 같습니다.
따라서, 툴팁 UI와 관련된 성능은 따로 개선 작업을 진행하지 않기로 결정했습니다. 3. 특정 참여자의 시간 현황만 보는 기능참여자 이름 태그를 바꿔가며 클릭할 경우, 참여자가 변경될 때 부분적으로 렌더링된 현상이 발생하기는 하나, 개선할 정도의 수치는 아니라고 판단했습니다. 🚀 2단계 - 성능 예산 세워보기측정할 성능 지표 정하고 성능 예산 세우기
Q. 어떤 지표들(metrics)을 사용하기로 했고, 왜 이 지표를 선정했나요?어떤 지표들을 사용해야할 지 감이 잡히지 않아서, 구글의 RAIL과 web.dev의 web-vitals article에서 권장하는 수치들을 참고했습니다. 해당 아티클에서 권장하는 수치들을 기준으로 성능 예산을 결정했습니다. Q. 우리 서비스의 성능 예산에는 어떤 것들이 있나요?2-1 성능 예산이란
핵심 지표core-web-vitals 내용을 참고해서, 웹 성능에서 가장 중요한 3가지 지표를 권장 수치에 맞게 개선해 보기로 했습니다. 1. LCP(Largest Contentful Paint)
2. INP(Interaction to Next Paint)
현재 INP를 수치상으로 측정할 수 있는 기능이 Lighthouse에서 별도로 존재하지 않기 때문에, 핵심 기능에 대한 이벤트 처리를 고려하여 INP를 측정할 예정입니다. 우선적으로는 이벤트 상호 작용 과정에서 로딩 처리를 하여 현재보다 개선해보겠습니다. 3. CLS(Cumulative Layout Shift)
리소스가 비동기식으로 로드되거나 DOM 요소가 기존 콘텐츠 위의 페이지에 동적으로 추가되기 때문에 발생합니다.
부가적인 지표other-web-vitals아티클을 참고해서, 부가적인 지표 또한 개선해 보기로 했습니다. 1. FCP (First Contentful Paint)
2. SI(Spped Index)
3. TBT(Total Blocking Time)
현재 약속 시간 현황 조회 페이지에서 lighthouse를 측정한 결과 TBT가 450ms로 측정된 것을 확인할 수 있습니다.
4. LightHouse Performance 점수
5. WebPageTest 성능 점수
작업 목록요청 크기 줄이기1. JS 리소스 크기 줄이기JS 리소스 크기를 줄이는 방법에는 압축과 난독화가 있다. 웹팩을 사용해서 프로덕션 빌드를 할 때는 자동으로 압축과 난독화가 진행되기 때문에 별도의 플러그인을 사용하지 않기로 합니다. 2. CSS 리소스 크기 줄이기웹팩 공식문서에서도 확인할 수 있듯, 프로덕션 빌드를 할 때는 번들링된 JS 파일에서 CSS 파일을 분리할 것을 권장하고 있습니다. 팀 모모는 @emotion/react 라이브러리를 활용해서 DOM 요소들을 스타일링 하고 있습니다. 해당 라이브러리는 CSS-in-JS라이브러리로 babel transpile 과정에서 minify되기 때문에 별도의 설정은 하지 않습니다. 따라서 웹팩에서 제공하는 MiniCssExtractPlugin를 사용해서 CSS 파일을 분리하는 작업만 진행하도록 예정입니다. 3. 자바스크립트 파일 압축 방식 변경하기
적용되지 않는 이유를 파악하고 br 압축 성능을 사용할 예정입니다. 4. 이미지 크기 줄이기기존 momo-bundle.js 파일에 SVG 형식이 함께 포함되어 로딩 속도가 늦어지는 현상이 발생합니다. 따라서 이미지 리소스의 확장자를 변경하거나 SVG를 추가로 최적화하는 방향으로 논의해 볼 예정입니다. 5. 사용하지 않는 폰트 제거하기subset 적용해서 필요하지 않는 폰트를 제거하고 폰트 파일의 크기를 줄일 수 있도록 합니다. 요청 우선순위 결정하기1. 폰트 preload 적용하기slowdown x 6, Slow 4G 환경에서 측정한 결과 폰트를 다운로드 받는 데 3.2초 걸려 폰트 출렁임 현상이 발생할 수 있습니다. 폰트 출렁임 현상을 최대한 개선하기 위해 preload를 사용한다. 뱅크 샐러드의 지연 시간 없이 웹폰트 서빙하기를 참고해서, 문제를 해결할 예정입니다. 필요한 것만 요청하기1. 페이지별 리소스 분리성능개선 미션에서 적용했던 것처럼 페이지 별 lazy loading 구성할 수 있도록 합니다. 약속 시간 현황 페이지에 방문한 약속 참여자들이 약속 생성 페이지로 이동하지 않는 상황이 더 많을 것 같다고 판단했습니다. dynamic import, React Suspense를 활용해서 코드 스플리팅을 구현합니다. 추가로 느린 네트워크 환경을 고려해 라우팅을 할 경우, Layout Shift가 발생하지 않도록 로딩 fallback UI를 구현합니다. 같은 건 매번 새로 요청하지 않기CloudFront 캐시 설정 / S3 메타데이터 설정은 아래와 같이 설정합니다.
최소한의 변경만 일으키기
report15.mov🚀 3단계 - 측정하고 개선 포인트 찾기개선 전 측정측정 환경: Mobile, CPU slowdown x6, Slow 4G 환경에서 측정 약속 생성 페이지약속 현황 페이지약속 추천 페이지약속 확정 페이지 |
Beta Was this translation helpful? Give feedback.
-
1단계: 성능 관리 대상
2단계: 성능 예산 세우기어떤 지표들(metrics)을 사용하기로 했고, 왜 이 지표를 선정했나요?
우리 서비스의 성능 예산에는 어떤 것들이 있나요?
테스트 환경
기타
3단계: 측정 및 개선 포인트 찾기로그인(/home)1. 정량 지표
2. 시간 기반 지표3. 렌더링 지표sorry cat 최초 import시 partially frame drop 별도의 layout shift는 일어나지 않음 모임 만들기(/darakbang/[id]/add-moim)1. 정량 지표
2. 시간 기반 지표3. 렌더링 지표모임 만들기 시 움직이는 상단바가 partially frame drop을 유발하지 않음 헤더에 있는 뒤로가기 버튼이 넘어갈 대마다 재 렌더링됨 모임 목록 조회1. 정량 지표2. 시간 기반 지표3. 렌더링 지표다락방 메인 페이지의 나의모임, 찜한모임 목록 조회시 로딩 UI로 인해 간헐적으로 partially frame drop을 일으킴 모임 상세 보기(+모임 참여/모집 완료)1. 정량 지표
2. 시간 기반 지표3. 렌더링 지표
모임 참여1. 정량 지표
2. 시간 기반 지표
채팅 목록1. 정량 지표
2. 시간 기반 지표3. 렌더링 지표스켈레톤 애니메이션이 간헐적으로 partially frame drop을 일으킨다 채팅창이 렌더링 되지 않는다 채팅1. 정량 지표
2. 시간 기반 지표3. 렌더링 지표새로운 채팅이 올 시 ChattingRoomPage 전체가 렌더링된다. 개선 포인트
|
Beta Was this translation helpful? Give feedback.
-
땅콩 성능 개선 리포트1단계 - 성능 관리 대상우리 서비스에서 지속적으로 성능을 관리해야 하는 대상 설정하기
2단계 - 성능 예산 세우기측정할 성능 지표 정하고 성능 예산 세우기
3단계 - 측정하고 개선 포인트 찾기측정 결과LightHouse
이미지 측정bundle 측정퍼포먼스 측정
개선 지점
|
Beta Was this translation helpful? Give feedback.
-
- 데벨업 성능 개선 리포트1단계 - 성능 관리 대상 설정하기
2단계 - 성능 예산 세우기
- 3단계 - 측정하고 개선 포인트 찾기
1. 자바스크립트 번들 사이즈 줄이기[결과] dev: 24.7MB → 1.9MB S3와 CDN을 통한 배포 시 메인 페이지에서 불러오는 번들 크기는 약 25MB이었습니다. 권장되는 번들 최대 사이즈는 224KB으로, 데벨업의 소스코드 번들은 권장 사이즈보다 약 100배 큰 사이즈를 갖고 있었습니다. 이렇게 번들 사이즈가 매우 커서 자바스크립트 파일을 다운받는데 많은 시간이 소요되었습니다. 자바스크립트 다운로드가 완료되어야 웹 페이지를 로드할 수 있는 브라우저 특성상, 화면에 요소들이 그려지는 시간도 오래 걸렸습니다. 따라서 이를 해결하고자 자바스크립트 번들 사이즈를 줄이기로 결정했습니다. 방법 1.
7.57 → 5.48 (prod) const CssMinimizerPlugin = require('css-minimizer-webpack-plugin');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
module.exports = {
module: {
rules: [
{
test: /\.(css|scss)$/i,
use: [MiniCssExtractPlugin.loader, 'css-loader'],
},
]
},
// ...
optimization: {
minimize: true,
minimizer: ['...', new CssMinimizerPlugin()],
},
}; 방법 2. Lazy Loading를 활용한 Code Splitting import React, { lazy } from 'react';
const MissionDetailPage = lazy(() => import('./pages/MissionDetailPage'));
const MainPage = lazy(() => import('./pages/MainPage'));
const MissionSubmitPage = lazy(() => import('./pages/MissionSubmitPage'));
const UserProfilePage = lazy(() => import('./pages/UserProfilePage'));
// ... 기타 페이지들
2. 폰트 최적화
-문제 해결폰트를 외부 경로에서 가져오는것은 마찬가지이지만, 필요한 폰트인 regular와 bold만 따로 따로 불러옴으로써 불필요한 HTTP 통신을 줄였습니다. 또한 link 태그가 아닌 직접 font-face를 선언해서 사용함으로써 Redering Blocking 문제를 해결하였습니다. 다만 이런 방법을 선택했을시 깜빡임 현상 (FOUT)이 발생할 수는 있으나, 아직 실제적으로 발생하지 않은 문제이기도 하고, 렌더링 문제를 해결해주는 장점이 더 크다고 판단하여 도입하였습니다. @font-face {
font-family: 'Pretendard';
font-weight: 400;
font-display: swap;
src: url('https://fastly.jsdelivr.net/gh/Project-Noonnu/[email protected]/Pretendard-Regular.woff')
format('woff');
}
@font-face {
font-family: 'Pretendard';
font-weight: 700;
font-display: swap;
src: url('https://fastly.jsdelivr.net/gh/Project-Noonnu/[email protected]/Pretendard-Bold.woff')
format('woff');
} -폰트 최적화 후 상황CDN 경로에서 불러오기 때문에 캐시가 된 것을 확인할 수 있습니다. 3. 이미지 사이즈 최적화의도 용량이 큰 이미지는 네트워크 요청 병목을 만들며, 늦은 이미지 로드는 사용자에게 답답한 느낌을 준다. 따라서 이미지 크기를 적정 수준으로 유지하고자 한다. 목표 개별 이미지 파일의 120KB를 넘지 않도록 한다. 측정 Before 고해상도의 이미지가 없어 약 70kb~570kb로 높지 않은 수준이지만, 2개의 이미지가 기준 수치를 초과했다. 개선 lossless 압축 및 webp 변환을 수행했다. avif가 아닌 webp를 선택한 이유는 둘 간의 파일 사이즈가 거의 차이 나지 않는데(1~2kb), 지원 브라우저 범위에서 차이가 있었기 때문이다. |
Beta Was this translation helpful? Give feedback.
-
🍀 '코딩해듀오' 팀 성능 리포트🚀 1단계 - 성능 관리 대상 설정하기기능적으로 가장 핵심이 되는 요구사항은 무엇인가요?
서비스 특성상 어떤 환경에서의 사용자 경험이 더 중요한가요?
🚀 2단계 - 성능 예산 세우기어떤 지표들(metrics)을 사용하기로 했고, 왜 이 지표를 선정했나요?
1. 정량 기반 지표 (Quantity Based Metrics)
2. 시간 기반 지표 (Timing Based Metrics)
3. 렌더링 지표 (Rendering Metrics)
4. 규칙 기반 지표 (Rule Based Metrics)
우리 서비스의 성능 예산에는 어떤 것들이 있나요?1. 정량 기반 지표 (Quantity Based Metrics)
2. 시간 기반 지표 (Timing Based Metrics)
3. 렌더링 지표 (Rendering Metrics)
4. 규칙 기반 지표 (Rule Based Metrics)
🚀 3단계 - 측정하고 개선 포인트 찾기측정 결과자바스크립트 번들 크기
리소스 파일 크기
Performance
Lighthouse
WebPageTest
개선 방안소스 코드 최적화
이미지 최적화
폰트 최적화
Sentry Preconnnect / Font Preload
애니메이션 로직 개선
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
크루루 팀 성능 리포트1단계 - 성능 관리 대상 설정‘크루루’의 핵심 기능 영역
주요 사용자 경험 환경 : 데스크탑
2단계 - 성능 예산 세우기측정 환경 설정
성능 지표별 선정 이유
3단계 - 측정하고 개선 포인트 찾기측정 결과 1) 주요 리소스 용량
측정 결과 2) 페이지별 Lighthouse, Performance 측정 결과
개선 포인트
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
All reactions