SSR(Server Side Rendering) ?

SSR(Server Side Rendering) ?

·

2 min read

SSR ?

서버 사이드 렌더링은 클라이언트가 서버에 요청할 때 마다 서버에서 렌더링을 하여 요청에 따른 HTML 을 클라이언트가 받습니다.

  • 렌더링하는 주체자는 서버

렌더링 과정

frontend_rendering_ssr

  1. 클라이언트가 서버에게 페이지를 달라고 요청을 하고

  2. 서버에서 요청에 응답하기 위해 필요한 코드를 실행하는 동작 및 DB 조회나 모든 것을 한 후 HTML 을 만들어서

  3. 만들어진 HTML 을 클라이언트에게 보내줍니다.

SSG, ISR 과의 차이점

렌더링의 주체자가 모두 서버인 것은 동일 하지만 빌드할 때 렌더링 하거나 주기적으로 렌더링을 하는 것과는 반대로

SSR 은 클라이언트에서 요청이 올 때 그 때 마다 페이지를 새롭게 만들어서 전달 합니다.

SSR 장점

  1. 더 빨라진 초기 페이지 접근

    ➡️ 서버 측 렌더링은 서버가 JavaScript 다운로드 및 실행을 기다리는 대신 미리 렌더링된 HTML을 클라이언트에 전송하므로 브라우저에서 웹 사이트를 로드하는 데 걸리는 시간을 개선할 수 있습니다.

  2. SEO 가 좋습니다.

    ➡️ 검색 엔진은 페이지의 전체 HTML 콘텐츠를 볼 수 있으므로 서버측 렌더링 페이지를 더 잘 인덱싱할 수 있습니다. 이것은 더 나은 검색 엔진 순위와 웹 사이트 트래픽 증가로 이어질 수 있습니다.

  3. 자바스크립트가 필요 없습니다.

    ➡️ 자바스크립트 활성화가 되어있지 않아도 빠르게 컨텐츠를 볼 수 있습니다.

  4. 실시간 데이터 사용

    ➡️ 항상 최신의 데이터를 반영한 화면을 받을 수 있습니다.

    ➡️ 요청 할 때 마다 렌더링을 해서 요청하는 사용자에 따라서 사용자에게 맞는 데이터를 제공 할 수 있습니다.

SSR 단점

  1. 서버 부하 증가

    ➡️ 요청 할 때 마다 서버에서 렌더링을 한 후 클라이언트에게 전달하기 때문에 응답 시간이 느려지고 서버에 부하가 증가 될 수 있습니다.

  2. CDN에 캐싱이 어렵습니다.

    ➡️ 요청할 때 마다 페이지를 만들어야 합니다.

  3. 초기 로딩 이후 페이지 이동 시 CSR 보다 느립니다.

    ➡️ 이동 시 마다 클라이언트가 서버에 요청을하고 응답을 받는 방식의 한계

지금까지 여러 렌더링 방법을 알아봤습지만 완벽한 렌더링 방법은 없습니다.


참고

blog

blog2

https://www.patterns.dev/posts/server-side-rendering