[유데미x스나이퍼팩토리] 프로젝트 캠프 : Next.js 2기 - Next.js 기본(CSR, SSR 내용 정리)

 

📝 데이터 패칭 방법 - CSR, SSR (feat. Next.js)

---

💡 CSR(Client Side Rendering)

렌더링이 클라이언트 쪽에서 일어나는 방식

 

렌더링 주체

• 클라이언트
• React는 기본으로 CSR 합니다.

 

CSR 동작 과정

1. 첫 로딩시
   1. 유저가 웹사이트에 방문하면, 브라우저가 서버에 콘텐츠를 요청한다.
   2. 이에 서버는 빈 뼈대만 있는 HTML을 응답으로 보내준다.
   3. 브라우저가 연결된 JavaScript 링크를 통해 서버로부터 다시 JavaScript 파일을 다운로드한다. (이때, 유저는 아무것도 볼 수 없다.)
   4. 다운 완료된 JavaScript가 동적으로 페이지를 만들어 브라우저에 띄워준다.
2. 첫 로딩 이후 달라진 부분(데이터)만 서버에서 불러온다(Ajax)

즉, 서버에서 처리 없이 클라이언트로 보내주기 때문에 자바스크립트가 모두 다운로드되고 실행이 끝나기 전까지 사용자는 볼 수 있는 것이 없다

 

데이터 패칭 방법

1. CSR에서 데이터 패칭은 useEffect()를 사용하는 고전적인 방식으로 사용할 수 있다. 클라이언트 기반에서 발생하는 데이터 패치이기 때문에 useState 같은 인터렉션 훅을 사용할 수 있다.
2. 클라이언트 렌더링 과정에서 데이터 요청이 발생한다.

 

패칭 데이터

1. 달라진 부분(데이터)만 서버에서 불러온다

 

 

기본

(home)/page.tsx

"use client";
import { useEffect, useState } from "react";

const Main = () => {
  const [loading, setLoading] = useState(true);
  const [posts, setPosts] = useState([]);
  const getPosts = async () => {
    const data = await (
      await fetch("https://jsonplaceholder.typicode.com/posts")
    ).json();
    setPosts(data);
    setLoading(false);
  };

  useEffect(() => {
    getPosts();
  }, []);

  return (
    <>
      <h1>Main Component</h1>
      {!loading && JSON.stringify(posts)}
    </>
  );
};
export default Main;

 

 

💡 SSR(Server Side Rendering) (feat. Next.js)

서버 쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식

 

렌더링 주체

• 서버

 

SSR 동작 과정

1. 유저가 웹사이트에 방문하면, 브라우저가 서버에 콘텐츠를 요청한다.
2. HTML이랑 CSS만 적용된 정적 페이지를 1차로 요청한다.(이때, 유저는 콘텐츠를 볼 수 있다.)
3. 정적 페이지 렌더링 후 자바스크립트 파일을 2차로 요청하고 다운로드한다. 다운 받아지고 있는 사이에 유저는 콘텐츠를 볼 수는 있지만 조작은 불가능하다. 이때의 사용자 조작을 기억한다.
4. JavaScript가 다운 완료되면 자바스크립트를 정적페이지에 기능을 적용하고 (=하이드레이션) 기억하고 있던 사용자 조작을 실행한다.

즉, 서버에서 이미 렌더 가능한 상태로 클라이언트에 전달되기 때문에, JS가 다운로드되는 동안 사용자는 무언가를 볼 수 있다.

이 과정이 더 빠른 이유??
1차 요청 응답은 매우 가벼운 파일이라 빠르게 로드하고 렌더링 할 수 있다(reflow, repaint 다 완료).
2차 요청 응답은 크리티컬 렌더링 패스(화면 렌더링과정) 없이 자스만 입히는 거라 빠르게 로드해서 보여줄 수 있다.

 

데이터 패칭 방법

1. SSR에서 데이터 패칭은 서버 컴포넌트에서 데이터 통신을 하는 것을 말합니다. 서버에서 이루어지기 때문에 사용자 정의 인터렉션 훅(useState) 같은 것을 사용할 수 없습니다.

 

패칭 데이터

1. url이 달라지면 해당 url에 해당하는 컨텐츠(완성된 페이지)를 서버에서 다시 불러옵니다.(= 하드 내비게이션)
   1. 네트워크 탭에서 완성된 페이지를 응답받는지 확인하면서 SSR을 확인할 수 있다.

1. 장점
   1. 로딩 속도
      1. 웹 화면이 렌더링 되기 전인 서버에서 데이터 요청이 발생하기 때문에 빠릅니다.
      2. 한 번 요청한 데이터 통신은 내부적으로 캐시(Cache)되어서 재요청 시 캐시 된 데이터를 활용하기 때문에 응답이 빠릅니다.

기본

const getPosts = async () => {
  const data = await (
    await fetch("https://jsonplaceholder.typicode.com/posts")
  ).json();
  return data;
};

const HomePage = async () => {
  const posts = await getPosts();
  return (
    <>
      <h1>HomePage Component</h1>
      {JSON.stringify(posts)}
    </>
  );
};
export default HomePage;

 

 

 

💡CSR vs SSR (간단 요약)

렌더링 주체

• CSR : 클라이언트
• SSR :서버

 

동작 과정

• CSR : 빈 껍데기 HTML 응답 > CSS, Javascript 로드 후 클라이언트에서 렌더링 
• SSR : 데이터 + HTML + CSS 서버 렌더링 후 정적페이지 응답 > 자바스크립트 로드 후 적용 

 

화면 볼 수 있는 시기

• CSR : 자바스크립트까지 실행되어야 화면 볼 수 있음
• SSR : 1차 정적페이지 응답받으면 볼 수 있음

 

로드 속도

• 첫 페이지 로딩할 때
  • CSR : HTML, CSS, Javascript 한 번에 불러옴 => 많아서 느림
  • SSR : 필요한 부분의 정적페이지와 Javascript만 불러옴 => 가벼워서 빠름
• URL 변경할 때
  • CSR : 이미 모든 코드를 받아왔음 => 빠르게 로딩
  • SSR : 처음 로딩 과정을 반복해야 함 => 느림

 

SEO 대응

• CSR : 자바스크립트를 실행해야 동적 콘텐츠가 생성되기 때문에 크롤러가 읽을 게 없음 => 불리
• SSR : 서버에서 콘텐츠를 넣어서 보내주기 때문에 크롤러가 읽을게 있음 => 대응하기 용이 

 

서버 부하 

• CSR : 클라이언트에 일감을 몰아주기 때문에 서버 부하가 적음
• SSR : 매번 서버 요청을 하기 때문에 서버 자원을 더 많이 사용 (URL만 바뀔 때마다 계속 요청)

 

사용 시기

• CSR: 상호작용이 많은 애플리케이션 => 온라인 게임,
• SSR : 초기 로딩속도, SEO가 중요한 애플리케이션 => 뉴스웹사이트, 마케팅 웹사이트