SSR이 꼭 필요한가요?

Next.Js에서 개발 중인 블로그 서비스(Minimal 블로그)

이마

이번에 명명된 SSR은 Server Side Rendering의 이니셜로, 넓은 의미에서도 템플릿 엔진을 사용하여 서버에서 HTML을 생성하는 기법이 포함되어 있습니다.아래 설명된 SSR은 서버 쪽에서 고객을 조립하여 VirtualDOM을 조립하는 방법을 가리킨다.
우선 SSR이 과연 무엇을 해결하기 위해 존재하는지 여기서부터 고민해보고 싶다.

SSR에 대한 경과

많이 생략되었지만 페이지를 표시하기 전의 패턴을 고려했습니다.
가장 간단한 방법은 HTML 파일을 직접 반환하는 것입니다.

서버는 HTML 파일만 반환하고 클라이언트는 HTML만 지운 후 표시됩니다.
CSS를 사용하는 경우 대화식으로 표시할 수 있습니다.템플릿 엔진과 작업 관리자 등을 사용하면 공통화할 수 있다.
그러나 서버 통신을 점차적으로 동태적으로 진행하여 사용자에게 그 결과를 보여주고 입력을 받는 페이지를 만들려고 한다.그리고 Javascript를 사용하여 사용자의 입력과 데이터 업데이트 등에 반응하여 DOM 구조를 조작하기 시작합니다.

처음에 JQuery 등 사이트에서 순조롭게 운영되었다. 예를 들어 상호작용이 복잡해지면서 DOM의 조작도 시간이 걸리고 VirtualDOM의 React와 같은 프로그램 라이브러리가 등장했다. 데이터가 복잡해지면서 MVC의 분리를 제창하면서 Flex와 Redux 같은 구조가 등장했다.그러나 이와 동시에 자바스크립트 파일의 무게도 상당히 무거워졌다.
이러한 CSR(Client Side Rendering)이면 Javascript 파일을 읽고 실행하기 전에 사용자가 기다립니다.
일반적으로 디스크 IO와 CPU 시간이 네트워크 IO보다 훨씬 빠르기 때문에 서버 측에서 조립하고 사용자에게 그려진 DOM을 되돌려주는 것이 SSR이 나타난 과정이다.

장점과 단점

아마 이 기사는 보는 사람에 따라 다양한 상황이 있을 것이기 때문에 어떤 경우에도 적용할 수 있는 내용만 대충 쓰려고 합니다.
SSR은 주로 FMP(First Meaningful Paint) 점수를 올리는 방법이다.
따라서 SEO 대책이 필요한 서비스(블로그 등)와 고속화 자원 분배에 효과적인 방법이다.
그나저나 SEO 대책도 많은데 위에서 말한 것은 디스플레이 속도도 모바일 검색 순위에 영향을 미친다에 관한 일이다.
구글의 파행기가 자바스크립트를 설명할 수 있기 때문에 자바스크립트를 읽지 않으면 콘텐츠를 표시할 수 없는 SEO 대책은 SSR이지만 조건이 변하지 않아 장점이라고 할 수 없다.
역설적으로 이점이 없는 서비스에서 SSR을 사용하는 경우 서비스가 복잡해지고 리베이트가 줄어든 경우가 많다고 생각한다.나는 이것이 아마도 매우 큰 결점일 것이라고 생각한다.
SSR을 사용했지만 사용자의 입력 등에 반응하려면 클라이언트는Javascript로 처리해야 하고 SPA는 URL을 뛰어넘을 때도 하나의 앱처럼 표시될 경우어떤 페이지로 이동하든지 클라이언트의 상태와 서버 측의 상태가 일치하도록 API를 설계해야 하며 항상 주의해야 한다.나는 이것이 매우 고생스럽다고 생각한다.

최후

사실 저는 지금 터치next.js를 하고 있는데 그것에 대한 기사를 쓰고 싶은데 터치 과정에서 자유도가 낮고 복잡하지만 해결할 기회가 적다고 생각하기 시작해서 SSR이 무엇을 위한 것인지, 무엇을 위한 것인지, 정말 무엇이 필요한지 정리한 글을 썼습니다.잘못이 있으면 메시지를 남겨 주세요.
추기 (2012/02/26)
Next.js에 관해서는 지금 상당히 세련된 것 같아,Next.js를 위해 기억해야 할 것은 많지만 많지 않다. (단어는 페이지 디렉터리,public 디렉터리,getInitial Propos 정도) 다양한 활용 방법으로 설계되었기 때문이다.react+webpack-dev-server 등으로 개발을 시작하려는 분위기라면 주저하지 마세요, 넥스트.js를 사용해 보는 것을 추천합니다.
여러분의 생각을 도울 수 있다면 다행입니다.
추기 (2010/05/24)
Next.Js에서 개발 중인 블로그 서비스(Minimal 블로그)도 참고해주세요.