FE_최적화

최적화란?

만들어진 동작에 대해 데모하면서 속도 등을 체크해야 한다.

웹사이트 최적화 방법 베스트 : 아무것도 x 현실베스트 : 덜 일한다

—

첫페이지 왜 이렇게 느림?

first contentful paint
first meaningful paint 왜이렇게 늦게 반응함? 왜이렇게 끊김?(애니메이션)

-> 첫페이지 로딩을 빠르게 하기, 반응성올리기, 부드럽게 ㅣㅇ어져보이기 ——

lighthouse라는 것을 사용해서 성능 점수를 매길 수 있다!! 이걸 보고서 공부하는 것도 좋음 - 웹성능을 판단하는 기준이 나와있음 (클릭반응시간, 첫화면 시간 등)

개발자도구 Performance 탭에서 컨텐츠를 가져오는데까지 얼마나 시간이 걸리는지 정량적으로 확인 가능 병목시간도 알 수 있음 (어떤 함수에서 얼마나 느리게 걸리는지 확인가능(CallTree)) 의미있는 화면단위로 보면 좋아요

첫페이지 빨리 / 반응성 빠르게 / 부드럽게~ 성능개선의 핵심은 UX~!!! (인터랙션 순서나 동작방식보다는 성능!!)

—

최적화 작업 진행 순서

진단- 어디가 왜 얼만큼 느린가?(Performance, lighthouse)
개선
테스트- side effect는 없는가?
진단 -어디가얼만큼 빨라졌는가?

——

모던 웹 개발에서의 최적화 요약

돔 파싱 방해하지말기 : 자바스크립트 코드를 html 중간에 넣지 x
빌드를 통한 코드 최적화(압축, 파일 합치기) : 프로덕션을 보면 웹팩에 난독화 개발자 옵션의 소스코드처럼... (옵스케이팅) 코드를 줄이는 것 파일을 머지해서 리퀘스트를 줄이고 소스의 공백을 없애서 파일의 용량을 줄이는 방법들 등을 사용함. 웹팩의 플러그인 있으니 찾아보자. 기본중의 기본임.
첫페이지 느린 이유는 리퀘스트를 보내고 서버에서 응답값을 줬어(빈페이지) 이제 다시 자바스크립트 코드 해석하고 패치 요청을 함. 이걸 줄이려면 ssr을 해야하는데..
ssr이 필요한 이유는 첫페이지 때문. 리퀘스트 보낼때 이미 서버에서 만들어진 Html을 보낼게. 리퀘스트 보내고 html받아와서 렌더링 끝. 근데 페이지 단위 개발 아님? 맞앗 ㅓ벗에서 렌더링 하는거.
근데 이걸 더 빠르게 하려면 pre-rendering이 있음. 이거도 ssr으 ㅣ한축. 첫페이지는 어차피 변하지 않아! 빌드단계에서..! 렌더링할 html을 미리 만드는 것.사용자 요청이 오기도 전데!
근데 번거롭죠. 리액트 용으로 렌더링할 결과를 만들어서 클라이언트에게 줘야하는데...
야 그러면 서버사이드 렌더링 용 서버를 만들어! (노드) 클라이언트 서버를 만든다거나 그런일들을 그떄 사용 지옥으로 가는 길
SSR은 꼭 필요할 때만 하세요!!
Lazy Loading : 게으른 로딩. 첫페이지가 하얗지만 프로그레스 바가 진행되는 걸 보여주면 사용자 입장에서는 훨씬 나음.... 안심을 주는 것!!

리플로우 / 리페인팅 : 이런것들을 안하는게 좋음 reflow 일으키는 css 속성은? 검색해서 막는게 중요.

라이브러리는 별도의 파일로 분리하고 서비스 파일은 따로 분리 (웹팩의 split chunk) 배포되는 번들을 여러개로 나눠서! 서비스 코드는 업데이트 될때마다 보내기

리렌더링 최소화

중복계산 줄이기

네트워크 요청 캐시하기

다이나믹 임포트 ( 레이지 컴포넌트를 그때 가져올 수 있음) 리액트 레이ㅣ지

리액트 메모, 리액트 콜백

fetch Data 캐시

어떤 방법이건 저장을 해두고 유효한 시간 내에 다시 받아오면 된다!!

useSWR 이나 리액트 쿼리를 사용하면 파워풀하고 성능좋은 캐싱 작업을 할 수 있따!!!! 보니까 안쓸 이유가 없다!

캐시 전략 - useSWR

근데 둘을 무조건 써야하는건 아님. 코드가 지저분해지고 얼마나 효과있윾ㄹ까? 하는 의문 있긴함 그래도 알고는 있어야죠 몇군데에 한번 사용해보세요