Post

브라우저 렌더링 방식

Posted Updated
By BoKyung
14 min read
브라우저 렌더링 방식

1. 클라이언트 사이드 렌더링 (CSR, Client-Side Rendering)

사용자의 브라우저 (클라이언트) 에서 자바스크립트를 이용해 동적으로 페이지를 렌더링하는 방식

작동 방식

  1. 사용자가 웹사이트에 접속하면 서버는 최소한의 HTML 파일과 자바스크립트 파일을 보냅니다.

  2. 브라우저는 이 자바스크립트 파일을 다운로드하고 실행하여 페이지를 동적으로 생성하고 콘텐츠를 표시합니다.

  3. 페이지 이동 시에는 전체 페이지를 다시 로드하는 대신, 필요한 데이터만 서버에서 받아와 해당 부분만 업데이트합니다.

장점

  1. 빠른 페이지 전환: 초기 로딩 후에는 필요한 데이터만 받아오므로 페이지 간 이동이 빠르고, 부드러운 UX를 제공합니다.

  2. 서버 부하 감소: 렌더링을 클라이언트에서 처리하므로 서버의 부담이 줄어듭니다.

  3. 풍부한 사용자 인터랙션: 동적인 UI/UX 구현에 유리하여 복잡한 웹 애플리케이션에 적합합니다.

단점

  1. 느린 초기 로딩 속도: 초기 접속 시 전체 자바스크립트 파일을 다운로드하고 실행해야 하므로 첫 페이지가 보이는 데까지 시간이 걸릴 수 있습니다.

  2. SEO의 어려움: 검색 엔진 크롤러가 초기의 빈 HTML 페이지만 수집할 수 있어 콘텐츠를 제대로 인식하지 못할 수 있습니다.

2. 서버 사이드 렌더링 (SSR, Server-Side Rendering)

사용자가 요청할 때마다 서버에서 완전한 HTML 파일을 생성하여 클라이언트에 전달하는 방식입니다.

작동 방식

  1. 사용자가 웹사이트에 요청을 보냅니다.

  2. 서버는 요청에 맞춰 렌더링이 가능한 HTML 파일을 동적으로 생성합니다.

  3. 완성된 HTML 파일을 클라이언트에 전달하여 즉시 페이지를 보여줍니다.

  4. 이후 브라우저에서 자바스크립트 파일을 다운로드하고 실행하여 페이지의 상호작용을 가능하게 합니다.

장점

  1. 빠른 초기 로딩 속도: 서버에서 완성된 HTML을 제공하므로 사용자가 콘텐츠를 빠르게 볼 수 있습니다.

  2. SEO에 유리: 검색 엔진 크롤러가 완성된 HTML 콘텐츠를 쉽게 수집하고 인덱싱할 수 있습니다.

단점

  1. 서버 부하 증가: 모든 요청마다 서버에서 페이지를 생성해야 하므로 서버에 부담이 갈 수 있습니다.

  2. 페이지 이동 시 깜빡임: 페이지를 이동할 때마다 전체 페이지를 새로고침하므로 화면 깜빡임이 발생할 수 있습니다.

3. 정적 사이트 생성 (SSG, Static Site Generation)

웹사이트를 빌드하는 시점에 미리 HTML 파일을 생성하여 서버에 배포하는 방식입니다.

작동 방식

  1. 개발이 완료되고 빌드하는 시점에 모든 페이지에 대한 HTML 파일이 미리 생성됩니다.

  2. 생성된 정적 파일들은 서버나 CDN에 배포됩니다.

  3. 사용자가 페이지를 요청하면 미리 생성된 HTML 파일이 즉시 전달됩니다.

장점

  1. 매우 빠른 로딩 속도: 미리 생성된 정적 파일을 제공하기 때문에 로딩 속도가 매우 빠릅니다.

  2. 강력한 SEO: 모든 페이지가 완전한 HTML 형태로 존재하기 때문에 검색 엔진 최적화에 매우 유리합니다.

  3. 서버 부하 최소화: 단순히 정적 파일만 제공하기 때문에 서버의 부담이 거의 없습니다.

단점

  1. 데이터 변경 시 재빌드 필요: 콘텐츠가 변경될 때마다 전체 사이트를 다시 빌드하고 배포해야 합니다.

  2. 동적 콘텐츠 처리의 한계: 실시간 데이터나 사용자 맞춤형 콘텐츠를 제공하기 어렵습니다.

렌더링 방식 선택

  • CSR: 사용자 상호작용이 많고 복잡한 대화형 웹 애플리케이션 (ex. SNS 피드, 대시보드 등)

  • SSR: SEO가 중요하고, 실시간으로 데이터가 변경되는 콘텐츠 중심의 웹사이트 (ex. 뉴스 사이트, 이커머스 플랫폼 등)

  • SSG: 콘텐츠 변경이 잦지 않고, 빠른 로딩 속도가 중요한 정적 웹사이트 (ex. 랜딩 페이지, 블로그, 기술 document 등)

최근에는 Next.js와 같은 프레임워크를 통해 SSR과 SSG의 장점을 결합한 하이브리드 렌더링 방식을 사용하기도 합니다. 예를 들어, 자주 변경되지 않는 페이지는 SSG로 미리 생성하고, 실시간 데이터가 필요한 페이지는 SSR로 처리하여 성능과 사용자 경험을 모두 개선할 수 있습니다.

웹사이트 분석

핵심 원칙은 서버가 보낸 첫 HTML에 최종 콘텐츠가 담겨있는지 여부 입니다.

  1. 페이지 소스 보기
    • JavaScript 가 실행되기 전, 서버로부터 받은 HTML을 확인하는 방식입니다.

  • 분석 방법: 마우스 오른쪽 버튼 클릭 > ‘페이지 소스 보기’

  • 결과 분석

    • SSR/SSG 의심: <body> 태그 안에 페이지에서 보이는 주요 텍스트 콘텐츠 (<title>, <meta name="description"> 등)이 그대로 보입니다.
      1
2
3
4
5
6

      <body>
  <main>
    <h1>오늘의 주요 뉴스: AI 기술의 발전</h1>
    <p>인공지능 기술이 빠르게 발전하며...</p>
  </main>
</body>
    • CSR 의심: <body> 태그 안이 거의 비어있고, <div id="root"></div> 와 같이 뼈대 역할만 하는 태그가 보입니다. 의미 있는 콘텐츠가 없으며, 용량이 큰 js 파일이 링크되어 있습니다.
      1
2
3
4

      <body>
  <div id="root"></div>
  <script src="/static/js/bundle.js"></script>
</body>
  1. JavaScript 비활성화
    • CSR은 JavaScript 없이 동작할 수 없습니다. 이 점을 이용하여 렌더링 방식을 명확히 구분할 수 있습니다.
  • 분석 방법

    • 개발자 도구 켜기 (F12)

    • 명령어 팔레트 실행 (Ctrl+Shift+P 또는 Cmd+Shift+P)

    • javascript 입력 후, Disable JavaScript 선택

    • 페이지 새로고침

  • 결과 분석

    • SSR/SSG 확신: 주요 콘텐츠가 대부분 그대로 표시됩니다.

    • CSR 확신: 빈 페이지가 나오거나, 로딩 아이콘, 또는 JavaScript 활성화 요청 메시지가 나타납니다.

  1. 네트워크 탭 분석 → 하이브리드 방식 확인
    • 위 과정을 통해 SSR/CSR 기본 구분은 가능합니다. 다만, 현대적인 프레임워크는 하이브리드 방식을 사용하기도 합니다.

  • 첫 페이지는 SSR/SSG로 로드하고, 이후의 페이지 이동은 CSR(SPA) 처럼 동작하는 방식입니다.

  • 분석 방법

    • 개발자 도구 > 네트워크 탭으로 이동

    • 첫 페이지 로딩 확인

    • 네트워크 기록을 지우지 않고, 웹사이트 내부의 다른 페이지로 이동

  • 결과 분석
    • 전통적인 SSR (Multi-Page Application)

      • 페이지 이동 시 새로운 HTML 문서 (Document) 요청이 목록 최상단에 나타납니다.

      • 즉, 페이지를 이동할 대마다 서버로부터 새로운 HTML을 통째로 받아옵니다.

      • ex. Spring Boot + Thymeleaf, PHP, JSP 등

    • 하이브리드 SSR/SSG (Next.js, Nuxt.js 등)

      • 첫 페이지 로딩 시 첫 문서 (Document) 응답에 콘텐츠가 포함되어 있습니다.

      • 페이지 이동 시 새로운 HTML 문서 요청이 보이지 않습니다. 대신, Fetch/XHR 필터에 보이는 JSON 데이터나 JS 파일만 비동기적으로 호출합니다.

하이브리드 방식 (App Shell + CSR)

  • 하이브리드 방식을 사용할 경우, 첫 페이지에 <head> 태그가 채워져있을 수 있습니다.

  • <head> 태그는 SEO에 필수적인 요소들이 들어있기 때문에, CSR을 사용하지만 <body> 가 비어있는 HTML을 서빙할 때 <head> 태그를 채워서 보내는 방식입니다.

  1. 서버의 역할 (SSR/SSG 부분):
    • 사용자가 페이지를 요청하면, 서버는 즉시 응답을 보냅니다.
  • 이때 보내는 HTML은 App Shell (껍데기) 입니다. 이 껍데기에는 검색 엔진 최적화(SEO)에 필수적인 **<head>** 태그(title, meta description 등)가 완벽하게 포함되어 있습니다.
    • 이 내용은 ‘페이지 소스 보기’ 에서 확인할 수 있습니다.
  • 하지만 <body> 태그 안에는 실제 콘텐츠가 아닌, 앱을 구동할 JavaScript를 로드하는 코드와 최소한의 뼈대(스켈레톤 UI 포함)만 들어있습니다.
  1. 브라우저의 역할 (CSR 부분):
    • 브라우저는 이 껍데기 HTML을 받습니다.

  • 그 후, HTML에 포함된 JavaScript 파일들을 다운로드하고 실행합니다.

  • 이 JavaScript가 API 서버에 데이터를 요청하고, 응답받은 데이터로 실제 페이지 콘텐츠를 동적으로 그려 **<body>** 내부를 채웁니다. 이것이 CSR의 동작 방식입니다.

이 방식은 다음과 같은 서비스에 특히 효과적입니다.

  • 사용자 인증이 필수적인 웹 앱: 마이페이지, 대시보드, 관리자 페이지 등 (검색 엔진에 노출될 필요 없는 개인 정보는 CSR로 안전하게 처리)

  • 초기 로딩이 매우 중요한 서비스: 검색 엔진에는 서비스의 정체성을 알리고, 사용자에게는 앱과 같은 빠른 인터랙션을 제공하고 싶을 때

CS
Crawling Web
This post is licensed under CC BY 4.0 by the author.