0Pricing
Web Performance Optimization & Lighthouse · 강의

서버 측 렌더링(SSR)의 영향

서버 측 렌더링(SSR)과 클라이언트 측 렌더링(CSR)의 성능상 절충점을 평가하고 TTI에 미치는 영향을 분석합니다.

서버 측 렌더링(SSR)의 영향은(는) CoddyKit의 무료 Web Performance Optimization & Lighthouse 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Web Performance Optimization & Lighthouse 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Web Performance Optimization & Lighthouse 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

SSR vs. CSR: The Core Idea

Welcome to understanding how web pages get built! Today, we'll explore two fundamental ways web content reaches your browser: Client-Side Rendering (CSR) and Server-Side Rendering (SSR).

Both have unique impacts on performance, especially how quickly a user can see and interact with your page.

How Client-Side Rendering Works

With CSR, your browser receives a minimal HTML file, often just a blank page with a link to a JavaScript bundle. It's like an empty canvas.

  • Browser downloads HTML: Very small, quickly.
  • Browser downloads JavaScript: This is the main part, often large.
  • JavaScript fetches data & builds UI: After loading, JS executes, calls APIs, and dynamically injects content into the page.

The user sees content only after these steps complete.

CSR Performance & Initial Load

CSR can feel slow initially. The user might see a blank screen or a loading spinner for a noticeable period. This impacts metrics like First Contentful Paint (FCP) and Largest Contentful Paint (LCP).

However, once loaded, subsequent navigation within the app can be very fast, as only data (not full pages) needs to be fetched.

Try this simple CSR example:

<!DOCTYPE html>
<html>
<head>
  <title>CSR Demo</title>
  <style>
    body { font-family: sans-serif; text-align: center; }
    #app { border: 1px solid #ccc; padding: 20px; margin: 20px auto; max-width: 300px; min-height: 50px; }
  </style>
</head>
<body>
  <div id="app"><p>Loading content...</p></div>
  <script>
    document.addEventListener('DOMContentLoaded', () => {
      setTimeout(() => {
        document.getElementById('app').innerHTML = '<h2>Welcome!</h2><p>Content rendered by JS.</p><button>Click Me</button>';
      }, 1000); // Simulate network/processing delay
    });
  </script>
</body>
</html>

How Server-Side Rendering Works

With SSR, the server does the heavy lifting. When a user requests a page, the server processes the request, fetches any necessary data, and constructs the full HTML response.

  • Browser requests page: Sends request to server.
  • Server builds HTML: Fetches data, renders the complete page on the server.
  • Browser receives full HTML: Gets a ready-to-display page.

The user sees content almost immediately as the HTML arrives.

SSR Performance & Initial Load

SSR generally leads to much faster First Contentful Paint (FCP) and Largest Contentful Paint (LCP). Users see meaningful content very quickly, improving perceived performance and SEO.

However, the server must generate the HTML for every request, which can add latency on the server side if not optimized. Let's see an SSR-like output:

<!DOCTYPE html>
<html>
<head>
  <title>SSR Demo</title>
  <style>
    body { font-family: sans-serif; text-align: center; }
    .content { border: 1px solid #ccc; padding: 20px; margin: 20px auto; max-width: 300px; }
  </style>
</head>
<body>
  <div class="content">
    <h2>Welcome!</h2>
    <p>Content rendered directly by the server.</p>
    <button onclick="alert('Hello from SSR!')">Click Me</button>
  </div>
</body>
</html>

Understanding Time To Interactive (TTI)

Time To Interactive (TTI) measures how long it takes for a page to become fully interactive. This means:

  • The page has displayed useful content (FCP/LCP).
  • Event handlers are registered for most visible UI elements.
  • The page responds to user interactions within 50 milliseconds.

TTI is critical because a user can see content but still be unable to click buttons or type into fields if the page isn't interactive.

SSR's TTI Challenge: Hydration

While SSR delivers content quickly, it often sends static HTML. To make this HTML dynamic and interactive, the client-side JavaScript still needs to load and 'take over' the DOM. This process is called hydration.

During hydration, JavaScript attaches event listeners and builds the virtual DOM. If this JS bundle is large, or takes a long time to execute, it can delay TTI even after the content is visible.

Comparing TTI: SSR vs. CSR

The TTI impact differs:

  • CSR: TTI often aligns closely with FCP/LCP, as all content and interactivity are loaded together. If the JS bundle is small, TTI can be fast.
  • SSR: FCP/LCP are fast, but TTI can be delayed if hydration is slow. Users might see content but experience a frustrating 'dead zone' where nothing responds.

The goal is to minimize this gap between visible content and interactive content.

Choosing the Right Approach

Deciding between SSR and CSR depends on your project's needs:

  • SSR is great for: Content-heavy sites (blogs, e-commerce), good SEO, fast initial load for users on slow connections.
  • CSR is great for: Highly interactive web applications (dashboards, social media feeds), where initial load time is less critical than rich user experience post-load.

Hybrid approaches like Static Site Generation (SSG) or Progressive Hydration also exist to combine benefits.

Quick Check: Rendering Strategies

Based on what we've learned, which statements correctly describe the performance trade-offs between Server-Side Rendering (SSR) and Client-Side Rendering (CSR)?

Recap: SSR, CSR & TTI

In this lesson, we explored Server-Side Rendering (SSR) and Client-Side Rendering (CSR). You learned:

  • CSR defers rendering to the browser, potentially slowing initial content display but offering dynamic experiences.
  • SSR renders HTML on the server, providing fast initial content (FCP/LCP) but can delay interactivity (TTI) due to hydration.
  • Time To Interactive (TTI) is crucial, measuring when a page is fully usable.

Choosing between them involves balancing initial load speed, interactivity needs, and the impact of hydration on TTI.

자주 묻는 질문

“서버 측 렌더링(SSR)의 영향” 강의는 무료인가요?

네 — “서버 측 렌더링(SSR)의 영향” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Web Performance Optimization & Lighthouse 강의 전체를 잠금 해제할 수 있습니다. Web Performance Optimization & Lighthouse 강의에는 총 4개의 강의가 포함되어 있습니다.

“서버 측 렌더링(SSR)의 영향”에서 뭘 배우나요?

서버 측 렌더링(SSR)과 클라이언트 측 렌더링(CSR)의 성능상 절충점을 평가하고 TTI에 미치는 영향을 분석합니다. 브라우저에서 직접 실행하는 실습 코드로 Web Performance Optimization & Lighthouse을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Web Performance Optimization & Lighthouse을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Web Performance Optimization & Lighthouse은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“서버 측 렌더링(SSR)의 영향” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Web Performance Optimization & Lighthouse 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Web Performance Optimization & Lighthouse 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. 백엔드 성능 병목
  2. 데이터베이스 쿼리 최적화
  3. 서버 측 렌더링(SSR)의 영향
  4. API 응답 캐싱과 압축
← Web Performance Optimization & Lighthouse(으)로 돌아가기