여러 개의 페이지로 구성된 어플리케이션.
새로운 페이지를 요청할 때마다 서버에서 렌더링된 정적 리소스(
HTML
,CSS
,JavaScript
)가 다운로드된다.
페이지 이동하거나 새로고침하면 전체 페이지를 다시 렌더링한다.
HTML
파일을 서버로부터 전달받는다. 따라서 검색엔진이 페이지를 크롤링하기에 적합 → SEO
측면에서 유리함JS
파일을 들고오기 전에 기능이 작동하지 않음한 개의 페이지로 구성되어 있는 어플리케이션.
사이트 최초 진입시에만 모든 리소스를 받아오고 이 후 데이터를 Fetch할 때만 서버와 통신
즉, Virtual Dom에 의해 필요한 부분만 갱신
사용자의 브라우저에 띄울 화면은 서버에서 렌더링을 한 이후에 완성된 페이지를 응답하게 됨
페이지 진입 시 최초에 한번만 모든 리소스를 클라이언트 측에 전달하고, 해당 리소스들을 통해 클라이언트 측에서 렌더링을 진행하는 방식
위에서 알아본 것 처럼 SPA가 등장하고 그 특성때문에 CSR을 많이들 사용하게 되었다.
다만 위에서 서술했던 것 처럼 초기에 많은 리소스를 받아와야 하기 때문에 페이지 초기 진입시 사용자에게 불편한 경험을 줄 수 있다는 것과 SEO(Search Engine Optimization)
에 유리한 점을 가지는 SSR을 고려하게 된다.
일반적인 검색엔진 봇이 SPA 어플리케이션의 페이지를 볼 때 아래 코드와 같은 소스를 보게 된다.
<html>
<head>
<title>Single Page Application</title>
<link rel="stylesheet" href="app.css" type="text/css">
</head>
<body>
<div id="app"></div>
<script src="app.js"></script>
</body>
</html>
모든 페이지의 코드가 위와 같다면 페이지의 색인이 될만 한 정보가 없게된다.
‼️ 유진님이 지난 번에 주셨던 질문
index.html
에 meta정보를 담을 수 있다고 하더라도 그 방대한 양을 다 담기도 어려울 뿐만 아니라, 담아도 페이지의 구별력이 떨어짐위에 서술한 맹점을 극복하기 위해 SPA환경에서도 SSR을 사용하기 시작하였다.
Next.js
나 Gatsby
와 같은 프레임워크를 이용해 SPA에서도 SSR을 사용할 수 있다.
해당 프레임워크를 사용하면 CSR과 SSR을 상황에 따라 사용할 수 있어 더 나은 UX를 제공할 수 있도록 하며, SEO측면에서도 유리한 고지를 점할 수 있게 된다.
또한 Next.js의 경우 SSG(Static-Site Rendering)을 통해 빌드타임에 페이지마다 정적인 HTML코드를 미리 만들어 놓고(Pre-Rendering) 요청에 따라 응답한다.
SSG를 통해 기존의 SSR처럼 요청을 받을 때마다 페이지를 Generating하는 것보다 서버의 부하를 줄이고, 더 빠르게 응답할 수 있게 된다.
[FE] SSR(Server-Side-Rendering) 그리고 SSG(Static-Site-Generation) (feat. NEXT를 중심으로)