초기의 웹 사이트

MPA (Multi Page Application)

1. 클라이언트가 서버에 리소스를 요청하고 서버에서는 해당 요청에 맞는 페이지의 HTML 파일을 응답해준다.

2. 그 후에 애플리케이션에서 링크를 이동하거나 서버에 변경 사항을 요청 했을 때, 서버에서는 새로운 HTML 파일을 응답해준다.

이러한 불편함들과 이전보다 웹 내에서의 유저 인터랙션이 많아진 점, 컴퓨터의 성능이 증가한 점, 모바일 사용자가 늘어나 연속되는 페이지 간의 유저 경험을 중요시하게 되면서 SPA 웹 어플리케이션이 등장했고 많이 사용되게 되었다.

SPA (Single Page Application)

1. 초기에 서버에 리소스를 요청하고 서버에서는 해당 요청에 맞는 페이지의 HTML 파일을 응답해준다.

2. 그 후에 애플리케이션에서 링크를 이동하거나 서버에 변경 사항이 있어도 서버에는 AJAX를 통해 필요한 부분만 요청을 하고 서버에서도 변경할 부분의 데이터만 응답해 불필요한 서버 요청을 줄였다.

AJAX (Asynchronous JavaScript And XML)

JavaScript와 XML (현재는 대부분 JSON)을 이용해 서버와 필요한 부분만 요청하고 응답 받는 기법이라고 할 수 있다.

AJAX를 통해 변경이 필요한 부분만 서버에 요청하고 응답 받으면서 MPA의 단점이었던 페이지 깜박거림과 지연 시간을 줄여 서버 부하 감소와 사용자 경험을 높였다.

웹의 렌더링 방식

CSR (Client Side Rendering)

1. 클라이언트가 서버에 요청을 하면 하나의 빈 HTML파일을 브라우저에 응답해준다.

2. HTML파일에는 내용이 없기 때문에 브라우저는 즉시 JS 파일을 다운로드한다.

3. JS 파일을 다운로드 후에 자바스크립트를 통해 동적으로 화면을 렌더링한다. 화면이 브라우저에 보이는 순간부터 사용자는 상호작용이 가능하다.

4. 이 후에 페이지 이동할 때는 AJAX를 이용해 서버에 필요한 부분만 요청해 화면을 렌더링한다.

"use client";

import { useEffect, useState } from "react";

async function fetchPosts() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const data = await res.json();
  return data;
}

export default function CSRPage() {
  const [post, setPost] = useState([]);

  useEffect(() => {
    fetchPosts().then((data) => {
      setPost(data);
      console.log("csr - render");
    });
  }, []);

  return (
    <main>
      <h1>CSR PAGE</h1>
      {JSON.stringify(post)}
    </main>
  );
}

SSR (Server Side Rendering)

1. 클라이언트가 서버에 요청을 하면 클라이언트의 요청에 맞는 HTML파일을 컴파일 후에 브라우저에 응답해준다.

2. 브라우저는 HTML 파일을 화면에 렌더링한다.이 때부터 JS파일을 다운로드한다.

3. JS파일이 모두 다운로드되면 사용자와의 상호작용이 가능해진다.

4. 이 후에 페이지 이동할 때는 똑같이 서버에서 미리 렌더링 한 HTML파일을 응답해주는 과정이 반복된다.

async function fetchPosts() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts", {
    cache: "no-store",
  });
  const data = await res.json();
  return data;
}

export default async function SSRPage() {
  const posts = await fetchPosts();
  console.log("ssr - render");

  return (
    <main>
      <h1>SSR PAGE</h1>
      {JSON.stringify(posts)};
    </main>
  );
}

SSG

async function fetchPosts() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts", {
    cache: "force-cache",
  });
  const data = await res.json();
  return data;
}

export default async function SSGPage() {
  const posts = await fetchPosts();
  console.log("ssg - render");

  return (
    <main>
      <h1>SSG PAGE</h1>
      {JSON.stringify(posts)};
    </main>
  );
}

ISR

async function fetchPosts() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts", {
    next: { revalidate: 100 },
  });
  const data = await res.json();
  return data;
}

export default async function ISRPage() {
  const posts = await fetchPosts();
  console.log("isr - render");

  return (
    <main>
      <h1>ISR PAGE</h1>
      {JSON.stringify(posts)};
    </main>
  );
}

실험하기

TTFB (Time to Fisrt Byte)

• 정의: 사용자가 페이지 요청을 보낸 순간부터, 브라우저가 서버로부터 첫 번째 바이트의 응답을 받기까지 걸린 시간.

• 의미: 네트워크와 서버 성능을 모두 반영하는 지표.
→ 서버 렌더링(SSR)에서는 특히 중요하고, CDN 캐싱(SSG/ISR)에서는 크게 단축됨.

for r in csr ssr ssg isr; do
  awk -F',' -v r="$r" '$2~"route="r && $3~"mode=warm"{
    for(i=1;i<=NF;i++) if($i~/^ttfb=/){split($i,a,"="); print a[2]}
  }' perf.csv | sort -n | awk -v r="$r" '{
    a[NR]=$1
  } END {
    if(NR){ m = (NR%2)?a[(NR+1)/2]:(a[NR/2]+a[NR/2+1])/2; printf "%s TTFB_p50=%fs\n", r, m }
  }'
done

LCP (Largest Contentful Paint)

• 뷰포트 내에서 가장 큰 콘텐츠(보통 이미지나 큰 텍스트 블록)가 화면에 뜨는 시점
→ 사용자 체감 로딩 속도

INP (Interaction to Next Paint)

• 사용자가 클릭/탭/타이핑 등 입력했을 때 화면이 반응해 다시 페인트되는 데 걸린 시간
→ 인터랙션 체감 반응 속도

FID (First Input Delay)

• 사용자가 페이지에서 처음으로 입력(클릭, 탭, 키 입력 등)을 했을 때,
브라우저가 그 입력을 실제로 처리하기 시작하기까지 걸린 시간.

• “페이지가 처음으로 반응할 수 있는 시점”을 보여주는 지표.

정리

• LCP → “언제 보여?” (화면 보이는 속도)

• FID → “첫 입력에 바로 반응해?” (첫 클릭/탭 반응 속도)

• INP → “계속 반응 잘해?” (전체 상호작용 반응성)

• TTFB → “서버에서 얼마나 빨리 응답 시작해?” (네트워크+백엔드 성능)

지표가 커질 때 의미하는 것

LCP (Largest Contentful Paint)

• 크면:
• 화면에 표시되는 주요 이미지/텍스트 용량이 크거나 (예: 큰 hero image)
• 네트워크 대역폭이 느리거나
• JS/CSS 파싱·렌더링이 오래 걸려서 콘텐츠가 늦게 그려짐.

• 즉, 리소스 크기 + 네트워크 속도 + 렌더링 성능의 영향을 받음.

INP (Interaction to Next Paint)

• 크면:
• 메인 스레드가 무거운 JS 실행에 막혀 있음 (예: 무거운 연산, 이벤트 핸들러 최적화 안 됨).
• React 같은 프레임워크가 리렌더링을 너무 많이 해서 반응 지연.
• 디바이스 성능이 낮아도 INP가 커질 수 있음.

• 즉, 코드 최적화 부족 + CPU 부하 + JS 블로킹 문제.

FID (First Input Delay)

• 크면:
• 초기 로딩 시 JS 번들이 너무 커서, 브라우저 메인 스레드가 실행 끝날 때까지 입력을 처리 못 함.
• SPA에서 hydration이 길어질 때 흔히 발생.

• 즉, 초기 JS 번들 크기 + hydration 지연 문제.

TTFB (Time To First Byte)

• 크면:
• 서버 응답이 느림 (DB 쿼리 지연, SSR에서 API 호출 지연).
• 네트워크 왕복(RTT)이 멀어서 발생 (예: 한국에서 미국 서버 요청).
• CDN 캐시 미스(cache miss)로 원 서버까지 다녀오는 경우.

• 즉, 네트워크 지연 + 서버 처리 속도 + 캐싱 전략 문제.

Reference

웹의 페이지 구성 방식과 렌더링 방식

초기의 웹 사이트는 유저 인터랙션이 적고 컴퓨터의 성능이 그다지 좋지 않았기 때문에 단순히 HTML과 CSS를 이용해서 페이지를 보여주기만 하는 정적인 애플리케이션이 많았다.그렇기 때문에 페이지에 맞는 HTML 파일을 만들어놓고 클라이언트가 요청했을 때 그에 맞는 페이

https://velog.io/@davidktlee/%EC%9B%B9%EC%9D%98-%ED%8E%98%EC%9D%B4%EC%A7%80-%EA%B5%AC%EC%84%B1-%EB%B0%A9%EC%8B%9D%EA%B3%BC-%EB%A0%8C%EB%8D%94%EB%A7%81-%EB%B0%A9%EC%8B%9D

Next.js 에서 알아보는 4가지의 렌더링 방식 (CSR, SSG, ISR, SSR)

Next.js는 리액트 기반의 웹 프레임워크로, 다양한 렌더링 방식을 제공한다.오늘은 Next.js 14 버전부터 등장한 App Router를 기반으로 CSR, SSG, ISR, SSR를 적용하는 방법에 대해 알아볼 것이다.  초기 설정앞으로의 예시에서 실제 데이터환경을 구성하여 렌더링 방식이 어떻게 동작하는지 확인할 것 이다.json-server를 사용하여 간단한 API 서버를 구축하고, 이를 통해 Next.js의 다양한 렌더링 방식에서 데이터를 가져오는 과정을 살펴볼 것이다. 1. Next.js 프로젝트 생성$ npx create-next-app@15.2.1 [project_name]설정 옵션으로는 app router를 사용하였고, 이 외에는 자유롭게 선택해도 된다. 2. json-server 설치 ..

https://llddang-blog.tistory.com/82