예전에도 배운적이 있지만, 다시한번 개념을 확실하게 정리하기 위해 글을 써보기로했다. 다른사람에게 촤르르르르! 설명할 수 있게!!
CSR , SSR 그리고 SPA는 현대 웹개발에서 반드시 집고 넘어가야 할 개념입니다. SPA는 3세대 웹이 등장하면서 기존에 웹이 제공해 주지 못했던 풍부한 UX를 구현할 수 있게 해준 중요한 키워드 입니다. 이 SPA는 CSR과 SSR 이 두가 방법으로 지원할 수 있습니다.
Hyper Text
: 링크로 연결된 문서Markup Language
: “이렇게 보여줘라” 에 대한 지시HTML
: 웹페이지의 내용을 브라우저에게 어떻게 렌더링(rendering) 해주라고 마크업 해주는 것SPA(Single Page Application)
- 하나의 파일로 전체 사이트를 구현React
의 출현!)<html파일 수>
일견 당연해보이기도 한다
⇒ 우리는 이미 여러 페이지를 넘나들며 사용하는 것처럼 보이기 때문
정적 웹사이트로 구성된 html 파일이 여러 개.
정적 웹사이트?
페이지 이동 시 화면 깜빡임 O
<div id="root" />
의 내용을 싹 교체하는 것.
- 또한, SPA(결과물) = CSR, SSR (렌더링 방법)로 나누어 이해하면 좋다.
Clinet Side Rendering의 약자로써 최초에 1번 서버에서 전체 페이지를 로딩하여 보여주고 이후에는 사용자의 요청이 올 때 마다, 리소스를 서버에서 제공한 후 클라이언트가 해석하고 렌더링을 하는 방식입니다.
1. Create React App (CRA) ← Only CSR
- 아무런 초기 설정 없이도 CRA를 통해 React 기반의 SPA 사이트를 구현할 수 있게 됨.
- (과장 조금 보태서) 터미널에
npx create-react-app my-app
,npm run build
명령어 만으로 사이트 하나를 만드는 것이 가능.- webpack, babel 등 복잡한 세팅을 거치지 않아 React 기반 웹 프로젝트 확산에 큰 기여.
- 그런데 얼마 간 시간이 지나면서 조금씩 이상한 점이 드러나기 시작.
- 🤔: "우리 사이트가 검색에 너무 안 걸리는걸?"
- 원인) CRA로 build한 프로젝트는 Only CSR(Client Side Render)로 실행되기 때문.
Server Side Rendering의 약자로써 단어 그대로!! 서버에서 렌더링을 작업합니다. 기존에 존재하던 방식으로 사용자가 웹페이지에 접근할 때, 서버에 페이지에 대한 요청을 하며 서버에서는 html,view와 같은 리소스들을 어떻게 보여질지 해석하고 렌더링하여 사용자에게 반환합니다.
웹에서 제공하는 정보량이 많아지고 데스크탑보다 성능이 다소 떨어지는 스마트폰의 웹에 대한 요구가 커지면서 새로운 기법이 탄생했습니다.
:CSR의 경우, 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기 때문에 서버 측에서 렌더링하여 전체 페이지를 다시 읽어들이는 것보다 빠른 반응속도를 기대할 수 있습니다.클라이언트 측에서 렌더링을 하게 되면 서버 사이드 렌더링이 따로 필요하지 않기 때문에 일관성 있는 코드를 작성할 수 있습니다.
CSR은 페이지를 읽어들이는 시간, 자바스크립트를 읽어들이는 시간, 그리고 자바스크립트가 화면을 그리는 시간까지 모두 마쳐야 콘텐츠가 사용자에게 보여집니다. 여기서 웹서버에서 콘텐츠 데이터라도 가져와야 한다면 그 시간은 더욱 길어집니다. 즉, 초기 구동속도가 느려집니다. 초기 구동속도를 제외하고는 빠른 반응을 보여줍니다.**
이와 반대로 SSR의 경우 서버에서 view를 렌더링하여 가져오기 때문에 view를 보기까지 초기 구동속도가 빠릅니다. 물론 JS파일을 전부 다운로드 받기 전까지는 제대로 동작하지 않지만 사용자 측면에서는 빠르다 느낄 수 있습니다.
SEO(Search Engine Optimization(최적화))
대부분의 웹 크롤러, 봇들이 자바스크립트 파일을 실행시키지 못하고 HTML에서만 컨텐츠를 수집합니다. 때문에 CSR 방식으로 개발된 페이지를 빈 페이지로 인식하게 됩니다. 검색엔진에 제대로 노출이 되지 않는 다면 웹페이지의 유입이 줄어든다.
그렇다면....그 웹사이트는.....
🤔 : "SPA의 장점을 살리면서 SEO도 같이 챙길 수는 없을까?"
⇒ SSR (Server Side Rendering)
SSR은 view를 서버에서 전부 렌더링하여 내려주므로 HTML에 모든 컨텐츠가 저장되어 있기 때문에 SEO 적용에 큰 문제가 없습니다.
기존에 SSR에서는 사용자에 대한 정보를 서버 측에서 세션으로 관리를 하지만 CSR방식은 클라이언트 측의 쿠키말고는 사용자에 대한 정보를 저장할 공간이 없습니다.
CSR + SSR? ⇒ Next.js (like CRA)
Next.js는 간단하게 말하면 리액트에서 SSR을 쉽게 적용할 수 있게 해주는 라이브러리이다.
첫 번째, 사용자가 처음 페이지를 접속을 요청 했을때 Next.js 서버는 사용자에게 랜더링될 HTML을 응답 값으로 보내줍니다 ( SSR 방식 ).
두 번째, 그 후 브라우저는 추가적인 자바스크립트 번들을 다운로드 받아 실행합니다.
세 번째, 사용자가 해당 페이지에서 다른 페이지로 이동할때는 Next.js에 서버가 아닌 브라우저에서 처리하여 이동하게 합니다. ( CSR 방식 )
>:: 원리 & 구조
/index
를 입력.main.js
파일을 다운로드 받음. (hydration)go to second
링크를 클릭./second
로 라우팅하고 second 페이지 코드를 생성.hydration
정리
웹서비스들이 점점 발전하고 User Interaction이 증가함에 따라 단순한 정적 페이지가 아닌 다이나믹한 user interaction을 구현한 동적인 웹으로 발전했다.이에 따라 MPA(Multi Page Application)에서 SPA(Single Page Application)으로 발전되고 SPA의 CSR, SSR 렌더링 방법이 나오게 되었다. CSR은 (Client Side Rendering) 최초에 1번 서버에서 전체페이지를 로딩하여 보여주고 이후에는 사용자의 요청이 오면 클라이언트가 해석하고 렌더링 하는 방식이다. 아무런 초기 설정 없이도 CRA(라이브러리)를 통해 React 기반의 SPA 사이트를 구현할 수 있게 되었다.하지만 CSR 방식으로 개발된 페이지를 빈 페이지로 인식하게되어 검색엔진에 제대로 노출되지 않는 SEO(Search Engine Optimizaion)문제가 발생하게 되었다. SPA의 장점을 살리면서 SEO도 같이 챙길 수는 없을까?"라는 고민끝에 SSR이 나왔다. SSR은 (Server Side Rendering)은 서버에서 렌더링을 작업하는 것을 말한다. SSR은 view를 서버에서 전부 렌더링 하여 내려주므로 HTML에 모든 컨텐츠가 저장되어 있기 때문에 SEO 적용에 큰 문제 가 없다. CSR과 SSR의 장점과 생산성을 위해 사용할 수 있는 Next.js(라이브러리/:프론트 서버에서 백엔드 서버에게 직접 요청 가능함)있는데 SSR의 CRA 으로 간단히 구성이 가능하다.