🔍 CSR(Client Side Rendering)

클라이언트(브라우저)에서 웹 페이지를 렌더링하는 방식

1. 브라우저가 웹서버에 요청
2. 웹서버는 비어있는 HTML문서(index.html)를 반환(HTML문서가 비어있기 때문에 처음에 접속하면 빈 화면이 보임)
3. HTML문서에 있는 어플리케이션 자바스크립트 링크를 참고하여 웹 서버로 부터 자바스크립트 파일을 다운받는다.
4. 추가로 필요한 데이터가 있다면 서버에 요청해서 받아온다.
5. 이것들을 기반으로 사용자에게 화면을 보여준다.

자바스크립트 파일에는 어플리케이션을 구성하는 로직, 라이브러리, 프레임워크를 포함 ex) react, vue, angular) 따라서 다운로드 받는데 많은 시간이 소요된다.

📌 단점

• 브라우저에 첫화면이 표시되기까지 많은 시간이 소요.(그동안 사용자는 빈 페이지를 보게 되므로 ux가 좋지 않다.)
• SEO(Search Engine Optimization)가 좋지 않음. (브라우저의 검색엔진은 HTML문서를 보고 웹 크롤링을 하게 되는데 HTML문서가 바어져 있기 때문이다.)

🔍 SSR(Server Side Rendering)

클라이언트에서 모든걸 처리하는 방식과는 다르게 서버로부터 완성된 HTML문서를 받아온다.(HTML문서 + 동적으로 처리 가능한 소스코드) 문서를 받은 클라이언트는 사용자가 화면을 바로 볼 수 있게 브라우저에 띄어준다. CSR 방식처럼 서버에 두번 요청하는 것과 같은 번거로움이 없다.

📌 단점

• 사용자가 클릭을 했을때 전체적인 웹사이트를 서버에서 받아온다.(깜빡임 이슈가 나타난다 -> 좋지않은 ux)
• 서버에 과부화가 걸리기 쉽다. 사용자가 많을 수록 사용자가 클릭할때 서버에서 데이터를 가져와야 하기 때문이다.
• 사용자가 빠르게 웹 사이트 화면을 볼 수 있지만, 동적으로 처리가능한 자바스크립트를 다운받지 않아 반응이 없을 수 있다 (처음 HTML문서를 받았을때 TTV가 먼저 일어나고 이후 클릭을 했을때의 서버로부터 클릭에 대한 처리 코드를 받음으로써 TTI가 일어난다. 따라서 TTV와 TTI의 공백이 길다.)

TTV(Time To View) 사용자가 웹 사이트를 볼 수 있는 시간 TTI(Time To Interact) 클릭 or 인터렉션이 가능하게 되는 시간

🔍 SSG(Static Site Generation)

모든 유저에게 동일한 화면으로 보일 수 있는 페이지는 매 번 동적으로 생성하게 되며 비효율적이다. 즉, 한번만 생성한 이후 CDN에 저장해두고 필요할 때마다 로드 하면 된다. SSG는 정적으로 웹 페이지를 빌드시 미리 생성해 두어서 서버에 베포해 놓은 방식으로 빠른 정적 렌더링이 가능한다. 웹 페이지들은 추가적으로 서버에서 데이터를 받아 오거나 동적으로 처리해야하는 로직이 있다면 자바스크립트 파일을 함께 가지고 있기 때문에 모든 페이지가 정적이 아닌 셈이다. SSG는 쇼케이스 웹사이트 처럼 내용이 거의 변하지 않는 웹 사이트에서만 사용된다. React의 경우 Next.js와 Gatsby.js에서 SSG을 제공해 준다.

📌 장점

• SEO에 친화적 (이미 생성된 파일을 전달하는 방식이기 때문이다.)
• 정적 사이트는 미리 만들어져서 사용자에게 제공될 준비가 되어 있기 때문에 가장 빠른 웹 페이지이다.

🔍 ISG(Incremental Static Regeneration)

ISG도 SSG와 같이 빌드 시에 구성된 데이터를 기반으로 페이지를 작성하고 보여준다. ISG는 SSG와 달리 콘텐츠를 업데이트 했을 때 전체 사이트를 재빌드할 필요 없이 페이지별로 정적 생성을 사용할 수 있다. 그리고 설정된 시간이 지나면 자동으로 재빌드 하고 데이터를 업데이트 한다. ISG는 SSR과 SSG의 장점을 합쳐져 있는 방식으로 매우 효과적이다. (블로그와 같이 자주 변경되지 않는 사이트에 사용)

📌 장점

• SSG와 동일하게 ISR도 페이지를 미리 렌더링하고 캐시하기 떄문에 매우 빠르다.
• SEO에 친화적
• 내용이 변경되어도 사이트를 다시 베포할 필요가 없다.

🔍 SPA(Single Page Application)

하나의 Page로 구성된 Application이다. CSR의 렌더링 방식을 이용한다. ❗️but, 모든 SPA가 CSR 방식을 이용하는 것은 아니다. ❗️기본적으로 (react, vue, angular)가 있고 특히 react는 Next.js와 Gatsby.js에서 SSG을 제공하기 때문에 모든 SPA가 CSR 방식이 아니다.

처음 요청시 딱 한 페이지만 불러오고 페이지 이동 시 기존 페이지의 내부를 수정해서 보여주는 방식이다.(ajax의 방식으로 부분만 렌더링해주는 느낌이다.) 첫 페이지를 로딩한 시점에서 페이지 리로딩 없이 추가로 필요한 데이터만 서버로 부터 받아온다.

AJAX(Asynchronous JavaScript And XML) 서버와 통신하기 위해 XMLHttpRequest 객체를 사용하는 것을 말한다. JSON, HTML, XML, 텍스트 형식등의 다양한 포멧을 데이터를 주고 받는다. AJAX는 비동기성으로 전체페이지를 업데이트하지않고 일부분만 업데이트가 가능하게 해준다. 이는 좋은 ux 제공한다.

📌 장점

• 필요한 리소스만 부분적으로 로딩 클라이언트가 처음요청한 정적리소스와 받은 데이터들은 모두 캐시에 저장한다.

  📌 단점

• JavaScript 파일을 번들링해서 한 번에 받기 때문에 초기 구동 속도가 느리다. (Webpack의 code splitting으로 해결 가능)
• 검색엔진최적화(SEO)가 어려움 (SSR로 해결 가능)
• 보안 이슈 (프론트엔드에 비즈니스 로직 최소화) SSR에서는 사용자에 대한 정보를 서버측에서 세션으로 관리를 하지만 CSR 방식에서는 클라이언트측의 쿠키말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않다.

Code Splitting이란? code splitting의 기능으로 런타임시 동적으로 로드할 수 있는 여러 번들을 만들 수 있다. 사용자가 현재 필요로하는 것들만 lazy-load할 수 있으므로 앱의 성능을 크게 향상시킬 수 있다. 앱의 전체 코드 양을 줄이지는 않지만 사용자가 필요로하지 않은 코드를 로드하는 것을 피하고, 초기 페이지 로드시 필요한 코드만 받게 됩니다.

🔍 MPA(Multiple Page Application)

여러 개의 Page로 구성된 Application이다. MPA은 SSR렌더링 방식으로 이용한다. 새로운 페이지를 요청할 때마다 서버에서 렌더링된 정적 리소스가 다운된다. 페이지를 이동하거나 새로고침을 하면 전체 페이지를 다시 렌더링한다. ❗️ SSR과 장단점이 같다. (+단점: 페이지 이동시 불필요한 템플릿도 중복해서 로딩하므로 성능이 떨어진다.)

SPA와 MPA의 차이