1. AJAX/SPA

JSON 데이터를 자바스크립트를 이용해서 동적으로 HTML 요소를 렌더링해서 페이지에 업데이트하는 방식

1) AJAX의 정의

• Asynchronous Javascript And XML, 자바스크립트와 XML을 이용한 비동기적 정보 교환 방법이다.

2) 탄생 배경

• 1990년대 웹사이트는 작은 버튼 하나를 클릭하더라도 페이지를 다시 서버에 요청을 보내 가져와서 화면을 구성했다.
• 당연히 매번 새로고침이 생기는 이 방식의 유저 사용성은 최악이었다.
• 그렇게 2000년 중반 즈음 현재 fetch기능의 조상격인 XMLHttpRequest라는 기능이 등장했다.
• 이를 통해 유저가 한 페이지에 머물면서 필요한 일부 데이터만을 JSON 포맷으로 서버에서 받아올 수 있게 되었다.
• 그 JSON 데이터를 자바스크립트를 이용해서 동적으로 HTML 요소를 렌더링해서 페이지에 업데이트하는 방식이 AJAX이다.
• AJAX를 적극적으로 활용한 어플리케이션을 SPA(Single Page Application)이라고 한다.

3) 원리

• SPA를 구현하기 위해 사용하는 렌더링 방식이 CSR이다(+유니버셜 렌더링).
• CSR방식의 SPA는 최초 HTML, CSS, JS를 1회만 로드하고 이후에는 자바스크립트 파일을 통해 DOM 또는 필요한 HTML 파일을 조작하는 방식을 취한다.

2. CSR

서버가 편하나 첫 로딩 속도와 SEO는 별로

1) 정의

• Client Side Rendering, 말 그대로 클라이언트 측에서 렌더링이 진행된다.
• 브라우저가 서버로부터 HTML, JS파일을 받아 직접 렌더링한다.

2) 원리

• 유저가 사이트에 방문하면 클라이언트는 서버에 요청을 보내서 HTML, JS파일을 가져온다.
• 클라이언트는 HTML을 렌더링하고 JS를 로드하여 유저에게 화면을 보여준다.

3) 장점

① HTML 렌더 속도 = JS 로드 속도

• 클라이언트가 HTML, JS를 모두 받아 처리하므로 TTI와 TTV가 같다.
• TTI는 Time To Interation, TTV는 Time To View로 유저가 화면을 보는 시점에는 모든 기능을 사용할 수 있다는 뜻이다.
• 예를 들어 버튼을 눌렀을 때 그에 설정된 API가 작동되지 않는 일은 없다.

② 서버에 부하가 적음

• 서버로부터 받아와서 처리하므로 서버가 하는 일이 적어진다.

4) 단점

① 첫 로딩이 느림

• 첫 화면을 보기까지 걸리는 시간은 유저 사용성에 큰 영향을 끼친다.
• 그러나 CSR은 서버로부터 모든 것을 받아와서 클라이언트에서 모두 처리한 다음 유저에게 보여주므로 첫 로딩이 느리다.

② SEO 효율 낮음

• 네이버같은 검색엔진은 크롤봇이 내 사이트의 HTML 소스코드를 파악하여 자신들의 사이트에서 내 사이트가 검색되기 쉽게 도와준다.
• 그런데 CSR은 자바스크립트로 동적으로 앱을 구성하기에 HTML Body가 비어있는 편이다.
• 검색창에 노출이 중요한 요즘 꽤나 치명적인 단점이다.

3. SSR

빠른 로딩과 높은 SEO효율, 서버가 고생

1) 정의

• Server Side Rendering, 서버 측에서 HTML파일을 미리 렌더링하여 클라이언트에 전달하는 방식

2) 원리

• 유저가 사이트에 방문하면 클라이언트는 서버에 페이지 요청을 보낸다.
• 서버는 HTML을 미리 렌더링하여 클라이언트에 넘겨주고 JS를 같이 넘겨준다.
• 클라이언트는 렌더링이 끝난 HTML을 바로 화면에 띄우고 그 후 JS를 다운받아 로드한다.

3) 장점

① 빠른 첫 로딩

• 미리 서버에서 렌더링이 끝난 HTML을 받아오므로 유저가 화면을 볼 수 있는 속도가 빠르다.

② SEO 효율

• 컨텐츠가 HTML Body에 담기므로 효율적인 SEO를 할 수 있다.

4) 단점

① 서버에 무리

• 서버가 하는 일이 많아지는 것은 좋지 않은데 SSR은 서버가 하는 일을 증가시키므로 좋지 않다.

② HTML 렌더 속도 ≠ JS 로드 속도

• 클라이언트는 서버에서 받아온 렌더링이 끝난 HTML을 바로 띄운 후 JS를 다운받아 로드하므로 TTI와 TTV가 다르다.

4. 개인적인 생각

1) 둘다 단점이 치명적이다

• 검색창 노출과 유저 사용성이 중요한 요즘 CSR의 방식과 서버에 무리가 많이 가는 SSR을 각각 고집하는 것은 좋지 않은 것 같다.
• 그러면서 생각해본 것은 왜 Next같은 SSR 프레임워크가 핫할까라는 것이었다.
• 단지 CSR의 단점보다 SSR의 단점이 견딜만해서?
• 이는 멍청한 생각이었다. 공부를 해보니 Next는 SSR만 사용하는 것이 아닌 SSR의 특징을 살린 React 기반의 프레임워크였다.

2) NextJS

• 즉, NextJS는 앱을 초기 구성할 때는 SSR방식으로 처리하되 CSR방식 리액트에 하이드레이션(흡수)되는 구조를 가지고 있다.
• 결국엔 CSR 방식으로 돌아간다는 것이다.
• Next로 만든 앱의 초기 구성은 SSR의 방식으로 할 수 있으니 첫 로딩 속도는 줄이고 초기 구성 데이터로 SEO 효율을 높일 수 있으며 그 후는 SPA 사용하듯 CSR로 사용하면 되니 서버에 부담도 줄일 수 있다.
• 이렇게 SSR+CSR로 구성된 앱을 Isomorphic App, Universal Rendering라고 한다.