오랫만에 유노님의 짤을 보며 항상 대충이라는 벌레를 경계하며 시작해본다!
면접을 준비하면서 많이 접했던 주제이고 대략적으로 알고 있지만,
한번 쯤 스스로 정리 하고 싶었던 csr과 ssr에 대해 이번 기회를 통해 정리하려고 한다!
구글에서 저공하는 web.dev에서 발췌하여 원문을 해석해보았다
(정리하면서 쓴글이여서 원문이 궁금하지 않으면 번역부분만 읽어도 좋을듯 싶다!)
CSR은 무엇인가요?
CSR은 JavaScript를 사용하여 브라우저에서 직접 페이지를 렌더링(화면을 그리는 방식)을 의미한다.
모든 로직, data fetching, templating 및 라우팅은 서버가 아닌 클라이언트에서 처리한다.
일반적으로 Dom을 사용하여 브라우저에서 앱을 렌더링한다.
원문
Client-side rendering (CSR) means rendering pages directly in the browser using JavaScript. All logic, data fetching, templating and routing are handled on the client rather than the server.
rendering an app in a browser, generally using the DOM.
출처 https://web.dev/rendering-on-the-web/
csr의 성능관점에서 몰랐던 점
- 몰랐던 단점:
csr은 모바일에서 빠르게 유지하기 어려울 수 있다.
Client-side rendering can be difficult to get and keep fast for mobile.
- 렌더링 성능 접근 방법(빠르게!)
It can approach the performance of pure server-rendering if doing minimal work, keeping a tight JavaScript budget and delivering value in as few RTTs as possible.
순수한 서버 렌더링의 성능에 접근 할 수 있다. 만약 최소한의 작업을 수행하면, 자바스크립트의 타이트한 budget(예산을) 유지하면서, 그리고 가능한 적은 RTT(왕복지연 시간- 신호 송수신 시간)로 값을 전달하면서.
Critical scripts and data can be delivered sooner using , which gets the parser working for you sooner.
중요한 스크립트와 데이터는 를 사용하여 더 빨리 전달할 수 있습니다 . 그러면 parser가 더 빨리 작동합니다.
cf) 잉 PRPL이 뭐징??
PRPL 은 다음의 약자라고 합니다.
Push: 초기 URL 에서 가장 중요한 리소스만 푸시합니다.
Render: 초기 경로를 먼저 렌더링 합니다.
Pre-cache: 남은 경로를 사전에 미리 캐시합니다.
Lazy-load: 지연로드 요청에 따라 필요 시 남은 경로를 로드하고 다음 루트를 만들어 보여줍니다.
Patterns like PRPL are worth evaluating in order to ensure initial and subsequent navigations feel instant.
PRPL 과 같은 패턴은 평가할 가치가 있습니다. 보장하기 위해 초기와 후속 탐색이 즉각적으로 느껴지도록
(부족한 직독직해 양행 부탁..ㅎ)
SSR은 무엇인가요?
Server rendering generates the full HTML for a page on the server in response to navigation.SSR은 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 페이지를 보여주는 방식이다. JSP/Servlet의 아키텍처에서 이 방식을 사용했다.
출처: naverD2
서버 렌더링은 서버의 페이지에 대한 전체 HTML을 생성한다 탐색에 대한 응답으로.
This avoids additional round-trips for data fetching and templating on the client, since it’s handled before the browser gets a response.클라이언트에서 데이터 가져오기와 템플릿팅에 대한 추가 왕복을 방지합니다.
이것은 브라우저가 응답을 받기 전에 처리되기 때문!
ssr의 성능 관점에서 몰랐던 점
TTV, TTI, FPC 에 대해서는 알고 있었지만 TTFB,FP는 이번에 정리 하면서 알게 되었다!
TTFB: 첫 번째 바이트까지의 시간 - 링크를 클릭한 후 콘텐츠의 첫 번째 비트가 들어오는 사이의 시간으로 표시됩니다.
FP: 첫 번째 페인트 - 픽셀이 처음으로 사용자에게 표시될 때입니다.
FCP: First Contentful Paint - 요청된 콘텐츠(기사 본문 등)가 표시되는 시간입니다.
TTI: 대화형 시간 - 페이지가 대화형이 되는 시간(연결된 이벤트 등).
Server rendering generally produces a fast First Paint (FP) and First Contentful Paint (FCP).
서버 렌더링은 일반적으로 빠른 FP( First Paint ) 및 FCP( First Contentful Paint )를 생성합니다.
Running page logic and rendering on the server makes it possible to avoid sending lots of JavaScript to the client, which helps achieve a fast Time to Interactive (TTI).
서버에서 페이지 로직과 렌더링을 실행하면 많은 JavaScript를 클라이언트에 보내는 것을 피할 수 있어 빠른 TTI( Time to Interactive )를 달성하는 데 도움이 됩니다.
This makes sense, since with server rendering you’re really just sending text and links to the user’s browser.서버 렌더링을 사용하면 실제로는 텍스트와 링크를 사용자의 브라우저에 보내는 것이기 때문에 이것은 의미가 있습니다.
This approach can work well for a large spectrum of device and network conditions, and opens up interesting browser optimizations like streaming document parsing.
이 접근 방식은 광범위한 장치 및 네트워크 조건에서 잘 작동할 수 있으며 스트리밍 문서 구문 분석과 같은 흥미로운 브라우저 최적화를 제공합니다.
서버 렌더링을 사용하면 사용자가 사이트를 사용하기 전에 CPU 바운드 JavaScript가 처리되기를 기다리지 않을 것입니다.
(cpu 바운드가 뭔지 몰라서 찾아봤는데 프로세스 진행 속도가 CPU 속도에 의해 제한됨을 의미한다고 한다! 깊은 내용은 나중에 다시 찾아봐야겠다!)
Even when third-party JS can’t be avoided, using server rendering to reduce your own first-party JS costs can give you more "budget" for the rest. third-party JS 를 피할 수 없는 경우에도, 서버 렌더링을 사용하여 first-party(직접 개발) JS 비용 을 줄이면 나머지에 대해 더 많은 " 예산 "을 얻을 수 있습니다.However, there is one primary drawback to this approach: generating pages on the server takes time, which can often result in a slower Time to First Byte (TTFB).
그러나 이 접근 방식에는 한 가지 주요 단점이 있습니다. 서버에서 페이지를 생성하는 데 시간이 걸리고 이로 인해 TTFB( Time to First Byte )가 느려질 수 있습니다.
아하 첫화면이 렌더링 되는게 오래된다고만 생각했었는데! 오래걸리는 정확한 시점이 TTFB(링크를 클릭한 후 콘텐츠의 첫 번째 바이트가 들어오는 시간이)가 느려지는 것이였음!
Whether server rendering is enough for your application largely depends on what type of experience you are building.서버 렌더링이 애플리케이션에 충분한지 여부는 주로 구축하는 경험 유형에 따라 다릅니다.
중요한 점! 일부 선택할 수 있다는 것!
There is a londgstaning debate over the correct applications of server rendering versus client-side rendering, but it’s important to remember that you can opt to use server rendering for some pages and not others.
서버 렌더링과 클라이언트 측 렌더링의 올바른 응용 프로그램에 대한 오랜 논쟁이 있지만
일부 페이지에는 서버 렌더링을 사용하고 다른 페이지에는 사용하지 않도록 선택할 수 있다는 점을 기억하는 것이 중요합니다.
넷플릭스도 하이브리드 렌더링 기술을 사용하고 있다!
Some sites have adopted hybrid rendering techniques with success. Netflix server-renders its relatively static landing pages, while prefetching the JS for interaction-heavy pages, giving these heavier client-rendered pages a better chance of loading quickly.
일부 사이트는 성공적으로 하이브리드 렌더링 기술을 채택했습니다. Netflix 서버는 상대적으로 정적인 랜딩 페이지를 렌더링하는 반면, 상호 작용이 많은 페이지에 대해 JS를 미리 가져오기 때문에 클라이언트에서 렌더링한 무거운 페이지에 더 빨리 로드할 수 있는 기회를 제공합니다.
Many modern frameworks, libraries and architectures make it possible to render the same application on both the client and the server.많은 최신 프레임워크, 라이브러리 및 아키텍처를 통해 클라이언트와 서버 모두에서 동일한 애플리케이션을 렌더링할 수 있습니다
These techniques can be used for Server Rendering, however it’s important to note that architectures where rendering happens both on the server and on the client are their own class of solution with very different performance characteristics and tradeoffs.이러한 기술은 서버 렌더링에 사용할 수 있지만, 렌더링이 서버와 클라이언트 모두에서 발생하는 아키텍처는 성능 특성과 절충점이 매우 다른 자체 솔루션 클래스라는 점에 유의하는 것이 중요합니다.
React users can use renderToString() or solutions built atop it like Next.js for server rendering.React 사용자는 renderToString() 또는 서버 렌더링을 위해 Next.js 와 같이 그 위에 빌드된 솔루션을 사용할 수 있습니다.
Vue users can look at Vue’s server rendering guide or Nuxt. Angular has Universal.
Vue 사용자는 Vue의 서버 렌더링 가이드 또는 Nuxt 를 볼 수 있습니다 . Angular에는 유니버설 이 있습니다.
Most popular solutions employ some form of hydration though, so be aware of the approach in use before selecting a tool.
가장 인기 있는 솔루션은 어떤 형태의 hydration작용을 사용하므로 도구를 선택하기 전에 사용 방법을 알고 있어야 합니다.
그 외
Streaming server rendering and Progressive Rehydration
Partial Rehydration
Trisomorphic Rendering
등 소개하고 있는데 따로 소개하지는 않고 한번쯤 읽어보면 좋을 것 같다
CSR vs SSR 장단점
장단점 부분은 드림코딩 엘리님의 강의를 많이 참고하여 정리했다.
https://www.youtube.com/watch?v=iZ9csAfU5Os
CSR의 장점
1) TTV와 TTI와의 간극
초기 로딩시간이 조금 오래 걸리긴 해도 TTV(사용자가 웹사이트를 볼 수 있음과 동시에) TTI(사용자가 인터렉션) 할 수 있다
2) 빠른 인터렉션, 모바일 환경
page 전체를 요청하지 않고 필요한 부분만 변경해서 인터렉션이 빠르고, 모바일 네트워크에서도 빠른 속도로 렌더링이 가능 (위의 웹데브에서도 모바일에서 서버사이드 렌더링이 느리다는 점과는 비교하여 장점인 부분이다)
CSR의 단점
1) 초기 로딩 시간이 오래걸림 inital Loading may take too long
- 사용자가 첫화면을 보기까지 오래걸리면 서비스 이탈율이 발생할 수 있다
2) Low SEO(search Engine Opimization)
- javascript가 실행되어야 (html) 내용이 채워지기 때문에 body 대부분 비워져있어서, SEO에 적합하지 않은 형태입니다.(구글봇에서는 어느정도 개선 되었지만 그럼에도 SEO 부분에서 아쉬운 부분임)
SSR의 장점
1) 초기 로딩속도 빠름 (initial page load is faster)
- 서버에서 어느정도 완성된 페이지가 오기 때문에 TTV 시점이 더 빠르다
2) 효율적인 SEO
- 모든 콘텐츠가 HTML에 담겨있기 때문에 SEO가 페이지 분석을 하기 용이하다
SSR의 단점
1) 깜빡임 이슈 blinking issue, Non-rich site interactions
- 사용자가 클릭을 하면 전체적인 웹 사이트를 다시 서버에서 받아오는 것과 동일해서 좋지 않은 사용자 경험 이슈가 있음
2) 서버 과부하 (server side overhead)
- 특히 사용자가 많은 제품일수록 가용자가 클릭할 때마다 서버에서 필요한 데이터를 가지고 와서 html을 만들어야 하기 때문에 서버에 과부하가 걸릴 수 있음
3) TTV와 TTI의 간극이 크다 (need to wait before interacting)
- 사용자가 빠르게 웹사이트를 확인 할 수는 있지만 동적으로 처리하는 js를 아직 못해서 반응이 없는 경우가 발생할 수 있음
이렇게 장단점을 가지고 있기 때문에 각 서비스 특성에 맞게 고려해서 개발해야 한다
이러한 장단점을 보완하기 위해 reactDOM.server를 사용 할수도 있고,
https://ko.reactjs.org/docs/react-dom-server.html
SSG (Static Site Generation)
React는 클라이언트 사이트 렌더링에 특화된 라이브러리 이지만,
Gatsby 라이브러리와 함께 사용하면,
React로 만든 웹 어플리케이션을 정적으로 웹페이지를 미리 생성하여
서버에 배포해 놓을 수 있다.
모두다 정적이지도 않고 추가적으로 동적으로 처리해야 하는 로직이 필요하다면 동적인 요소도 추가할 수 있다.
React + Next.js
Next.js는 강력한 serverside 렌더링을 지원하는 라이브러리 였는데,
요즘에는 static getneration, no pre-rendering, pre-rendering
CSR과 SSR을 잘 섞어서 유연하게 우리의 목적에 맞게 작성할 수 있게 해준다.
마무리
When deciding on an approach to rendering, measure and understand what your bottlenecks are.
렌더링 접근 방식을 결정할 때 병목 현상이 무엇인지 측정하고 이해하십시오.
Consider whether static rendering or server rendering can get you 90% of the way there.
정적 렌더링 또는 서버 렌더링을 사용하여 90%를 달성할 수 있는지 고려하십시오.
It's perfectly okay to mostly ship HTML with minimal JS to get an experience interactive.
인터랙티브한 경험을 얻기 위해 최소한의 JS로 HTML을 제공하는 것은 전혀 문제가 되지 않습니다.
Here’s a handy infographic showing the server-client spectrum:
다음은 서버-클라이언트 스펙트럼을 보여주는 편리한 인포그래픽입니다.
