CSR vs SSR

 

 

 

클라이언트 사이드 렌더링(Client-Side Rendering, CSR)과 서버 사이드 렌더링(Server-Side Rendering, SSR)은 웹 애플리케이션의 콘텐츠를 어디에서 렌더링할지 결정하는 두 가지 주요 접근 방식이다

각각의 방식은 사용자 경험과 검색 엔진 최적화(SEO)에 다른 영향을 미친다

 

클라이언트 사이드 렌더링 (CSR)

CSR에서는 브라우저가 서버로부터 HTML을 다운로드 받은 후, JavaScript를 이용하여 애플리케이션의 나머지 부분을 빌드한다

이 접근 방식에서는 초기 로딩 시간이 더 길 수 있지만, 일단 애플리케이션이 로딩되면 페이지 간의 전환은 매우 빠르다

장점:

• 사용자 경험: 페이지 간 전환 시 새로운 페이지를 서버로부터 다시 로드할 필요가 없어 사용자 경험이 개선된다
• 프론트엔드 분리: 백엔드와 프론트엔드 로직이 분리되어 각각 독립적으로 개발할 수 있다

단점:

• 초기 로딩 시간: 첫 페이지 로딩 시 모든 스크립트를 다운로드 받아야 하므로 시간이 오래 걸릴 수 있다
• SEO 문제: 검색 엔진이 JavaScript를 실행하지 않는 경우 콘텐츠 인덱싱에 문제가 발생할 수 있다

 

서버 사이드 렌더링 (SSR)

SSR에서는 서버가 사용자의 요청에 따라 각 페이지를 미리 렌더링하여 완성된 HTML을 클라이언트로 전송한다

이 방식은 사용자가 페이지를 요청할 때마다 서버에서 새로운 페이지를 생성하여 보내준다

장점:

• SEO 최적화: 서버에서 렌더링된 페이지는 검색 엔진에 의해 더 쉽게 크롤링되고 인덱싱될 수 있다
• 초기 로딩 성능: 사용자는 서버로부터 완성된 페이지를 받기 때문에, 초기 콘텐츠를 더 빠르게 볼 수 있다

단점:

• 서버 부하: 각 페이지 요청마다 서버에서 HTML을 생성해야 하므로 서버 부하가 증가할 수 있다
• 사용자 경험: 페이지를 전환할 때마다 서버로부터 새로운 HTML을 받아야 하므로, CSR에 비해 사용자 경험이 떨어질 수 있다

 

결론

CSR과 SSR의 선택은 애플리케이션의 요구 사항에 따라 달라진다

SEO가 중요하고 초기 로딩 성능을 중시하는 경우 SSR이 유리할 수 있으며,

사용자 경험을 최우선으로 고려하고 애플리케이션의 동적인 상호작용이 많은 경우 CSR이 더 적합할 수 있다

최근에는 두 가지 방식의 장점을 결합한 하이브리드 접근 방식이나 Next.js와 같은 프레임워크를 사용하여 SSR과 CSR의 이점을 모두 활용하는 방법도 인기를 얻고 있다