React를 사용한 서버 측 렌더링

React에 대해 조금

React는 Facebook 개발자 커뮤니티에서 만들고 유지 관리하는 오픈 소스 프론트엔드 JavaScript 라이브러리입니다. 사용자 인터페이스 또는 UI 구성 요소를 빌드하는 데 사용됩니다.

그러나 이 정의는 초보자에게 완전히 이해되지 않을 수 있습니다. React에 대한 간략한 설명과 여기에 대한 매우 상세한 기술 설명까지 안내하는 완벽한 블로그 게시물이 있습니다. 여기에서 찾을 수 있습니다.

웹 페이지의 여정 | 서버에서 브라우저로

서버 측 렌더링이 무엇인지 이해하려면 먼저 웹 페이지가 화면에 어떻게 표시되는지에 대한 개요를 얻는 것이 중요합니다. 이는 아래 다이어그램에 의해 설명됩니다.

1. 웹사이트의 URL을 입력하거나 웹사이트 링크를 클릭할 때마다 브라우저는 URL로 식별되는 적절한 서버로 일부 파일에 대한 요청을 보냅니다.
2. 서버는 HTML 및 JavaScript 파일과 같은 일부 파일을 브라우저로 보냅니다.
3. 귀하의 브라우저는 이러한 파일을 다운로드 및 '렌더링'하거나 처리하며 귀하는 귀하가 요청한 웹 페이지를 보고 상호작용할 수 있습니다.

이것은 웹 페이지의 여정을 지나치게 단순화한 것이지만, 이 작업을 수행하기 위한 다양한 하위 단계와 다양한 방법(서버 측 렌더링 포함)을 설명하기에 충분한 서문입니다.

'일반' 클라이언트 측 렌더링 웹 페이지의 여정

이전 섹션에서 언급한 프로세스를 더 자세히 살펴보면 사용자 화면에 웹 사이트를 표시하기 위해 오랫동안 사용되어 온 클라이언트 측 렌더링 또는 CSR이라는 기술이 있습니다. 이것은 다음 다이어그램에 설명되어 있습니다.

1. 웹사이트의 URL을 입력하거나 웹사이트 링크를 클릭하면 브라우저는 URL로 식별되는 적절한 서버로 일부 파일에 대한 요청을 보냅니다.
2. 서버는 이미지 파일, CSS 파일 및 JavaScript 파일과 같은 다른 자산에 대한 참조가 포함된 HTML 파일을 보냅니다.
3. 브라우저는 서버에 다시 요청을 보내고 HTML 파일에서 참조하는 CSS 및 JavaScript 파일을 포함하여 모든 파일을 다운로드합니다.
   1. 이는 사용자가 연결 상태가 좋지 않고 JavaScript 파일의 크기가 큰 경우 웹 사이트의 로딩 시간을 늘리는 데 기여할 수 있습니다.
4. 브라우저에서 이러한 파일을 다운로드하면 브라우저는 프레임워크 또는 라이브러리(예: React)를 실행하고 웹 페이지를 대화형으로 만드는 역할을 하는 JavaScript 파일을 구문 분석합니다.
   1. 속도 최적화 관점에서 이 지점은 클라이언트 시스템에 따라 달라지며 클라이언트가 저전력 하드웨어인 경우 상당한 시간이 걸릴 수 있습니다.
   2. 이러한 단계가 진행되는 동안 사용자는 여전히 로딩 화면을 봅니다.
5. 웹 페이지가 마침내 완전히 로드되고 사용자가 웹 페이지를 보고 상호 작용할 수 있습니다.

위에서 언급한 단계에서 분명히 알 수 있듯이 사용자의 관점에서 볼 때 필요한 모든 파일이 클라이언트 시스템에 의해 다운로드 및 렌더링된 후에만 최종 단계에서 웹 사이트를 보고 상호 작용할 수 있습니다.

이는 프레임워크를 실행하고 JavaScript 파일을 구문 분석하는 클라이언트 시스템의 성능에 따라 달라지기 때문에 엄청난 시간이 걸릴 수 있습니다.

서버 측 렌더링 웹 페이지의 여정

한 줄로 설명하자면, Server Side Rendering 또는 SSR은 클라이언트 측 JavaScript 프레임워크 웹사이트를 CSR의 경우와 같이 클라이언트 대신 서버에서 정적 HTML 및 CSS로 렌더링하는 프로세스입니다.

아래에 언급된 것은 웹 페이지가 React를 사용하여 Server Side Rendering을 사용하는 여정을 그림으로 나타낸 것입니다.

1. 웹사이트의 URL을 입력하거나 웹사이트 링크를 클릭하면 브라우저는 URL로 식별되는 적절한 서버로 일부 파일에 대한 요청을 보냅니다.
2. 서버는 CSR에서와 같이 바닐라 HTML 파일을 전송하는 대신 react-dom/server 에서 가져온 renderToString 함수를 사용하여 앱을 문자열로 렌더링합니다.
   1. 그런 다음 index.html 파일에 삽입되어 브라우저로 전송됩니다.
   2. SSR의 핵심은 기능적으로 말하면 클라이언트 시스템이 아닌 서버가 페이지를 렌더링하는 곳이기 때문입니다.
3. 브라우저는 이 HTML 파일을 렌더링하여 브라우저에 뷰가 채워집니다.
   1. 그러나 이것은 아직 대화형이 아니지만 사용자는 웹 페이지의 최종 보기를 볼 수 있습니다.
4. 브라우저는 서버에 다시 요청을 보내고 JavaScript 파일을 포함하여 HTML 파일에서 참조하는 모든 파일을 다운로드합니다.
5. 모든 스크립트가 다운로드되면 React 구성 요소가 클라이언트에서 다시 렌더링됩니다. 그러나 이번에는 기존 뷰를 덮어쓰는 대신 수화합니다.
   1. 뷰 '하이드레이팅'은 렌더링된 DOM(Document Object Model) 요소에 이벤트 핸들러를 연결하지만 렌더링된 DOM 요소는 그대로 유지한다는 의미입니다. 이렇게 하면 DOM 요소의 상태가 유지되고 뷰가 재설정되지 않습니다.
6. 웹 페이지가 마침내 완전히 로드되었으며 사용자는 이제 3단계에서 볼 수 있었던 페이지와 상호 작용할 수 있습니다.

따라서 사용자의 관점에서 볼 때 가장 큰 시각적 변화 중 하나는 웹 페이지가 매우 빠르게 '표시'된다는 것입니다. 브라우저의 관점에서 HTML을 렌더링하는 것은 리소스를 많이 사용하지 않기 때문입니다.

이것은 본질적으로 비 SSR 앱보다 페이지 로드를 더 빠르게 만들지 않지만 JavaScript 파일이 백그라운드에서 다운로드 및 구문 분석된 후 웹 페이지가 대화식으로 전환될 때 사용자에게 웹 페이지 보기를 제공합니다. 이것은 TTI, 즉 Time To Interactive(사용자가 웹 페이지를 요청할 때부터 웹 페이지가 완전히 상호 작용하는 데 걸리는 시간)가 웹 페이지가 표시되는 데 걸리는 시간보다 약간 더 길다는 것을 의미합니다. 브라우저에서.

따라서 SSR 시나리오에서 더 빠른 첫 번째 렌더링 시간을 위해서는 HTML과 CSS가 사용자에게 의미가 있어야 하고 JavaScript는 로딩이 지연되기 때문에 HTML과 CSS를 향상시킬 수 있습니다.

React와 SSR의 작동에 대한 일반적인 오해 는 사용자가 새 데이터를 요청하는 것과 같이 모든 변경 후에 서버가 모든 단계를 다시 완료하고 새 UI가 포함된 HTML 파일을 브라우저에 보낸다는 것입니다. 그러나 이것은 사실이 아닙니다. . 페이지에 대한 부분적인 업데이트만 수행됩니다. 렌더링은 서버에서 수행되지만 최종 출력은 앞에서 설명한 대로 '수화'하여 DOM에 삽입됩니다.

서버 측 렌더링 | 사용하지 않는 시기와 시기

• 강력한 SEO가 필요한 경우 검색 엔진이 크롤링하기 쉽기 때문에 SSR로 이동하십시오.
• 블로그, 뉴스 웹사이트, 정적 웹사이트 및 텍스트가 많은 웹사이트와 같이 콘텐츠 중심이고 상호작용 중심이 아닌 웹사이트의 경우, SSR은 웹사이트의 핵심, 즉 콘텐츠를 빠르게 로드하므로 이점이 될 수 있습니다.
• 브라우저로 보낼 파일을 렌더링하고 생성하려면 서버 측에서 시간과 노력이 필요합니다. 따라서 서버 및 운영 예산이 낮은 경우 서버에 많은 요청이 전송되므로 SSR을 구현하지 않는 것이 좋습니다.
  • 그러나 Firebase와 같은 공급자를 사용하면 클라우드 기능을 사용하여 콘텐츠를 동적으로 생성할 수 있고 서버는 CDN 캐시에 저장할 수 있습니다.
  • 이렇게 하면 다음에 사용자가 요청할 때 파일 생성이 서버에서 다시 수행되지 않습니다. 오히려 로컬 CDN 에지에서 제공되므로 서버 리소스를 덜 사용하면서 사용자의 관점에서 로드 시간을 개선할 수 있습니다.

React는 SSR에 어떻게 좋은가요?

React는 가상 DOM(Document Object Model)의 개념을 통합하기 때문에 SSR을 구현하는 탁월한 선택입니다.

이를 통해 개발자는 React 앱의 가상 버전을 만들고 서버 자체에 가질 수 있습니다.

이렇게 하면 앞에서 설명한 대로 renderToString 함수를 사용하여 HTML로 렌더링하는 것이 더 쉬워지고 브라우저로 전송하여 브라우저가 매우 빠르게 렌더링하고 클라이언트 시스템에서 가상 버전을 만들 수 있습니다.

따라서 이 가상 버전이 우리가 서버에서 보낸 HTML과 일치한다는 사실을 보면 React는 이를 다시 렌더링하지 않으므로 TTI(Time To Interactive)를 줄여 웹 페이지를 '더 빠르게' 로드할 수 있습니다.

SSR, 하루 종일, 매일!

우리는 모든 것을 위한 모든 솔루션이 있기를 바라지만, 특히 신기술의 경우에는 그렇지 않습니다. SSR에는 많은 이점이 있지만 앞에서 설명한 것처럼 SSR이 좋은 선택이 아닐 수 있는 몇 가지 경우가 있습니다. 고도로 상호 작용하는 사이트가 그 선두에 있습니다.

이것이 바로 Creole Studios가 등장하는 곳입니다. 우리는 기술 세계에 등장하는 거의 모든 새로운 기술에 항상 뒤지지 않는 일련의 기술 전문가를 보유하고 있습니다. 우리는 귀하의 비즈니스 요구 사항을 이해하고 SSR 또는 CSR 앱과 같은 맞춤형 솔루션을 제공할 것이며 귀하를 위해 무거운 일을 하는 동안 아무 걱정도 하지 않으셔도 됩니다. 저희에게 연락하고 머리에서 나온 아이디어를 앱으로 가져오세요!