Codestates SEB FE 42기/정리노트

S2 unit7 | [HTTP/네트워크] AJAX , SSR vs CSR

2realzoo 2022. 12. 3. 12:52

📌 AJAX

  • Asynchronous JavaScript And XMLHttpRequest의 약어
  • Javascript, DOM, Fetch, XMLHttpRequest, HTML 등의 기술을 사용하는 웹 개발 기법(개념)
  • SPA를 만드는 기술

✔ AJAX의 가장 큰 특징

: 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있음

 

👍 AJAX 장점

  • 서버에서 HTML 완성하여 보내주지 않아도 웹페이지 만들 수 있음
    • 이전 : 서버에서 HTML을 완성하여 보내주어야 화면에 렌더링이 가능
    • AJAX : 서버에서 필요한 데이터만 비동기적으로 가져와 브라우저에서 화면의 일부분을 업데이트하여 렌더링 할 수 있다.

 

  • 표준화된 방법
    •  이전 : 브라우저마다 다른 방식으로 AJAX 사용
    •  XHR 표준화 이후 : 브라우저에 상관없이 AJAX 사용

 

  • 유저 중심 애플리케이션 개발
    • 필요한 부분만 렌더링 하기 때문에 빠르다. =>  상호작용 많은 애플리케이션에 적합

 

  • 더 작은 대역폭
    • 대역폭 : 네트워크 통신 한 번에 보낼 수 있는 데이터의 크기
    • 이전 : 서버로부터 완성된 HTML 파일 받아와야 하므로 데이터 크기가 큼
    • AJAX : 필요한 데이터를 텍스트 형태(JSON, XML 등)로 보내기 때문에 비교적 데이터의 크기가 작음

 

👎 AJAX 단점

  • Search Engine Optimization(SEO)에 불리
    • AJAX 방식은 처음 받는 HTML 파일엔 데이터를 채우기 위한 틀만 작성되어 있는 경우가 많음. 따라서 검색 사이트에서 정보를 긁어가기 어려움
  • 뒤로가기 버튼 문제
    • AJAX에서는 이전 상태를 기억하지 않으므로 History API를 사용하여 뒤로가기 기능을 따로 구현해야 함 

 

 

전통적 웹 애플리케이션

  • <form> 태그 사용해 서버에 데이터 전송.
  • 서버는 응답으로 새로운 웹 페이지 제공 (요청 보내면 매번 새 페이지로 이동)

 

 Fetch 사용

  • 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있음
  • 비동기적으로 통신
  • Fetch 통해 필요한 데이터만 가져와 Javascript에서 DOM 사용해 조작하여 필요한 부분만 변경

Fetch vs XHR 비교

Fetch XHR(XMLHttpRequest)
XHR보다 가벼움 Fetch보다 무거움
Javascript와 호환 가능한 JSON 사용 XML 사용
반환 값으로 Promise 가짐 Cross-Site 이슈 존재

 

Fetch 예제

// Fetch를 사용
fetch('http://52.78.213.9:3000/messages')
	.then (function(response) {
		return response.json();
	})
	.then(function (json) {
		...
});

 

XMLHttpRequest 예제

// XMLHttpRequest를 사용
var xhr = new XMLHttpRequest();
xhr.open('get', 'http://52.78.213.9:3000/messages');

xhr.onreadystatechange = function(){
	if(xhr.readyState !== 4) return;
	// readyState 4: 완료

	if(xhr.status === 200) {
        // status 200: 성공
		console.log(xhr.responseText); // 서버로부터 온 응답
	} else {
		console.log('에러: ' + xhr.status); // 요청 도중 에러 발생
	}
}

xhr.send(); // 요청 전송

📌 SSR vs CSR

✔ SSR (Server Side Rendering)

: 웹 페이지를 서버에서 렌더링 (SPA 불가능)

1. 브라우저가 서버에게 요청을 보냄

2. 서버에서 정해진 즉시 렌더링 가능한 웹 페이지 파일을 브라우저로 전송

3. 서버의 웹 페이지가 브라우저에 도착하면 즉시 렌더링 됨

4. 클라이언트가 자바스크립트 받음

=> 다운 받는 동안 컨텐츠 볼 수 있지만 조작 불가. 이때 조작하면 기억해두었다가 나중에 실행

5. 브라우저가 Javascript 프레임워크 실행

6. 기억하고 있던 사용자 조작 실행. 웹 페이지 상호작용 가능

 

💬 브라우저가 다른 경로로 이동할 때마다 같은 작업 반복

 

단점

- 서버 과부하 이슈 : 사용자가 클릭할 때마다 전체 웹 사이트를 서버에서 다시 받아오므로 생기는 서버 과부하 

 

 

사용 목적

  • SEO(Search Engine Optimization)가 우선순위인 경우
  • 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우 (단일 파일 용량이 적어 빠른 렌더링 가능)
  • 웹 페이지가 사용자와 상호작용이 적은 경우

사용 예시

  • 네이버 블로그 : 검색엔진 최적화에 유리한 SSR 사용. 블로그는 사용자와 상호작용이 적음
  • The NewYork Times : 빠른 로딩 속도, 신문사의 경우 검색엔진에 노출되는 것이 중요하므로 사용.

 

✔ CSR (Client Side Rendering)

: 웹 페이지를 클라이언트(브라우저)가 렌더링 (SPA 가능)

1. 브라우저가 서버에게 요청을 보냄

2. 서버는 페이지의 골격이 될 단일 페이지(Single Page)와 함께 Javascript 파일을 보냄

3. 브라우저가 웹 페이지를 받으면 함께 보내진 Javascript 파일이 브라우저의 웹 페이지를 렌더링함

=> SSR과 달리 다운 받는 중에 유저는 아무 것도 볼 수 없음

4. 만약 웹 페이지 구성에 데이터베이스의 데이터가 필요할 시에는 Fetch같은 API가 사용됨

5. 완전히 렌더링 후에 상호작용 가능

 

💬 사용자가 다른 경로 요청할 시 동적으로 라우팅 관리

 

단점

- SEO 불리 :  구글에서는 삽입된 자바스크립트 코드 분석, 실행으로 크롤링하여 단점 보완 중 

 

 

사용 목적

  • SEO가 우선순위가 아닌 경우
  • 사이트에 상호 작용이 많은 경우, 빠른 라우팅으로 강력한 사용자 경험 제공
  • 웹 애플리케이션 제작하는 경우 빠른 동적 렌더링으로 더 나은 사용자 경험 제공

 

사용 예시 

  • 아고다 : 예약 사이트는 상호작용이 많으므로 서버에 부담이 적은 CSR 사용

 

✔ SSR vs CSR

두 가지 방법을 같이 사용하면 이점을 동시에 이용할 수 있음

첫 페이지만 SSR + 그 이후로는 CSR => SPA 가능