서버 측 렌더링에 대한 해당 기사도 읽었습니다. 일부 프레임워크는 노드 측에서 초기화되는 것 같습니다. 하지만 일반적인 프런트엔드 프레임워크에는 DOM이 포함되어야 하지만 서버에는 DOM 작업이 없어야 한다고 생각합니다. 제가 묻고 싶은 것은: 1. 소위 서버사이드 렌더링이 해결하는 문제는 무엇인가요? 2. SEO 문제는 어떻게 해결됐나요? 3. 스파 애플리케이션의 첫 화면 성능이 낮은 것에 대한 현재 솔루션은 무엇입니까?
가장 큰 것은 SEO 문제를 해결하는 것이고, 두 번째는 클라이언트 렌더링 속도를 높이는 것입니다.
서버 측 렌더링(SSR) 간단히 말하면 ReactDOM.renderToString 이 메서드를 호출하고 서버 측에서 js 컨텍스트로 구성 요소를 렌더링한 다음 클라이언트 측에서 반응할 때 html 태그를 반환합니다. 실행, 반응을 통해 가상 DOM은 반응 ID를 비교하여 점진적으로 업데이트됩니다. 즉, 특정 DOM에 클라이언트에 대한 업데이트가 없으면 서버의 결과를 직접 얻으므로 클라이언트의 렌더링 속도는 어느 정도 속도가 빨라졌습니다.
두 번째는 seo입니다. 서버가 html 태그를 직접 반환하기 때문에 크롤러라도 실제 seo 태그를 반환합니다. 이는 일부 포털에 매우 유용합니다. 이러한 방식으로 검색 엔진 크롤러는 웹사이트의 주요 정보를 크롤링할 수 있으며 이는 웹사이트 순위에 도움이 됩니다.
SSR 성능 측면에서 일반적인 솔루션은 캐시를 통한 것으로 보입니다. github에는 electronic-react-ssr-caching react-ssr-optimization과 같은 프로젝트가 있습니다. 이러한 프로젝트는 본질적으로 캐시를 통해 SSR을 최적화합니다. props를 비교함으로써 캐시는 다음 렌더링 속도를 높입니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
React의 서버 측 렌더링과 관련하여 제가 이해한 바를 간략하게 말씀드리겠습니다.
가장 큰 것은 SEO 문제를 해결하는 것이고, 두 번째는 클라이언트 렌더링 속도를 높이는 것입니다.
서버 측 렌더링(SSR) 간단히 말하면
ReactDOM.renderToString이 메서드를 호출하고 서버 측에서 js 컨텍스트로 구성 요소를 렌더링한 다음 클라이언트 측에서 반응할 때 html 태그를 반환합니다. 실행, 반응을 통해 가상 DOM은 반응 ID를 비교하여 점진적으로 업데이트됩니다. 즉, 특정 DOM에 클라이언트에 대한 업데이트가 없으면 서버의 결과를 직접 얻으므로 클라이언트의 렌더링 속도는 어느 정도 속도가 빨라졌습니다.두 번째는 seo입니다. 서버가 html 태그를 직접 반환하기 때문에 크롤러라도 실제 seo 태그를 반환합니다. 이는 일부 포털에 매우 유용합니다. 이러한 방식으로 검색 엔진 크롤러는 웹사이트의 주요 정보를 크롤링할 수 있으며 이는 웹사이트 순위에 도움이 됩니다.
SSR 성능 측면에서 일반적인 솔루션은 캐시를 통한 것으로 보입니다. github에는 electronic-react-ssr-caching
react-ssr-optimization과 같은 프로젝트가 있습니다. 이러한 프로젝트는 본질적으로 캐시를 통해 SSR을 최적화합니다. props를 비교함으로써 캐시는 다음 렌더링 속도를 높입니다.