그동안 여러 프로젝트를 진행해왔지만, 백엔드와 직접적으로 프로젝트를 진행해보기는 처음이다. 백엔드 2명, 프론트엔드 1명으로 프로젝트를 진행했다.
나홀로 프론트엔드를 진행해야 했던만큼 해야하는 양은 많다고 느껴졌지만, 그래도 이것저것 다 해볼수 있겠다싶어서 너무 즐거웠음 😀😀
(앞으로 닥쳐올 미래도 모른채...🤣🤣)
먼저, 어떤 구조로 가야하는지 찾아봐야했다. 그렇게 찾아봤던 것들이 바로 SSR?, CSR?
이번 기회에 CSR 방식과 SSR 방식의 차이를 명확히 파악하여 자신이 구현하고자 하는 서비스에 맞는 방식을 택할 수 있는 안목을 길러보는게 좋겠다고 판단했음...
CSR(Client Side Rendering)과 SSR(Server Side Rendering)이란? 차이점
1. CSR(Client Side Rendering)
CSR의 큰 특징으로 세가지가 있었다.
1) 최초 한 번 HTML, static, js 등을 다 받아와서 로딩하는 방식
2) 이후에는 클라이언트의 요청이 있을 때마다 리소스를 서버에서 제공하고 클라이언트가 해석 후 렌더링
3) 클라이언트 요청=> 변화가 필요한 영역만 서버에 전달=> 서버에서 클라이언트로 리소스 전달=> 클라이언트에서 view 처리, 처음에 HTML에 대한 정보 비어 있음
- SPA(Single Page App) 형식의 프론트엔드 라이브러리(React, Vue)의 방식이다. (내가 여지껏 했던 방식이 CSR의 방식이었구나.. )
2.SSR(Server Side Rendering)
1) 전통적인 웹 어플리케이션 방식
2) 클라이언트가 서버에 요청=> 서버가 클라이언트에 응답
3) 이 과정을 매번 반복하고, 페이지가 전체적으로 렌더링 되기 때문에 반응 속도가 느리다
4) 처음에 HTML에 대한 정보 포함
(React SSR 라이브러리=Next.js)
결론?
이것만 보고는 당연히 그러면 CSR방식이 좋은건가? 느꼈는데 생각해보니 사이트마다 쓰임새가 너무 다르다. 일반적으로 빠르게 최신화와 랜더링이 필요한 사이트가 있는가 하면, 단순하게 클라이언트에게 정보를 제공하고 빠르게 랜더링하고 그럴 필요가 있겠느냐가 궁금했다.
그리고 가장 중요했던 것은 CSR의 경우 HTML 파일이 비어 있어,
데이터를 수집할 수 없다는 것이다.
즉, SEO 검색엔진에 CSR이 최대 단점이라는 것...
(지금은 그래도, 대응할 수 있는 검색엔진의 성능을 높이고 있다하는데 아직은 무리라는 말이 있어서) 그렇다면 SSR로 해야하는게 맞겠거니 Next.js를 사용해보기로 했다...
Next.js란?
nextjs는 React로 만드는 서버사이드 렌더링 프레임 워크이며, 서버사이드 렌더링을 도와준다.
프레임 워크로서의 React와는 무슨 차이?
많은 차이가 있지만, 그중에서 폴더 기반 페이지로 분류할 수 있을것 같다.
react의 경우 라우터 기반으로 페이지를 분류하지만, Next.js의 경우 pages 폴더 내부의 파일 구조가 즉시 페이지로 구현이 된다는 차이가 있었다. 이러한 틀을 그대로 사용하는 것을 프레임워크입니다.
Next.js에서 SEO를 해결?
클라이언트 렌더링의 경우 모든 js 파일을 로드하고 사용자는 웹을 보게됩니다. 이때까지 사용자는 많은 시간을 대기해야 합니다.
seo 문제 - 클라이언트 사이드의 경우 자바스크립트가 로드 되지 않은 경우 아무런 정보를 보이지 않습니다. 구글의 검색엔진의 경우 자바스크립트가 로드되지 않은 페이지를 검색엔진으로 스캔함으로 결론적으로 검색에 아무 페이지도 걸리지 않게 됩니다.
이 두가지를 해결하는 것이 서버렌더링입니다.
첫번째 문제는 서버에서 자바스크립트를 로딩함으로 클라이언트 측에서는 자바스크립트를 로딩하는 시간이 줄어들게 되고,
두번째 문제는 검색엔진이 자바스크립트를 읽는 것이 아닌 서버 측에서 자바스크립트, html, css를 만들어 컨텐츠를 직접 업로드 함으로 검색엔진에 게시글이 걸리게 됩니다.
또한 meta 태그를 자유롭게 추가함으로 seo를 용이하게 할수 있습니다.
참고 사이트
