csr 문제점
-lighthouse 점수가 낮게 나옴.
- 초기 body가 비어있다가 js가 돌면서 렌더링이 되는 방식
- client에서 초기에 렌더링 해야 할 요소가 많아짐
-메모리 누수가 많음
ssr
-
node.js의 발전으로 client와 server를 같은 언어를 쓸 수 있게 되면서
다시 렌더링의 책임을 server로 일부 돌리는 움직임이 나타난다. -
과거에는 client, server에 따라 각각의 언어로 뷰 로직을 구현했다.
-
serverless가 아니게 되므로 server책임이 생긴다
-
관리해야하는 server가 있기 때문에 트래픽이 몰릴 경우 스케일 업, 스케일 아웃 등의 관리가 필요할 수 있다.
-
docker로 말아서 배포할 경우 빌드 및 배포 시간이 csr대비해서 더 늘어난다.
-
세팅이 복잡하다.
그런데,,, ssr이든 csr이든 콘텐츠 변경이 많이 없으면, 렌더링 해둔채로 캐싱해두면 되는게 아닐까?
ssr의 경우 렌더링 결과를 redis에 캐시해서 제공하는 식으로 최적화 했었는데, 이걸 그냥 html 파일로 만들어버린다면?
csr, ssr 상관없이 렌더링 될 수 있는 모든 경우의 수를 미리 만들어 놓는건 어떨까?
=> SSG라는 결론에 도달
-
동적인 페이지를 포함해서 사이트의 모든 페이지를 정적으로 만들어버림
-
모든 동적인 케이스에 따라 사이트를 만드므로, server가 다시 필요없게 된다.
=> 자연스럽게, meta tag문제도 해결 -
렌더링 해둔 결과물을 제공하므로 ,JS실행시간도 줄일 수 있다.
-
이미 생성된 정적인 페이지를 내려주므로 CDN을 통해 제공할 수 있기 때문에, 큰이득을 얻을 수 있다.
<But .... 문제점>
+++ 그런데 ... 동적으로 렌더링해야하는 컨텐츠가 많을 경우,
빌드 시간이 컨텐츠 갯수에 비례해서 증가한다.
++++ 배포된 이후에 컨텐츠의 내용이 바뀌면, 변경된 내용을 적용하려면 다시! 빌드해서 배포해야한다.
Distributed Persistent Rendering
- ssg의 단점을 보완하기 위한 방법, 정적 생성하는 것은 동일
- 일부 페이지만 정적으로 생선, 비교적 중요하지 않은 페이지는 최초 접근 시 렌더링 하고 그 결과를 정적 파일로 만든다.
Incremental Static Regeneration
- next.js에서 dpr를 isr이라는 개념으로 지원한다.
- 정적으로 생성되는 페이지에 필요시 revalidate라는 값으로 유효시간을 설정한다.
- 해당 값이 지난 이후 요청이 들어오면, 최신 데이터를 반영해 다시 렌더링한다.
