SSR vs CSR, 어느 쪽을 선택할까?

안녕하세요:)

저번 시간에는 '웹 페이지가 브라우저에 어떻게 그려지는지'에 대해 알아보았습니다. 렌더링 과정이 웹 페이지 성능과 UX에 얼마나 중요한 역할을 하는지 살펴보며, 최적화 방법도 알아봤었죠.

 

이번 글에서는 웹 개발에서 상당히 많이 논의되는 두 가지 렌더링 방식인 SSR(Server-Side Rendering)과 CSR(Client-Side Rendering)에 대해 다뤄보려 합니다.

 

두 가지 방식 중 어떤 방식이 더 좋을까요?

그 답은 상황에 따라 다를 수 있다는 것입니다. 그래서 오늘은 이 두 가지 렌더링 방식이 어떻게 작용하는지, 각 방식의 장단점은 무엇인지, 그리고 어떤 상황에서 어떤 방식을 선택해야 하는지를 살펴보겠습니다.

 

먼저 SSR과 CSR이 각각 무엇인지부터 살펴보도록 하겠습니다.

 

1. SSR? CSR?

SSR(Server-Side-Rendering)은 HTML, CSS, JavaScript 리소스를 서버에서 미리 렌더링 하여 클라이언트로 전송하는 방식입니다. 반대로, CSR(Client-Side-Rendering)은 웹 페이지를 처음 로딩할 때 서버로부터 최소한의 HTML, CSS, JavaScript 리소스를 받아온 후, 클라이언트측에서 렌더링을 진행하는 방식입니다.

SSR, CSR 참고 이미지 (https://www.heavy.ai/technical-glossary/server-side-rendering), (https://medium.com/@olayidecodes/client-side-rendering-vs-server-side-rendering-3c41f03c700d)

 

SSR과 CSR의 렌더링은 어떻게 이루어질까요?

SSR은

1. 사용자가 서버에 웹 페이지를 요청합니다.
2. 요청을 받은 서버는 HTML, CSS, JavaScript를 모두 렌더링하여 처리하게 됩니다.
3. 그렇게 완성된 HTML파일을 클라이언트로 보냅니다.
4. 브라우저는 받은 파일을 그대로 화면에 표시합니다.
5. 이후 JS가 로드되어 상호작용이 가능한 페이지가 됩니다.

CSR은

1. 사용자가 서버에 웹 페이지를 요청합니다.
2. 서버는 최소한의 HTML과 JS를 클라이언트로 보내게 됩니다.
3. 브라우저가 받은 JS를 실행합니다.
4. 그리고 JS가 API를 통해 서버로부터 데이터를 가져옵니다.
5. 가져온 데이터를 동적으로 DOM을 생성하여 페이지를 렌더링합니다.

그렇다면 SSR과 CSR의 장단점은 무엇일까요?

 

2. SSR의 장단점

먼저, SSR의 장점은 초기 로딩 속도의 이점과 SEO 부분의 이점. 이렇게 두 가지로 가져갈 수 있습니다.

자세한 설명을 덧붙이자면, SSR은 서버에서 클라이언트로 렌더링된 HTML파일을 전송하기 때문에, 웹 페이지에 접속한 사용자가 페이지를 빠르게 볼 수 있습니다. 특히, 인터넷 연결이 느리거나 저사양 기기를 사용하는 사용자들에게 훨씬 좋을 수 있습니다.

SEO 참고 이미지(https://www.geeksforgeeks.org/search-engine-optimization-seo-basics/)

또한, SEO(Search Engine Optimization)에도 유리하게 작용합니다, 검색 엔진 크롤러는 주로 HTML을 읽어들이기 때문에, SSR 방식으로 제공된 페이지는 검색 엔진에 쉽게 노출될 수 있습니다. 노출이 잘 되면 검색 순위 향상에 도움이 되겠죠?

 

SSR 방식의 단점은 뭘까요?

SSR방식은 렌더링 처리를 서버에서 하기 때문에, 서버의 부하가 증가됩니다. 클라이언트 측에서 요청이 많이 들어오면 들어올수록 서버의 부하는 더 커지게 되는데, 이러한 단점 때문에 다수의 사용자가 요청을 보내는 대형 웹 사이트에서는 문제가 될 수 있습니다. 

 

여기서 이어지는 단점이 하나 더 있는데, '페이지를 전환할 때마다 새로고침이 필요하다는 것'입니다. 왜냐하면, 사용자가 페이지를 이동할 때마다 서버에 요청이 발생하게 되는데, 이때 서버는 다시 렌더링을 처리하고 클라이언트로 보내게 되는데, 이 과정에 전체 페이지를 새로고침 해야 하므로, 페이지를 전화할 때 속도가 많이 느려질 수 있습니다.

 

반면, CSR 방식에서는 이러한 단점이 완화가 되는데, 이제 CSR의 장단점도 알아보겠습니다.

 

3. CSR의 장단점

CSR의 장점은 페이지 전환의 이점과 서버 부하의 감소, UX 인터페이스의 이점. 이렇게 세 가지로 가져갈 수 있습니다.

CSR방식은 웹 페이지가 한 번 로드되면, 이후 페이지 전환이 매우 빠르게 이루어지는데, 전체 페이지를 리로드할 필요 없이 반드시 필요한 최소한의 데이터만 가져와서 DOM을 업데이트할 수 있기 때문입니다. 그리고 클라이언트측에서 렌더링 작업을 처리하므로, 서버의 부하가 줄어들게 됩니다.

 

또한, CSR은 다양한 프론트엔드 프레임워크들과 결합해서 풍부한 인터페이스 제공이 가능합니다. 이 방식이 풍부한 인터페이스를 제공할 수 있는 이유는 렌더링을 클라이언트측에서 처리하기 때문입니다. 사용자가 웹 페이지와 상호작용하는 로직과 데이터 처리가 브라우저에서 이루어지므로, 페이지가 로드된 후에는 서버와 별도의 통신 없이 실시간 UI변화를 구현할 수 있습니다.

 

이러한 이점들을 제공해주는 CSR 방식의 단점은 무엇일까요?

 

CSR방식에서는 SSR방식에 장점이 단점이 됩니다. 로딩 속도 저하, SEO에서의 불리함, 클라이언트 디바이스 성능에 따른 속도 문제, 이렇게 세 가지로 볼 수 있습니다. CSR은 클라이언트측에서 렌더링이 이루어지기 때문에, 처음 페이지가 로드되기까지 시간이 걸릴 수 있습니다. 또한 검색 엔진 크롤러가 페이지 콘텐츠를 제대로 인덱싱하지 못할 가능성이 있으며, CSR은 클라이언트의 리소스를 많이 사용하기 때문에 클라이언트측 디바이스 성능이 낮으면 페이지가 느리게 동작하게 됩니다.

 

4. SSR vs CSR, 어떤 방식을 선택해야 할까?

각기 다른 장단점을 가지고 있는 두 방식 중에 뭘 선택해야 할까요? 어떤 방식을 선택할지는 프로젝트의 요구사항에 따라 달라집니다.

 

1. SSR방식 선택

• SEO가 중요하거나, 초기 로딩 속도가 중요할 경우(대량의 콘텐츠가 있는 웹 사이트, 뉴스 사이트 등)

2. CSR방식 선택

• 섬세한 상호작용이 필요하거나, SPA(Single Page Application)를 개발하는 경우(웹 애플리케이션, 대시보드 등) 그리고 서버 부하를 줄여야 하는 경우

Next.js(공식 문서)

어떤 방식을 선택할지는 위와 같은 상황에 따라 달라지게 됩니다. 하지만 오늘날 웹 애플리케이션은 SSR과 CSR을 적절히 혼합해서 사용하기도 합니다. 혼합방식을 체택한 대표적인 프레임워크는 Next.js인데, SSR을 기본으로 하면서 클라이언트 사이드에서 필요한 부분은 'use client'를 통해 CSR 방식을 사용할 수 있도록 제공합니다. 이러한 하이브리드 렌더링 방식은 초기 로딩 속도와 SEO에서 이점을 얻으면서도, 풍부한 UX를 제공할 수 있게 합니다. 

 

끝내는 말

이번 글에서는 SSR과 CSR에 대해 알아보았는데요. 두 방식은 장단점이 명확하게 있지만 요구사항에 맞는 방식을 선택하여 사용해야 한다는 결론이 나왔습니다. Next.js라는 하이브리드 렌더링을 지원하는 프레임워크도 있다하니 해당 프레임워크를 사용해도 좋을 거 같습니다.

(필자가 Next.js 쓰는 데 아주 만족스럽습니다 ㅎㅎ)

 

다음 글에서는 현대 웹 애플리케이션에서 중요한 역할을 하며, 풍부한 UX를 제공하는데 필수 개념인 'SPA(Single Page Application)'에 대해 알아보도록 하겠습니다. 

 

읽어주셔서 감사합니다:)