브라우저 렌더링 CSR와 SSR

 

최근 클라이언트 사이드 렌더링(CSR)을 기반으로 발전해온 프론트엔드 개발에서 

이 CSR의 단점을 보완하기 위해 과거의 전통적인 웹 동작 방식인 서버 사이드 렌더링(SSR)을 채택하는 경우가 많아졌습니다.

 

 

 

리액트를 사용하여 웹 프론트엔드 개발을 할 때, CSR 방식으로 개발이 가능하고

Next.js, Remix 등의 프레임워크를 사용하거나 환경세팅을 통해 SSR 방식으로 개발이 가능합니다.

 

 

---

1. WEB

 

먼저 웹의 역사를 살펴봐야 합니다. 1990년 중반까지는 대부분의 웹이 정적 사이트로

정해진 url로 접속하면 서버의 html 문서를 받아와서 보여주는 형식이였습니다.

 

즉,  페이지 안에서 다른 링크를 클릭하면 다시 서버의 해당 html 문서 받아왔습니다.

 

1998년, XMLHttpRequst의 등장으로 JSON과 같은 형식으로 서버에서 필요한 데이터만 받아올 수 있게 되었습니다. 

 

이런 방식이 2005년  AJAX라는 이름을 가지고 되고,

이것이 현재 널리 쓰이고 있는 SPA(싱글페이지 어플리케이션)입니다. 

싱글 페이지 애플리케이션 - 위키백과, 우리 모두의 백과사전

 

이런 SPA 트렌드, PC의 고성능화, JS표준화 등으로 

개발 커뮤니티 기반 React, Vue, Angular와 같은 프레임워크가 등장하였습니다. 

 

이것이 CSR이 프론트엔드 개발에서 주를 이루게 되었고,  크게 기술의 도약을 가져왔습니다.

 

하지만 이 CSR에도 문제점들이 있었기 때문에,

전통적인 웹 동작 방식인 SSR을 다시 채택하는 경우가 늘어나게 되었습니다.

 

클라이언트에서 모든 방식을 처리하지 않고 서버에서 필요한 데이터를 모두 가져와서 html파일을 

클라이언트에게 보내주게 됩니다.

 

 

그러면 이 SSR이 모든 솔루션인가?

 

아래에 기술할 부분과 같이 SSR에도 문제점이 존재하였는데, 결국 웹 개발에 있어서는

TTV, TTI 등의 성능을 고려해야 하고 상황에 맞게 적절히 관리할 수 있도록 해줘야 합니다.

 

 

즉,

CSR의 경우 TTV까지 시간이 걸리므로 사용자에게 최종적으로 번들링해서 사용자에게 보내주는

js파일을 효율적으로 분할하여 정말 필수적인 부분만 보내는 것 등을 고려해야하고

 

SSR의 경우 TTV이후 TTI까지 시간 단차를 줄이기 위한 노력을 해야 할 것 입니다.

 

---

웹사이트 성능 분석시 TTV와 TTI도 중요한 요소로 사용됩니다. 

 

TTV(Time To View) 사용자가 웹사이트를 보는데까지 걸리는 시간 

TTI(Time To Interact) 사용자가 클릭을 하거나 인터렉션이 가능하게 되는데 걸리는 시간

 

 

 

 

2. CSR ( Client Side Rendering)

클라이언트 사이드 렌더링은 SPA로, 클라이언트인 브라우저가 렌더링을 처리하는 방식입니다.

클라이언트 사이드에서 HTML을 반환한 후에 JS가 동적으로 데이터를 주고받으며 클라이언트에서 렌더링을 진행합니다.

점점 복잡해지는 웹페이지를 구현하기 위해서 전통적인 방식의 SSR보다는 CSR로 웹을 구현하는 경우가 많아졌습니다.

 

 

작동 과정 :  사이트 접속 -> 빈 HTML 요청 / 다운 -> JS 요청 / 다운 -> JS 실행 ->  데이터를 서버로 받음 -> Content 확인

 

 

 

장점

1. SSR 보다 조금 더 빠른 인터랙션(TTI)이 가능 (웹 기능 눌렀을 때 반응)

2. 모바일 네트워크에서도 빠른 속도로 렌더링이 가능

3. lazy loading 지원 (페이지 로딩 시 중요하지 않은 리소스의 로딩을 늦추는 기술)

 

단점

1. Googlebot과 Searchconsole 등에 검색 노출이 되지 않음 (빈 html 가져와서 검색에는 뜨지 않음)

2. 사용자가 처음으로 컨텐츠를 볼 수 있는 시점(TTV)까지 속도가 느림 

 

 

 

 

3. SSR ( Server Side Rendering)

서버사이드 렌더링은 서버에서 렌더링을 작업하는 방식입니다.

 

전통적인 웹 어플리케이션 렌더링 방식으로 사용자가 웹 페이지에 접근할 때, 

서버에 각각의 페이지에 대한 요청을 하면 html, js 파일 등을 다 다운로드해서 화면에 렌더링하는 방식

 

 

작동 과정 :  사이트 접속 -> 서버에서 만든 HTML 요청 / 다운 -> JS 요청 / 다운 -> Content 확인

 

 

 

 

장점

1. 사용자가 처음으로 컨텐츠를 볼 수 있는 시점(TTV)을 앞당길 수 있음

2. 검색엔진최적화(SEO) 적용 가능

 

단점

1. 사용자의 모든 요청에 관해 필요한 부분만 수정하는 것이 아닌, 완전히 새페이지를 로딩(새로고침)

2. 전체를 로딩하다보니 CSR보다 느리고, bandwitdh를 많이 쓰고, 사용자 경험 좋지 않음

(사용자가 처음으로 컨텐츠를 볼 수는 있으나, 화면단에는 html요소들이 나오나 js파일이 다 다운로드 되지않아서 버튼이 클릭되지않는 등의 현상이 있을 수 있음)

 

 

 

 

 

4. SSG (static site generation)

 SSG는 웹 애플리케이션의 각 페이지를 사전에 렌더링하여 정적 HTML 파일로 만듭니다. 이러한 렌더링은 개발자가 정의한 데이터나 콘텐츠를 포함한 페이지를 미리 생성하는 것을 의미합니다.

 

SSG로 생성된 정적 파일들은 웹 서버에 배포되어 사용자에게 제공됩니다. 이때, 서버는 동적 데이터베이스 쿼리나 계산을 필요로 하지 않으며, 단순히 미리 생성된 정적 파일을 반환합니다. 또한 캐싱으로 여러 사용자에게 재사용될 수 있습니다. 이를 통해 반복적인 렌더링 작업을 피하고, 사용자에게 더 빠른 페이지 로딩 속도를 제공할 수 있습니다.

 

이를 통해 빠른 초기 로딩 속도, SEO최적화, 서버부하 감소, 보안 등의 이점을 가질 수 있습니다.

 

 

 

 

 

여기서 SSR과 SSG의 방식의 차이가 헷갈렸는데, 요약하면 아래와 같습니다.

 

SSR

사용자가 웹 페이지에 접속하면, 서버는 해당 페이지의 렌더링을 처리합니다. 서버는 필요한 데이터를 가져와서 페이지의 HTML과 함께 사용자에게 전송합니다. 사용자의 브라우저는 이를 받아서 렌더링한 후, 사용자는 초기에 완전히 렌더링된 페이지를 볼 수 있습니다.

 

SSG

개발자가 웹 애플리케이션의 각 페이지를 사전에 렌더링합니다. 사전 렌더링된 페이지들은 정적인 HTML 파일들로 생성됩니다. 이렇게 생성된 정적 파일들이 웹 서버에 배포되어 사용자에게 제공됩니다.

 

 

 

따라서, SSR과 SSG는 렌더링 시점과 방식에서 차이가 있다는 것을 알 수 있습니다.

 

 

 

 

 

 

 

참고자료

(번역)도대체 SSG가 뭘까요? Next.js로 설명하는 정적 사이트 생성

Static Site Generator | Gatsby