frontend project optimization

sangwoo noh·2022년 5월 19일

슬기로운 회사생활

목록 보기

24/26

저번엔 MSA 적용하는 내용을 다루었다.
이번엔 프로젝트 최적화와 리팩토링에 관련된 내용을 다룬다

번들링 도구를 webpack에서 vite로 변경하였다.
구글프로젝트인 squoosh로 이미지 최적화. 퍼센테이지에따라 완급조절

ref : https://squoosh.app/

3.이미지중 svg로 대체가능한부분 svg로 대체

Tree-Shaking

require방식으로 모듈을 사용한내용을 import,export 방식으로 변경
외부 변수를 의존하는 함수들을 가능하면 순수함수로 분리하여 side effect를 유발하지 않는 형식으로 전환 및 Tree-shaking 유도(쉽게 말하면 순수함수로 함수형 프로그래밍)
정말 side effect가 일어날 확률이 없는경우라고 판단되면
package.json에 아래와같이 입력하면 된다.

"sideEffects": [
    "./src/components/Input.js"
  ]

필요한 부분만 import 하기

import { function1, function2 } from "someModule"

다만 이때 주의할점?은 모듈이 자체적으로 export방식을 지원안하면 하나마나 tree shaking을 진행하지 않는다.
주의라기보다 확인을 하고 작업을 진행하면된다.
나는 VSC에서 import cost라는 확장기능을 사용하여 위 내용적용시 용량차이가 존재하는 모듈은 전부 변경하여 적용했다.

사용안하는 코드 삭제하기
물론 빌드로직에따라 알아서 최적화가 되긴하지만 자체적인 판단에 애매한경우에는 그냥 남기기도 한다니깐 확실하게 걍 지워줌

부분적으로 dynamic import 적용

초기에 로딩되는 내용이 쓸때 없이 많아지는것을 방지하고 완급조절이 가능함
한번에 너무 많은양을 다운받으면 힘드니깐(카드값처럼 생각하면됨 할부로 처리하자)

사용안하는 이미지 정리(css에서 사용안하지만 참조하고있는 부분이 있는지 확인)

이것또한 build시 알아서 사용되는 이미지만 남지만 일단 물리적으로 없애면 더 확실하다.
실제로 몇개의 이미지는 사용안됨에도 불구하고 프로젝트 내부의 css에서 참조하고 있다던지 딴 component에서 export로 참조만하고 사용을 안하고 있는 컴포넌트에서 사용하고 있다고 판단되어 빌드시 포함되는 경우가 있었음.
다 정리해준다.

쓸때없이 over fetching, under fetching되고있는 부분은 없는지 확인

이것을 해결하기위해 graphql 적용

쓸때없이 너무 많은 변수를 생성하고 있지 않은지?
예를들면

const TestComp = () => {
  const SomeCompoent = () => {
    return (
        <div>haha<div>
    )
  }
  let title = "hit me"
  let comp1 = SomeComponent  // 굳이?
  return () {
      {comp1()}
  }
}

등등 기형적인 구조를 가진경우

const SomeCompoent = () => <div>haha<div>
const TestComp = () => {
  const title = "hit me"
    return () {
		{title}
        <SomeComponent />
    }
}

암튼 이렇게 쓸때없이 result값을 넣어주는 패턴을 버려준다.
컴포넌트의 단위가 지금은 작으니깐 와닿지 않을 수도있지만 용량이 큰 컴포넌트를
조건에 따라 컴포넌트를 표시하는경우 괜히 메모리만 잡아먹는다.

재사용가능한 패턴을 찾아 모듈화 시키거나 또는 재사용을 풀어준다.
완급조절을 하라는건데 ...

// pattern1
let num=0
for (i=0;i<2;i++){
	num += 1
}

// pattern2
let num=0
num += 1
num += 1
num += 1

알고리즘적으론 pattern1이 더 맞는말이겠지만..
성능적으론 pattern2가 더 빠를수 밖에 없다.

이런부분을 찾아서 완급조절을 해주면된다.

용량도 줄일것인가 실행속도를 빠르게 할것인가 고민하고 고민하자.
무지성 원패턴 적용이 아닌 득과 실을 따졌을때 얻는것이 많으면 적용하고 잃는것이 많으면 버리면된다.

결과

빌드파일 용량: 40MB => 4MB
개발시 번들링속도: 4분 => 10 ~ 15초
초기페이지 다운로드 용량: 10MB~40MB => 1.9MB
메인화면 로딩완료 속도: 5~10s => 2~5s(기존로직에서 under fetching을 변경하고 SSR적용 및 캐싱으로 tric을 좀 사용하면 훨씬 빨라질듯 하다.)

후기

쓸때없는 파일 제거랑 이미지최적화가 제일 드라마틱했고
사실 코딩에쓰여진 텍스트를 줄인다고 뭐 얼마나 줄어들겠나 싶다.
모듈 참조방식이 조금 꿀이었고, 대충 여기까지 물리적인 용량 최적화를 적당히 하고
나머지는 성능 최적화를 하는것이 적당하다 싶다.
알고리즘 수정,
fetching이 사이드이펙트로 중복이 되는경우는 없는지,
over fetching과 under fetching이 일어나는구간은 없는지,
캐싱이 안돼서 매번 새롭게 값을 할당하고있는경우는 없는지
많~은 노오오오오력을하면 성능최적화가 조금씩 조금씩 되고 확률적으로 그중에 분명 크게 얻어걸리는것이 몇개 있다.