The RED: Back to the Basics - 웹 어플리케이션의 성능을 200% 끌어올리기
===
###### tags: `석기`
---
## 프론트엔드 개발자가 왜 성능을 신경써야하나요
- 생각보다 많이 관여하는 것이 아니긴하다.
- 백엔드가 훨씬 관여가 심하긴하다.
- 즉, 백엔드와 맞물려 성능을 최적화 해야할 수 있다.
:::danger
Make it work, Make it right, **Make it fast**
:::
### 성능을 왜 신경써요?
- 사용자 경험이 좋아져요.
- 비용을 아끼면 사장님이 좋아하고,
- 면접 문제 단골.
## 코드 바깥의 성능
### 성능은 시간, 리소스로 측정한다.
#### 시간
##### 초기 구동 시간
- 파일 다운로드
- 최신 브라우저는 도메인달 6개 접속만 동시 처리.
- 보통 이미지같은 경우에는 다른 도메인에서 부른다.
- 화면 크기와 해상도에 따라 적절한 이미지 로딩
- 웹 폰트 최적화
- 화면 크기에 따라 필요한 스타일 시트만 로딩
- 컨텐츠 렌더링
- 로딩 속도 개선
- 필수 컨텐츠가 아니라면 비동기 로딩 고려.
- 이미지, 아이프레임, 등은 Lazy Loading 을 고려해보자.
- 시간이 많이 걸린다면 placeholder나, skeleton 으로 대체해라.
- 인터렉션 가능
##### 계산 시간
- 웹 워커, 느긋한 계산, 메모이제이션이 사용됨.
- 웹 워커
- 자바스크립트는 싱글 스레드이지만, 멀티 스레드가 가능하다.
<img src="https://i.imgur.com/1BwrPbM.jpg" width="90%" />
- 원래 아래처럼 코드가 존재한다.
<img src="https://i.imgur.com/hhHdOFt.jpg" width="80%" />
- 주황색으로 된 부분이 시간이 오래걸리는 로직.
- 이를 바깥으로 아래처럼 뺄수 있다.
<img src="https://i.imgur.com/wGnGNKn.jpg" width="90%" />
- 느긋한 계산
- 커다란 데이터가 있다면 범위를 줄이는 것 부터 시작하자.
- 메모이제이션
- 계산 결과를 기억해두고 반복 사용하는 기법.
- 피보나치 수열에서 사용하는 예제.
## 애니메이션 성능
##### 반응 시간
- 지나치게 느린 애니메이션 및 응답속도는 사용자 경험을 저해한다.

- 위 이미지의 요점은, javascript 동작이 늦어지면, 나머지 뒤에 스타일 / 레이아웃, 페인트, 등 모두 느려진다.

- javascript 로 애니메이션을 조정하는 방법은 피하자.
- 가능하면 transform, opacity 위주로 사용하자.
- 자동적으로 브라우저가 효율적이게 컴파일한다.

- three, velocity 도 하나의 방법이다.
- will-change 브라우저가 알아서 최적화하도록 조정할 수 있다.
- 리소스가 밀릴수 있으니 조심해야한다.
- 최후의 수단이다. 이건 ㄹㅇ.
- DOM 접근은 정말 적게하라.
- element를 업데이트 하는 경우에는 한번에 몰아서 하자.
```javascript=
const app = document.getElementById('app');
const frag = document.createDocumentFragment();
for(let i = 0 ; i < 100 ; i++){
const el = document.createElement('div');
el.innerText = `Element ${i}`;
frag.appendChild(el);
}
app.appendChild(frag)
```
## Javascript 코드의 성능
리소스 측면 - 자원을 덜쓰는게 효율적인 것.

#### 메모리 누수
:::warning
프로그램이 필요하지 않는 메모리를 계속 점유하는 현상.
:::
- Javascript 엔진이 판단하기 떄문에 추정해야한다.
<center><img src="https://i.imgur.com/HNlBd6C.png" width="60%" /></center>

- 위와 같은 상황에서
- 5번 단계가 존재하지 않는다면 ==메모리 누수==가 발생한다.
- z가 참조하는 것은 o2 일뿐인데,
- 어느곳에서도 참조하지 않는 o1도 살아있어야 o2가 존재하므로,
- o1가 불필요하게 살려놓아야한다.
**이런 현상이 원래 있었다.**

- 이제는 이런 문제를 해결 할 수 있다.
:::success
그렇다면 이제 메모리 누수를 걱정하지 않아도 되는것 아닌가?
:::
==**아니다. 약간의 부주의함으로 발생하는 경우는 아직 있다.**==
<center><img src="https://i.imgur.com/72geEOz.png" width="80%" /></center>
- 전역변수에 큰 데이터
- 이 전역변수는 계속 남아있기 때문에.
- 클로저
- 본인이 써야하므로, 즉, 자신이 생성된 환경을 기억하기 떄문에 계속 남아있다.
- 생성된 실행 컨텍스트의 변수가 해제가 안됨.

- 위와 같이 해결은 가능하다. / 하지만 피해라!
- 큰데이터가 다른 변수에서 참조
- bigData가 필요없어지더라도 다른 변수에서 참조하므로.