Skip to content

Latest commit

 

History

History
85 lines (64 loc) · 6.22 KB

SPA_MPA_CSR_SSR.md

File metadata and controls

85 lines (64 loc) · 6.22 KB
Raw

SPA_MPA_CSR_SSR

SPA ↔ MPA

(Single Page Application) ↔ (Multi Page Application)

  • MPA

    • 여러 개(Multiple)의 페이지로 구성된 어플리케이션

    • 새로운 페이지 요청을 할 때마다 정적 리소스 다운로드.

      • 매번 전체 페이지가 다시 렌더링 ⇒ 서버에서 이미 렌더링해서 가져오기 떄문에 첫 로딩 빠름

    • 웹 페이지 화면마다 완성된 정적 html로 보여줌 ⇒ SEO 측면에서 유리함 (크롤링에 적합)

    • 클라이언트가 서버에 페이지 요청시, 클라이언트에게 HTML만 넘겨줌

    • 페이지마다 키워드가 노출되어 있어 검색이 쉬움

    • 매 페이지 요청마다 리로딩 발생 함 ⇒ 페이지 이동마다 “깜빡”

    • 서버렌더링에 의해서 서버에 대한 가중.

    • 페이지를 이동할 때 사용하지 않는 템플릿도 중복해서 로딩함.

  • SPA

    • 하나(Single)의 페이지로 구성된 어플리케이션
    • 웹 애플리케이션에 필요한 모든 정적 리소스를 최초 한 번에 다운로드
      • 이후 새로운 요청이 있을 때 페이지 갱신에 필요한 데이터만 전달 받아서 페이지 갱신 ⇒ “깜빡” 없이 자연스러운 사용자 경험
    • SPA는 CSR 방식으로 렌더링
    • html단 구성이 심플해서 크롤러가 크롤링 해 올 컨텐츠가 없음 
      <body>
	<div id="app"> </div>
    • SPA 방식이 모두 CSR인 것은 아님 ⇒ React는 SPA로 CSR로 렌더링되지만 프레임워크 Next.js를 활용해서 SSR을 할 수 있게 구현이 되어 있음.

SSR ↔ CSR

(Server Side Rendering) ↔ (Client Side Rendering)

  • SSR
    • 서버가 화면 완성 ( 소스코드를 제공하는 쪽)
    • 서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달
    • 서버에서 이미 렌더 가능한 상태로 클라이언트에 전달되어 JS가 다운로드 되는 동안 사용자는 무언가를 보고 있을 수 있음.
  • CSR
    • 클라이언트의 화면 완성 (소스코드를 받은 쪽 (브라우저))
    • SSR과 달리 렌더링이 클라이언트 쪽에서 일어남.
    • 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보냄
    • 서버에서 처리 없이 클라이언트로 보내주기 때문에 JS가 모두 다운로드 되고 실행이 끝나기 전까지 사용자는 볼 수 있는게 없음

차이

  1. 웹페이지 로딩 시간
    1. 첫 페이지 로딩 시간
      1. SSR > CSR
      2. CSR은 HTML, CSS와 모든 스크립트들을 한 번에 불러오고 SSR은 필요한 부분의 HTML과 스크립트만 불러옴
    2. 첫 페이지 이외 로딩 시간 (사이트가 다른 곳으로 이동하는 경우에 ••• )
      1. CSR > SSR
      2. CSR은 이미 다 불러온 상태 / SSR 은 첫 페이지 로딩 과정을 다시 실행
  2. SEO <!! 여기서 가장 중요한 지점 !! >
    1. 검색 엔진은 크롤러로 웹 사이트를 읽는데 •••
      • CSR은 JS를 실행시켜 동적으로 컨텐츠 생성 → JS가 실행되어야지만 메타데이터가 생성되어 크롤러가 읽을 수 있음.
      • SSR은 서버 사이드에서 컴파일되어 클라이언트로 넘어오기 때문에 크롤러 대응에 용이
  3. 서버 자원 사용
    1. SSR > CSR
      1. CSR은 클라이언트 단에서 일을 주로 처리해 서버에 부하가 적음
      2. SSR은 매번 자원을 요청해 서버 자원을 더 많이 사용

⇒ 리액트 프레임워크로 Next를 사용하는 이유도 기존 CSR 환경에서 돌아가던 리액트를 SSR 형태로 구현해 SEO 최적화 하기 위함!!!!!

SSG

  • https://www.daleseo.com/spa-ssg-ssr/

    SSG: Static Site Generator

    정적 사이트 생성기로 번역할 수 있는 SSG(Static Site Generator)는 누가 접속하든 항상 동일한 내용을 보여주는 웹사이트를 만드는데 최적화된 방법이라고 볼 수 있겠습니다. 그래서 제품 카탈로그나 개인 블로그처럼 컨텐츠의 변경이 자주 일어나지 않는 비교적 소규모 웹사이트를 제작할 때 매우 유용한데요. 대표적인 정적 사이트 생성 도구로는 Gatsby, Hugo, Jekyll, Hexo 등을 뽑을 수 있습니다.

    SSG로 생성되는 웹사이트는 모든 웹페이지를 미리 싸그리 만들어놓고 요청이 들어오면 만들어 놓은 웹페이지를 그대로 응답만 해줍니다. 따라서 서버와 클라이언트 측 모두 랜더링을 위해서 할 일이 별로 없기 때문에 SSG로 생성된 웹사이트는 속도가 엄청 빠르다는 특징이 있습니다. 게다가 CDN(Content Delivery Network)을 활용하면 미리 만들어 놓은 웹페이지를 유저와 지리적으로 최대한 가까운 곳에 캐싱(catching)해놓을 수도 있습니다.

    SSG는 Headless CMS(Content Management System)와 궁합이 잘 맞아서 함께 사용하기 좋은데요. 일반적으로 Headless CMS에 저장해놓은 모든 컨텐츠를 빌드(build) 시점에 API를 통해 몽땅 읽어와서 웹페이지로 만들어내는 경우가 많습니다.

    SSG로 생성된 웹사이트는 하나의 웹페이지에서 돌아가는 SPA와 달리, 미리 만들어놓은 수 많은 웹페이지로 이루어졌기 때문에 검색 엔진이 크롤링하기 매우 적합한 구조를 가지게 됩니다. 따라서 검색 엔진 최적화(SEO)가 중요한 마켓팅 웹사이트를 제작할 때는 SSG가 매우 보편적으로 사용되고 있습니다.

    SSG의 가장 큰 단점은 아무래도 빌드 시점에 웹사이트 전체를 매번 다시 만들어 내다 보니 컨텐츠가 자주 업데이트되는 웹사이트에서는 큰 비효율이 발생하게 됩니다. 보통 웹사이트의 규모가 커지면 자연스럽게 빌드(build) 시간이 길어지는데, 이러면 변경된 컨텐츠가 웹사이트에 반영되는데 시간이 점점 오래 걸리 게 되기 때문입니다.

    요즘에는 이러한 약점을 극복하기 위해서 정적 사이트 생성기가 전체 웹사이트를 재생성 하는 대신에 변경이 필요한 웹페이지만 골라서 업데이트 해주는 똑똑한 기능을 제공하고 있습니다.