웹 렌더링 방식들에 대한 좋은 영상이 있어서 자료로 남깁니다. 다음과 같은 렌더링 방식들을 비교해주는 콘텐츠입니다. Server Side Rendering vs. Client Side Rendering vs. Static Site Generation vs. Deferred Site Generation vs. Incremental Static Regeneration vs. Edge Rendering vs. Hybrid Rendering ======================== ======================== =========================== //
Client Side Rendering
웹사이트는 클라이언트의 브라우저에서 JavaScript 를 이용해서 렌더링이 됩니다. 이러한 방식을 Client Side Rendering 이라고 합니다.
이러한 방식은 클라이언트의 웹 브라우저에서 실행되기 때문에 다음과 같은 특징을 갖습니다. 웹 렌더링을 위한 서버가 필요 없기 때문에 비용이 절감됩니다. In-app ux 가 구현 가능하고 Offline support 가 가느ㅇ합니다. 하지만 최초 웹 브라우저 로딩 시 성능이 안 좋다는 특징이 있습니다.
또한 검색 엔진에 최적화 되지 않는다는 특징이 있는데요. 왜냐하면, 검색 엔진 클로러는 웹 페이지가 렌더링 되는 것을 그냥 기다려주지 않기 때문입니다.
Server Side Rendering
Server Side Rendering 에서는 화면을 서버에서 렝더링 한 다음, 유저 장치에게 보내주는 특징을 가지고 있습니다. Next.js 가 대표적입니다.
SSR 에서는 다음과 같은 특징들을 갖습니다.보안이 상승된다는 점이 있는데요. SSR 에서는 모든 웹의 동장이 API 를 통해서만 진행되기 때문에 그렇습니다.
역시나 가장 큰 단점은 비용이 너무 크게 증가합니다. 각각 유저가 처리하던 렌더링을 서버에서 다 처리해주어야 하니까요.
Static Site Generation
Static Site Generation 이라는 것도 있는데요. 페이지를 아예 빌드 시에 다 렌더링을 해놓고 렌더링 된 페이지들을 유저에게 제공하는 방식입니다. 말그대로 '정적' 페이지를 활용하는 사이트에서는 효과적인 방법으로 사용할 수 있을 것 같은데요.
이 방식에서는 CDN 에서 정적 페이지를 유저에게 제공해주는 방식으로 동작합니다. 위와 같은 특징들을 가지게 되는데요.
가장 큰 단점은 빌드 타임이 크게 증가하게 된다는 겁니다. 모든 정적 페이지들을 다 렌더링을 해야 빌드가 끝나기 때문에 빌드 타임이 굉장히 길어지게 됩니다. 그리고 가장 최악인 점은 내가 일부만 수정했더라도 모든 페이지들을 모두 다 렌더링을 다시 해야 결과물을 서버에서 확인해볼 수 있다는 점입니다.
Deferred Site Generation
Deferred Site Generation 은 장점을 섞은 렌더링 방식인데요.
가장 중요한 페이지들은 build time 에서 렌더링 하고 나머지 페이지들은 cloud worker 에서 유저가 요청이 들어오면 렌더링 해서 활용하는 방식입니다. 위와 같은 특징 들이 있습니다.
가장 큰 단점은 작은 변경점이 생겼다면, 전체 빌드 과정을 다시 수행해야 한다는 점입니다.
Incremental Static Regeneration
Incremental Static Regeneration 은 Static Site Generation 에서 수정된 일부분만 다시 빌드할 수 있도록 개선된 것을 의미합니다.
Incremental Static Regenration 의 특징을 살펴보겠습니다.재밌는 특징은, static site generation 임에도 불구하고 'dynamic data' 를 rebuild 없이 지원하기 시작 했다는 것인데요.
그리고 SSG 이기 때문에 서버에서 렌더링 된 것들을 이미 들고서 유저가 접근하면 제공해주기 때문에 유저 경험이 상당 부분 개선 될 수 있습니다.
가장 큰 단점은 'real time' 에서 드러납니다.무슨 말이냐면, static site generation 인 만큼, 유저가 최초에 만나는 페이지는 '빌드' 시에 있던 데이터들을 기반으로 렌더링 된 페이지이기 때문에 '실시간 데이터'가 반영된 페이지를 유저가 최초에 만날 수 없다는 겁니다. 이후에 유저가 다시 화면을 재렌더링 요청하는 과정을 거쳐야 실시간 데이터를 다시 만날 수 있다는 것이죠. 이런 것을 해결하기 위해서 ISR 2.0 을 이용하는 것을 권장하고 있는데요. On-demand ISR 입니다. 무엇이냐면, 개발자가 특정 url 에 유저가 접근하면, 이 페이지에서는 실시간 재렌더링을 강제하는 방식입니다. 이렇게 하면 실시간 데이터에 대응할 수 있게 됩니다.
Edge Rendering
Edge Rendering 은 CDN 과 유사하게 동작하는데요. Edge Redering 에서는 엣지 서버에서 웹 콘텐트를 캐싱하고 서비스 한다는 특징이 있습니다. 그래서 렌더링을 엣지 서버에서 진행하고, 유저는 여기에서 렌더링 된 자료들을 가져다가 사용하는 방식입니다.
이런 Edge Rendering 은 다양한 장점을 가지게 되는데요. dynamic content 에 효과적으로 대응할 수 있게 되면서, real time data 를 효과적으로 대응할 수 있게 됩니다.
그리고, network latency 도 개선되는데요. 왜냐하면 모든 유저가 다양한 엣지 서버를 통해서 데이터를 가져가기 때문입니다. 또한 확장성도 개선되는데요. 서버가 여러개가 운용이 되기 때문에 내가 필요하면 서버를 늘이거나 줄일 수 있기 때문입니다.
가장 큰 단점은 '유연성'입니다.Edge 서버 방식은, 특정한 구현 방식을 강요하기 때문입니다.
Hybrid Rendering
Hybrid Rendering 은 Server side Rendering 과 Client Side Rendering 방식을 혼합한 방식입니다.
이런 Hybrid Rendering 은 2.0 으로 훨씬 더 강력해졌는데요. 각 routes 마다 caching strategy 를 각각 가져갈 수 있게 되었기 때문입니다.그래서 위에서 보이는 것과 같이 우리가 원하는 대로 렌더링 방식을 조정할 수 있다는 것이 큰 장점입니다.
미래에 좀 더 다뤄볼 렌더링은..
Jamstack
Jamstack 이라는 것을Fuentes 라는 분이 만들었다고 하는데요.
Jamstack 은 웹 레이어와 비즈니스 로직을 분리시키는 아키텍처 접근 방식이라고 합니다.
