CSR, SSR, SSG, ISR

티스토리 뷰

🙋‍♀️ 기술면접 대비

CSR, SSR, SSG, ISR

2022. 9. 27. 16:03

정적 웹페이지

: 고정된 HTML, CSS, 자바스크립트, 이미지 등을 서버가 줘서 변하지 않는 웹페이지

ex) 단순한 정보소개 페이지

동적 웹페이지

: 게시판이나 통계페이지처럼 데이터베이스 등 계속 바뀌는 내용에 따라 사용자가 방문할 때마다 서버가 그때그때 HTML 내용들을 렌더링해서 보냄

ex) JSP, PHP

MPA

- 여러개의 페이지로 구성되어 요청 때마다 정해진 페이지를 반환한다.

- 주로 ssr 방식으로 html문서 렌더링

- 사용자가 페이지를 요청할 때마다 요청한 UI와 필요한 데이터를 서버가 HTML로 파싱해서 보여주는 방식

- 사용자가 아주 사소한 요청을 하더라도 매번 전체 페이지를 렌더링 해줘야함

- 완성된 형태의 HTML파일을 서버에서 전달받기때문에 검색엔진이 페이지를 크롤링하기 적합 -> seo관점에서 유리

- 매번 페이지 전체를 새로 불러와서 렌더링해야하기 때문에 화면이 깜빡이는 등의 성능 상 이슈 발생

- 프론트와 백이 밀접하게 연관되어 있어 개발 복잡도 증가

SPA

- 하나의 페이지로 구성되어 요청에 따라 화면을 재구성한다.

- 주로 csr 방식으로 html문서 렌더링

- SPA는 정적 웹사이트처럼 서버한테서는 똑같은걸 받아가는데 거기 있는 JS코드가 서버로부터 데이터를 요청해서 그 받아온 정보에 - 따라 브라우저가 HTML요소들을 랜더링한다.

- 페이지 이동을 해도 다른 페이지로 이동하는게 아니라 한 페이지 내에서 자바스크립트로 HTML요소들을 동적으로 바꿔주는 것

- 하나의 HTML파일을 기반으로 자바스크립트를 이용해 동적으로 화면의 컨텐츠를 바꾸는 방식

- 처음 한번만 리소스를 다운받고, 이후 새로운 요청이 들어왔을때는 필요한 데이터만 부분적으로 바꾸어준다

- 서버없이도 개발이 가능하며 디버깅이 상대적으로 쉽다.

- 로컬 데이터를 효과적으로 캐시할 수 있다. 처음 받은 데이터를 모두 로컬 캐시에 저장해놓고 오프라인에서도 사용 가능

- 초기에 앱에 필요한 모든 정적 리소스를 다 받아야하기 때문에 초기 구동속도가 느리다.

- seo관점에서 불리하다.

- 연속되는 페이지 간의 사용자 경혐을 향상시키고 웹 애플리케이션이 데스크톱 애플리케이션처럼 동작하도록 도와준다.

💡 SPA === CSR인 것은 아니다. MPA === SSR인 것은 아니다.

MPA, SPA는 웹 어플리케이션을 구성하는 형태 (페이지를 한개쓰는지 여러개쓰는지)

SSR, CSR은 렌더링 방식 (렌더링을 서버에서 하는지 클라이언트에서 하는지)

1️⃣ Server Rendering vs Static Rendering

Server Rendering

탐색에 대한 응답으로 서버에서 페이지에 대한 전체 HTML을 생성한다.

위 작업은 브라우저가 응답을 받기 전에 처리되기 때문에 클라이언트에서 data fetching 및 templating을 위한 추가적인 통신의 왕복을 방지한다.

https://web.dev/rendering-on-the-web/#server-rendering

위 링크 보고 정리하기!

2️⃣ SSR (Server Side Rendering)

- 클라이언트 측 또는 범용 앱을 서버의 HTML로 랜더링한다.

- 브라우저에서 응답을 받기 전 데이터 fetching 및 템플릿 작성이 처리되므로 클라이언트에서 추가적인 통신의 왕복이 발생하지 않는다.

- 사용자에게 보여줄 웹페이지를 서버에서 모두 구성하여 보내주는 방식이다.

SSR 동작 방식

1) 사용자가 웹페이지 방문 (request)

2) 서버가 리소스를 확인하고 페이지 내의 서버측 스크립트 실행 후 HTML컨텐츠를 컴파일 및 준비

3) 컴파일된 HTML은 추가 렌더링 및 표시를 위해 브라우저로 전송 (response)

4) 브라우저는 HTML을 다운로드하고 렌더링

5) 브라우저가 자바스크립트를 다운로드하고 실행하여 페이지를 사용자와 interactive가 가능하도록 만듬

6) 사용자가 페이지를 이동할 경우, 위 과정을 반복

장점

서버를 이용해서 페이지를 구성하기 때문에 클라이언트에서 구성하는 CSR보다 페이지를 구성하는 속도는 늦어지지만 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점은 빨라진다.
js파일을 다운로드하고 적용하기 전에 이미 브라우저에서 보여지기 때문에 초기 로딩 시간이 CSR에 비해 짧다.
seo에 사용되는 meta태그들이 미리 정의되어 SEO에 친화적이다.
사용자 정보를 서버측 세션으로 관리하기 용이하므로 CSR에 비해 보안이 우수하다.
클라이언트에서는 서버에서 완성하여 보내준 페이지만 렌더링하면 되므로 클라이언트의 부담이 CSR에 비해 덜하다.

단점

페이지를 이동할때마다 로딩 및 화면깜빡임(새로고침현상)이 발생한다.
페이지 이동 시마다 서버에서 페이지를 생성하기 때문에 TTFB가 느리다.
서버에서 렌더링까지 진행하면 서버가 담당하는 일이 많기 때문에 서버에 부하가 걸릴 위험이 존재한다.
데이터가 채워진 html문서를 화면에 띄운 다음 js를 다운받기 때문에 렌더링과 동시에 인터렉션할 수 없다.
클라이언트에서 자바스크립트로 렌더링하는 CSR에 비해 SSR은 서버에서 HTML문서를 생성해야하기 때문에 서버 호스팅이 필요하다.
페이지 이동이 있을 때마다(서버에 요청이 올 때마다) HTML파일을 생성하기 때문에 CDN수준에서의 컨텐츠 캐시가 불가능하다.

💡 SPA형태에 ssr을 지원하도록 CSR과 SSR을 적절히 혼합한 프레임워크가 Vue의 경우 Nuxt.js, React의 경우 Next.js, Gatsby.js

3️⃣ CSR (Client Side Rendering)

- 일반적으로 DOM을 사용하여 브라우저에서 앱을 랜더링한다.

- 모든 로직, 데이터 가져오기, 템플릿, 라우팅을 클라이언트에서 처리한다.

- 유저와 상호작용이 많은 경우 사용하기 적합하다.

- JS 번들 크기의 영향을 많이 받는다.

동작방식

1) 사용자가 웹페이지 방문 (request)

2) 브라우저는 최소한의 HTML파일(script, meta, link 등을 포함한 빈 컨텐츠)을 다운로드 (response)

3) 위에서 다운로드한 HTML파일에 포함된 script태그를 읽어 자바스크립트 번들 파일을 다운로드

4) AJAX를 통해 API 요청을 수행하여 동적 컨텐츠를 가져오고 파싱하여 최종 컨텐츠를 렌더링

5) 사용자가 페이지를 이동할 경우, 서버에 추가 HTML파일을 요청하는게 아니라 이미 받은 자바스크립트를 이용하여 렌더링

장점

첫 로딩 시 필요한 파일크기는 커서 초기 로딩속도는 느리지만 다 받은 후에는 동적으로 빠르게 렌더링하기 때문에 SSR에 비해 빠른 사용자 인터렉션 속도를 보여준다 (ux에 유리하다)
화면깜빡임(새로고침현상)이 발생하지 않고 부드러운 사용자 경험을 보여준다.
클라이언트 View단에서 처리할 일을 서버가 신경쓰지 않아도 된다.
js사용이 가능한 동적 html을 생성해서 보여주기 때문에 렌더링과 동시에 인터렉션 가능하다.
이미 스크립트가 캐싱된 경우, 인터넷 없이 웹 어플리케이션을 실행할 수 있다.

단점

검색 엔진 크롤러가 페이지를 처음 방문했을 때 빈페이지이기 때문에 SEO에 친화적이지 않다.
하나의 html로 모든 페이지를 구성하기 때문에 메타데이터 변경을 위한 추가적인 작업이 필요하다.
초기 페이지 로드 시간이 SSR에 비해 느리다 → 브라우저가 html, js 등을 다운로드하고 프레임워크를 실행하는 동안 사용자는 빈페이지를 보게된다
번들사이즈가 커지면 로딩 속도가 느려질 수 있다 → tree-shaking과 code-spliting에 신경써야함)
클라이언트의 하드웨어 및 소프트웨어에 많이 의존한다