목차
1. SSR
2. SSG
3. CSR
4. Next.js
5. 렌더링 과정 정리
클라이언트-서버 간의 HTML문서를 요청하고 받는 과정에서, 이 HTML 문서를 클라이언트 사이드에서 렌더링 할 것인지, 아니면 서버 사이드에서 렌더링 할 것인지로 나눌 수 있습니다.
먼저 서버 측에서 렌더링 하는 과정을 알아보겠습니다.
1. SSR (Server-Side Rendering)
SSR은 서버에서 페이지를 렌더링하는 방식으로, 서버 측에서 웹 페이지의 내용을 생성하여 클라이언트(브라우저)에 전달하는 웹 개발 방식입니다.
SSR를 지원하는 프레임워크나 프로그래밍 언어의 예시로는 Next.js, Angular Universal, Gatsby, Express.js, PHP 등이 있습니다.
1-1. SSR의 장점
SSR의 장점을 살펴보겠습니다.
1) SEO : SSR은 초기 로드 시 서버에서 전체 페이지의 HTML을 생성하기 때문에 검색 엔진이 웹페이지를 크롤링하기 쉽습니다.
2) 첫 페이지 로딩 속도가 빠름 : SSR은 서버에서 페이지의 초기 렌더링을 처리하기 때문에, 클라이언트가 요청하는 페이지를 미리 렌더링 된 HTML로 제공하여 초기 로딩 속도가 빠릅니다.
이로 인해 사용자 경험을 향상시킬 수 있습니다. 따라서 모바일 사용자나 저속 인터넷 연결에도 잘 전달하기 때문에 사용자 경험이 향상됩니다.
1-2. SSR의 단점
그러나 SSR은 초기 로드 시 서버에서 HTML을 생성하므로 이에 따른 단점도 존재합니다.
1) 서버 부하: 서버측에서 렌더링하기 때문에 서버 부하가 증가할 수 있습니다. 많은 사용자가 한꺼번에 페이지를 요청한다면 서버의 성능에 좋지 않은 영향을 줄 수 있기 때문에 서버 성능 최적화가 필요합니다.
2) 인터렉션의 한계 : SSR은 초기 렌더링 시에만 서버에서 페이지를 생성하기 떄문에 사용자와의 상호작용적인 요소 (이벤트에 따른 동작)은 클라이언트에서 추가 처리가 필요합니다.
이는 CSR에 적합하기 때문에 인터렉션이 많다면 CSR 개발 방식을 주로 사용하고 있습니다.
3) TTV 와 TTI 사이의 간극 : 사용자는 초기 로드 시 렌더링 된 페이지를 볼 수는 있지만 아직 이벤트를 일으키는 등 인터렉션은 할 수 없습니다. 이를 Time to view 와 Time to Interact의 갭이 크다고 표현합니다. 초기 렌더링 후 클라이언트에서 js 를 다운로드 하고 실행해야 페이지 인터렉션이 가능해집니다.
4) 페이지 이동 시간의 증가 : 페이지를 이동할 때 마다 페이지에 필요한 리소스를 다운로드하고 생성하기 때문에 CSR 방식에 비해 이동 시간이 더 깁니다.
5) 화면 깜빡임
2. SSG (Static-Site Generation)
SSG란 Static-site generation의 약자로, CSR 과 SSR의 단점을 보완하기 위해, 즉 더 매끄러운 서비스를 위해 미리 서버에 화면을 저장해두었다가 꺼내쓰는 방식입니다. 이 정적 사이트의 생성은 빌드 시 pre-rendering을 통해 페이지별로 각각의 HTML 문서를 미리 가지고 있다가, 서버로 요청이 들어올 때 알맞은 페이지를 반환해줍니다.
이를 통해 SSR의 초기 로딩 속도와 SEO의 이점을 유지하면서도 동적인 기능을 사용할 수 있다는 장점이 있습니다.
위 사진은 pre-rendering을 설명하고 있습니다. 여기서 Hydration이란 사전에 생성된 정적 페이지를 클라이언트 측에서 동적으로 변환하는 과정을 의미합니다.
pre-rendering은 SSR 방식을 SPA에 적용해 CSR의 단점을 보완하기 위한 것인데 대표적으로 Next.js가 리액트를 기반으로 이 방식을 지원하고 있습니다. 아래 4장에서 더 자세히 살펴보겠습니다.
그 전에, 가장 많이 사용되고 있는 CSR을 살펴보겠습니다.
3. CSR (Client-Side Rendering)
CSR은 클라이언트(브라우저)에서 웹 페이지의 렌더링을 처리하는 웹 개발방식 입니다.
3-1. CSR의 장점
1) 초기 로딩 이후의 빠른 상호작용: 클라이언트에서 동적으로 필요한 데이터만 가져와서 렌더링하기 때문에 상호작용과 응답성이 빠릅니다.
2) 서버 부하 분산: 서버에서 초기 렌더링을 처리하므로 서버의 역할이 단순화되고 처리량이 줄어 서버 부하가 SSR 보다 상대적으로 적습니다. 네트워크 사용량도 줄어듭니다.
3) 페이지 이동 시간 단축 : 초기 로딩 시 정적 리소스와 번들 자바스크립트를 다운로드 하기 때문에, 그 이후 이동할 페이지에 대한 필요한 부분만 추가로 요청한다.
4) 화면 깜빡임이 없음
=> 사용자 인터렉션이 중요한 페이지라면 SSR보다 CSR이 더 적합함!
3-2. CSR의 단점
1) SEO 제한: 초기 HTML은 매우 간결하고 비어있는 상태입니다. 따라서 검색 엔진 크롤러가 콘텐츠를 인식하기 어려워 검색 엔진 최적화가 매우 제한되어있습니다.
2) 최초 페이지 로딩 시간 지연 : 브라우저에 HTML 파일이 전송되기 까지는 빠르지만, 렌더링에 필요한 리소스와 자바스크립트 번들을 다운로드 한 후 화면에 그리는데 걸리는 시간이 깁니다.
3-3. CSR의 단점 보완 방법
대부분의 앱이 이 CSR 방법을 적용하고 있기 때문에 이를 기반으로 보완하는 방법을 사용하는 것이 필요합니다. 단점을 보완할 수 있는 방법은 아래와 같습니다.
1) code splitting | tree-shaking | chunk 분리 등을 통해 js bundle 크기를 줄여 초기 로딩 속도를 보완하기
2) pre-rendering : 웹 라이브러리나 웹팩 플러그인을 통해 각 페이지에 대한 html 파일을 미리 생성해 둔 뒤 , 크롤러가 페이지 소스를 요청한다면 사전에 렌더링 한 html 페이지를 보여주는 방식 적용하기
3) SSR, SSG 도입: 현재 사용하고 있는 SPA에 SSR과 SSG를 함께 도입하기
3번에 대해 자세히 살펴보면 프레임워크 없이 도입하는 방법이 있고 그렇지 않은 방법이 있습니다.
.
.
.
CSR + SSR/SSG = ?
프레임워크 없이는 express.js나 nest.js 를 도입해 별도의 서버를 운영해주는 방법이 있는데, 특히 express.js는 서버에서 라우팅을 설정하거나 이벤트 핸들러 함수를 서버측에서 렌더링할 수 있습니다. 또한 React 컴포넌트를 HTML 문자열로 변환할수도 있어 SEO의 향상을기대할 수 있지만 서버 환경 구축이나 빌드 등의 작업이 어렵기 때문에 프론트엔드 개발자에게는 진입장벽이 있다고 할 수 있습니다.
그렇기 때문에 보다 쉽게 적용하기 위해 도입된 프레임워크들이 있습니다. React 에서는 Next와 Gatsby가 있고, Vue에서는 Nuxt가 있습니다.
서버사이드 렌더링과 간편한 라우팅, 간결한 개발 환경과 배포 등으로 많은 인기를 얻고 있는 프레임워크인 Next.js를 알아보겠습니다.
4. Next.js
Next.js는 브라우저에 렌더링할 때 기본적으로 pre-rendering을 지원합니다. 이 프레임워크를 사용하지 않은 원래의 리액트 앱의 CSR 방식은 번들링 된 js가 클라이언트에서 모든 추가 렌더링을 담당했지만, 이 Next.js를 사용하면 앱 빌드 타임 때 해당하는 페이지 별로 각각의 HTML 문서를 미리 생성해 보관하게 됩니다. 그러다가 서버로 요청이 들어올 때 알맞은 페이지를 반환해줍니다.
이렇게 빌드 때 페이지별 HTML이 생성되고 request 가 들어올 때 마다 재사용됩니다. 따라서 응답 속도가 매우 빠르다는 장점이 있지만, 데이터의 변동이 빈번하게 일어난다면 pre-rendering 방식을 취하지 말고 기존 리액트 처럼 필요할 때 data를 fetch 해 그때마다 렌더링 하는 것이 더 나을때도 있습니다.
그러나 만약 작업하고 있는 프로젝트에 속한 페이지가 퍼포먼스에 집중되어있는 페이지이거나 마케팅, 블로그 게시물, 제품목록 등과 같이 정적으로 생성해 반환해도 문제가 없다면 static page가 훨씬 빠르고 효율적일 것입니다.
Next.js는 페이지별로 SSR과 SSG를 나눠서 세분화하여 제공하고 있기 때문에 웹개발자들이 선호하고 있으며 프론트엔드 기술에서 필수적으로 공부해야할 부분이 되었습니다.
5. 렌더링 과정 정리
1) CSR
CSR은 위 사진 처럼 javascript 파일을 받고 실행하기 전 까지는 (api로 데이터를 가져오는 등의 상황에서) 웹페이지를 보여주지 않기 때문에 UX에 훨씬 좋다는 장점을 가지고 있습니다.
반대로 SSR은
HTML을 구성하면서 필요한 데이터를 fetch하고, 브라우저에 웹사이트를 렌더링 하면 유저가 사이트의 생김새를 볼 수 있지만 인터렉션 할 수는 없습니다. 아직 js를 실행하지 않았기 때문이죠
그러나 UX 관점에서 봤을때 웹페이지를 아직 동적으로 실행할 수 없다면(이벤트에 응답할 수 없다면) 아예 보여지지 않는 편이 낫습니다.
정리하자면 Next.js 와 같은 프레임워크를 통해
1. SEO 적용 또는 pre-rendering이 필요없고 user interaction이 빈번하거나 데이터 fetch가 많다면 CSR을 적용하기
2. Static 문서로 충분하면서 빠른 문서 반환이 필요하다면 SSG 방식을 적용하기
3. 매 요청마다 화면이 달라지면서 서버사이드로 렌더링하고 싶다면 SSR을 적용하기
이러한 기능을 다양하게 적용해주면 됩니다.
:)
Reference:
https://www.youtube.com/watch?v=YuqB8D6eCKE&t=3s
https://guiyomi.tistory.com/125
추가 공부할 것
[Web] 🗂프론트엔드에서 번들링이란? / 🛠Webpack
↑ 위 사진은 초등학교 입학을 위한 제품 번들이다. 이런식으로 어떤 제품을 묶음으로 판매하는 것을 '번들링'한다고 한다.그럼 웹 개발을 할 때 '번들링'을 한다고 하면 무슨 의미일까?(참고로
velog.io
'Computer Programming > CS' 카테고리의 다른 글
| CPU와 메모리 그리고 M1, M2 chip (0) | 2023.07.07 |
|---|---|
| 인증/인가 (세션, 토큰, JWT) (0) | 2023.07.05 |
| 'www.google.com'을 브라우저 주소창에 입력하면 일어나는 일 (웹의 동작 방식) (0) | 2023.07.03 |
| 자바스크립트의 클로저 동작 방식 (렉시컬환경과 렉시컬 스코프) (0) | 2023.06.21 |
| [DB] SQL 과 NoSQL의 차이 (MySQL vs MongoDB) (0) | 2023.05.10 |
