본문으로 건너뛰기
黯羽轻扬매일 조금씩

SSR 의 장단점

무료2020-10-11#Front-End#SSR#React SSR#SSR Pros and Cons#SSR的优缺点#SSR的优势

SSR 을 도입해야 하는가, 도입하면 어떤 장점이 있는가?

一.SSR 개요

SSR(Server-Side Rendering) 은 새로운 개념이 아니며, 프론트엔드와 백엔드 분리之前의 긴 기간 동안에는 서버 사이드 렌더링이 주류였습니다(JSP, PHP). 서버 사이드에서 완전한 HTML 페이지를 생성합니다

前端渲染模式的探索 에서 발췌

서버 사이드에서 컴포넌트 렌더링 작업을 완료하는이유는 성능과 접근성이라는 두 가지 큰 장점이 있기 때문입니다

二.2 가지 큰 장점

성능

CSR(Client-side rendering) 모드와 비교하여 SSR 의 성능 장점은 2 가지 측면에 나타납니다:

  • 네트워크 링크

    • 클라이언트의 이차 요청 데이터 네트워크 전송 오버헤드 절감

    • 서버 사이드의 네트워크 환경이 클라이언트보다 우수하며, 내부 서버 간 통신 경로도 더 짧음

  • 콘텐츠 프레젠테이션

    • 첫 화면 로딩 시간 (FCP) 이 더 빠름

    • 브라우저 콘텐츠 파싱 최적화 메커니즘이 기능을 발휘할 수 있음

네트워크 링크 측면에서, 서버 사이드에서 API 요청을 발송하고, 반환된 데이터를 HTML 응답 콘텐츠와 함께 한 번에 클라이언트로 전송하므로 CSR 의 이차 요청보다 빠릅니다. 또한 서버 사이드의 네트워크 전송 속도가 더 빠르고 (더 큰 대역폭을 가질 수 있음), 통신 경로도 더 짧으며 (같은 데이터센터에 배포 가능), 통신 효율도 더 높습니다 (RPC 사용 가능)

콘텐츠 프레젠테이션 측면에서, CSR 의 HTML 은 대부분 빈 껍데기입니다:

<!DOCTYPE html>
<html>
<head>
    <title>My Awesome Web App</title>
    <meta charset="utf-8">
</head>
<body>
    <div id="app"></div>
    <script src="bundle.js"></script>
</body>
</html>

클라이언트는 이러한 HTML 을 받으면 즉시 빈 페이지를 렌더링할 수밖에 없으며, 이차 요청 데이터가 돌아온 후에야 의미 있는 콘텐츠를呈现할 수 있습니다. 반면 SSR 이 반환하는 HTML 에는 콘텐츠 (데이터) 가 있어, 클라이언트는 즉시 의미 있는 첫 화면 콘텐츠 (First Contentful Paint) 를 렌더링할 수 있습니다. 동시에 정적인 HTML 문서는 스트리밍 문서 파싱 (streaming document parsing) 등의 브라우저 최적화 메커니즘도 그 기능을 발휘하게 합니다

중요한 차이점은 SSR 이 클라이언트 환경에 의존하지 않는다는 것입니다. 네트워크 환경과 디바이스 성능을 포함합니다. 즉, 사용자의 네트워크 상태가 매우 나쁜 경우 (약한 네트워크), 디바이스 성능이 매우 나쁜 경우 (저가, 구형 디바이스) 에도 서버 사이드 렌더링은 최적의 사용자 환경 (Wi-Fi 네트워크, 하이엔드 디바이스) 과 거의 유사한 콘텐츠 로딩 경험을 보장할 수 있습니다

접근성

접근성 (accessibility) 은 두 가지 측면에서 이해할 수 있습니다:

  • 사람에 대해: 오래되고 특수한 사용자 디바이스. 예를 들어 JavaScript 를 비활성化した 디바이스

  • 로봇에 대해: 크롤러 프로그램 등. 전형적으로 검색 엔진 크롤러

전자는 일반적으로 너무 신경 쓸 필요가 없지만, 후자는 두 가지 큰 "고객"에 주목해야 합니다:

  • 검색 엔진: SEO

  • 소셜 미디어: 페이지 콘텐츠를抓取하여 썸네일 정보 표시 (Twitter 카드 등)

PC 사이트의 경우, 검색 엔진이 올바르게 인덱스하고 페이지 내용을 정확하게 이해할 수 있도록 보장하는 것은 중요한 상업적 가치가 있습니다 (검색 결과가 상위에 노출되어 노출량이 커짐). 모바일 엔드에서는 검색 엔진 크롤링을 고려할 필요는 없지만, 유사한 소셜 공유 수요도 있으며, 소셜 미디어는 타겟 페이지 내의 이미지 등을 썸네일 정보로抓取합니다

P.S.확실히 일부 검색 엔진은 무거운 CSR 의 SPA 를 올바르게 크롤링할 수 있지만, 전부는 아니며,さらに一大批의 소셜 미디어는 대부분 응답 HTML 에서 일부 콘텐츠만 썸네일 정보로 추출합니다.동적 렌더링 HTML(일부) 콘텐츠의 수요는 절실히 존재합니다

이러한 장점을 가지고 있지만, SSR 은 CSR 만큼 널리 응용되지 않습니다. SSR 이 6 가지 난제에 직면하고 있기 때문입니다

三.6 가지 난제

난제 1: 기존 CSR 코드를 어떻게 활용하여 아이소모픽을 구현할 것인가

다운그레이드,复用, 마이그레이션 비용 감소 등의 목적으로, 일반적으로 한 세트의 JavaScript 코드로 클라이언트, 서버 사이드를 가로질러 실행하는 아이소모픽 방식을 채택하여 SSR 을 구현합니다. 그러나 기존 CSR 코드를 서버 사이드에서 실행되게 하려면 먼저 많은 문제를 해결해야 합니다. 예를 들어:

  • 클라이언트 의존: API 의존과 데이터 의존 두 가지로 나뉩니다. 예를 들어window/document등의 JS API, 디바이스 관련 데이터 정보 (화면 너비와 높이, 폰트 크기 등)

  • 라이프사이클 차이: 예를 들어 React 에서, componentDidMount는 서버 사이드에서 실행되지 않습니다

  • 비동기 작업이 실행되지 않음: 서버 사이드의 컴포넌트 렌더링 프로세스는 동기적이며, setTimeout, Promise등은 기다릴 수 없습니다

  • 의존 라이브러리의 적응: React, Redux, Dva 등.さらに서드파티 라이브러리 등이 universal 환경에서 실행될 수 있을지도 불확실하며, 환경을 가로질러 상태를 공유할 필요가 있는지도문제입니다. 상태 관리층을 예로 들면, SSR 은 그 store 가 직렬화 가능해야 합니다

  • 양쪽에서 상태 공유: 공유가 필요한 모든 상태에 대해, (서버 사이드에서) 어떻게 전송하고, (클라이언트에서) 어떻게 수신할지 고려해야 합니다

난제 2: 서비스의 안정성과 성능 요구

클라이언트 프로그램과 비교하여, 서버 사이드 프로그램은 안정성과 성능에 대한 요구가 훨씬 엄격합니다. 예를 들어:

  • 안정성: 이상 크래시, 무한 루프

  • 성능: 메모리/CPU 리소스 점유, 응답 속도 (네트워크 전송 거리 등도 고려해야 함)

따라서백엔드 전문적인 문제에 직면합니다. 데모 수준의 SSR 은 그다지 어렵지 않을 수 있지만, 고가용성 SSR 서비스는 결코 쉽지 않습니다. 대량 트래픽/고병행에 어떻게 대처할지, 어떻게 장애를 식별할지, 어떻게 다운그레이드/신속 복구할지, 어떤 링크에 캐시를 추가해야 할지, 캐시를 어떻게 업데이트할지……

난제 3: 부대 시설의 건설

SSR 의 가장 핵심적인 부분은 렌더링 서비스이지만, 그 외에도 고려해야 합니다:

  • 로컬 개발 키트 (검증 + 구축 + 미리보기/HMR+ 디버깅)

  • 릴리스 프로세스 (버전 관리)

한整套의 엔지니어링 시설은 SSR 모드에서는 모두 재고려해야 합니다

난제 4: 돈 문제

SSR 렌더링 서비스를 도입하는 것은 실제로 네트워크 구조에 하나의 노드를 추가하는 것이며, 대량 트래픽이 지나는 곳에서는 모든 레이어가 돈입니다:

Most importantly, SSR React apps cost a lot more in terms of resources since you need to keep a Node server up and running.

컴포넌트 렌더링 로직을 클라이언트에서 서버로 변경하여 실행하므로, 계산 리소스 비용을 고려해야 합니다

난제 5: hydration 의 성능 손실

클라이언트는 SSR 응답을 받은 후, (JavaScript 기반의) 인터랙션 기능을 지원하기 위해 여전히 컴포넌트 트리를 생성하고, SSR 이 렌더링한 HTML 과 연관시키고, 관련 DOM 이벤트를 바인딩하여 페이지를 인터랙티브하게 만들어야 합니다. 이 프로세스를 hydration 이라고 합니다

hydration 에 필요한 JavaScript 코드의 로딩과 실행은 CSR 모드보다 그다지 적지 않을 수 있습니다. 이 부분 작업은 클라이언트에서 실행되며, 사용자 디바이스 성능에 제한받아,较差의 디바이스에서는 지각 가능한 비인터랙티브 시간을 초래할 수 있습니다:

  • CSR: 인터랙티브하지만 데이터가 없음 (비동기로 데이터 요청 중이며, 매우 길어질 수 있음)

  • SSR: 데이터는 있지만 인터랙티브하지 않음 (JS 를 가져온 후 hydrate 프로세스 시작, 콘텐츠는 보이지만 인터랙티브하지 않음. 일반적으로 그다지 길지는 않음)

리치 인터랙션 시나리오에서는 후자가 반드시 전자보다 사용자 경험이 좋다고 할 수 없습니다

난제 6: 데이터 요청

서버 사이드 동기 렌더링은 먼저 요청을 발송하고, 데이터를 받은 후에야 컴포넌트 렌더링을 시작하므로 3 가지 문제에 직면합니다:

  • 데이터 의존을 비즈니스 컴포넌트에서 분리해야 함

  • 클라이언트 공공 파라미터 누락 (cookie 등 클라이언트가 기본적으로 부여하는 header 정보 포함)

  • 양쪽 데이터 프로토콜이 다름: 서버 사이드에는 더 효율적인 통신 방식이 있을 수 있음. 예를 들어 RPC

현재 주류인 CSR 모드에서는 데이터 의존과 비즈니스 컴포넌트가 밀접하게 결합되어 있으며, 서버 사이드에서 발송해야 하는 데이터 요청은 모두 컴포넌트 라이프사이클 함수에 혼재되어 있습니다.데이터 의존을 분리하는 것은 CSR 코드도 동시에 개조해야 함을 의미합니다. 공공 파라미터, 데이터 프로토콜 등의 차이도 코드复用, 유지보수성에 대해 몇 가지 새로운 도전을 제기합니다

四。애플리케이션 시나리오

첫 화면 로딩 성능도 접근성도, 콘텐츠密集型페이지에 대해서만 의미가 있으며, 인터랙션密集型페이지에서는 SSR 이 미리 렌더링할 수 있는 콘텐츠가 많지 않아 사용자에게 큰 의미가 없으며, SEO 의 필요성도 검토의 여지가 있습니다. 따라서, SSR 은 정적인 콘텐츠 표시 시나리오에 적합합니다. 전형적으로, 상품 상세, 가이드, 기사 등의图文混排 시나리오입니다

다른 측면에서, 반드시 100% SSR 일 필요는 없으며, 특정 페이지를 렌더링하는 것뿐만 아니라 페이지 프레임만 렌더링하는 것도 좋은 응용입니다:

"Application Shell" is an excellent concept. But sometimes, we might need to render a part of the page in the server. It could be the header with user info. In such cases, you need server-side rendering.

참고 자료

댓글

아직 댓글이 없습니다

댓글 작성