최종 수정 : 2024-05-31
1. 라이브러리(Library) / 프레임워크(Framework)
- 리액트(React)는 자바스크립트의 라이브러리
- Next.JS는 자바스크립트의 프레임워크
라이브러리(Library)
- 어플리케이션을 만들 때 필요한 자원(기능: 함수)의 모임
- 응용 프로그램이 라이브러리를 사용한다.
프레임워크(Framework)
- 코드를 작성하는 기본적인 틀을 제공해서 보다 효율적으로 어플리케이션을 만들 수 있도록 하는 소프트웨어 환경
- 프레임워크에 의해 응용 프로그램이 사용된다.
2. CSR / SSR
둘의 차이는 유저가 브라우저에서 보는 화면(UI)를 어디에서 만들어 주는지에 따라 다르다.
- React는 CSR(Client-Side-Rendering)
- Next.js는 SSR(Server-Side-Rendering)
1) React 동작 방식 (CSR)
1. 유저가 앱에 브라우저에 접속하면,
2. 앱은 javascript 정보가 들어 있는 빈 html 문서를 브라우저에게 전달한다. 즉, javascript파일을 브라우저에게 전달하는 것이라 할 수 있다.
3. 브라우저가 javascript 파일을 다운로드 하는 순간, 유저는 빈 화면을 보게 된다(접속에 대한 응답).
4. 브라우저에서 javascript파일 다운로드가 끝나면, 리액트 코드가 있는 js파일을 실행한다.
5. 브라우저에 있는 리액트 코드가 UI를 동적으로 렌더링한다.
6. 유저는 앱 화면을 보게 된다.
-> 브라우저가 javascript 코드를 가지고 있지 않거나, 요청 중인 상태일 경우 UI를 구성할 수 없다. 유저는 빈 화면을 마주하게 된다. 리액트 코드가 실행되기 전까지 그렇다. 이렇게 클라이언트 측에서 UI를 빌드하는 것을 CSR 방식이라 한다.
React는 SPA로 하나의 페이지 안에서 모든 데이터를 주고 받는다. react-router-dom 같은 라우팅 라이브러리를 사용해서 페이지 이동처럼 보이게 만들어 준다. 하지만 실제로는 페이지가 이동하는 것이 아니다. URL이 변경될 때, 보여지는 컴포넌트가 달라지는 것 뿐이다. 그러므로 실제로 페이지가 이동된 후, 다시 HTML과 JavaScript를 받아오는 것이 아니다.
React에서는 맨 처음 유저가 웹에 방문하면 HTML을 받아오고 CSS와 JavaScript를 불러와 웹을 동작시키면, React안에 작성해놓은 코드들이 동작한다.
장점
- 초기 로드만 완료되면 이후 렌더링이 빠르다.
- 서버에 요청할 것이 거의 없어 서버 부담이 적다.(data 필요시에만 요청)
- Web Applications에 좋다.
단점
- SEO에 좋지 않다.
(초기 HTML에는 동적으로 생성되는 콘텐츠가 포함되어 있지 않다. 검색 엔진 크롤러가 페이지를 수집할 때 동적으로 생성된 콘텐츠를 인식하지 못하기 때문에, 검색 결과에서 노출되는 확률도 떨어진다.)
(또한, 페이지 로딩이 JavaScript 파일의 다운로드와 실행에 따라 지연됨에 따라 초기 로딩 속도가 느릴 수 있는데, 검색 엔진이 페이지의 초기 로딩 속도를 평가하는 중요한 요소 중 하나이므로 검색 엔진이 페이지를 빠르게 로딩할 수 없을 경우 페이지 노출이 낮아지는 원인이 될 수 있다.)
- 초기 로드가 오래 걸린다.
- 외부 라이브러리가 필요한 경우가 많다.
2) Next 동작 방식 (SSR)
1. 유저가 앱에 접속하면,
2. 서버에서 리액트를 실행한다.
3. 리액트는 UI를 렌더링한다.
4. 렌더링된 결과를 통해 HTML을 브라우저에게 제공한다. 이때 유저는 앱의 초기화면을 보게 된다(접속에 대한 응답).
5. 이후 브라우저는 리액트 코드가 있는 JavaScript 파일을 다운받고 실행시킨다. 이때부터 리액트와 같이 CSR의 동작(동적 렌더링)을 하게 된다. 이런 과정을 hydration이라고 한다.
-> 서버에서 UI를 모두 구성한 후 유저에게 응답 화면을 보여주는 방식이다. 화면이 pre-rendering되어 유저는 인터넷 속도에 상관없이 화면에 뭔가 나오는 것을 볼 수 있다. 이렇게 서버 측에서 UI를 렌더링하는 것을 SSR 방식이라 한다.
참고) hydration
- 리액트 코드가 브라우저에 이미 존재하는 HTML과 동기화하여 앱이 동적으로 상호작용할 수 있도록 하는 과정
장점
- SEO에 좋다.
(HTML 파일에 모든 정보가 포함되어 있기 때문에 봇이 데이터를 수집할 수 있다. 덕분에 페이지의 콘텐츠가 검색 엔진에 잘 색인되고 순위가 올라갈 수 있게끔 만든다.)
- 향상된 성능
(SSR과 SSG를 통해 웹사이트의 성능을 향상시킨다.)
- 프리 렌더링(Pre-Rendering)을 통해 페이지 로딩 속도가 향상된다.
- 덕분에 사용자 경험(UX)도 개선된다.
- Static Sites(정적 앱)에 좋다.
- Next.js는 확장성이 용이한 덕분에 고트래픽(high-traffic) 웹사이트를 다룰 수 있다. 트래픽이 증가함에 따라 웹사이트를 확장할 수 있다.
- 클라우드 기반 호스팅 서비스를 통해 쉽게 배포할 수 있다.
- CSR과 SSR을 통해 다이나믹한 콘텐츠를 제공하며, 사용자에게 원활하고 흥미로운 경험을 제공한다.
단점
- 전체 앱을 서버에서 앞서 렌더링하기 때문에 컴포넌트 로딩이 오래 걸릴 수 있다. 이때, 유저는 빈 화면을 볼 수도 있다.
- 서버에 매번 요청하기 때문에 서버 부하가 크다(view 변경 시 요청).
- 페이지를 요청할 때마다 새로고침되어 UX가 떨어진다.
- Next.js는 복잡한 웹 사이트에 적합한 프레임워크이다. 그렇기에 단순한 웹사이트를 만들 때는 너무 많은 복잡성이 추가될 수 있다.
CSR과 SSR 무엇이 더 좋은가?
SSR이 CSR 이후 각광 받으면서, CSR보다 SSR이 더 최신 기술, 혹은 더 '좋은' 기술'이라고 생각하는 사람들이 있다. 하지만 생각해보면, SSR은 SPA가 아닌 MPA에서 정적 페이지를 렌더링할 때부터 쓰이던 기술로, 예전 기술을 SPA 환경에서 채택한 것이라고 볼 수 있다. 그러므로, 어떤 기술이 좋다, 나쁘다 혹은 최신이나 아니다를 논하는 것은 무의미하다. 이보다는, 만들고 있는 웹 사이트에 맞게 CSR과 SSR 중 채택하여 정할 수 있는 능력이 있어야 한다.
■ 참고 영상 및 글
[NextJS] NextJS 시작하기 - 2. React.js와 Next.js의 차이점 (framework vs. library, CSR vs. SSR)
CSR과 SSR의 장단점 Next.js 선택 이유와 고려사항
https://seo0yoon.tistory.com/221
Next.js 웹 개발 프레임워크: 장점과 단점, SEO를 고려한 선택 방법
Next.js를 사용하면서 리액트랑 별반 다르지 않다고 느꼈던 이유
https://www.reason-to-code.com/blog/why-we-couldn't-feel-the-difference-of-nextjs/
'프론트엔드 > Next.JS' 카테고리의 다른 글
| Next.JS 타입 (0) | 2024.05.24 |
|---|---|
| [팀 미팅 질문] SSR / CSR / SSG 각각의 특징과 각 방식을 어떤 상황에 사용하면 좋을지 설명해 주세요. (0) | 2024.04.27 |
| Next JS 오류 해결 (0) | 2023.08.02 |
| 미들웨어(middleware) (0) | 2023.07.24 |
| 로딩 UI / 병렬적으로 수행 / 에러 UI (0) | 2023.07.24 |
댓글