웹사이트 최적화

오래되고 기능이 많은 서비스를 대상으로 해야 효과가 있다.

 

Network

자원들이 많이 쓰이는지

서버에 갔다오는 시간이 얼마나 오래 걸렸는지

 DOM content element의 로딩 시점을 알아냄

Performance -병목지점 ( 어느 부분에서 시간이 많이  소요되었는지)를 보며 성능을 측정했었다.

 

LightHouse 

로딩 속도에 대한 진단 

성능 개선의 척도가 된다

FCP : 

FMP: 

 

웹페이지의 성능을 결정하는 주요 요소

* 첫페이지가 느린 것  FCP, FMP

* 반응이 느린 것

* 끊기는 것 (애니메이션)

 

 

최적화 작업 진행 방법

진단  -> 개선 -> 테스트 -> 진단 

 

*참고) 프레임워크는 바닐라보다 더 많은 절차로 프로그래밍이 동작된다 .

 

😮 ?웹최적화에 대해서 아시는거 잇어요

Dom로딩을 빠르게 하기 위해서 JS 를 defer시에 적용해서

파일을 압축하고 머지시켜서 배포하는 등의 전략을 통해 로딩속도를 줄일 수 있다.

 

---

1️⃣  첫페이지를 빠르게  하자

* HTML Parsing 방해하지 않기

<script> body 끝에 , defer 나 async를 사용

 

*buid를 통한 코드 최적화 (파일 압축하고 머지 배포)

code obfuscation 오브스케이팅(난독화)  -> 내가짠 function이름의 글자 or 공백 등을  축소해 물리적인 사이트의 사이즈를 줄인다.

여러개 파일들을 합쳐서 배포 

 

*SSR

SPA 싱글페이지  어플리케이션 의 동작 과정

사용자 요청 ->index.html 껍데기 먼저 줌 ->  JS요청 -> JS받아왔음 -> API 요청이잇음 -> API 받아옴 -> 렌더링 함 -> 화면 보임 ( 사실 느림)

 

SSR 서버사이드 렌더링

index.html 요청 -> 어? 아까 요청했자나? cache에 넣기 -> 기다리다가 요청하면 -> 빨리 response

미리 의미있는 첫페이지를 서버에서 처리해  전달하자!

클라이언트에서 리액트로 렌더링하면, 서버에서도 리엑트로 렌더링을 해야함 -> 

❤️ 첫페이지를 빠르게 뜨게 함

❤️ SEO에 좋음

 

클라이언트 사이드 렌더링 CSR

CSR로 렌더링 -> Node.js로 연결해서 전달함 (프론트서버)

pre-rendering : build단계에서 API요청을 다 해 완성된 결과를 전달 

 

*Lazy Loading

이미지로딩은 렌더링 결정하기 때문에,  스크롤 이벤트를 방해할 수 있음

lascChild로 append를 시켜서 

ex) 100개의 이미지가 있다면 , 10개만 먼저 가져오고  -> 사용자의 스크롤 ->  그 다음에 10개 가져오고 

동적으로 script파일을 화면에 추가하는 것 

JS lazy Loading: <script 를 동적으로 화면에 넣으면  -> DOM에 추가됨 -> 바로 server에 요청 (request) -> 브라우저는 바로 실행

Image lazy Loading: <img 를 동적으로 DOM에 추가하기 ->  ''

React? -> lazy component Loading 가능!

 

Dynamic import 

동적으로 JS 중간에 코드를 import 해서 tk사용 

 

IntersectionObserver

 

 

2️⃣  느린 애니메이션의  지연을  해결하자

*메인 스레드를 blocking 하지 않기 위한 내부조치들 (Fiber architecture)

- 메인스레드가 빈 시간에 틈틈이 들어와 일을 처리함 

- Fiber architecture: 메인스레드에 방해가 되지 않도록 이미렌더링 된것과 렌더링 될것을 비교하여 새로 들어올것만 리렌더링 한다.

- React 내부에 있는 소스코드

 

* Re-rendering 최소화 (가상 DOM을 통한 베모리 단계에서의 변경사항 비교)

 

*중복계산 줄이기

React = 리렌더링이 많이 되는 구조  => 그 안의 복잡한 연산을 최소화 해야 함

Data fetching :

사용자가 어떤걸 눌르면 서버에 요청해서 가져오는 게 기본 구조이지만 ,

사용자가 일정 시간내에 중복된 data를 중복해서 요청할 경우에는 캐시에 저장해두었다가 제공하는 방법이 있음 (유효캐시시간동안)

chache then network

유효캐시시간이 끝나갈쯤에 캐시요청과 더불어 서버에도 동시에 요청하여 cache update를 실시한다.

 

*네트워크 요청 캐시하기 (Service Worker<PWA>, Cache header전략)

service Worker 일종의 cache 가로채기  - 브라우저(클라이언트 단)에서 동작함

서비스에 따라 cache정책을 세워서 따라야 한다 . (주식같은경우는 실시간으로 데이터가 변하기 때문에)

 

*복잡한 연산 위임 (Web Worker 활용)

JS는 싱글스레드지만 멀티스레드처럼 동작 가능하게 만듦

비용이 비싸고 병목현상이 뚜렷할 경우에 활용하는 것이 좋음