😶 CSR vs SSR
보통 사람들이 리액트는 CSR이라서 SEO에 안좋다. Next.Js는 SSR을 지원해주기 때문에 SEO에 좋다.
등등과 같은 얘기들을 하면서 CSR과 SSR에 대해 말합니다. 저도 얼핏 대충 알기만 하지, 자세하게 모르기 때문에
이번 기회에 정리를 해보려고 합니다.
📌 CSR (Client Side Rendering)
클라이언트 사이드 렌더링, 말 그대로 클라이언트 측에서 렌더링을 진행한다는 것입니다.
브라우저 측에서 JS를 다운받고, 리액트를 실행시킵니다. 모든 로직과 데이터 가져오기, 템플릿, 라우팅과 같은 것들은
서버가 아닌 클라이언트에서 처리가 됩니다. 완전히 실행이 다 되면 사용자는 화면을 볼 수 있고 작동을 시킬 수 있습니다.
FCP: First Paint - 픽셀이 처음으로 사용자에게 표시되는 시점.
TTI: Time To Interactive - 페이지가 상호작용 가능하게 될 때 까지의 시간 (이벤트 발생 등).
CSR은 보통 SPA(Single Page Application)에서 쓰이는 기법입니다.
리액트로 만든 홈페이지에 들어가면, index.html을 다운받게 되고 그 안의 index.js 파일을 다운로드 하게 됩니다.
모든 코드들이 index.js 파일에 들어있기 때문에 처음에 번들된 이 파일을 다운받는데 시간이 꽤 걸릴 수 있습니다.
(사용자들이 첫 화면을 보는데 시간이 걸릴 수 있다.)
그리고 화면을 그리는 코드를 받아서 화면을 그리긴 하지만, 데이터를 받아오진 않았습니다.
그래서 데이터베이스에서 받아와 그리는 뷰들은 아직 보이지 않는거죠. (이 때 loading 컴포넌트가 보일겁니다.)
CSR은 또한 검색엔진(Search Engine)의 망에 걸리지 않습니다.
검색엔진은 index.html을 기준으로 어떤 데이터들이 있는지, 알맞은 태그들이 들어가 있는지 판단을 하여
이 사이트가 알맞은 사이트인지 판단을 하지만, CSR로 작성된 애플리케이션의 HTML은 텅 비어있습니다.
그래서 검색엔진의 눈에 띄지 못하는 것이죠. 검색엔진최적화(Search Engine Optimization)에 취약합니다.
(구글의 검색엔진은 js까지 실행시켜 판단을 하는 아주 똑똑한 검색엔진이라, 구글은 제외입니다.)
그리고 애플리케이션이 커짐에 따라 필요한 JavaScript의 양이 증가하는 경향이 있습니다.
그러면 처음에 다운받는 bundle 사이즈가 늘어나니, 첫 화면을 보는 사용자의 입장에선 더욱 더 느려질 수 있겠죠.
하지만 CSR를 사용하는 SPA에서 단점만 있는 것은 아닙니다.
우리가 리액트를 사용하는 이유와 비슷하죠.
클라이언트가 페이지를 이동할 때 화면이 깜빡하지 않아도 바로 렌더링이 되는 사용성 측면에서의 장점.
서버에서는 데이터를 주고 받는 일만 하면되니까 SSR보다 서버의 부하를 줄여줄 수 있는 성능 측면에서의 장점등이 있습니다.
CSR 단점
1. SEO(검색엔진최적화)가 좋지 않다.
2. 사용자가 첫 화면을 보는데 시간이 많이 걸린다. (code splitting으로 어느정도 해결 가능)
3. 애플리케이션이 커짐에 따라 필요한 JavaScript의 양이 증가하는 경향이 있어서, 다운로드 속도가 느려질 수 있다.
CSR 장점
1. 서버의 부하를 줄여줄 수 있다.
📌 SSR (Server Side Rendering)
서버 사이드 렌더링, CSR과 반대로 서버에서 렌더링을 진행합니다.
클라이언트가 사이트에 들어오면 서버측에서 데이터를 가져와서 페이지를 구성한 후 브라우저에 전달합니다.
SSR은 클라이언트가 페이지를 이동할 때 서버측에서 데이터를 불러와서 다시 브라우저에게 모든 내용을 전달합니다.
그래서 다시 렌더링하지 않아도 되는 부분까지 다시 렌더링을 하는 단점이 있습니다.
그리고 서버에서 대부분의 일을 처리하기 때문에 서버의 부하가 심하다는 단점이 있죠.
SSR은 CSR보다 사용자가 느끼기에 첫 화면을 빠르게 볼 수 있습니다.
서버측에서 모두 처리를 하고 보내기 때문이죠.
또한 CSR과 반대로 SEO(검색엔진최적화)가 좋습니다.
이미 데이터가 다 박힌 HTML을 반환하기 때문에 검색엔진이 읽었을 때, 텅 빈 HTML 보다는 좋은 사이트로 인식을 하죠.
(개발자가 알맞은 시멘틱 태그를 넣는 것과 같은 검색엔진최적화 작업이 필요합니다.)
SSR 단점
1. 서버의 부하가 심하다.
2. 개발자가 여러가지 신경써야 할 부분들이 많다.
SSR 장점
1. SEO(검색엔진최적화)가 좋다.
📌 Next.js
SSR을 지원해주는 node.js 기반 오픈소스 프레임워크입니다.
요즘 많은 기업들이 SEO를 중요시 여기면서 뜨고있는 프레임워크입니다.
Next.js에는 SSR 말고도 몇가지 장점들이 있습니다.
1. Automatic Routing
pages 폴더 밑에 폴더 및 파일을 구성하면 자동으로 라우팅 처리가 됩니다.
react-router-dom에서 하나하나 명시해야 했던 라우팅을 파일 및 폴더 구성으로만으로 끝낼 수 있습니다.
2. Server Rendering
빠른 렌더링 가능, SSR 없이 SEO 적용이 불가능 한건 아닙니다.
3. Automatic Code Splitting
Next.js는 리소스가 임포트 된것들을 분석하여, 로딩한 페이지가 꼭 필요로하는 JS 파일만 로드합니다. 그래서 첫페이지 로드가 빠르고 나중에 꼭 사용되는 JS 파일들만 클라이언트에 보냅니다.
이 외에도 여러가지 장점들이 있지만, Next 프레임워크에만 국한되는 장점이 아니기 때문에 언급하지 않았습니다.
또한 Next 프레임워크에는 static generation, dynamic rendering 등등 여러가지 렌더 방식들을 제공하고 있습니다.
마무리
CSR이 최고다, SSR이 최고다 이런 방식으로 접근하지 마세요.
개발에 정해진 방식은 없습니다. 적합한 방식이 존재할 뿐이죠.
공식 문서와 같은 static하고, 페이지의 변화가 없는 사이트에는 빌드시 HTML를 만들어놓고 들어오는 사용자에게 제공하는 prerendering 같은 방식을 사용할 수 있고,
회사 홈페이지 내부의 이벤트 페이지 제작 같은 경우에는 SEO가 중요하지 않습니다. (광고로 제공하기 때문)
이 경우에 Next 프레임워크를 사용해서 개발자의 리소스를 늘릴 필요는 없는 것 입니다.
위와 같이 상황에 맞는 적재적소에 기술을 사용하는 것이 좋습니다.
그러기 위해서는 각각의 장단점을 알고 있어야 합니다.
참고
'개발지식' 카테고리의 다른 글
[개발지식] Webpack과 Babel은 왜 쓰이는 건지 알고 계신가요? (0) | 2022.01.26 |
---|---|
[개발지식] 브라우저 저장소, 각각에 대해서 자세히 알고 계신가요? (0) | 2022.01.21 |
[개발지식] 브라우저 동작방식에 대해서 알고 계신가요? (0) | 2022.01.13 |
[개발지식] 웹 서버와 웹 애플리케이션 서버의 차이, 정확히 알고 계신가요? (0) | 2022.01.11 |
[개발지식] CORS, 잘 알고 계신가요? (0) | 2022.01.08 |