SSR과 CSR, 그리고 Spring

항상 브라우저가 동작하는 방식을 막연하게 아는 상태로 작업했습니다..ㅠㅠ
Kotlin & Spring 입문 강의를 들으면서 접한 SSR, CSR에 대해 정리해보았습니다.

 

렌더링 (Rendering)

브라우저에서 웹 페이지를 만들어내는 과정을 말합니다.
브라우저의 렌더링 엔진이 웹 사이트의 HTML, CSS 문서를 읽어 화면을 그려내고, 자바스크립트 엔진이 JavaScript 코드를 읽어 기능을 작동시킵니다.
 

(참고 https://yozm.wishket.com/magazine/detail/646/)

 
 
렌더링 방식에는 SSR, CSR이 있습니다.
 

SSR (Server Side Rendering)

서버 쪽에서 렌더링준비를 마친 상태로 클라이언트에 전달하는 방식입니다.
서버가 즉시 렌더링 가능한 HTML 파일을 전달하면 브라우저는 이를 렌더링해 화면을 만든 상태에서 JavaScript를 다운받습니다.
따라서 첫 페이지 로딩이 빠릅니다. 브라우저가 JavaScript를 읽는 동안 사용자는 이미 만들어진 화면을 볼 수 있습니다. (이때 사용자가 행한 조작을 기억해뒀다가 JS 프레임워크가 실행되면 이를 실행합니다.)
하지만 매번 HTML 파일을 다시 만들어야 해서 변경 사항이 있을 때, 나머지 페이지를 불러올 때는 로딩이 느립니다.
 

CSR (Client Side Rendering)

클라이언트 쪽에서 렌더링하는 방식입니다.
서버가 JS가 링크된 HTML 파일들을 전달하면 브라우저가 이를 다운받아 JavaScript를 다운받습니다. 이후 JS 프레임워크가 실행되면 API를 호출해 서버로부터 데이터를 받아옵니다.
SSR과 달리 JavaScript가 실행되기 전까지 사용자는 화면을 볼 수 없습니다. 그래서 첫 페이지 로딩은 느립니다.
하지만 한 번에 모두 다운받아 놓았기 때문에 나머지 페이지를 불러올 때는 SSR보다 로딩이 빠릅니다. 또 변경 사항이 생겨도 이미 만들어놓은 화면에서 JavaScript를 실행해 속도가 빠릅니다.
 

(참고 https://velog.io/@vagabondms/%EA%B8%B0%EC%88%A0-%EC%8A%A4%ED%84%B0%EB%94%94-SSR%EA%B3%BC-CSR%EC%9D%98-%EC%B0%A8%EC%9D%B4)

 
 
SSR와 CSR은 SEO에 있어서도 차이가 있습니다.
 

SEO (Search Engine Optimization)

Search Engine이란 구글, 네이버처럼 검색할 수 있는 Application을 말합니다.
검색 엔진은 완성된 HTML에서 검색어에 해당하는 단어가 있는지 확인하는 방식으로 동작합니다.
CSR은 JavaScript가 실행되기 전인 미완성의 HTML 상태에서 읽히기 때문에 검색 엔진에 잘 잡히지 않습니다.

그래서 CSR과 SSR을 모두 활용하는 프레임워크들이 등장했습니다.
기존 CSR 방식에서는 프론트엔드 서버가 클라이언트에게 HTML/CSS/JS를 전달하고, 백엔드 서버가 클라이언트에게 데이터를 전달했습니다.
이제 백엔드 서버는 프론트엔드 서버에게도 데이터를 전달합니다. SEO가 필요한 부분은 미리 데이터를 받아와 페이지를 만들기 위해서입니다.
 

Spring의 역할

따라서 오늘날 Spring은 클라이언트, 프론트엔드 서버의 요청에 따라 데이터를 응답합니다.
응답 포맷은 대부분 JSON이므로, 각각의 요청에 맞는 적절한 JSON 객체를 반환하는 게 Spring의 주된 역할....이라는 게 튜터님의 설명입니다ㅎㅎ
 
 
그러니까...
프론트엔드와 원활하게 협업할 수 있는, 다른 백엔드 개발자가 쉽게 유지보수할 수 있는.... 그런 식으로 개발하는 게 백엔드 개발자의 역할이겠구나 생각합니다!ㅎㅎ