SEO (CSR, SSR, SSG)

김선우·2022년 6월 30일
0

웹 페이지를 렌더링하는 방식에는 크게 CSR, SSR이 있고, 각각의 정의와 특징 및 장단점, 더해서 SSG까지 알아보도록 하자. 또한 이러한 렌더링 방식이 SEO(검색엔진 최적화)에 얼마나 유리한지 까지도 짚어볼 것이다.

  • SEO
    검색엔진 최적화, 즉 검색엔진에서 찾기 쉽도록 사이트를 개선하는 프로세스이다. 대표적인 방식으로는 특정 검색어를 웹 페이지에 적절하게 배치하고 다른 웹 페이지에서 링크가 많이 연결되도록 하는 것이다.

웹페이지를 렌더링 하는 방식에 따라 SEO에 영향을 미친다. 아래는 렌더링 방식과 그에 대한 설명이다.

  • CSR: Client Side Rendering의 약자, 렌더링이 클라이언트 쪽에서 일어난다.
    즉, 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다.
  • SCR: Server Side Rendering의 약자. 서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식이다.

랜더링이 되는 영역의 관점에서 봤을 때, CSR, SSR은 서로 상반되는 개념이다.

또한,

  • SSG: Static Site Generator의 약자, SSR처럼 서버로부터 완성된 HTML을 받아오지만, 다른 점은 HTML 파일의 생성시점이 빌드 타임이라는 것이다.

CSR

브라우저(클라이언트 측에서) 웹페이지를 렌더링 하는 것을 뜻한다. 모든 데이터, 로직, 라우팅은 서버가 아니라 클라이언트 측에서 처리된다.

CSR의 경우 자바스크립트 번들의 크기에 영향을 많이 받기 때문에, 세심한 코드분할 (code-spliting)이 고려되며, '필요한 것만 필요할 때' 제공해야 한다.

  • CSR 동작 방식

    일반적으로 아래와 같이 동작한다.
  1. 사용자가 웹 페이지를 방문하면(request), 브라우저는 최소한의 HTML 파일을 다운로드(response) 한다. 이 HTML 파일은 script, meta, link 등의 태그를 포함하며, 빈 컨텐츠의 index.html 파일이라고 보면 된다.
    브2. 라우저는 index.html에 있는 자바스크립트 번들 파일을 다운로드한 다음 AJAX를 통해 API 요청을 수행하여 동적 컨텐츠를 가져오고 파싱하여 최종 컨텐츠를 렌더링한다.
  2. 사용자가 페이지를 이동할 경우, 서버에 추가 HTML파일을 요청하지 않고 이미 받은 자바스크립트를 이용하여 렌더링 한다.
  • CSR 장점

  1. 후속 페이지 로드 시간이 더 빠르다. CSR을 위해 이미 모든 지원 스크립트가 사전에 로드되었기 때문에 CSR의 로드 시간이 줄어든다.
  2. 별도의 API를 호출할 필요가 없는 페이지이거나 지연 로딩 모듈이 필요하지 않다, 이미 스크립트가 캐싱된 경우 인터넷 없이도 해당 CSR 웹 애플리케이션을 실행할 수 있다.
  3. CSR은 서버를 호출할 때마다 전체 UI를 다시 로드할 필요가 없다.
  • CSR 단점

  1. 초기 페이지 로드 시간이 SSR에 비해 느리다. CSR을 사용하면 브라우저는 브라우저에서 사용 가능한 컨텐츠로 HTML을 컴파일하기 전에 기본 HTML, CSS 및 모든 필수 스크립트를 로드하기 때문이다.
  2. SEO에 친화적이지 않다. 검색 엔진 크롤러가 해당 페이지에 처음 방문했을때는 빈 페이지이기 때문에 이해할 수가 없다. 물론 자바스크립트를 실행시킬 수 있는 구글 크롤러와 같은 검색엔진 크롤러가 등장하고 있긴하지만, 아직 많은 검색 엔진 크롤러들이 지원되지 않는다.
  3. 브라우저가 페이지를 표시하기 전에 HTML 및 JavaScript 파일을 다운로드하고 프레임 워크를 실행하는 동안 사용자는 빈페이지를 보게 되므로 사용자 경험(UX)가 좋지 않다.
    클라이언트의 하드웨어 및 소프트웨어에 너무 많이 의존한다. 사용자 기기에 따라, 하위 지원되는 하드웨어 및 소프트웨어 사용자라면, 최적의 시간에 페이지를 렌더링하지 못하게 될 확률이 크다. 페이지의 이탈률은 페이지 로드시간에 정비례한다. 또한 이탈률이 높을수록 검색엔진 순위도 낮아 질 수 있다.

SSR

클라이언트측 또는 유니버셜 앱을 서버의 HTML로 렌더링하는 방식이다.

이렇게 하면 브라우저에서 응답을 받기 전에 데이터 패칭 및 템플릿 작성이 처리되므로 클라이언트에서 위 행위에 대 추가 왕복이 발생하지 않는다.

  • SSR 동작 방식

  1. 가 웹 페이지를 방문하면(request), 서버는 리소스를 확인하고 페이지 내에 있는 서버측 스크립트를 실행 후 HTML 컨텐츠를 컴파일 및 준비한다.
  2. 된 HTML은 추가 렌더링 및 표시를 위해 클라이언트 브라우저로 전송된다(response).
  3. 저는 HTML을 다운로드하고 최종 사용자가 사이트를 볼 수 있도록 한다.
  4. 저는 자바스크립트를 다운로드하고 실행하면서 페이지를 대화형(interactive)으로 만든다.
  5. 가 페이지를 이동할 경우, 위 동작을 반복한다.
  • SSR의 장점

  1. 초기 페이지 로드시간이 빠르다(FP 및 FCP가 빠르다). 렌더링이 준비된 HTML 파일을 브라우저에서 로드하기 때문에 CSR에 비해 더 빠르다.
  2. 서버에서 페이지 로직 및 렌더링을 실행하면 많은 자바스크립트를 클라이언트에 보내지 않아도 되므로 TTI(Time to Interactive)를 빠르게 수행할 수 있다.
  3. SEO에 친화적이다. 이미 다 만들어진 페이지를 검색엔진 크롤러가 요청에 대한 응답으로 받기 때문이다.
  4. 클라이언트 하드웨어 및 소프트웨어 성능에 영향을 덜 받는다. 일반적으로 서버는 더 높은 컴퓨팅 성능과 훨씬 더 높은 네트워킹 속도를 가진 시스템이다. 클라이언트에서는 서버에서 완성된 페이지만 렌더링해 주면 된다. 즉 클라이언트의 부담이 CSR에 비해 덜하다.
  • SSR 단점

  1. 페이지 이동시마다 서버에서 페이지를 생성하는데 시간이 걸리기 때문에 TTFB(Time to First Byte)가 느리다.
  2. 페이지 로드가 너무 무겁다면, 오히리 사용자 경험을 개선하는게 아니라 해칠 수 있다. 초기 페이지 로드시 데이터가 많이 필요한 대시 보드가 예가 될 수 있다.
  3. 서버는 항상 각 요청이 올때마다 HTML파일을 생성하기 때문에 CDN 수준에서의 컨텐츠 캐시가 되지 않는다.

CDN : aws의 cloudflare를 생각하면 됨. 엔드 유저의 요청에 '물리적'으로 가까운 서버에서 요청에 응답하는 방식

  1. 서버의 호스팅이 필요하다. 클라이언트에서 자바스크립트를 이용해 렌더링하는 CSR에 비해 서버 사이드에서 HTML파일과 안에 내용을 생성해야 하기 때문에 서버 호스팅이 필요하다.
  2. CSR에 비해 더 많은 개발 노력이 필요하며, SSR 프레임워크를 사용한다면 추가적인 러닝 커브에 대한 비용이 발생한다.

두 방식의 장,단점은 다른 한쪽의 단, 장점이라고 봐도 무방할 정도로 서로 반대이다. 완전한 중간은 아니지만 SSG라는 기법을 둘의 중간 쯤이라고 보고있다.

SSG

SSR처럼 서버로부터 완성된 HTML을 받아오지만, 다른 점은 HTML 파일의 생성시점이 빌드 타임이라는 것이다. Static이라는 용어가 들어간 것은 HTML이 정적이라는 것이지 페이지가 정적이라는 것이 아니다.

  • SSG 동작방식

  1. 사용자가 웹 페이지를 방문하면(request), 엣지 캐싱(edge caching)된 HTML 클라이언트로 반환해 준다.
  2. 브라우저는 HTML을 다운로드하고 최종 사용자가 사이트를 볼 수 있도록 한다.

edge caching: 최종 사용자에게 더 가까운 컨텐츠를 저장하기 위해 캐싱 서버를 사용하는 것이다. 대표적으로 CDN을 많이 사용한다.

  • SSG 장점

  1. 빌드 타임에 HTML 파일이 생성되기 때문에 빠른 FP, FCP, TTI를 제공한다. 또한 매 요청마다 생성하는 것이 아니므로, SSR과 달리 일관성있게 빠른 TFB를 달성할 수 있다.
  2. 이미 생성된 HTML 파일을 받기 때문에 SEO 친화적이다.
  3. build 명령은 실제로 사이트를 방문하는 사람의 워크플로를 벗어나므로 시간이 좀 걸리더라도 문제되지 않는다.
  • SSG 단점

  1. 모든 URL에 대해 개별 HTML 파일을 생성해야 한다. 따라서 URL을 미리 예측할 수 없거나 URL을 예측할 수 없으면 적용이 어렵다.
profile
생각은 나중에..

0개의 댓글