들어가기 앞서 🌱

2022년 5월부터 개발을 시작했다. 올해 1월부터 지금까지 약 6개월간 프론트엔드 취업을 위해 달려왔다. 가만히 생각해보면 5월부터 6월은 나에게 있어 내면을 더욱 단단하게 했던 훈련의 시간이었다. 공부에만 집중할 수 없는 상황이 겹겹이 쌓여, 상당히 답답하고 쓰라렸다. 그럼에도 불구하고 매일 알고리즘과 네트워크 및 프레임워크 공부를 하고 있었다. 그러나 정작 눈에 보이는 결과물이 없는 것으로 보였고, 나에게 있어 부족한 부분이 무엇인지에 대해 고민해보게 됐다. 또한 다른 사람들과 비교하여 낙심하기도 하고 가끔은 무기력하게 공식문서를 읽었던 적도 있었다. 하지만 가만히 나를 방치할 수 없었다. 환경을 바꾸기 위해 노력했고 5월 중순에 작은 프로젝트라도 병행하기로 했다. pain-point를 찾으며 기획을 진행했고 현재는 배포 직전의 상황이다. 그 후 다시 전진할 원동력이 생겼고 전신 갑주를 입은 듯 달려갈 수 있게 됐다. 그러다 LIVID STUDY를 지원하게 됐고 합격하게 돼, 7월부터 9월까지 총 3개월간 진행될 예정이다. 매주 정리한 내용을 블로그에 정리하고 더 나아가 토론 주제들을 정리해보려고 한다.

1장 내용 정리

교제는 프론트엔드 성능 최적화 가이드를 활용하여 매주 1장씩 읽고 토론하는 방식으로 스터디를 진행한다.

📕 1장에서 중요한 포인트

1. 크롬 개발자 도구의 performance 패널, Lighthouse, 네트워크 패널 분석
2. 이미지 CDN을 통한 사이즈 최적화
3. 코드 분할과 컴포넌트 지연 로딩
4. 텍스트 압축 기법
5. 병목 코드 분석과 최적화
6. webpack-bundle-analyzer 번들 분석

❓왜 성능 최적화가 필요하지?

실제 비지니스 환경에서 웹 페이지의 성능이 저하되면 유저의 이탈률이 높은 것이 검증됐습니다. 역도 마찬가지. 구글에서 로딩 속도와 이탈률 및 전환률의 관계를 살펴보니 로딩 속도가 3,5,6,10초로 느려질수록 32,90,106,123 퍼센트 이탈률이 상승했다고 합니다. 핀터레스트는 로딩 시간을 40% 줄여서 검색 유입률과 가입자수를 15% 늘렸다고 합니다.

웹 성능 최적화에 있어 두가지 요소

첫번째는 로딩 성능

서버로 요청을 보내 응답을 받는데 걸리는 성능

• 다운로드 리소스 줄이거나 크기를 줄이는 것
• 코드 분할로도 가능

1-1. 이미지 사이즈 최적화

너무 큰 사이즈의 이미지를 무분별하게 사용하면 네트워크 트래픽이 증가해서 로딩이 오래 걸린다. 교제에서는 실제 웹페이지에서 필요한 이미지 사이즈에 2배정도 되는 사이즈가 적당하다고 한다. 그 이유는 레티나 디스플레이와 같은 고해상도 디스플레이에 대응하기 위함이라고 한다.

• 이미지 CDN
  물리적 거리의 한계를 극복하기 위해 유저와 가까운 곳에 콘텐츠 서버를 두는 기술을 의미한다.
  imgix를 사용할 수 있다.

1-2. 코드 분할

SPA 특성상 모든 리액트 코드가 하나의 자바스크립트 파일로 번들링돼 로드되기에 오래걸리는데 이것을 코드 분할을 통해서 필요없는 코드는 떼어내고 해당 코드를 필요한 시점에 따로 로드할 수 있게 만들 수 있습니다.

두번째는 렌더링 성능

받아온 응답을 브라우저에 보여주는데 걸리는 성능, 즉 js 코드를 얼마나 효율적으로 작성했느냐에 따라 화면이 그려지는 속도와 UI가 달라진다.

2-1. 텍스트 압축

웹 페이지에 좁속하면 다양한 리소스를 내려받는데 그중에서 HTML,CSS,JS등이 있다. 다운로드 전에 서버에서 미리 압축할 수 있다.

2-2. 병목 코드 최적화

lightHouse 패널에서 view original Trace를 통해 performance 패널로 이동하여 확인할 수 있습니다.

병목 코드를 최적화하기 위해 Performance 패널 살펴보기

1. CPU 차트 , network 차트
   가장 최상단에 있는 차트를 통해 알 수 있는 것중 눈 여겨볼 것은 빨간색 선인 병목이 발생하는 지점입니다.

2. Network 타임라인
   서비스 전반의 로드 과정의 네트워크 요청을 시간순으로 보여줍니다.

3. Frames, Timings, Main

3-1. Frames는 화면에 변화가 있을떄마다 스크린샷을 제공해줍니다.

3-2. Timings은 User Timing API를 통해 기록된 정보를 기록한다고 합니다.

그럼 여기서 UserTiming API가 무엇인지 살펴보면
UserTiming API는 성능을 측정하는데 사용하는 JS의 API이라고 하는데 정확히 정리해보면 웹 브라우저의 Performance API의 일부라고 합니다.
3-3. main은 브라우저의 메인 스레드에서 실행되는 작업을 보여줍니다.

4. 하단 탭
   
   summary 탭을 통해서 전반적인 작업이 걸리는 시간을 알 수 있고 Bottom-up 탭은 페이지가 렌더링 되기 직전부터 처음까지 역순으로 보여주며 Event log는 말 그대로 발생한 이벤트를 보여줍니다.

분석 툴

1. lightHouse

mode

• Navigation : lightHouse의 기본 값으로 초기 페이지 로딩 시 발생하는 성능 문제를 분석
• Timespan : 사용자가 정의한 시간 동안 발생한 성능 문제 분석
• Snapshot : 현재 상태의 성능 문제를 분석
  Categories
• Performance : 웹 페이지의 로딩 과정에서 발생하는 성능 문제를 분석
• Accessibility : 서비스의 사용자 접근성 문제 분석
• Best Practices : 보안과 웹 개발 최신 표준에 중점을 두고 분석
• SEO : 검색 엔진에서 얼마나 크롤링되는지 분석

웹 바이탈에 영향을 주는 요소들

1. FCP (10퍼센트) : 페이지가 로드될 때 브라우저가 돔의 첫 번째 부분을 렌더링하는 데 걸리는 시간을 나타낸 지표입니다. 위의 사진을 보면 1.8초가 걸린 것을 확인할 수 있습니다.
2. Speed Index(10퍼센트) : 동일한 초에 렌더링이 이루어진 페이지가 각각 있을때 페이지 내의 요소들이 나뉘어 먼저 렌더링돼 시각적으로 보여지는 페이지가 SI 점수를 높게 받습니다.
3. Largest Contentful Paint (25퍼센트) : 페이지가 로드될 때 화면 내에 있는 큰 이미지 혹은 텍스트 요소가 렌더링되는데 걸리는 시간을 나타내는 지표입니다. 위에서 보면 2.3초가 걸렸음을 알 수 있습니다.
4. TTI (10퍼센트) : 말 그대로 유저와 상호 작용이 가능한 시점까지 걸리는 시간을 나타내는 지표입니다. js 파일이 커, 로드가 늦어진다면 html이 렌더링되고 잠시 상호작용이 안되는 경우가 있을 수 있습니다.
5. TBT(30퍼센트) : TTI와 비슷한데, 페이지가 클릭, 키보드 입력등의 사용자 입력에 응답하지 않도록 차단된 시간을 총합한 지표이고, 측정은 FCP와 TTI 사이 측정
6. CLS (15퍼센트) : 예기치 못한 레이아웃 이동을 측정한 지표

현재 lightHouse 웹 바이탈에 영향을 주는 요소 중 TTI는 제외됐다는 것을 알게 됐다. 네트워크에 영향을 많이 받기 때문이라는 글을 읽었다.

마치며 🌱

1장은 실습 위주로 진행된 챕터여서 부담도 없었을 뿐 아니라 너무 재밌었다. 여기서 알게 된 이미지, 코드 분할등 현재 배포 단계에 있는 알리고 올리고 프로젝트에 적용해보려고 한다. 알리고 올리고 사이트에서 최적화해야 할 것들이 머릿속에 맴돈다. 빠르게 적용해야겠다.

확실히 여러 명이 같이 토론의 형태로 여러 가지 주제에 대해 깊이 이야기해볼 수 있어서 유익하고 재밌다.

출처

1. 프론트엔드 성능 최적화 가이드 (책)
2. LIVID STUDY GIT REPO