SPA/ SSR (1)

1. 질문 & 답변 & 토의

• SSR 문제 → CSR 어떤 컨셉으로 해결 가능했기 때문에 등장
• SSR은 server에서 렌더링 담당, CSR은 client에서 렌더링 담당하는 차이
• SSR문제: ‘server에서 완성된(js가 실행된) html탬플릿을 받아오기 때문에 깜빡임 현상이 불가피하다. (ux 안좋음)
• CSR
• 준혁: 사용자와 동적으로 상호작용이 가능하고, 새로고침 없이 데이터를 동적으로 변경이 가능
• CSR은 모든 HTML 파일과 static 파일을 초기에 모두 다운로드 받고, 이후 필요한 리소스가 있을 때만 서버에 데이터를 요청하여 화면을 업데이트 한다.
• 따라서 필요한 부분만 업데이트하기 때문에, 새로고침이 없이 데이터 변경이 가능합니다.
꼬리질문
[Q. CSR의 단점과 극복방법은? ]
• SSR + CSR
• ~~문제가 있었다 두괄식 위력으로.. → 어떤식으로 두괄식으로 습관이 안 되어있다..
• Time To View / Time To Interact를 말하고 싶으셨던 것 같은 준혁넴

From gitHub (링크)

1. SPA와 MPA에 대해서 각각 설명해주세요.

2. SSR (Server Side Rendering) 과 CSR (Client Side Rendering)을 각각 설명해주세요.

1. SEO(검색 엔진 최적화)에 유리 : 화면을 구성하는 각각의 페이지가 있기 때문에 SEO에 유리하다.

2. 빠른 초기 로딩 속도 : 서버로부터 화면을 렌더하기 위한 필수적인 요소를 먼저 가져오기 때문에 CSR 보다 초기 로딩 속도가 빠르다.

1. 불편한 사용자 경험 : 매번 페이지를 요청할 때마다 새로고침

2. 서버 부하 증가 : 페이지를 요청할 때마다 서버에서 모든 리소스를 응답하기 때문에 서버 부담이 증가됨

1. 빠른 속도 및 서버 부하 감소 : 변경된 부분과 관련된 데이터만 가져옴

2. 사용자 친화적 : 페이지 안의 컨텐츠를 클릭하여 다음 단계로 전환하는 과정에서 링크가 없어서 깜빡임 없이 부드러운 이동을 경험할 수 있다.

1. SEO에 불리 : 자바스크립트를 사용하여 사용자와 상호작용 후에 페이지를 로드함 -> 웹 크롤러가 페이지를 색인화하려고 하면 빈 페이지를 보이게 함

2. 느린 초기 로딩 속도 : 초기에 모든 JS 파일을 다운받아야함

3. SSR과 CSR의 동작과정를 말해주세요.

1. 클라이언트에서 초기 화면을 로드하기 위해 서버에 콘텐츠 요청을 보낸다.

2. 서버는 화면에 표시하는데 필요한 완전한 리소스(HTML, JS, CSS 등)를 응답한다.

3. 브라우저가 JS를 다운로드하고 HTML에 JS를 연결한다.

4. 화면을 구성하는 요소 중 하나만 변경해도 서버는 완전한 리소스를 보내기 때문에 앱이 다시 시작되고 화면이 깜빡임

1. 클라이언트에서 초기 화면을 로드하기 위해 서버에 콘텐츠 요청을 보낸다.

2. 서버는 빈 뼈대만 있는 html을 응답으로 보내준다.

3. 브라우저가 연결된 JS링크를 통해 서버로부터 다시 JS파일을 다운로드 받습니다. 모든 JS를 다운 받아야 하기 때문에 초기 로딩 시간이 더 오래걸린다.

4. 화면을 구성하는 요소 중 하나만 변경하면 그 부분과 관련된 리소스만 응답한다. 화면이 깜빡이지 않고 수정된 데이터가 표시된다.

4. SPA (Single Page Application) 와 CSR (Client Side Rendering) 은 같은 개념인가요?

• 차이점

5. CSR의 단점을 보완할 수 있는 방법은 없을까요?

1. 초기 로딩 속도 보완

• code splitting, tree-shaking, chunk 분리를 통해 js 번들 크기를 줄여서 초기 돔 생성 속도를 줄이면 초기 로딩 속도를 개선할 수 있다.

1. SEO 개선

• pre-rendering으로 개선 : 웹 라이브러리나 웹팩 플러그인을 통해 각 페이지에 대한 html 파일을 미리 생성해 둔 뒤 서버에서 요청하는 자가 만약 크롤러라면 사전에 렌더링된 HTML 버전 페이지를 보여주는 방식을 통해 개선할 수 있다.

1. 초기 로딩 속도 보완 & SEO 개선

• CSR을 사용하고 있는 SPA에 SSR이나 SSG를 도입하면 된다.

6. SSR과 CSR을 중심으로, 렌더링 관점에서의 흐름 변화를 말해주세요.(최근 추세)

• fetch API의 원조인 XMLHttpRequest API가 개발 되었다.

• html 문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 필요한 데이터만 받아올 수 있게 되었고

• 이 데이터를 JavaScript를 이용해서 동적으로 HTML 요소를 생성해서 페이지에 업데이트 하는 방식이다.

• XMLHttpRequest 를 이용하는 방식이 공식적으로 AJAX라는 이름을 가지게 되었다.

• 구글에서도 AJAX를 이용해서 Gmail, Google Maps과 같은 웹 어플리케이션을 만들기 시작했고 이것이 현재 널리 쓰이는 SPA이다.

• 기존에는 Server에서 받은 html을 바탕으로 Client가 화면을 그렸지만, CSR 방식은 서버에서 받는 게 아니라 Client에서 알아서 화면을 그리는 방식이다. React나 Vue 같은 라이브러리/프레임워크는 SPA를 만드는 것을 지원하고 CSR 방식으로 동작한다.

• CSR의 단점들 때문에 1990년 중반에 사용했던 Static Sites에서 영감을 받은 SSR이 도입되게 된다.

• CSR을 사용했을 때보다 첫 페이지 로딩이 빨라진다.

• 모든 내용이 html에 담겨져있기 때문에 효율적인 SEO 대응이 가능하다.

• Static Sites에서 발생했던 깜빡임 이슈(SSR단점) + CSR 단점 등으로 인해 CSR + SSR 방식이 도입됨.

• 사용자가 처음 들어왔을 때의 페이지는 서버에서 받아 렌더링하고(SSR) 그 뒤에 발생하는 라우팅은 CSR로 하는 방식이다.

• 첫 진입 이후에는 CSR 방식으로 동작하도록 하면 사용자가 url을 이용해도 페이지 깜빡임 없이 사용할 수 있게 된다.

• 정적인 웹사이트를 생성해주는 툴인데 일반적으로 마크다운 파일을 읽어 HTML을 생성하는 기능을 가진다.

• React의 경우는 CSR에 특화된 라이브러리이지만 Gatsby 라이브러리와 함께 사용하면 React로 만든 웹 어플리케이션을 정적으로 웹 페이지 생성을 미리 해두어서 서버에 배포해놓을 수 있다.

7. SEO는 무엇인가요?

Ref

• [10분 테코톡] 🍻주모의 SPA

• [10분 테코톡] 🎨 신세한탄의 CSR&SSR

• SPA기반 웹사이트의 SEO

• [WEB] Client Side Rendering과 Server Side Rendering