7. Streaming SSR의 단점

Suspense와 Streaming SSR 방식도 몇 가지 한계가 있음

1. 비록 JS 코드가 브라우저에 의해 비동기적으로 스트리밍 된다고 해도, 결과적으로는 웹 페이지 로딩에 필요한 전체 코드가 사용자 디바이스로부터 다운로드되어야 함

따라서, 애플리케이션의 기능이 추가될수록, 사용자가 다운로드 받아야 하는 코드의 양도 증가함 → 사용자가 정말로 그 많은 데이터들을 다운 받아야 하는지?

2. 특정 컴포넌트가 사용자와 상호작용할 수 있는 컴포넌트인지에 대한 여부와 관계없이, 모든 리액트 컴포넌트는 클라이언트 측에서 Hydration을 거쳐야 하도록 강제되고 있음

결과적으로 이러한 프로세스는 클라이언트 쪽에서 별도의 인터랙션이 필요하지 않을 수도 있는 컴포넌트들까지도 브라우저를 통해 다 처리해야 하기 때문에 리소스를 비효율적으로 소비하고 그만큼 로딩 시간이 증가, 사용자와 상호작용할 수 있는 시간을 지연시키게 됨

→ 별도의 인터랙션이 필요하지 않은 컴포넌트들도 hydration 되어야 하는지?

3. 서버가 좋은 연산 처리 능력을 보유하였음에도 불구하고, JS 파일의 실행은 여전히 사용자 디바이스에서 수행됨

결과적으로 사용자마다 서로 다른 디바이스의 성능 차이에 따라 페이지의 응답 속도가 달라지며, 특히 성능이 좋지 않은 디바이스에서는 응답 속도가 더 느려짐

→ 렌더링에 필요한 수많은 작업들이 꼭 사용자의 장치에서 수행되어야만 하는지?