개인 공부 토탈
왜 Next.JS를 사용해야만 하는가?
React 프레임워크의 한계 => 원칙적으로 CSR만 가능.
CSR은 서버에서 핵심 HTML을 받은 뒤 이를 기반으로 렌더링을 하기 때문에, 서버가 렌더링을 전담하는 SSR에 비해 SEO(검색 엔진 최적화)의 효과를 볼 수가 없다.
SEO의 효과를 보려면 서버에서 렌더링을 해야 한다 => SSR이 되면 클라이언트 쪽에서 HTML 페이지를 다운받아 표시한다 => JS 다운로드까지 완료되면 사용자 상호작용도 가능해진다.
웹 페이지를 렌더링하는 2가지 방식:
서버 사이드 렌더링 vs 클라이언트 사이드 렌더링.
SSR이란 무엇인가?
고전적인 웹페이지 렌더링 방식.
1) 서버를 향해, 클라이언트가 페이지를 요청한다.
2) 그러면 서버는 요청/Request를 수락한 후, 전체 HTML 파일을 생성한다.
3) 전체 HTML 파일을 유저의 브라우저로 송신한다.
4) 브라우저는 이 전체 HTML 파일을 유저의 화면에 띄운다.
CSR이란 무엇인가?
비교적 현대적인 웹페이지 렌더링 방식.
SSR과 달리, CSR에서는 필요한 데이터와 JS만 골라내서 브라우저로 전송한다.
그 후, '브라우저에서' 나머지 HTML 파일을 만든 후 유저 화면에 렌더링해 띄운다.
SSR과 CSR의 차이
1)퍼포먼스/성능: 초기 로딩 속도는 SSR이 더 빠르다. (=단, 웹페이지 안에서 실시간으로 변동하는 기능이 필요하다면 SSR보다는 CSR이 더 낫다.)
1.1)사용자 경험: 초기 로딩 속도가 느린 대신, 페이지 전환 시의 속도는 CSR이 더 빠르다. 브라우저 측에서 상호작용을 처리할 수 있기 때문이다.
2)SEO/검색 엔진 최적화 관점: 서버에서 완전한 HTML을 제공하는 SSR이 더 빠르다. CSR로 SSR 수준의 SEO를 하고 싶다면 추가적인 작업이 더 필요하다.
3)보안 취약점 관련 관점: 보안 측면에서 SSR이 더 안정적이다.
서버가 전체 HTML 파일을 생성하고 클라이언트에게 제공한다.
이 과정에서, 클라이언트가 민감한/취약한 정보에 접근할 기회는 상대적으로 적어진다.
출처: https://www.linkedin.com/pulse/server-side-rendering-vs-client-understanding-anbarasan-rathinam/
+ chatgpt 질문 일부.
+https://bziwnsizd.tistory.com/89