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%" /> - 느긋한 계산 - 커다란 데이터가 있다면 범위를 줄이는 것 부터 시작하자. - 메모이제이션 - 계산 결과를 기억해두고 반복 사용하는 기법. - 피보나치 수열에서 사용하는 예제. ## 애니메이션 성능 ##### 반응 시간 - 지나치게 느린 애니메이션 및 응답속도는 사용자 경험을 저해한다. ![](https://i.imgur.com/JARsGDU.png) - 위 이미지의 요점은, javascript 동작이 늦어지면, 나머지 뒤에 스타일 / 레이아웃, 페인트, 등 모두 느려진다. ![](https://i.imgur.com/Te0wgVZ.png) - javascript 로 애니메이션을 조정하는 방법은 피하자. - 가능하면 transform, opacity 위주로 사용하자. - 자동적으로 브라우저가 효율적이게 컴파일한다. ![](https://i.imgur.com/1Gxmqrz.png) - 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 코드의 성능 리소스 측면 - 자원을 덜쓰는게 효율적인 것. ![](https://i.imgur.com/zQMM8XJ.png) #### 메모리 누수 :::warning 프로그램이 필요하지 않는 메모리를 계속 점유하는 현상. ::: - Javascript 엔진이 판단하기 떄문에 추정해야한다. <center><img src="https://i.imgur.com/HNlBd6C.png" width="60%" /></center> ![](https://i.imgur.com/BRlWPjY.png) - 위와 같은 상황에서 - 5번 단계가 존재하지 않는다면 ==메모리 누수==가 발생한다. - z가 참조하는 것은 o2 일뿐인데, - 어느곳에서도 참조하지 않는 o1도 살아있어야 o2가 존재하므로, - o1가 불필요하게 살려놓아야한다. **이런 현상이 원래 있었다.** ![](https://i.imgur.com/E4x5Mpm.png) - 이제는 이런 문제를 해결 할 수 있다. :::success 그렇다면 이제 메모리 누수를 걱정하지 않아도 되는것 아닌가? ::: ==**아니다. 약간의 부주의함으로 발생하는 경우는 아직 있다.**== <center><img src="https://i.imgur.com/72geEOz.png" width="80%" /></center> - 전역변수에 큰 데이터 - 이 전역변수는 계속 남아있기 때문에. - 클로저 - 본인이 써야하므로, 즉, 자신이 생성된 환경을 기억하기 떄문에 계속 남아있다. - 생성된 실행 컨텍스트의 변수가 해제가 안됨. ![](https://i.imgur.com/u4NfAno.png) - 위와 같이 해결은 가능하다. / 하지만 피해라! - 큰데이터가 다른 변수에서 참조 - bigData가 필요없어지더라도 다른 변수에서 참조하므로.