초창기 웹 애플리케이션 (MPA, SSR)

📌 MPA (Multi-Page Application)

• 다중 페이지로 이뤄져있어 변경사항이 있을 때마다 서버로 페이지를 요청해서 새로 렌더링 한다.

웹 애플리케이션의 역사를 보자면, 초창기 웹은 텍스트 중심의 단순 문서였다. 따라서 MPA(Multi-Page Application) 방식으로 구현되었다. MPA는 페이지 변경시마다 서버에 페이지 요청을 하여 새로고침이 발생하고 깜빡임이 있었다. 웹의 발전과 함께 복잡도가 증가하면서 MPA 방식의 성능 이슈가 발생했다.

이후 2004년 웹 시장에서는 굉장히 획기적인 일이 발생한다. 바로 제시 제임스(Jesse James)라는 사람이 Ajax 기술 사양을 발표하여 JavaScript를 통해 서버로부터 비동기적으로 데이터를 처리하는 획기적인 기술을 제시했다. Ajax 기술의 등장으로 필요한 부분만 리로드할 수 있게 되어 성능 문제가 해결되었다.

📌 전통적인 Page기반 SSR (Server-Side Rendering)

이런식으로 서버에서 html로 페이지를 다 만들어서 클라이언트에게 주는 것을 SSR이라고 한다.

SSR 동작 흐름

1. 사용자가 웹 접속 후 브라우저가 서버에 리소스를 요청한다.
2. 서버는 즉시 렌더링 가능한 초기 콘텐츠가 로딩된 html 파일을 만든다. (리소스 체크, 컴파일 후 완성된 HTML 컨텐츠로 만든다.)
3. 초기 렌더링: 브라우저에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링 된다. 그러나 사이트 자체는 조작 불가능하다. (Javascript가 읽히기 전이다.)
4. JS 처리: 브라우저가 자바스크립트를 다운받는다. 다운 받아지고 있는 사이에 유저는 콘텐츠는 볼 수 있지만 사이트를 조작할 수는 없다. 이때의 사용자 조작을 기억하고 있는다.
5. JS가 서버에서 전달된 HTML에 이벤트리스너 등을 할당해서 인터랙티브한 페이지를 제공한다. JS까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용 가능해진다.

SSR 특징 - 웹 성능 지표 관점

• 👍 FCP가 빠르다.
  • FCP(First Contentful Paint): 사용자가 화면에서 콘텐츠를 볼 수 있는 페이지 로드 타임라인의 첫 번째 지점
• 👎 TBT가 발생한다.
  • Total Blocking Time(TBT) : FCP로부터 TTI(사용자가 페이지에서 상호작용이 가능한 시점)까지의 시간

더욱 늘어난 니즈 (SPA, CSR)

📌 SPA (Single-Page Application)

하지만 갈수록 더욱 복잡해지는 애플리케이션은 니즈가 늘어났다. 하나의 페이지 안에서 데이터를 받아 와서 필요한 부분만 부분적으로 업데이트하도록 하는 **SPA(Single-Page Application)**가 등장했다.

📌 CSR (Client-Side Rendering)

CSR은 모든 렌더링 작업을 브라우저에서 수행하는 방식이다. 서버로부터 최소한의 HTML과 JS 파일을 받아 브라우저가 이를 기반으로 UI를 동적으로 생성한다. CSR은 빠르게 SPA의 표준으로 자리잡았으며 페이지 전환 시 전체 페이지를 다시 로드하지 않고 필요한 부분만 업데이트함으로써 사용자 경험을 크게 향상했다.

CSR 동작 흐름

1. 사용자가 웹 접속 후 브라우저가 서버에 리소스 요청한다.
2. 서버는 간단한 HTML 파일과 JS 파일을 브라우저로 전송한다. 주로 <div id="root"></div>와 같은 최소한의 구조만 포함된다. (TTFB)
3. 초기 렌더링: 브라우저가 HTML과 CSS를 다운로드하고 렌더링해서 초기 페이지 구조를 만든다. (이때 SSR과 달리 사용자는 빈 화면을 보게된다.)
4. JS 처리: 브라우저는 HTML에 포함된 script 태그를 통해 JS를 다운로드하고 실행한다.
5. JS가 서버에서 전달된 HTML에 기능을 추가해서 페이지가 인터렉티브해진다.
6. fetching data: 데이터를 위한 API가 호출되고, 서버가 API로부터의 요청에 응답한다. (이때 사용자는 placeholder를 보게 된다.)
7. API로부터 받아온 data를 placeholder 자리에 넣어준다.
8. UI 완성: 이 데이터를 기반으로 UI가 완성되고, 이때 LCP(Largest Contentful Paint)가 측정된다.

CSR 특징 - 웹 성능 지표 관점

• 👍 TTFB가 빠르다.
  • TTFB(Time to First Byte): 요청을 보내고 응답의 첫번째 바이트가 도착하기까지의 시간
  • 서버가 복잡한 HTML을 렌더링하지 않고, 빈 HTML+JS 번들 링크만 보내주면 되기 때문에 작업이 단순하여 TTFB가 빠른 경향이 있다.
• 👎 FCP / LCP가 안좋다.
  • FCP(First Contentful Paint): 브라우저가 요청을 보낸 시점부터 DOM의 첫 번째 콘텐츠가 화면에 렌더링되는 시점
  • LCP(Largest Contentful Paint): 브라우저가 요청을 보낸 시점부터 가장 큰 콘텐츠 요소가 화면에 렌더링되는 시점
  • 빈 HTML+JS 파일 링크를 줘도, 사용자가 실제로 콘텐츠를 보려면 JS 실행 후에야 보이기 때문에 늦어진다.
  • fetch로 json 형식으로 받아서 렌더링하는 서버랑 통신하는 과정까지 마쳐야하기 때문에 첫페이지가 느리다.

CSR의 문제점

1. 초기 로딩 속도 CSR에서는 HTML, CSS 렌더링 후 JS 파일을 다운로드, 파싱, 실행해야지만 인터랙티브한 페이지를 볼 수 있다. 이 모든 과정이 순차적으로 이루어져야하기 때문에 FCP, LCP를 포함한 초기 로딩 성능을 저하한다. 이는 사용자가 사용하는 디바이스의 성능이 안좋거나 네트워크 연결 속도가 느릴수록 로딩 시간이 길어지기 때문에 저사양 디바이스에서 사용자 경험이 크게 떨어질 수 있다.

2. 사용자 경험 서버에서 최소한의 HTML만 제공되기 때문에 JS 실행 전까지는 빈 화면 또는 로딩 스피너만 보여주게 된다. 또한 대량의 데이터를 가져오는 애플리케이션에서는 data fetching 및 렌더링 과정이 길어져 사용자가 주요 콘텐츠를 보는 시간이 길다.

3. JS bundle size JS는 클라이언트에서 다운받는다. 기능이 많아질수록 JS bundle size도 늘어나 브라우저가 이를 처리하는데 많은 시간이 소요된다.

4. SEO 검색 엔진 크롤러는 주로 서버에서 렌더링된 HTML 콘텐츠를 인덱싱한다. 하지만 CSR에서는 하나의 div 태그가 포함된 HTML만 제공하기 때문에 검색 순위가 낮아질 수 있다.

5. 성능 최적화 초기 렌더링 시 HTML 구조가 거의 없기 때문에 브라우저에서 효율적인 HTML 캐싱이 어렵다. 또한 data fetching, 상태관리, 컴포넌트 렌더링 등의 모든 작업을 클라이언트에서 처리하기 때문에 브라우저의 부하가 증가한다.

📌 CSR의 문제점 해결을 위한 현대적인 SSR 방식

CSR은 위와 같은 한계가 있기 때문에, 이를 보완하기 위해 현대적인 SSR 방식이 발전했다. 전통적인 SSR은 서버에서 완성된 HTML을 내려주기 때문에 초기 렌더링은 빠르지만, 매 요청마다 서버 부하가 커지고 동적인 상호작용 구현이 제한적이라는 단점이 있었다.

이를 해결하기 위해 Hydration 기반 SSR이 등장했다. 서버는 미리 렌더링된 HTML을 클라이언트로 보내 즉시 콘텐츠를 보여주고(FCP 개선), 이후 브라우저에서 자바스크립트가 실행되면서 해당 HTML과 매칭되어 이벤트 바인딩과 상호작용이 가능해진다. 이렇게 하면 SSR의 빠른 초기 로딩과 CSR의 동적 인터랙션을 모두 누릴 수 있다. Next.js, Nuxt.js 같은 프레임워크들이 대표적이다. 또한, SSR의 성능 문제를 개선하기 위해 SSG(Static Site Generation), ISR(Incremental Static Regeneration) 같은 방식도 도입되었다.

• SSG는 빌드 시점에 HTML을 생성해 두어 요청 시 즉시 반환할 수 있어 TTFB와 FCP가 모두 빠르다. 다만, 데이터가 자주 바뀌는 페이지에는 적합하지 않다.
• ISR은 특정 주기로 정적 페이지를 다시 생성하는 방식으로, 최신성을 유지하면서도 정적 사이트의 속도를 유지할 수 있다.

현대 웹은 이러한 전략들을 혼합해 사용한다. 예를 들어, 블로그 글 목록은 SSG로, 실시간 데이터가 필요한 대시보드는 SSR로, 로그인이나 마이페이지 같은 일부 영역은 CSR로 구현하는 Hybrid Rendering 방식이 일반적이다.

💡 따라서 오늘날의 SSR은 단순히 “서버에서 렌더링한다”에 그치지 않고, CSR의 장점을 흡수해 초기 로딩 성능과 SEO, 상호작용성을 모두 고려하는 진화된 렌더링 방식으로 이해할 수 있다.

SSR vs CSR