(네트워크) AJAX, SSR, CSR

그러나 가져오기를 사용하면 페이지를 이동하지 않고도 서버에서 필요한 데이터를 가져올 수 있습니다.

• 가져오기를 사용하면 사용자가 현재 페이지에서 작업하는 동안 서버와 통신할 수 있습니다.
• 즉, 브라우저는 가져오기가 서버에 요청을 보내고 응답을 받을 때까지 모든 작업을 중지하는 대신 페이지를 계속 사용할 수 있도록 하는 비동기 메서드를 사용합니다.
• 또한 자바스크립트는 DOM을 이용해 조작할 수 있기 때문에 페치는 전체 페이지가 아닌 필요한 데이터만 가져와서 DOM에 적용함으로써 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 수정할 수 있도록 한다.

XHR 및 가져오기

Fetch 이전에는 표준화된 XHR(XMLHttpRequest)이 사용되었습니다.

• Fetch는 XHR의 단점을 보완한 신기술입니다. 웹 API오전.
• XHR은 교차 사이트 문제와 같은 불편있었다
• 반대로 가져오기 약속이 지원됩니다 XML보다 가벼움 자바스크립트와 호환 JSON 사용하다.
• 따라서 오늘날 Fetch는 XHR보다 더 많이 사용됩니다.

예제 가져오기

// 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(); // 요청 전송

AJAX의 이점

• 서버에서 HTML을 완성하고 제출하지 않고도 웹 페이지를 만들 수 있습니다.
  • 이전에는 서버가 HTML을 완성하고 전송하여 화면에 렌더링해야 했습니다. 그러나 AJAX를 사용하면 서버가 전체 HTML을 전송하지 않고 필요한 데이터가 전송됩니다. 브라우저에서 화면의 일부만 업데이트하여 비동기 검색 및 렌더링 할수있다.
• 표준화된 방법
  • 지금까지 다른 브라우저 방법은 AJAX를 사용하였으나 XHR이 표준화되어 있기 때문에 모든 브라우저에서 AJAX 사용할 수 있습니다.
• 사용자 중심 애플리케이션 개발
  • AJAX는 필요한 부분만 렌더링합니다. 더 빠르고 더 대화형 애플리케이션할수있다
• 더 작은 대역폭
  • 대역폭: 네트워크 통신 한번에 보낼 수 있는 데이터의 양
  • 기존에는 완성된 HTML 파일을 서버에서 받아야 했기 때문에 한 번에 보내는 데이터의 크기가 컸다.
  • 그러나 AJAX에는 데이터가 필요합니다. 텍스트 형식(JSON, XML 등)로 보낼 수 있기 때문에 데이터의 크기가 상대적으로 작습니다.

AJAX의 단점

• 검색 엔진 최적화(SEO)의 단점
  • AJAX 기반 웹 애플리케이션은 HTML을 수신하면 렌더링한 다음 서버에서 필요한 데이터를 비동기적으로 가져오고 그립니다.
  • 따라서 처음 받는 HTML 파일에는 데이터를 채우기 위한 프레임만 쓰는 경우가 많다.
  • 검색 사이트는 전 세계로 이동하여 모든 페이지에서 모든 정보를 스크랩하여 사용자에게 검색 결과로 표시합니다.
  • AJAX 기반 웹 애플리케이션의 HTML 파일에는 스켈레톤만 포함되어 있고 데이터가 없기 때문에 사이트 정보를 얻기가 어렵습니다.
• 뒤로 버튼 문제
  • 일반적으로 사용자는 뒤로가기 버튼을 누르면 이전 상태로 돌아갈 것이라고 생각하지만, AJAX는 이전 상태를 기억하지 못하므로 사용자가 의도한 대로 작동하지 않습니다.. 되돌아가기와 같은 기능을 구현하려면, 히스토리 API 별도 사용해야한다.

서버측 렌더링(SSR) 대 CSR(클라이언트 측 렌더링)

이 둘의 차이점을 아는 것은 웹 개발에서 매우 중요합니다.

SSR

• SSR은 서버 측 렌더링에 대한 약어입니다
• 브라우저에서 웹 페이지를 렌더링하는 대신 서버에서 렌더링하다.
• 브라우저가 서버의 URI에 GET 요청을 보낼 때, 서버는 지정된 웹 페이지 파일을 브라우저로 보냅니다.그리고 브라우저에서 서버에서 웹페이지가 도착하면 완전히 렌더링됨하다.
• 서버가 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링이러한 이유로 서버 사이드 렌더링이라고 합니다.
• 웹사이트의 내용에 데이터베이스의 데이터가 필요한 경우, 서버는 데이터베이스에서 데이터를 검색한 후 웹 페이지를 완전히 렌더링된 페이지로 변환한 후 브라우저에서 답으로 보내다.
• 웹 페이지를 탐색하는 사용자 브라우저가 다른 경로로 이동할 때마다 서버는 동일한 작업을 반복합니다.(웹페이지 재전송)

CSR

• CSR은 클라이언트 측 렌더링 수단
• 일반적으로 CSR은 SSR의 반대 개념으로 간주됩니다. CSR은 클라이언트에서 페이지 렌더링하다.
• 웹 개발에 사용되는 일반적인 클라이언트는 웹 브라우저입니다. 브라우저의 요청을 서버로 보내는 대신 서버는 웹 페이지를 렌더링합니다. 웹 페이지의 골격을 나타내는 단일 페이지가 클라이언트로 전송됩니다. 이때 서버는 웹사이트와 함께 합니다. 자바스크립트 파일을 보냅니다.
• 클라이언트가 웹 페이지를 수신하면 웹 페이지와 함께 전달되는 JavaScript 파일은 웹 페이지를 브라우저에서 완전히 렌더링된 페이지로 바꿉니다.
• 웹 사이트상에서 데이터베이스에 저장된 데이터가 필요할 때브라우저는 데이터베이스에 저장된 데이터를 검색하여 웹 사이트에 표시해야 합니다. 이를 위해 Fetch와 같은 API가 사용됩니다.
• 마지막으로, 브라우저가 다른 경로로 이동할 때 브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링합니다. 이때 표시되는 웹 페이지 파일은 첫 번째 서버에서 받은 웹 페이지 파일과 동일합니다. 같은 파일오전.

SSR과 CSR의 차이점

SSR과 CSR의 주요 차이점은 페이지가 렌더링되는 위치오전. SSR은 서버에서 CSR인 페이지 렌더링 브라우저(클라이언트)에서 페이지 렌더링 CSR은 사용자가 다른 경로를 요청할 때마다 페이지를 새로 고치지 않습니다. 라우팅을 동적으로 관리합니다.

1. 사용

SSR

• 검색 엔진 최적화(SEO) 우선 순위가 SSR(Server Side Rendering)인 경우 일반적으로 사용됩니다.
• 웹 사이트 첫 화면의 빠른 렌더링이 필요하시다면, 단일 파일 크기가 작은 SSR이 적합합니다.
• 대지 사용자와의 상호작용이 거의 없을 때, SSR을 사용할 수 있습니다.

CSR

• SEO가 우선 순위가 아닌 경우 CSR을 사용할 수 있습니다.
• 웹사이트에 풍부한 상호 작용이 있는 경우 CSR은 빠른 라우팅강력한 사용자 경험을 제공합니다.
• 웹 애플리케이션을 만들 때, CSR로 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공합니다.

2. 적용 예

SSR

(1) 네이버 블로그

• 네이버 블로그는 2020년 SSR 방식을 도입했습니다.
• SSR이 검색엔진최적화(SEO)에 유리하다는 것이 대표적인 이유다.
• 블로그의 경우 검색엔진에 최대한 많이 노출되는 것이 특히 유리하고, 다른 사이트에 비해 사용자와의 상호작용이 많지 않기 때문에 SSR이 현명한 선택이 될 수 있습니다.
• 개발자 관련 글을 올린 네이버 블로그의 네트워크 탭을 보면 HTML 파일에 동일한 내용이 포함되어 있는 것을 확인할 수 있습니다. 따라서 Google 및 Naver와 같은 검색 엔진 크롤러는 HTML 코드에 액세스하여 콘텐츠를 쉽게 추출할 수 있습니다.

• New York Times 웹 사이트도 SSR 방법을 사용합니다.
• SSR의 가장 큰 단점은 많은 사용자가 클릭하면 전체 웹사이트가 서버에서 다시 로드되어 발생하는 서버 과부하 문제CSR에 비해 하나가 있지만 초기 로딩 속도가 빠르기 때문에 구독자가 신문 기사를 빠르게 읽을 수 있다는 장점이 있습니다.
• 또한 신문 기사는 검색 엔진에 접근 가능한 것이 중요하기 때문에 SSR을 사용하여 SEO(검색 엔진 최적화)에 유리합니다.
• New York Times 웹 사이트의 네트워크 탭에 있는 위의 예를 보면 “dayspaper”라는 완성된 HTML 파일이 수신되고 렌더링됩니다. 콘텐츠가 변경되지 않은 HTML 파일에 포함되어 있기 때문에 검색 엔진 크롤러가 콘텐츠를 수집하기 쉽습니다.

CSR

(1) 아고다

• 아고다뿐만 아니라 많은 예약 사이트에서 CSR을 사용하고 있습니다.
• SSR은 서버에서 렌더링해야 하기 때문에 상호 작용이 많을수록 서버에 더 많은 부하가 걸립니다.CSR을 사용하면 서버가 필요한 데이터만 클라이언트에 전달하기 때문에 부하가 낮습니다.
• 그리고 SPA(Single Page Application) 기반으로 받은 데이터로 화면의 일부만 변경하기 때문에 빠른 렌더링이 사용자 경험에 유리합니다.
• 최근까지 아래 예시처럼 검색엔진최적화(SEO)는 HTML이 빈 페이지이기 때문에 SSR에 비해 불리했지만 이를 보완하기 위해 구글이 크롤링은 삽입된 JavaScript 코드를 분석하고 실행하여 수행됩니다.
• 단, 검색엔진 최적화가 필요한 서비스의 경우 최적화에 더 유리한 SSR을 사용하는 것이 좋습니다.

3. SSR 및 CSR 코드의 예

SSR

const express = require("express");
const app = express();

const infoArr = (
  "csr과 차이점이 느껴지나요?",
  "ssr이란?",
  "HTML은 어디서 조작될까요?",
  "Server Side Rendering",
  "검색엔진 최적화(Search Engine, Optimization)에 상대적으로 유리하다.",
  "초기로딩 속도가 빠르다.",
  "TTV(Time To View)와 TTI(Time To Interact)의 시간 공백이 있을 수 있다."
);

app.get("/", (req, res) => {
  res.send(
    "<html><body><h1>" +
      infoArr(Math.floor(Math.random() * infoArr.length)) +
      "</h1><h1>SSR</h1>" +
      "<h2>Server Side Rendering이란 무엇인가?</h2>" +
      "</body></html>"
  );
});

app.listen(8080);

CSR

const express = require("express");
const app = express();
const port = process.env.PORT || 5000;

const infoArr = (
  "ssr과 차이점이 느껴지나요?",
  "csr이란?",
  "SPA를 기반으로",
  "화면의 일부만 바꿔주는 것",
  "HTML은 어디서 조작될까요?",
  "Client Side Rendering",
  "AJAX를 통해서 서버로부터 필요한 데이터만 받습니다."
);
app.get(`/`, (req, res) =>
  res.send(infoArr(Math.floor(Math.random() * infoArr.length)))
);
app.get(`/csr`, (req, res) =>
  res.send(infoArr(Math.floor(Math.random() * infoArr.length)))
);

app.listen(port, () =>
  console.log(`Example app listening at http://localhost:${port}`)