https://slender-danger-059.notion.site/SSR-CSR-e6005878a059468495523d6483bb3a6d
MPA vs SPA
MPA(multi page application)
여러 페이지로 구성된 웹 어플리케이션. 사용자의 인터렉션이 발생할 때마다 서버로부터 새로운 html을 받아와서 해당 링크로 이동하여 페이지 전체를 새로 렌더링하는 전통적인 웹 페이지 구성 방식.
SPA(Single Page Application)
하나의 페이지로 구성된 웹 어플리케이션. 브라우저에 최초에 한번 페이지 전체를 로드하고, 이후부터는 특정 부분만 데이터(JSON)를 바인딩하는 방식.
- TTFB (Time To First Byte)
- 페이지를 요청했을 때 서버에서 데이터의 첫 번째 바이트가 도착하는 시점.
- FCP (First Contentful Paint)
- 페이지가 로드되기 시작하고 컨텐츠의 일부가 화면에 렌더링 되는 순간.
- FMP (First Meaningful Paint)
- 브라우저가 페이지의 주요 컨텐츠들을 화면에 렌더링하기 시작하는 순간.
- TTI(Time to Interactive)
- 페이지가 완전히 상호작용(interactive) 가능한 순간.
SSR
SSR의 과정
SSR 동작 방식
- 사용자가 웹 페이지를 방문하여 서버한테 특정 페이지를 요청, 서버는 리소스를 확인하고 페이지 내에 있는 서버측 스크립트를 실행 후 HTML 컨텐츠를 컴파일 및 준비.(
request) ,컴파일된 HTML은 클라이언트 브라우저로 전송.(response) - 클라이언트에서는 해당 HTML 파일을 파싱. 그 후 필요한 정적 리소스(CSS, 이미지 등)와 자바스크립트 파일을 다운로드하며, 페이지를 렌더링.
- 클라이언트에서 자바스크립트를 다운로드하고 실행.
- 페이지 인터렉션 가능.(
interactive)
SSR 장점
- 최초 페이지 로딩 시간이 짧음
요청한 페이지에 필요한 리소스만 다운로드하여 페이지를 생성하므로 렌더링에 필요한 시간이 짧음.
- 검색엔진 최적화에 적합
서버에서 페이지를 생성하므로 검색엔진에서는 빈 HTML 문서가 아닌 완성된 HTML 문서를 수집할 수 있으므로 검색엔진 최적화에 용이하다.
SSR 단점
- 자바스크립트 실행이 완료될 때까지 인터렉션 불가
SSR 방식은 사용자가 더 빨리 페이지를 조회할 수는 있지만 자바스크립트 실행이 완료될 때까지는 클릭 등 페이지 내에서의 상호 작용이 불가능.
- 페이지 이동에 걸리는 시간이 CSR 방식보다 긺
페이지를 이동할 때마다 해당 페이지에 필요한 리소스를 다운로드하고 페이지를 다시 생성해야 하므로 CSR 방식에 비해 페이지 이동에 TTFB(Time to First Byte)가 느리다.
- 페이지 이동시 리로딩이 발생하여 화면 깜빡임
매 페이지 요청마다 전체 UI를 다시 로드하기 때문.
CSR
CSR의 과정
CSR 동작 방식
- 사용자가 웹 페이지를 방문하여 클라이언트가 특정 페이지를 요청(
request) - 브라우저는 서버로부터 받은 최소한의 HTML 파일을 다운로드(
response) (이 HTML 파일은script,meta,link등의 태그를 포함하며, 빈 컨텐츠의index.html.) - 브라우저는
index.html에 있는자바스크립트 번들 파일및 정적 리소스(이미지, CSS 등)를 다운로드. - 페이지 렌더링이 완료된 후,
API요청을 수행하여 동적 컨텐츠를 가져오고 파싱하여 최종 컨텐츠를 렌더링. - 사용자가 페이지를 이동할 경우, 서버에 추가 HTML파일을 요청하지 않고 이미 받은 자바스크립트를 이용하여 렌더링.
CSR 장점
- 페이지 이동에 걸리는 시간이 짧음
페이지 렌더링에 필요한 정적 리소스와 번들 자바스크립트 파일은 최초 페이지 접근 시에만 다운로드하고, 이동할 페이지에 필요한 부분만 추가로 요청하므로 페이지 이동에 걸리는 시간은 짧다.(처음 렌더링때 사전에 로드되었기 때문)
- 데이터 응답을 받아올때까지 빈화면(or 로딩) (장점?)
CSR 방식은 번들 자바스크립트 실행이 완료된 후, API 응답을 받아오기 전까지는 빈 화면(혹은 별도로 설정한 로딩 화면)이 표출된다. 그리고 API에서 데이터를 받아온 후 화면에서 인터렉션이 가능.
(화면은 보이지만 인터렉션이 되지 않는 경우보다는 아예 화면이 렌더링되지 않는 편이 사용자에게는 더 직관적일 수 있다고 생각.)
CSR 단점
- 최초 페이지 로딩 시간이 SSR보다 오래 걸림.
브라우저에 HTML 파일이 전송되기까지의 시간(TTFB)은 짧지만, 렌더링에 필요한 리소스와 번들 자바스크립트 파일을 다운로드 한 후 화면을 그리는 데 걸리는 시간이 길기 때문에 전체적인 렌더링 완료 시간은 오래 걸리게 된다. 따라서, 코드 스플리팅 등을 통해 번들 파일의 용량을 줄이는 것이 좋음.
- 검색엔진 최적화에 적합하지 않음.
검색 엔진 크롤러가 해당 페이지에 처음 방문했을때는 빈 페이지이기 때문에 이해할 수가 없다. 물론 자바스크립트를 실행시킬 수 있는 구글 크롤러와 같은 검색엔진 크롤러가 등장.
→ DOM에 직접 접근하여 메타 태그 등을 바꿀 수 있는 라이브러리(react-helmet)가 있지만, 아직 많은 검색 엔진 크롤러들이 지원되지 않음.
SSR ? CSR?
- 유저랑 상호작용이 많다.
- 고객 개인의 정보로 이루어진 페이지들이라 검색 엔진에 노출될 필요는 없다.
→ CSR
- 누구에게나 항상 같은 내용을 보여준다.
- 회사 홈페이지 등 PR이 필요한 페이지
- 업데이트를 자주 한다.
→ SSR
SSR이지만 업데이트를 거의 안한다면,
SSG(Static Site Generator)
SSR처럼 서버로부터 완성된 HTML을 받아오지만, 다른 점은 HTML 파일의 생성시점이 빌드 타임. 즉, 각페이지의 HTML, JS, CSS를 빌드함으로써 모든 URL별 파일을 생성.
React의 경우 Next.js, Gatsby.js에서 제공
SSG 동작 방식
- 사용자가 웹 페이지를 방문하면(
request), 엣지 캐싱(edge caching)된 HTML 클라이언트로 반환해 준다. - 브라우저는 HTML을 다운로드하고 최종 사용자가 사이트를 볼 수 있도록 한다.
SSG 장점
- 응답 속도가 빠름
빌드 타임에 이미 HTML 파일이 생성됐기 때문에 빠른 FP, FCP, TTI를 제공.
SSG 단점
- 빌드의 귀찮음
• 이미 만들어져있는 페이지기 때문에 만약 업데이트하고자 한다면 다시 빌드시켜야 함.
