1장 블로그 서비스 최적화(2/2) [프론트엔드 성능 최적화 가이드]

프론트엔드 성능 최적화 가이드

지난 주 복습(지난주에 기억하지 못한 내용)

FCP	SI	LCP	TTI	TBT
First		Large	Interact	block

---

책을 읽어나가면서 든 생각

글을 읽기 → 이 책을 읽는 목적을 다시 떠올리기

결국 최적화를 하는게 목적인데

(1) 무엇을 (2) 어떻게 해야하는지를 봐야할 것 같다.

 

그리고 Lighthouse에서 Oppertuntiny와 DIAGNOSTICS를 통해 최적화 가능성을 찾아야 한다.

 

제목이 굵은 글씨로 이번 소제목은 '병목 코드 최적화' 라는 것을 알려준다.

그래서 '병목 코드 최적화'를 하겠군. 하고 따라가다 보니 왜? '병목' 코드라는 것을 알 수 있었지? 해서 다시 처음으로 돌아왔던 것.

 

병목코드를 확인하자! 가 아니라, Lighthose가 어떤 DIAGNOSTICS를 제시하는지 보는게 우선인 것 같다.

그래서 제시된 문제점중에 하나가

Reduce JavaScript execution time

즉, JS 실행 시간을 줄이기!

 

그렇다면 무엇에서 문제가 발행했지?를 떠올렸고 해당 항목을 클릭해서 열어봐야 한다(상세정보 확인).

여기서 Time을 보면 가장 많이 걸린 항목은 0.chunk.js (나는 1이 아니라 0인데..)

 

 

아 그러면 일단 오래 걸렸다는 것은 알 수 있는데, 문제를 어떻게 해결하지? (해결 할 수 있는건가?)

느린 작업을 찾기 위해 메인스레드의 작업을 확인해야 한다.

=> Performance 패널 확인하기

=> 또는 Lighthose 결과 페이지에서 View Original Trace 클릭

 

노란색, 보라색, 회색, 빨간색 등 다양하다.

뭐가 뭔지 모르겠지만, 상단 차트는 CPU이고 하단 차트는 NET

Network 타임라인을 보고싶다면 Network의 토글을 클릭

[Network 인 것을 어떻게 찾아가지? JS이니까 다운받아야 해서?]

첫 영역을 잡아주고

Summary를 확인해보기

 

removeSpecialCharacter 함수에서 문제가 생겼다는 것(시간이 오래 걸림)을 어떻게 판단한거지?

결국 removeSpecialCharacter 함수를 수정

= replace(정규표현식)

flag를 g로 사용하면 해당 문장 전체를 for문을 사용하지 않고도 전부 탐색이 가능

 

(*39p에서 str.replace()가 아니라, _str.replace()로 수정해야 300자로 잘린 문자열에서 replace 하는 것 같은데..?)

 

병목 코드를 최적화한 후 얻게된 것

1. TTI와 TBT가 줄었다(결국 인터렉션 하기 전까지의 로딩등 상태가 빨라졌다는 의미? TBT는 FCP부터 TTI사이의 시간동안 발생인데.. TTI가 TBT에 속하니 같이 빨라진 것?)

(교재에서는 Main스레드의 Task만 비교. 그런데 Lighthouse에서 TBT를 확인하는건 직접 TBT를 클릭하는 수밖에 없나? ...다음 페이지에 나와있음)

2. Diagnostics 섹션에서 Reduce JavaScript execution time 항목이 삭제됨

 

0.chunk js 파일은 다운로드가 오래 걸렸음

1. 다운로드를 모두 완료 한 후

2. 렌더링

 

Webpack Bundle Analyzer툴

- 웹팩을 통해 번들린됭 파일이 어떤 코드로 이루어져있는지 트리맵으로 시각화하여 보여줌

그러나, 프로젝트는 create-react-app을 통해 생성되었기 때문에 cra-bundle-analyzer 활용

npm install --save-dev cra-bundle-analyzer

npx cra-bundle-analyzer

 

실행하게되면 브라우저가 나타나고, 패키지들을 실제 크기에 따라 비율로 보여줌: 패키지 용량을 확인

거대 파일 안에 refactor, react-dom이 들어있음

react-dom은 리액트를 위한 것이니 생략

찾아야 할 내용은 refactor 패키지(내에서 최적화 할 수 있는 요소)

dependencies 안에서 refactor를 참조하는 지 확인해야 한다. (refactor 검색)

react-syntax-highlighter 패키지가 refactor 참조

해당 하이라이팅 기능은 상세페이지에서만 필요하기 때문에 목록 페이지에서는 다운로드 되지 않아도 된다.

따라서 페이지별로 따로 로드하는 방법이 필요!

 

(그래서.. 방법은?)

 

코드 분할 → 지연로딩

코드 분할: 필요한 코드(페이지 부분)만 따로 로드

하나의 번들 파일을 여러개의 파일로 쪼개는 방법

 

방법1

- 페이지별로 코드 분할

방법 2

- 모듈별로 분할(공통으로 사용하는 모듈이 많은 경우)

 

코드 분할 적용 방법

1. 동적 import 사용: promise 형태로 반환 → 밖으로 빼줘야 함

import {add} from './math'
console.log('1+4 = ',add(1,4))

해당 모듈은 빌드 시에 함께 번들링됨

하지만, import(메서드) 사용

import('add').then(module=>{
    const {add} = module
    console.log('1+4 = ', add(1,4))
})

동적 import 사용: promise 형태로 반환 → 밖으로 빼줘야 함

(Suspense 안에서 렌더링해야 한다)

(1) fallback: SomeComponent가 값을 갖지 못하는 동안 prop에 정의된 내용으로 렌더링

(2) SomeComponent: 이후 SomeComponent가 온전히 로드된 후 렌더링

import React, {Suspense} from 'react'

const SomeComponent = React.lazy(()=> import('./SomeComponent'))
function MyComponent(){
    return(
        <div>
            <Suspense fallback={<div>loading...</div>}>
                <SomeComponent />
            <Suspense>
        </div>
    )
}

 

여기서는 페이지별로 (라우팅할 때) 분할하기 때문에 먼저 ..

왜지?!

(뷰에서 리스트로 오는 경우도 생각하는 건가? 이때는 ..)

아

그때그때 페이지만 보여주기 위해서. (내가 복잡하게 생각한건 페이지 안에 hilight 등 사용되기 때문에 해당 페이지 안에서 import 되는 부분을 생각했던 것 같다. 여기서는 그런것 보다 상위 차원에서 페이지별로 분할했기 때문에 페이지를 아예 독립적으로 import 하는 것으로 보인다.)

 

p54: 어디가 분할된건지 못 찾겠다.

 

텍스트 압축(잘못 안 내용: 지레짐작으로 폰트, 페이지 내에서 보이는 텍스트가 압축되는 것인줄 알았지만 코드 압축)

: 서버에서 실행

production 환경: 경량화, 난독화 같은 추가 최적화 작업이 이루어짐(따라서 production 환경으로 빌드된 서비스 성능 측정)

development 환경: 

build를 하고 Oppertunities 섹션을 확인하면

Enable text compression를 확인할 수 있는데 Potential Savings를 통해 얼마나 최적화 할 수 있는지 알 수 있다.

 

압축되었는지 확인하려면, HTTP의 헤더를 확인

Network 패널의 articles API 항목에 Response Headers에 Content-Encoding: gzip으로 표시되어있다면 압축되어 전송되었다는 의미

압축 방식은 두가지: Gzip, Deflate