Next.js: TTFB 및 CPU 부하를 줄이기 위한 스트림 렌더링

한가지 언급할건..

스트림 렌더링은 일반적으로 수행해야 할 작업의 양이 동일하기 때문에 CPU 향상을 많이 추가하지 않습니다. 그러나 응답 시간이 단축됩니다.

SSR 렌더링 시스템을 사용자 정의하는 방법을 제공하는 것은 꽤 좋은 생각입니다. 하지만 지금은 기본적으로 React의 renderToString() 메서드를 고수할 것입니다.

이것은 2.0 이후에 할 수 있는 것입니다.

스트림 렌더링은 일반적으로 수행해야 할 작업의 양이 동일하기 때문에 CPU 향상을 많이 추가하지 않습니다.

_aickin/react-dom-stream에서 _

ReactDOM.renderToString에 대한 한 번의 호출은 CPU를 지배하고 다른 요청을 고갈시킬 수 있습니다. 이것은 작은 페이지와 큰 페이지가 혼합된 서비스를 제공하는 서버에서 특히 문제가 됩니다.

스트리밍은 비동기 및 부분 모두를 통해 큰 페이지에 대한 메모리 할당 및 CPU 사용량을 현명하게 줄이지 않습니까?

이것이 같은 맥락이라고 생각했습니다. 누구든지 https://github.com/FormidableLabs/rapscallion을 시도 했습니까?

스트리밍 인터페이스를 제공하므로 클라이언트에 즉시 콘텐츠 전송을 시작할 수 있습니다.

문서의 다른 기능:

• 렌더링은 비동기식이며 비차단입니다.
• Rapscallion은 renderToString보다 약 50% 빠릅니다.
• 스트리밍 인터페이스를 제공하므로 클라이언트에 즉시 콘텐츠 전송을 시작할 수 있습니다.
• 스트리밍의 이점을 포기하지 않고 구성 요소의 HTML을 상용구로 래핑할 수 있도록 템플릿 기능을 제공합니다.
• 렌더링 속도를 더욱 높일 수 있는 구성 요소 캐싱 API를 제공합니다.

#2279에 Rapscallion의 예를 추가했습니다... Rapscallion + Next가 미쳤음을 확인할 수 있습니다. 스트리밍/약속 기반 렌더링은 훌륭하지만 구성 요소 수준 캐싱은 우리에게 게임 체인저입니다... :godmode:

이제 React 16에는 자체 renderToNodeStream 가 있으므로 next.js가 renderToString 대신 이를 사용하는 옵션을 추가하는 것은 큰 이점이 될 것입니다. @timneutkens 어떻게 생각하세요?

이미 추가할 목록에 있습니다 👍

이것에 대한 소식이 있습니까?

https://github.com/zeit/next.js/pull/4074#issuecomment -466996162

소식이 있나요?

Next.js는 사용자가 사용자 정의 비동기 렌더러를 사용할 수 있도록 사용자 정의 render ( renderToString 를 기본 렌더러로 사용)를 노출해야 합니다.
이 기능이 없기 때문에 비동기 렌더러를 사용하기 위해 razzle 를 사용해야 했습니다.

저는 다음 두 가지를 제외하고 Next.js의 모든 것을 좋아합니다.

• 커스텀 비동기 렌더러.
• 서버와 클라이언트 모두에 대한 사용자 정의 babel 구성.

어떤 로드맵/스트리밍 렌더링 지원 계획이 있습니까? 그래서 next.js에 이것을 가질 것으로 예상됩니다.

React Fizz / 이에 대한 계획을 구현하는 React 팀에서 보류 중입니다.

@timneutkens 여기에서 추적할 문제, PR은 무엇입니까?

2019년 8월 8일에 게시된 Facebook 블로그 게시물에서
https://reactjs.org/blog/2019/08/08/react-v16.9.0.html

서버 렌더링에 대한 업데이트
우리는 새로운 Suspense 가능 서버 렌더러에 대한 작업을 시작했지만 동시 모드의 초기 릴리스를 위해 준비되지 않을 것으로 예상합니다. 그러나 이 릴리스에서는 기존 서버 렌더러가 즉시 Suspense 폴백용 HTML을 내보내고 클라이언트에서 실제 콘텐츠를 렌더링할 수 있도록 하는 임시 솔루션을 제공합니다. 이것은 스트리밍 렌더러가 준비될 때까지 Facebook에서 현재 사용하고 있는 솔루션입니다.

아직 서버 스트리밍 지원을 기다리는 사람을 위해 :)

next.js에서 renderToNodeStream을 구현하는 업데이트나 다른 방법이 있습니까?

업데이트가 있습니까?

<3

모든 업데이트?

@StarpTech 나는 이것에 대해 조금 살펴보았고(이 기능도 궁금합니다!) 반응 팀이 react-flight 라는 작업을 하고 있는 것 같습니다. 이는 아마도 우리가 여기서 기다리고 있는 스트리밍 솔루션의 기반이 될 것입니다. :)

반응 비행:

커스텀 React 스트리밍 모델을 사용하기 위한 실험적인 패키지입니다.

내부 작업에 약간의 빛을 비추는 관련 PR, 내가 해석한 것(이 중 어느 것도 전문가가 아님 🙈)
#17285 : 비행을 위한 기본 API, 서버는 모든 것을 문자열로 스트리밍할 수 있어야 하지만 서버에서 비동기적으로 해결되는 청크에 대한 자리 표시자는 남겨둘 수 있습니다. 리액트가 스트림에서 실제로 나타내는 데이터 유형이 무엇인지 알 수 있는 불완전하지만 흥미로운 구문이 여기에 있습니다 .

# 17398 최근의 PR, 그래서 덩어리위한 API (당신이 운이 느끼는 경우) 당신 자신에서 그 부분을 시도해 볼 수도 있습니다를 추가합니다. 모든 것이 어떻게 합쳐질지 모르겠지만 그럼에도 불구하고 이 모든 작업이 완료되는 것을 보니 다소 기쁩니다. :)

_주제에서 약간 벗어난 내용일 수 있지만 이 호를 구독하는 사람들에게 흥미로울 수 있기를 바랍니다. :)_

@pepf 정보 감사합니다!

흠. 여러분, 흥미로운 정보 감사합니다. 나는 왜 NextJS가 지금 streamAsString을 사용하지 않고 서스펜스 및 기타에 대한 React 지원 SSR을 기다려야 하는지 생각하고 있습니다.

@arunoda 저 메모리 람다 함수 또는 Cloudflare 작업자에 매우 중요한 메모리 소비를 줄일 것이라고 생각합니다.

이것에 대한 소식이 있습니까?

소식이 있나요?

소식 있어? :피

반응 서스펜스가 절대 나오지 않을 것 같은 느낌이 나는 것을 감안할 때 이것을 다시 볼 수 있는 방법이 있습니까? 상당히 일반적인 콘텐츠가 적은 페이지(vercel의 서버리스 기능에서 렌더링됨)에서 800-1000ms의 초기 렌더링 시간을 보고 있습니다. 이론적으로 HTML을 스트리밍하면 초기 접촉 지점이 증가하고 훨씬 빠르게 인지되는 첫 번째 로드 ux로 이어질 수 있습니다.

NextJS가 아닌 Vercel의 한계인가요? Vercel은 Lambda와 같은 종류의 콜드 스타트업에 희생됩니까? 우리 팀은 콘텐츠가 많은 사이트를 많이 운영하고 있으며 전체 요청에 대해 타이밍이 50ms 미만입니다. 스트리밍이 여기서 은총알이 될 것이라고는 생각하지 않습니다.

나는 그것이 은색 총알이 될 것이라고 기대하지 않지만 분명히 환영할만한 개선이 될 것입니다.

50ms는 언급된 콜드 스타트 ​​시간에 비해 최적화하기에는 너무 작고 상대적으로 중요하지 않지만 Cloudflare 작업자와 같은 엣지에서 렌더링할 때는 그렇지 않습니다(가장 가까운 Cloudflare 엣지 위치에 대한 핑 또는 최소 절반 ), Cloudflare 작업자는 콜드 스타트 ​​시 일반적으로 5밀리초 미만으로 매우 빠르게 응답합니다. 대조적으로, Lambda 및 Lambda@Edge 함수는 모두 콜드 스타트에서 응답하는 데 1초 이상 걸릴 수 있습니다.
이것이 Varcel(자체 cdn을 빌드함)이 고용한 next.js 개발자에게 더 나은 사례가 되지 않는다는 것을 알고 있습니다.

사람들이 next.js를 Cloudflare 작업자에게 성공적으로 배포한 문서나 저장소가 있습니까? 나는 약간의 인터넷 검색을했고 그것에 대해 많이 찾지 못했습니다. 정말 놀랍습니다.

내 휴대전화에서 전송됨

2020년 7월 5일 오후 5시 47분에 Wis [email protected]이 다음과 같이 썼습니다.

50ms는 언급된 콜드 스타트 ​​시간과 비교하여 최적화하기에 매우 낮고 상대적으로 중요하지 않지만 Cloudflare 작업자와 같은 엣지에서 렌더링할 때는 50ms가 많습니다(가장 가까운 Cloudflare 엣지 로케이션에 대한 핑 또는 최소한 절반), Cloudflare 작업자는 콜드 스타트 ​​시 일반적으로 5밀리초 미만으로 매우 빠르게 응답합니다. 대조적으로, Lambda 및 Lambda@Edge 함수는 모두 콜드 스타트에서 응답하는 데 1초 이상 걸릴 수 있습니다.
이것이 Varcel(자체 cdn을 빌드함)이 고용한 next.js 개발자에게 더 나은 사례가 되지 않는다는 것을 알고 있습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 구독을 취소하세요.

50ms는 언급된 콜드 스타트 ​​시간에 비해 최적화하기에는 매우 작고 상대적으로 중요하지 않습니다.

명확히 하자면, 나는 50ms 응답 시간에 대해 불평하지 않았습니다. 저는 NextJS의 SRR이 콘텐츠가 많은 페이지에 대해 분당 3,000개 이상의 요청에서도 상대적으로 성능이 좋다고 지적한 것뿐이므로 Switz의 문제는 다른 곳에 있을 수 있습니다.

사람들이 next.js를 Cloudflare 작업자에게 성공적으로 배포한 문서나 저장소가 있습니까?

나도 그것에 관심이 있을 것이다. 현재 Fargate에서 실행 중이지만 앱을 엣지로 푸시하는 것이 논리적인 다음 단계가 될 것입니다.

HTML 내에서 가능한 모든 개선 사항을 적용했으며 서버 응답 시간이 엄청나게 빨라졌습니다! :(

@huggler 이 예제 를 cacheable-response 와 결합할 수 있습니다. Redis(또는 예를 들어 인메모리 캐시)를 사용하여 html을 캐시에 저장할 수 있습니다. 서버 응답 시간을 향상시킵니다.

사람들이 next.js를 Cloudflare 작업자에게 성공적으로 배포한 문서나 저장소가 있습니까? 나는 약간의 인터넷 검색을했고 그것에 대해 많이 찾지 못했습니다. 정말 놀랍습니다.

@switz @tils13 https://fab.dev/ 확인하셨나요? 우리는 2020년 초에 그것을 가지고 놀았고 그것은 시험판 상태에 있었지만 꽤 멀리 온 것 같습니다. 그들을 가로막는 제한 사항 중 하나는 Cloudflare 자체였지만 지금쯤이면 상황이 변경되었을 수 있습니다.

한동안 보지 않았습니다. 재평가해야 할 것입니다. 지난번에 보니 꽤 심각한 트레이드오프가 있었습니다.

나는 또한 https://github.com/flareact/flareact를 주시하고

이에 대한 업데이트가 있습니까?