(번역) 리액트 개발자를 위한 SSR 심층 분석

원문: https://www.developerway.com/posts/ssr-deep-dive-for-react-developers

지금부터 리액트의 서버 사이드 렌더링(SSR), 사전 렌더링(pre-rendering), 하이드레이션(hydration) 및 정적 사이트 생성(SSG)이 작동하는 방식, 비용, 성능에 미치는 영향, 이점 및 장단점에 대해 단계별로 살펴보시죠.

이전 글에서는 리액트 개발자를 위한 초기 로드 성능 심층 분석하기와 인기 있는 이유, 성능 플레임 차트를 기록하고 읽고 해석하는 방법에 대해 알아보았습니다. 또한 클라이언트 사이드 렌더링의 가장 중요한 두 가지 단점, 즉 초기 로딩 성능에 부정적인 영향을 미치고 자바스크립트가 없는 환경에서는 작동하지 않는다는 사실도 알게 되었습니다.

이 글에서는 SSR이라는 또 다른 렌더링 패턴과 사전 렌더링 및 SSG와 같은 변형을 소개함으로써 이러한 단점을 해결하는 데 초점을 맞출 것입니다. 아름다운 웹사이트를 위한 가장 간단한 사전 렌더링을 구현하고 그 비용과 해결 방법을 살펴본 다음, 적절한 SSR을 구현하고 성능 영향을 측정하고 SSR의 비용에 관해 이야기하고 웹사이트를 위한 SSG의 빠른 구현으로 마무리하는 스터디 프로젝트가 다시 시작됩니다.

이번 내용은 흥미진진할 것입니다!

자바스크립트가 없는 환경이 중요한 이유

먼저 자바스크립트가 없는 환경부터 시작하겠습니다. 그런데 이 말은 굉장히 의아할 수 있습니다. 요즘 누가 브라우저에서 자바스크립트를 비활성화하나요? 모든 곳에서 기본적으로 활성화되고, 자바스크립트 없이 작동하는 것은 거의 없으며, 대부분의 사람은 자바스크립트를 비활성화할 줄도 모릅니다. 그렇죠?

여기서 답은 “사람”이라는 단어에 있습니다. 더 정확히 말하자면, 웹사이트에 액세스할 수 있는 사람이 실제 사람만이 아니라는 사실에 있습니다. 이 분야의 두 가지 주요 플레이어가 있습니다.

• 검색 엔진 로봇(크롤러), 특히 구글 크롤러.
• 다양한 소셜 미디어 및 메신저의 '미리보기' 기능.

모두 비슷한 방식으로 작동합니다. 먼저 어떻게든 웹사이트 페이지의 URL을 가져옵니다. 이는 일반적으로 사용자가 소셜 미디어 친구들과 페이지 링크를 공유하려고 할 때 발생합니다. 또는 검색 봇이 온라인에 공개된 수백만 개의 페이지를 무의식적으로 크롤링할 때 발생합니다. 그래서 크롤러라고 불리는 것입니다.

둘째, 봇은 처음에 브라우저가 하는 것처럼 서버로 요청을 전송하고 HTML을 수신합니다.

셋째, 봇은 해당 HTML에서 원하는 정보를 추출하여 처리합니다. 검색 엔진은 텍스트, 링크, 메타 태그 등과 같은 정보를 추출합니다. 이를 바탕으로 검색 색인을 생성하고 페이지가 “구글 검색 가능” 상태가 됩니다. 소셜 미디어 미리보기는 메타태그를 가져와 큰 사진, 제목, 때로는 짧은 설명과 함께 우리가 모두 보았던 멋진 미리보기 기능을 만듭니다.

마지막으로 네 번째... 사실, 네 번째는 없을 때도 있습니다. 그게 다입니다. 자바스크립트 없이 순수한 HTML만 있습니다. 자바스크립트로 페이지를 제대로 렌더링 하려면 로봇이 실제 브라우저를 구동하고 자바스크립트를 로드한 다음 페이지 생성이 완료될 때까지 기다려야 하기 때문입니다. 이는 리소스와 시간 측면에서 상당히 큰 비용이 소요됩니다. 따라서 모든 로봇이 이를 수행할 수 있는 것은 아닙니다.

스터디 프로젝트에서 실제로 작동하는 모습을 확인할 수 있습니다. 다운로드하고 의존성을 설치합니다.

npm install

빌드하고 시작하세요.

npm run build
npm run start

홈(Home)과 설정(Setting) 사이를 탐색합니다. 탐색을 통해 페이지의 제목이 변경되는 것을 볼 수 있습니다. 홈(Home) 페이지는 "Study project: Home"으로, 설정(Setting) 페이지는 "Study project: Settings"로 변경됩니다.

이 제목은 다음과 같은 간단한 코드로 리액트에 삽입됩니다.

useEffect(() => {
  updateTitle("Study project: Home");
}, []);

내부 코드는 이게 전부입니다.

export const updateTitle = (text: string) => {
  document.title = text;
};

그러나 처음 로드할 때 잠시 "깜박이는" 것을 볼 수 있는데, 이는 기본 제목이 "Vite + React + TS"이기 때문입니다. 이는 index.html에 있는 제목이고 결과적으로 서버에서 받는 제목입니다.

이제 ngrok(또는 유사한 도구가 있는 경우)을 사용하여 웹사이트를 외부에 노출합니다.

ngrok http 3000

생성된 URL을 원하는 소셜 미디어에 게시하려고 시도합니다. 생성된 미리보기에서 기존의 “Vite + 리액트 + TS” 제목을 볼 수 있습니다. 이때 자바스크립트는 로드되지 않았습니다.

하지만 일부 봇에선 그렇지 않은 경우가 있습니다. 대부분의 성능이 좋은 검색 엔진은 자바스크립트 파일의 실행을 기다립니다. 예를 들어 구글은 “순수한” HTML의 구문을 분석하고 페이지를 “렌더링” 대기열에 넣는 2단계 프로세스를 통해 브라우저를 실행하고 웹 사이트를 로드한 다음 자바스크립트 렌더링을 기다립니다. 그리고 가능하면 모든 것들을 다시 추출하는 과정을 수행합니다.

그러나 이 프로세스는 자바스크립트에 크게 의존하는 웹사이트의 색인 작업이 “더 느리고 자원이 많이 소요될 수 있다”는 것을 의미합니다.

따라서 웹사이트의 경우 아래 두 가지가 중요합니다.

• 가능한 한 많은 검색 엔진에서 최대한 빨리 검색될 수 있도록 하는 것이 중요합니다.
• 소셜 미디어 플랫폼에서 공유할 수 있어야 하고 그 과정에서 보기 좋게 보이는 것이 중요합니다.

그런 다음 서버가 첫 번째 요청에 중요한 정보가 모두 포함된 “적절한” HTML을 반환하는 것이 매우 중요합니다. 이러한 웹사이트의 대표적인 예는 다음과 같습니다.

• 읽기 우선 웹사이트, 즉 다양한 형태의 블로그, 문서, 지식 기반, 포럼, Q&A 웹사이트, 뉴스 매체 등.
• 다양한 형태의 전자상거래 웹사이트.
• 랜딩 페이지.
• 이외 월드 와이드 웹에서 검색할 수 있는 거의 모든 것들.

즉, 첫 번째 HTML 응답으로 빈 div를 사용하여 “고전적인” 클라이언트 사이드 렌더링을 하는 SPA는 검색 엔진에 좋지 않습니다.

하지만 그렇다고 해서 분노에 차서 리액트를 버려야 한다는 뜻은 아닙니다. 먼저 시도해 볼 수 있는 몇 가지 해결책이 있습니다.

서버 사전 렌더링

이 경우에는 서버를 도입해야 합니다. 현재 스터디 프로젝트에서는 다음과 같이 보입니다.

app.get("/*", async (c) => {
  const html = fs.readFileSync(path.join(dist, "index.html")).toString();

  return c.html(html);
});

서버는 요청을 받으면 빌드 단계에서 미리 생성한 index.html 파일을 읽고 문자열로 변환한 후 요청자에게 다시 전송합니다. 이는 기본적으로 SPA를 지원하는 모든 호스팅 플랫폼이 수행하는 작업입니다. 다만 플랫폼에서 직접 제어하거나 수정할 수 있는 기능은 아닙니다.

하지만 “자바스크립트 없음” 문제를 해결하려면 지금 당장 서버를 수정해야 합니다. 다행히도 이는 큰 문제는 아닙니다. 우리가 작업한 내용이 문자열이라는 사실인 것만으로도 많은 것들이 단순화됩니다. 문자열을 다시 보내기 전에 이 문자열을 수정하는 것을 막을 수 있는 것은 아무것도 없기 때문입니다. 이제 기존 제목을 찾아서 “Study project”로 바꾸어 보겠습니다. 아래 예문을 확인해 보시죠.

app.get("/*", async (c) => {
  const html = fs.readFileSync(path.join(dist, "index.html")).toString();

  const modifiedHTML = html.replace(
    "<title>Vite + React + TS</title>",
    `<title>Study project</title>`
  );

  return c.html(html);
});

이 방법이 조금 더 나은 방법이지만, 실제로는 모든 페이지마다 제목이 바뀌어야 하므로 이렇게 정적으로 유지하는 것은 의미가 없습니다. 다행히도 각 서버는 요청이 어디에서 오는지 항상 정확히 알고 있습니다. 제가 사용하는 프레임워크(Hono)의 경우 c.req.path를 요청하여 경로 정보를 추출하기만 하면 됩니다.

그런 다음 해당 경로를 기반으로 다양한 제목을 생성할 수 있습니다.

app.get("/*", async (c) => {
  const html = fs.readFileSync(path.join(dist, "index.html")).toString();

  const title = getTitleFromPath(pathname);

  const modifiedHTML = html.replace(
    "<title>Vite + React + TS</title>",
    `<title>${title}</title>`
  );

  return c.html(html);
});

getTitleFromPath에서 다음과 같은 작업을 수행할 수 있습니다.

const getTitleFromPath = (pathname: string) => {
  let title = "Study project";

  if (pathname.startsWith("/settings")) {
    title = "Study project: Settings";
  } else if (pathname === "/login") {
    title = "Study project: Login";
  }

  return title;
};

실제 환경에서는 실제 페이지와 함께 배치하거나 페이지 내 코드에서 추출해야 할 수도 있습니다. 그렇지 않으면 거의 즉시 동기화되지 않습니다. 하지만 스터디 프로젝트의 경우 이 정도면 충분합니다.

마지막으로 예쁘게 만들기 위해 index.html 파일에서 원래 제목인 <title>Vite + 리액트 + TS</title>을 <title>{{title}}</title>과같이 바꾸고 템플릿으로 바꿀 수 있습니다.

<html lang="en">
  <head>
    <title>{{ title }}</title>
  </head>
  ...
</html>;

// 서버에서 이 작업을 대신하세요.
const modifiedHTML = html.replace("{{title}}", title);

향후에는 필요에 따라 템플릿 언어 중 원하는 언어로 변환할 수 있습니다.

물론 제목 title 태그에만 국한되지 않고 <head>에 있는 모든 정보를 이렇게 사전 렌더링 할 수 있습니다. 이렇게 하면 소셜 미디어 미리보기 기능의 “자바스크립트 없음” 문제를 비교적 쉽고 적은 비용으로 해결할 수 있어 일반적으로 이 이상은 필요하지 않습니다. 대부분은 정보가 포함된 <meta> 태그의 집합인 오픈 그래프 프로토콜에 의존합니다.

메타 태그뿐만 아니라 전체 페이지를 사전 렌더링 할 수도 있습니다! 하지만, 이 부분은 아래 '도전 과제' 블록에서 SSR에 대해 더 많은 것들을 배울 수 있습니다.

도전 과제

1. 백엔드에서 index 파일의 내용을 backend/pre-rendering-index.ts의 내용으로 바꿉니다.
2. src/index.html에서 title 태그의 내용을 {{ title }}로 바꿉니다.
3. 소셜 미디어 공유에 필요한 메타태그를 지원하도록 프런트엔드 및 백엔드 코드를 모두 리팩터링합니다(목록 참조).
4. 프로젝트를 빌드하고 다시 ngrok을 통해 노출한 다음 각 페이지(로그인, 홈, 설정)를 원하는 소셜 미디어에 공유해 보세요. 이제 미리보기가 제대로 작동하고 각 페이지의 세부 정보가 표시되어야 합니다.
5. 보너스 질문: 메타태그 정보가 클라이언트와 서버 간에 중복되지 않도록 프로젝트를 어떻게 리팩토링하나요?

사전 렌더링 서버 비용

위에서 메타태그 사전 렌더링이 비교적 저렴하다고 언급했습니다. 하지만 이것이 정확히 무엇을 의미할까요? 특히 도입 전의 비용과 노력에 비해 얼마나 저렴할까요?

안타깝게도 완전히 정적인 SPA와 비교하면 좋은 소식은 없습니다. 간단한 사전 렌더링 스크립트를 추가함으로써 이제 처리해야 할 복잡성이 명백하게 증가하는 것 외에 두 가지 문제가 생겼습니다.

어디에 배포할까요?

첫 번째 문제는 앱을 지금 어디에 배포해야 해야하는가입니다. 요즘에는 정적 리소스를 호스팅 하는 것이 매우 저렴하기 때문에 변경 전에는 호스팅 비용을 오랫동안 0으로 유지할 수 있었습니다. 이제는 서버가 필요합니다. 그리고 서버는 일반적으로 저렴하지 않습니다.

여기에는 가장 일반적으로 두 가지 해결법이 있습니다.

정적 리소스를 제공하는 호스팅 제공업체의 서버리스 펑션(function)을 사용할 수 있습니다. Cloudflare Workers, Netlify Functions, Vercel Functions, Amazon Lambdas 등입니다. 대부분의 정적 리소스 호스팅 제공업체는 어떤 형태로든 이러한 펑션을 갖추고 있을 것입니다.

여기서 장점은 서버와 유지 관리에 대해 신경 쓸 필요가 없다는 것입니다. 클라우드 펑션은 제공업체가 우리를 대신해 처리하는 미니 서버와 같습니다. 우리가 할 일은 코드를 작성하는 것뿐이고, 마법처럼 그냥 작동합니다. 그 외의 모든 것은 그들의 관심사입니다. 스터디 프로젝트, 일부 특정 분야의 프로젝트, 초기의 프로젝트, 바이럴성이 내재되어 있지 않은 프로젝트의 경우 클라우드 펑션이 최적의 선택이 될 것입니다.

클라우드 펑션은 일반적으로 구성 및 배포가 매우 쉽고, 사용량에 따라 요금이 책정되며, 실제로 엔드포인트에서 사용량에 따라 요금이 부과됩니다. 주말 동안 실수로 컨테이너를 실행 상태로 두었다가 예상치 못한 요금이 부과될 가능성은 없습니다.

단점은 "사용량 당 가격" 부분입니다. 웹사이트의 인기가 높을수록 사용량이 한도를 초과할 가능성이 높아집니다. 한 프로젝트가 HackerNews나 TikTok에서 인기를 얻으면서 갑자기 수백 명이 아닌 수백만 명의 방문자를 확보하고 소유자가 깜짝 놀라 5천 달러의 청구서를 받은 끔찍한 이야기를 몇 번 읽은 적이 있습니다. 따라서 서버리스 해결법에서는 지출 한도를 설정하고, 지출을 면밀히 모니터링하며, 이러한 상황에서 어떻게 해야 할지에 대한 계획을 세우는 것이 중요합니다.

서버리스 펑션이 마음에 들지 않는다면 실제 작은 노드(또는 다른 어떤 것들) 서버로 유지한 후 AWS, Azure, Digital Ocean, [선호하는 호스팅 제공업체 적용]에 이르기까지 모든 클라우드 플랫폼에 배포할 수 있습니다.

이 해결법에는 장점이 있습니다. 모든 것을 사용자가 제어할 수 있습니다. 한 해결법에서 다른 해결법으로 마이그레이션 할 때 공급업체에 종속되는 서버리스 펑션과 달리 코드 변경이 필요하지 않습니다. 가격은 일반적으로 훨씬 더 예측할 수 있고 훨씬 간단하며 사용량이 증가할 때 훨씬 저렴합니다. 또한 서버리스 펑션은 일반적으로 매우 제한적이지만, 원하는 기술 스택을 사용할 수 있습니다.

단점도 장점과 똑같습니다. 이제 모든 것은 여러분에게 달려 있습니다. CPU/메모리 사용량을 모니터링해야 합니다. 통합 가시성에 대한 걱정. 확장에 대한 걱정. 메모리 누수로 인해 밤잠을 설치게 될 것입니다.

그리고 지리적 영역에 대해서도 걱정해야 합니다. 이는 순수 SPA 앱에 어떤 종류의 서버를 도입할 때 발생하는 두 번째 문제로 이어집니다.

서버 도입이 성능에 미치는 영향

초기 로드와 지연 시간 및 CDN이 초기 로드 성능에 미치는 영향에 대한 글을 기억하시나요? 메타태그만 사전 렌더링하는 초보적인 서버라도 도입하여 신규 사용자든 기존 사용자든 상관없이 모든 초기 로드 요청에 대해 서버에 캐시 되지 않은 불가피한 왕복 요청을 의무적으로 도입하고 있습니다.

처음부터 좋지 않았던 SPA 앱의 초기 로드 성능을 조금 더 나쁘게 만들었을 뿐입니다. 얼마나 더 나빠졌는지는 서버가 정확히 어디에 배포되었는지에 따라 크게 달라집니다.

서버리스 펑션 중 하나로 배포된 경우라면 그렇게 나쁘지 않을 가능성이 있습니다. 일부 공급자는 이러한 펑션을 "엣지 서버"에서 실행할 수 있습니다. 즉, 이러한 펑션은 여러 서버가 최종 사용자에게 더 가까이 분산되어 있습니다. 정적 리소스에 대한 CDN과 거의 동일합니다. 이 경우 지연 시간이 최소화되고 성능 저하가 최소화됩니다.

하지만 자체 관리형 서버를 사용하면 분산 네트워크의 이점을 누릴 수 없습니다. 특정 지역에 배포해야 하기 때문입니다. 따라서 이 지역과 지구 반대편에 있는 사용자가 성능 저하의 영향을 실제로 느낄 수 있습니다.

성능에 미치는 영향이 중요하다면 어떻게든 해결해야 합니다. 복잡한 캐싱 전략, 다른 지역으로의 배포 등을 준비해야 합니다. 기본적으로 더 이상 서버가 없는 단순한 프런트엔드 앱이 아닙니다. 이제는 풀스택 또는 백엔드 우선 앱입니다.

Vercel/Netlify의 Next.js

바로 떠오를 수 있는 질문입니다. "Next.js로 프런트엔드를 작성하고 Vercel/Netlify에 배포하기만 하면 됩니다. 이런 내용을 꼭 알아야 하나요?"

여기서 정답은 "안타깝지만, 예, 피할 수 없습니다."입니다. 왜냐하면 Next.js 우선 호스팅 제공업체는 기본적으로 앱을 자바스크립트 파일과 여러 개의 작은 서버리스 펑션으로 변환하기 때문입니다. 사용자가 제어할 수도, 알지도 못하는 사이에 이런 일이 벌어집니다.

따라서 Next.js 프로젝트를 '정적'으로 내보내도록 명시적으로 설정하지 않은 경우 '사전 렌더링의 서버 비용'은 모든 항목에 적용됩니다.

도전 과제

1. Vercel/Netlify와 같은 서버리스 플랫폼에 "기본적으로" 배포(원클릭 배포)된 Next.js 앱이 있는 경우, 해당 앱을 위해 생성된 펑션이 몇 개인지 찾아보세요.
2. "엣지" 펑션인가요, 아니면 일반 펑션인가요? 사용량이 어떻게 계산되는지 알 수 있나요? 한도를 초과하기 전에 웹사이트가 처리할 수 있는 방문자 수는 몇 명인가요?
3. "일반" 펑션과 "엣지" 펑션의 조합이 있는 경우 어떤 펑션이 무엇을 담당하고 배포된 프로젝트에 어떤 영향을 미치는지 대응할 수 있나요?

서버에서 전체 페이지 사전 렌더링(SSR)

사전 렌더링에 대해 좀 더 이야기해 보겠습니다. 위 섹션에서는 기존 문자열을 다른 문자열로 대체하는 것이 쉽기 때문에 메타태그만 사전 렌더링했습니다. 하지만 <head> 태그를 넘어서면 어떻게 해야 할까요? 서버에서 전송되는 HTML 페이지의 <body> 태그의 내용을 살펴봅시다.

<body>
  <div id="root"></div>
  <script type="module" src="./main.tsx"></script>
</body>

클라이언트 사이드 렌더링이 어떻게 작동하는지 기억하시나요? 스크립트가 다운로드되고 처리되면 리액트는 "root" 요소를 가져와서 생성된 DOM 요소에 추가합니다. 그렇다면 빈 div 대신 일부 콘텐츠가 포함된 div를 반환하면 어떻게 될까요? 커다란 빨간색 블록으로 만들어 봅시다.

<div id="root">
  <div style="background:red;width:100px;height:100px;">Big Red Block</div>
</div>

index.html에 추가하고 프로젝트를 빌드하고 난 다음 시작하고 더 잘 보이도록 캐시를 비활성화하고 CPU와 네트워크 속도를 낮추는 것을 잊지 마세요.

페이지를 새로 고치면 큰 빨간색 블록이 잠시 깜박이다가 일반 대시보드 페이지로 바뀐 것을 볼 수 있을 것입니다. 첫 번째 좋은 소식은 빨간색 블록이 계속 남아 있지 않았다는 것입니다. 분명히 리액트는 내부에 무언가를 삽입하기 전에 “root” div를 지웁니다. 또는 기존 자식들을 재정의해도 이 글에서는 상관없습니다.

두 번째 좋은 소식은 성능 그래프를 보면 알 수 있습니다. 지금 기록해 보세요. 결과는 다음과 같이 나옵니다.

여기서 순서와 타이밍에 특히 주목해 주세요.

처음에는 이전에 보았던 그래프와 똑같아 보입니다. 먼저 서버에서 HTML을 기다리면 'Main' 섹션에 파란색 HTML 파싱 블록이 나타납니다. 이 블록은 어느 시점에서 CSS와 자바스크립트('Network'의 노란색과 보라색 블록)의 다운로드를 트리거 했습니다.

하지만 CSS 다운로드가 완료된 후 다른 일이 발생하기 시작했습니다. 먼저 보라색 Layout 블록(파란색 HTML 블록과 같은 수준)이 다소 길게 표시되었습니다. 전에는 이런 일이 없었는데요! 다운로드가 완료된 후 거의 즉시 FCP(First Contentful Paint)가 트리거 되었습니다. 하지만 상단의 자바스크립트 바는 여전히 로딩 중입니다! 그 후 자바스크립트 로딩이 완료되고, 처리되고, 페인팅 된 다음 LCP(Large Contentful Paint)가 트리거 되는 등 평소와 같은 상황이 계속됩니다.

프레임 스크린숏이 표시되는 맨 위 섹션에 마우스를 가져가면 FCP와 LCP 사이의 간격이 페이지에 큰 빨간색 블록이 표시된 기간과 정확히 일치하는 것을 확인할 수 있습니다. 저에게 있어 FCP와 LCP 사이의 간격은 약 500밀리초이며, FCP는 약 800밀리초, LCP는 약 1.3초입니다.

이 500ms는 초기 로드 시 클라이언트 사이드 렌더링 비용과 거의 비슷한 수준인 것 같습니다. 엄청나네요! LCP에서 500ms를 어떻게든 줄일 수 있다면 40%나 개선되는 것이죠! 이걸로 승진할 수도 있겠네요.

다행히 모든 것이 가능합니다. 리액트는 전체 앱을 사전 렌더링 할 수 있는 몇 가지 메서드을 제공하며 이론적으로 여기에서 사용할 수 있습니다. 예를 들어, “renderToString”이 있습니다. 문서에 따르면 이 메서드는 앱을 문자열로 렌더링 할 수 있습니다.

const App = () => <div>React app</div>;

// 어딘가의 서버
const html = renderToString(<App />); // 출력물: <div>React app</div>

이미 서버에서 문자열을 다루고 있기 때문에 이것은 완벽해 보입니다. 제가 해야 할 일은 빈 “root” div를 이 함수의 출력물로 대체하는 것뿐입니다. 메타 태그에서 했던 것과 똑같습니다. 해볼까요?

backend/index.ts로 이동하여 위에서 수정한 내용을 정리합니다. 주석 처리된 코드를 찾습니다.

// return c.html(preRenderApp(html));

그리고 코멘트를 취소합니다. 퍼포먼스를 다시 녹화합니다. 최종 결과는 다음과 같아야 합니다.

FCP와 LCP가 동시에 발생한 것을 보면 그 차이를 바로 확인해 볼 수 있습니다. 리액트로 생성된 메인 자바스크립트가 트리거 되기 전, 심지어 자바스크립트 로딩이 완료되기도 전에 말이죠. 이는 콘텐츠 사전 렌더링이 작동하고 있음을 의미합니다! 🎉 행복한 하루가 되었네요 ☀️☺️. 맨 위에 있는 스크린숏을 마우스로 가리키면 이는 무작위로 발생한 현상이 아니라 실제로 그 당시에 표시된 아름다운 대시보드가 맞는지 확인할 수 있습니다.

그런데 작은 이상 현상이 있습니다. FCP가 약속한 것보다 늦게 트리거 된다는 것입니다. 800ms로 예상했지만 실제로는 900ms 정도입니다. 모든 성능에 대한 반복적인 교훈으로, 정확한 수치를 미리 약속하지 않는다는 것입니다. 😅. 그런데 어디서 100ms가 손실된 걸까요?

먼저, 서버에 대한 초기 요청이 있는 왼쪽 맨 위 모서리인 "Network" 섹션을 살펴보세요. 파란색 실선이 보이시나요? 이것이 HTML 콘텐츠 다운로드입니다. 이제 단순한 빈 <div> 뿐만 아니라 더 많은 요소를 전송하고 있습니다. 정확한 수치를 보려면 해당 블록 위로 마우스를 가져가세요. 누락된 100ms 중 약 1/3이 콘텐츠 다운로드에 소요됩니다.

또한 'Parse HTML' 작업 뒤에 있는 보라색 'Layout' 블록에 주목하세요. 훨씬 길어 보이지 않나요? 정확한 수치를 보려면 다시 마우스를 가져가 보세요. 여기 100ms 중 3분의 2가 사라졌습니다. 브라우저는 추가 HTML을 다운로드할 뿐만 아니라 더 많은 요소의 위치를 계산한 후 페인팅해야 했기 때문입니다.

그래서 시간을 놓쳤습니다. 그래도 그만한 가치가 있지 않나요? LCP 타이밍에서 400ms를 단축하고 초기 로드 성능을 30% 개선했습니다! 그리고 또 다른 멋진 부분이 있습니다. 지금 자바스크립트를 비활성화하고 페이지를 새로고침해보세요. 대시보드가 그대로 표시됩니다! 전체 리로드를 유발하지만, 링크도 작동합니다.

이 부분이 바로 SSR의 가치입니다. 이제 페이지에 액세스 권한을 부여하려는 모든 검색 엔진과 다른 모든 로봇이 자바스크립트를 로드하지 않고도 모든 것을 볼 수 있습니다. 성능 향상은 좋은 보너스입니다. 그리고 불안정한 보너스이기도 합니다.

SSR의 초기 부하 악화의 가능성

성능에 확실한 해결책이 없기 때문에 불안정합니다. SSR이 SPA 앱의 초기 부하를 100% 증가시킬 것이라고 말하는 사람은 잘못 알고 있는 것입니다. 이제 네트워크 상태, 클라이언트 사이드 및 서버 사이드 렌더링이 어떻게 작동하는지 알았으니, SSR이 LCP를 악화시키는 시나리오를 생각해 볼 수 있을까요?

방법은 다음과 같습니다.

CPU 쓰로틀링을 비활성화하고 컴퓨터를 다시 빠르게 만듭니다. 네트워킹을 가능한 가장 느린 시뮬레이션으로 설정합니다. 저에게는 기본 Chrome 3G가 적합했지만, 컴퓨터의 속도에 따라 더 느리게 설정해야 할 수도 있습니다. 'disabled cache' 체크박스를 선택을 취소합니다. CSS/JS 파일이 브라우저 메모리에서 제공되기를 원합니다.

이제 사전 렌더링이 있는 경우와 없는 경우의 LCP를 측정합니다.

결과는 다음과 같습니다. 사전 렌더링이 없는 'SPA' 모드에서는 LCP가 약 2.13초입니다. 사전 렌더링을 사용하면 “SSR” 모드에서는 약 2.62초입니다. 거의 500밀리 초나 더 길어졌습니다!

성능 차트는 이 상황에서도 흥미롭게 읽을 수 있습니다. “SPA” 모드는 다음과 같습니다.

처음에는 네트워크 섹션에서 서버의 응답을 기다리는 아주 긴 블록(2초)이 표시됩니다. 이는 느린 네트워크 연결로 인한 지연 시간입니다. 그다음에는 네트워크가 아닌 브라우저 캐시에서 자바스크립트 및 CSS 리소스에 거의 즉각적으로 액세스 할 수 있습니다. 또한 빈 div일 뿐인 HTML 콘텐츠도 거의 즉각적으로 다운로드됩니다. 그런 다음 CPU 속도가 느려지지 않기 때문에 자바스크립트 실행 속도가 평범하거나 매우 빠릅니다. 이것이 리액트가 페이지를 생성하는 과정입니다. 그리고 마지막으로 페이지가 표시됩니다.

이제 SSR 모드가 활성화된 동일한 네트워크/CPU 조건입니다.

동일하게 초기 대기 시간과 지연 시간이 사라지지 않았습니다. 그런 다음 HTML 다운로드가 시작됩니다. 하지만 지금은 콘텐츠가 많기 때문에 다운로드에 시간이 아주 오래 걸리고 대역폭이 매우 줄어듭니다.

그리고 가장 흥미로운 부분은 콘텐츠가 다운로드되는 동안 메인 섹션에서 활동량이 급증하는 것을 볼 수 있다는 점입니다. 확대해서 마우스를 가져가면 대부분 레이아웃 작업입니다. 브라우저는 이미 (캐시에서) CSS와 자바스크립트를 다운로드한 상태이므로 작은 조각을 얻자마자 레이아웃을 그리는 데 필요한 모든 정보를 가지고 있습니다. 그리고 실제로도 그렇습니다.

페이지에서 인터페이스가 점진적으로 구축되는 것을 실제로 볼 수 있습니다. 먼저 사이드바, 상단 탐색, 상단 차트, 표가 차례로 표시됩니다. 이 모든 것이 HTML이 천천히 표시되는 순서대로 진행됩니다. 이것이 멋지지 않다면 무엇이 멋진지 모르겠습니다.

이 예는 이상한 엣지 케이스처럼 느껴지지만 실제로는 그렇지 않습니다. 예를 들어 느린 네트워크 + 엄청난 지연 시간 + 빠른 노트북의 조합은 비즈니스 여행객에게 자주 발생합니다. 또는 야생동물 사진작가. 또는 여행 블로거. 또는 원격지로 파견된 엔지니어도 마찬가지입니다. 따라서 앱이 주로 특정 틈새시장을 목표로하고 있고 이미 SPA인 경우 SSR을 도입하면 문제가 더 악화될 수 있습니다.

물론 그렇지 않을 수도 있습니다. 이는 다운로드되는 HTML의 크기, 디바이스의 실제 속도, 앱이 렌더링해야 하는 자바스크립트의 양에 따라 달라집니다. 결국 모든 것은 고객을 파악하고 모든 것을 측정하는 두 가지로 귀결됩니다.

SSR과 하이드레이션

콘텐츠를 더 빨리 보여주는 것에 대한 흥분으로 콘텐츠가 로드된 후 어떤 일이 일어나는지 조사하는 것을 잊었습니다.

큰 빨간색 블록의 동작을 기억하시나요? 리액트가 자체 요소를 로드하고 생성한 후에는 “root” div의 콘텐츠와 큰 빨간색 블록을 포함한 내부의 모든 것을 완전히 대체했습니다. 하지만 이상한 빨간색 블록 대신 향후 페이지의 실제 HTML을 보내면 어떻게 될까요?

사실 아무 일도 일어나지 않습니다. 리액트에게 이 콘텐츠가 중요하다고 어떤 식으로든 말하지 않았기 때문에 “루트” div의 전체 콘텐츠를 지우고 그 자체로 대체하는 것과 똑같은 방식으로 작동합니다. HTML 관점에서 보면 완전히 동일한 콘텐츠이므로 육안으로는 차이가 보이지 않습니다.

하지만 성능 프로필에서는 그 차이를 확인할 수 있습니다. CPU와 네트워크 속도를 낮춰 동작이 약간 더 잘 보이도록 하고 SSR 예제의 성능을 다시 기록합니다. CSS와 자바스크립트가 수신된 후 어떤 일이 일어나는지 주목해 주세요.

왼쪽 상단에는 리소스 다운로드가 완료된 네트워크 섹션이 있습니다. CSS를 받은 직후 아래에 큰 보라색 'Layout' 섹션이 표시되는데, 바로 여기에 SSR이 적용된 콘텐츠가 표시됩니다. 왼쪽 상단의 자바스크립트 노란색 블록 로딩이 완료되면 리액트가 시작됩니다. 다소 긴 작업(180ms)은 리액트가 UI를 빌드 할 때입니다. 오른쪽 맨 아래에는 다시 작은 레이아웃 블록이 표시됩니다.

이것은 우리가 이미 여러 번 보았던 클라이언트 사이드 렌더링의 전형적인 그림입니다. 리액트가 “root” div를 지우고 대신 생성하는 모든 것을 삽입하는 경우입니다. 그리고 이것은 완전히 불필요한 작업입니다. 리액트에는 이미 모든 DOM 요소가 존재하므로 대신 재사용할 수 있습니다. 당연히 더 빨라야 합니다.

이때 “하이드레이션”이라는 것이 등장합니다. “하이드레이션"은 위에서 제가 원했던 것과 정확히 일치하는 HTML이 페이지에 이미 있다는 것을 리액트에 보여줍니다. 따라서 리액트는 기존 DOM 노드를 재사용하고, 이벤트 리스너를 추가하고, 향후 기능을 위해 내부적으로 필요한 모든 것을 준비한 다음 하루를 마무리할 수 있습니다. 불필요한 컴포넌트를 처음부터 마운트 할 필요가 없습니다!

리액트의 하이드레이션은 실제로 한 번의 함수 호출로 매우 간단하게 구현할 수 있습니다. createRoot 진입점을 이것으로 대체하기만 하면 됩니다.

hydrateRoot(
  document.getElementById("root")!,
  <StrictMode>
    <App />
  </StrictMode>
);

이 코드는 src/main.tsx에서 찾을 수 있습니다. createRoot 부분을 주석 처리하고 hydration 부분을 주석 처리 해제하세요. 그런 다음 프로젝트를 다시 빌드하고 다시 시작하세요.

npm run build
npm run start

리액트 관련 자바스크립트 실행에 더 이상 보라색이 표시되지 않습니다. 그리고 이제 180ms에서 142ms로 약간 더 빨라졌습니다. 특히 이전에 LCP가 트리거 되었다는 점을 고려하면 지금은 그다지 크게 느껴지지 않을 수도 있습니다. 하지만 항상 이렇게 유지되는 것은 아닙니다.

예를 들어 'disable network cache'을 선택 해제하고 CPU를 낮추면서 네트워크 스로틀링을 제거해 보세요. 인터넷 속도는 빠르지만, 디바이스가 느린 재방문자를 가상화합니다. 하이드레이션이 없으면 FCP와 LCP가 분리되고 LCP가 자바스크립트 작업의 맨 끝으로 밀려납니다. 이 경우 LCP는 약 550ms입니다. 하이드레이션을 활성화하면 LCP는 FCP에 더 가깝게 이동하여 자바스크립트 작업이 시작될 때 약 280ms를 유지합니다.

메인 스레드를 차단하고 최대한 줄이는 문제도 있는데, 하이드레이션이 이를 도와줍니다. 또한 하이드레이션은 자바스크립트 리스너에만 국한된 것이 아닙니다. 또한 일부 초기 데이터를 가져와 앱에 주입할 수 있으므로 스피너나 콘텐츠의 플래시를 로딩하는 것을 방지할 수 있습니다. 이에 대해서는 나중에 다른 글에서 다룰 예정입니다.

이렇게 SSR을 구현해야 하나요?

이제 SSR이 특정 사례에 매우 유용할 수 있고 구현하는 것이 다소 사소해 보이기 때문에, 스터디 프로젝트의 코드를 사용하여 나만의 SSR을 구현할 수 있느냐는 질문이 생길 수 있습니다.

이 블로그의 대답은 매우 드물게도 '절대 안 된다'입니다! 이 해결법은 한 가지를 켜고 끄면서 사전 렌더링 된 콘텐츠가 다양한 관점에서 어떻게 작동하는지 살펴보는 스터디 목적으로는 괜찮습니다.

하지만 실제로는 전혀 사소한 일이 아닙니다. 저는 제대로 작동하기 위해 해야 할 일의 절반을 숨기고 절반은 아직 구현되지 않았습니다. 백엔드에서 최신 리액트 기능을 지원하지 않은 매우 기본적이고 거의 사용되지 않은 버전입니다.

우선, 여기에는 개발 서버에 대한 SSR이 없습니다. 따라서 프로젝트를 지속적으로 다시 빌드하는 것 외에는 SSR을 디버깅할 방법이 없습니다. 변경 사항을 적용하기 위해 항상 다시 빌드해야 하는 이유의 절반은 바로 이 때문입니다. (나머지 절반은 항상 프로덕션 빌드에서 성능을 측정해야 해서 특별히 죄책감을 느끼지 않습니다).

핫 리로드와 같은 멋진 기능을 원한다면 직접 구현해야 합니다. SSR을 Vite와 올바르게 통합하는 방법에 대한 전체 지침이 있습니다. 웹팩의 경우 매우 다르며 문서화가 잘 되어 있지 않을 가능성이 높습니다. 더 색다른 것을 위해 어디서부터 시작해야 할지 모르겠습니다.

둘째, 리액트 문서에서 보여드린 예쁘게 생긴 문자열인 const html = renderToString(<App />); 은 실제로는 작동하지 않습니다. 여기서 문제는 이 부분, 즉 <App />입니다. 이건 JSX이고, 우리가 대부분 리액트 코드를 작성하는 방식이기 때문에 지금은 매우 정상적으로 보입니다. 하지만 JSX가 작동하는 유일한 이유는 빌드 시스템에 Babel에 의해 구동되는 변환 단계가 있기 때문입니다(또는 아닐 수도 있고, 항상 달라질 수 있습니다). “순수” 노드나 다른 서버 프레임워크는 이를 지원하지 않습니다.

실제로 어떻게 구현되는지 backend/pre-render.ts를 살펴보세요.

먼저 Vite 자체에서 변환된 App 코드를 추출했습니다:

const { default: App } = await vite.ssrLoadModule("@/App");

웹팩을 사용하는 경우 수동으로 Babel 플러그인을 구성하고 등록해야 할 가능성이 높습니다. 따라서 첫 번째 단계부터라도 여기서 무슨 일이 일어나고 있는지, 앱이 어떻게 구현해야 하는지 이해해야 합니다.

두 번째 단계는 실제 renderToString입니다.

const reactHtml = renderToString(React.createElement(App, { ssrPath: path }));

여전히 문서와 달리 실제 백엔드 파일에 대한 JSX 지원은 Vite에서 추출하는 것과는 다릅니다. 하지만 문서를 읽어보면 renderToString이 데이터 스트리밍 및 대기를 지원하지 않는다는 것을 알 수 있습니다.

따라서 실제로 적절한 SSR을 구현하려면 앱에 이러한 새로운 기능이 필요한지 여부를 이해해야 합니다. 그리고 필요하다면 백엔드에서 구현하는 방법을 파악해야 합니다. 권장 방법에 대한 몇 가지 문서가 있고 깃허브에 해당 주제에 대한 토론에 대한 스레드도 몇 개 있으므로 최소한 시작은 할 수 있습니다.

그러나 많은 작업이 필요하고 언급된 내용은 시작에 불과하며, 어느새 프로젝트가 3개월이나 늦어져 기본적으로 자신만의 Next.js를 구현하고 있습니다. 왜 경쟁자가 그렇게 많지 않다고 생각하시나요?

그래서 매우 타당한 비즈니스 이유가 있고 시간, 리소스 및 전문성 측면에서 많은 지원이 없다면 이미 존재하는 SSR 프레임워크를 사용하는 것이 더 쉬울 수 있습니다. 특히 백엔드 부분은 퍼즐의 한 조각에 불과하다는 점을 고려하면 더욱 그렇습니다. 또한 프런트엔드에는 많은 복잡성이 수반됩니다.

SSR과 프런트엔드

앱의 크기와 SSR에 최적화된 정도에 따라 실제로는 백엔드 부분보다 훨씬 더 복잡할 수 있습니다. 그래요, 위에서 SSR을 구현하면서 숨겼던 또 하나의 사실은 프런트엔드 코드도 변경해야 한다는 점입니다.

브라우저 API와 SSR

브라우저로 전송되는 HTML을 어떻게 얻었는지 기억하시나요? 리액트의 renderToString으로 문자열을 생성한 다음 그 문자열을 다른 문자열에 주입했습니다. 이 과정 근처에는 브라우저가 없었고 앞으로도 없을 것입니다.

그렇다면 프런트엔드에서 사용하던 브라우저 변수에 대한 모든 호출은 어떻게 될까요? window.location, window.history, document.getElementById? window, document 등이 undefined 상태로 바뀔 것입니다. 전역 범위로 주입할 수 있는 브라우저가 없기 때문입니다.

따라서 리액트가 이들에 직접 접근하는 함수를 호출(즉, 컴포넌트를 렌더링)하려고 하면 window is not defined 오류와 함께 실패합니다. 앱 전체가 폭발할 것입니다. 단순히 폭발하는 것이 아닙니다. 서버 부분이 폭발할 것이고, 더 심각한 것은 프런트엔드 부분에서 오류를 포착하여 “작업 중입니다, 여기 쿠키가 있습니다”라는 예쁜 화면을 표시할 기회가 전혀 없다는 것입니다. 오류 처리는 서버에서 처리해야 하며, 특별한 '서버' 오류 화면이 있어야 합니다.

도전 과제

1. 프런트엔드 코드의 임의의 부분(예: src/App.tsx)에 간단한 console.info(window.location);을 추가해 보세요.
2. npm run build를 사용하여 앱을 다시 빌드하고 다시 시작합니다.
3. 화면에 Internal Server Error 문자열이 표시되어야 합니다.
4. 이 문제를 해결할 방법이 있나요?

이 문제를 해결하는 일반적인 방법은 window(및 다른 모든 변수)에 액세스 하기 전에 전역 변수가 선언되었는지 확인하는 것입니다:

if (typeof window !== "undefined") {
  // global window API를 사용할 수 있을 때 무언가를 수행합니다.
}

frontend/utils/use-client-router.tsx의 코드를 보면 바로 이것이 제가 해야 했던 일입니다. 그리고 런타임에 window, document 또는 다른 모든 것에 액세스해야 할 때마다 이 작업을 수행해야 합니다.

useEffect와 SSR

자세히 보면 useEffect 내부에서 typeof window를 확인할 필요가 없다는 것을 use-client-router파일을 보면 알 수 있습니다.

useEffect(() => {
  const handlePopState = () => {
    setPath(window.location.pathname);
  };
  window.addEventListener("popstate", handlePopState);
  return () => window.removeEventListener("popstate", handlePopState);
}, []);

서버에서 실행할 때(즉, renderToString과 친구를 통해) 리액트는 useEffect를 트리거하지 않기 때문입니다. 그리고 useLayoutEffect도 마찬가지입니다. 이러한 훅은 하이드레이션이 발생한 후에 클라이언트에서만 실행됩니다. 이 동작의 이유에 대해 더 자세히 알고 싶다면 이 짧은 설명과 핵심 리액트 팀원들의 이 주제에 대한 긴 토론을 살펴보세요.

자바스크립트가 로드될 때 콘텐츠의 "깜빡임"이 발생하므로 useEffect의 결과로 UI 변경이 예상되는 경우 반드시 염두에 두어야 할 사항입니다.

조건부 SSR 렌더링 불가

코드의 일부에는 브라우저 API에 대한 종속성이 너무 많아서 SSR 모드에서는 해당 부분의 렌더링을 완전히 건너뛰는 것이 더 쉽다고 생각할 수 있습니다. 따라서 자연스럽게 이렇게 하고 싶은 유혹이 생길 수 있습니다.

const Component = () => {
  // SSR 모드에서는 아무것도 렌더링하지 않습니다.
  if (typeof window === "undefined") return null;

  // 클라이언트 모드가 시작될 때 렌더링합니다.
  return ...
}

아니요. 이건 작동하지 않습니다. 아니, 더 정확하게는 작동할 것입니다. 리액트는 “서버” 코드에서 생성된 HTML이 클라이언트 코드에서 생성된 HTML과 완전히 동일하다고 기대할 것입니다.

너무 혼란스러워졌는데 클라이언트 사이드 렌더링 패턴으로 돌아가서 “root” div의 전체 콘텐츠를 지우고 새로 생성된 요소로 대체할 것입니다. 하이드레이션이 전혀 일어나지 않은 것처럼 작동하며 이에 따라 발생하는 모든 단점이 있습니다.

이 도전 과제를 시도해 보세요.

• frontend/pages/dashboard.tsx의 어딘가에(또는 원하는 다른 위치에) 코드를 사용하여 ClientOnlyButton 컴포넌트를 만듭니다.

const ClientOnlyButton = () => {
  if (typeof window === "undefined") return null;
  return <button>Button</button>;
};

• 페이지의 어딘가에 렌더링 합니다.
• 평소처럼 프로젝트를 다시 빌드하고 다시 시작합니다.
• 성능 프로필을 기록합니다. 하이드레이션이 아직 구현되지 않았을 때 보았던 그림이 리액트 자바스크립트 태스크 내부의 레이아웃 블록과 함께 표시되어야 합니다.

사라진 하이드레이션 - 운이 좋다면! 때로는 정말 이상한 레이아웃 버그가 발생하여 웹사이트가 완전히 망가져 보일 수 있습니다.

올바른 방법은 리액트의 라이프사이클에 의존하여 SSR과 호환되지 않은 블록을 “숨김”하는 것입니다. 이를 위해서는 상태를 도입하고 컴포넌트가 마운트되었는지 여부를 추적해야 합니다.

const Component = () => {
  // 초기에는 마운트 되지 않습니다.
  const [isMounted, setIsMounted] = useState(false);
};

그런 다음 컴포넌트가 마운트되었을 때, 즉 useEffect 내부에서 이 상태를 true로 뒤집습니다.

const Component = () => {
  // 초기에는 마운트 되지 않습니다.
  const [isMounted, setIsMounted] = useState(false);

  useEffect(() => {
    setIsMounted(true);
  }, []);
};

기억하세요. useEffect는 서버에서 실행되지 않으므로 웹사이트의 클라이언트 사이드 버전이 리액트에 의해 완전히 초기화될 때만 상태가 true로 바뀝니다.

마지막으로, SSR과 호환되지 않은 렌더링을 하고자 합니다.

const Component = () => {
  // 초기에는 마운트 되지 않습니다.
  const [isMounted, setIsMounted] = useState(false);

  useEffect(() => {
    setIsMounted(true);
  }, []);

  // SSR 모드에서는 아무것도 렌더링 하지 않습니다.
  if (!isMounted) return null;

  // 클라이언트 모드가 시작될 때 렌더링 합니다.
  return ...
}

도전 과제

1. 이전 예제의 ClientOnlyButton을 다시 작성하여 SSR에서 올바르게 작동하도록 합니다.
2. 평소처럼 프로젝트를 다시 빌드하고 다시 시작합니다.
3. 성능 프로필을 기록합니다. SSR 빨간색 모양으로 되돌아갑니다.

서드파티 라이브러리

모든 외부 종속성이 SSR을 지원하는 것은 아닙니다. 라이브러리는 항상 도박과도 같습니다. 일부 라이브러리의 경우 위의 해결법을 사용하여 SSR을 거부할 수 있습니다. 일부는 번들러에 의해 거부되므로 클라이언트 사이드 자바스크립트가 로드된 후 동적으로 가져와야 합니다. 그중 일부는 프로젝트에서 제거하고 더 SSR 친화적인 라이브러리로 대체해야 합니다.

SSR과 호환되지 않은 라이브러리가 전체 프로젝트의 기본 요소인 경우 특히 문제가 될 수 있습니다. 상태 관리 해결법이나 CSS-in-JS 해결법처럼 말입니다.

예를 들어, 스터디 프로젝트의 어딘가에서 Material UI 아이콘을 사용해 봅시다.

// 어딘가 예제에 있는 src/App.tsx
import { Star } from "@mui/icons-material";

function App() {
  // 나머지 코드는 같습니다.
  return (
    <>
      ...
      <Star />
    </>
  );
}

다시 빌드하고 시작하면 SSR이 함께 무너진 것을 볼 수 있습니다.

[vite] (ssr) Error when evaluating SSR module @/App: deepmerge is not a function

해결 방법을 재미있게 찾아보세요 😬

정적 사이트 생성(SSG)

서버에서 “적절히” 렌더링 되는 페이지가 반드시 필요하고 이를 위해 프런트엔드에서 발생하는 결과를 처리할 준비가 되어 있다고 가정해 봅시다. 예를 들어 멋진 “프로모션” 웹사이트를 구현하고 있다고 가정해 봅시다. 모든 검색 엔진에서 가능한 한 빨리 색인화되어야 하며 링크를 공유할 수 있는 모든 곳에서 공유할 수 있어야 합니다. 이것이 바로 이런 웹사이트의 핵심입니다.

또한 웹사이트의 모든 정보가 “정적”, 즉 사용자가 생성한 콘텐츠가 없고, 고려해야 할 권한이 없으며, 요청당 복잡한 데이터가 생성되지 않는다고 가정해 봅시다. 웹사이트는 제품을 소개하는 몇 개의 페이지와 '이용 약관'과 같은 몇 가지 표준 페이지, 일주일에 한 번 업데이트되는 블로그만 있다고 가정합니다.

이 상황은 케이크도 먹고 떡도 먹을 수 있는 드문 사용 사례입니다. 우리는 이미 서버에서 웹사이트를 사전 렌더링하는 것이 비교적 쉽다는 것을 알고 있습니다. 앱에서 React.renderToString을 호출하기만 하면 됩니다(어느 정도).

그렇다면 여기서 중요한 질문은 빌드 시간 동안, 즉 npm run build를 실행한 직후에 React.renderToString을 실행하지 못하게 하는 이유는 무엇일까요? 이론적으로 어쨌든 적절한 HTML 페이지를 사전 렌더링하여 브라우저에 전송하고 있습니다. 그리고 사전 렌더링 된 콘텐츠는 항상 동일합니다. 예전처럼 사전 렌더링해서 실제 HTML 파일로 저장하면 “적절한” 서버를 보유하는 수고를 덜 수 있을 것입니다. 그렇죠?

정답은, 그렇게 하는 것을 막을 방법이 전혀 없다는 것입니다. 이걸 실행해 보세요.

npm run build:ssg

먼저 Vite를 사용하여 일반적인 방식으로 웹 사이트를 구축한 다음, 빈 <div id=“root”></div>를 renderToString으로 생성된 콘텐츠로 대체하는 매우 근본적인 스크립트(backend/generate-static-pages.ts)를 실행합니다. 서버가 하는 일과 정확히 일치합니다. 이제 더 이상 서버가 필요하지 않습니다.

dist 폴더에서 빌드 된 파일을 살펴보세요. 이제 login.html과 settings.html이라는 추가된 두 개의 파일이 보입니다. HTML 파일을 열면 <div id=“root”>가 콘텐츠로 채워져 있는 것을 볼 수 있습니다.

이것은 모든 웹서버에서 시작할 수 있는 “정적” 웹사이트입니다.

npx serve dist

또는 다른 클라이언트 사이드 렌더링 앱과 마찬가지로 거의 모든 곳에 업로드 할 수 있습니다. 이번에는 CSR의 단점이 없고, 모든 검색 엔진이 즉시 제대로 색인을 생성할 수 있으며, 소셜 미디어 공유가 원활하게 작동합니다.

정적 웹사이트는 세 글자로 된 자체 약어까지 있을 정도로 훌륭한 기능입니다(SSG(정적 사이트 생성)). 물론 수작업이 필요 없이 자동으로 생성해 주는 프레임워크가 많이 있습니다. Next.js는 SSG를 지원하고, Gatsby는 여전히 인기가 많고, 많은 사람들이 Docusaurus를 좋아하고, Astro는 최고의 성능을 약속하며, 그 외에도 많은 프레임워크가 있습니다.

SSR에 대해 아직 할 말이 많지만, 여기 소개한 개념은 기초를 다지기 위한 것일 뿐입니다. 하지만, 이 글이 도움이 되었기를 바라며 다음에 다음 웹사이트를 만들 때 SSR로 시작할지 말지 결정해야 할 때 좀 더 자신감을 가질 수 있기를 바랍니다.