게시: 2019년 2월 6일, 최종 업데이트: 2026년 1월 5일
웹 개발자가 내려야 하는 핵심 결정 중 하나는 애플리케이션에서 로직과 렌더링을 구현할 위치입니다. 웹사이트를 구축하는 방법은 매우 다양하기 때문에 이 작업은 어려울 수 있습니다.
이 분야에 대한 Google의 이해는 지난 몇 년 동안 대규모 사이트와 대화하는 Chrome에서의 작업에 기반합니다. 일반적으로 개발자는 전체 리하이드레이션 접근 방식보다는 서버 측 렌더링 또는 정적 렌더링을 고려하는 것이 좋습니다.
이 결정을 내릴 때 선택하는 아키텍처를 더 잘 이해하려면 각 접근 방식에 대한 일관된 용어와 공유 프레임워크가 필요합니다. 그런 다음 페이지 성능 측면에서 각 렌더링 접근 방식의 장단점을 더 잘 평가할 수 있습니다.
용어
먼저 사용할 용어를 정의합니다.
렌더링
- 서버 측 렌더링 (SSR)
- 자바스크립트가 아닌 HTML을 클라이언트에 전송하기 위해 서버에서 앱을 렌더링하는 것
- 클라이언트 측 렌더링 (CSR)
- 브라우저에서 앱을 렌더링하고 JavaScript를 사용하여 DOM을 수정합니다.
- 사전 렌더링
- 빌드 시 클라이언트 측 애플리케이션을 실행하여 초기 상태를 정적 HTML로 캡처합니다. 이러한 의미의 '사전 렌더링'은 향후 탐색의 브라우저 사전 렌더링과 다릅니다.
- 수분 섭취
- 클라이언트 측 스크립트를 실행하여 서버에서 렌더링된 HTML에 애플리케이션 상태와 상호작용을 추가합니다. 하이드레이션은 DOM이 변경되지 않는다고 가정합니다.
- 리하이드레이션
- 하이드레이션과 같은 의미로 사용되는 경우가 많지만, 리하이드레이션은 초기 하이드레이션 후를 포함하여 최신 상태로 DOM을 정기적으로 업데이트하는 것을 의미합니다.
성능
- 첫 바이트까지의 시간 (TTFB)
- 링크를 클릭한 시점부터 새 페이지에 콘텐츠의 첫 번째 바이트가 로드되는 시점까지의 시간입니다.
- 첫 콘텐츠 페인트 (FCP)
- 요청된 콘텐츠 (기사 본문 등)가 표시되는 시간입니다.
- 다음 페인트에 대한 상호작용 (INP)
- 페이지가 사용자 입력에 일관되게 빠르게 반응하는지 평가하는 대표적인 측정항목입니다.
- 총 차단 시간 (TBT)
- 페이지 로드 중에 기본 스레드가 차단된 시간을 계산하는 INP의 프록시 측정항목입니다.
서버 측 렌더링
서버 측 렌더링은 탐색에 대한 응답으로 서버에서 페이지의 전체 HTML을 생성합니다. 이렇게 하면 브라우저가 응답을 받기 전에 렌더러가 이를 처리하므로 클라이언트에서 데이터를 가져오고 템플릿을 만드는 추가 왕복이 방지됩니다.
서버 측 렌더링은 일반적으로 빠른 FCP를 생성합니다. 서버에서 페이지 로직을 실행하고 렌더링하면 클라이언트에 많은 JavaScript를 전송하지 않아도 됩니다. 이렇게 하면 페이지의 TBT를 줄이는 데 도움이 되며, 페이지 로드 중에 기본 스레드가 자주 차단되지 않으므로 INP도 낮아질 수 있습니다. 기본 스레드가 차단되는 빈도가 줄어들면 사용자 상호작용이 더 빨리 실행될 기회가 많아집니다.
서버 측 렌더링을 사용하면 실제로 텍스트와 링크만 사용자 브라우저로 전송하므로 이는 당연한 결과입니다. 이 접근 방식은 다양한 기기 및 네트워크 조건에서 잘 작동하며 스트리밍 문서 파싱과 같은 흥미로운 브라우저 최적화를 가능하게 합니다.
서버 측 렌더링을 사용하면 사용자가 사이트를 사용하기 전에 CPU 바인딩 JavaScript가 실행될 때까지 기다릴 필요가 없습니다. 서드 파티 자바스크립트를 피할 수 없는 경우에도 서버 측 렌더링을 사용하여 자체 퍼스트 파티 자바스크립트 비용을 줄이면 나머지 부분에 더 많은 예산을 할당할 수 있습니다. 하지만 이 접근 방식에는 한 가지 잠재적인 단점이 있습니다. 서버에서 페이지를 생성하는 데 시간이 걸리므로 페이지의 TTFB가 증가할 수 있습니다.
서버 측 렌더링이 애플리케이션에 충분한지 여부는 주로 빌드하는 환경 유형에 따라 달라집니다. 서버 측 렌더링과 클라이언트 측 렌더링의 올바른 적용에 관해서는 오랫동안 논쟁이 있었지만, 일부 페이지에는 서버 측 렌더링을 사용하고 다른 페이지에는 사용하지 않는 방식을 선택할 수 있습니다. 일부 사이트에서는 하이브리드 렌더링 기법을 성공적으로 채택했습니다. 예를 들어 Netflix는 비교적 정적인 방문 페이지를 서버에서 렌더링하는 한편, 상호작용이 많은 페이지의 JavaScript를 prefetching 더 무거운 클라이언트 렌더링 페이지를 더 빠르게 로드할 수 있습니다.
많은 최신 프레임워크, 라이브러리, 아키텍처를 사용하면 클라이언트와 서버 모두에서 동일한 애플리케이션을 렌더링할 수 있습니다. 이러한 기법을 서버 측 렌더링에 사용할 수 있습니다. 그러나 서버와 클라이언트 모두에서 렌더링이 발생하는 아키텍처는 성능 특성과 장단점이 매우 다른 자체 솔루션 클래스입니다. React 사용자는 서버 측 렌더링을 위해 서버 DOM API 또는 이를 기반으로 빌드된 Next.js와 같은 솔루션을 사용할 수 있습니다. Vue 사용자는 Vue의 서버 측 렌더링 가이드 또는 Nuxt를 사용할 수 있습니다. Angular에는 Universal이 있습니다.
하지만 가장 많이 사용되는 솔루션은 어떤 형태로든 하이드레이션을 사용하므로 도구에서 사용하는 접근 방식을 알고 있어야 합니다.
정적 렌더링
정적 렌더링은 빌드 시 발생합니다. 이 접근 방식은 페이지의 클라이언트 측 JavaScript 양을 제한하는 한 빠른 FCP와 더 낮은 TBT 및 INP를 제공합니다. 또한 서버 측 렌더링과 달리 페이지의 HTML을 서버에서 동적으로 생성할 필요가 없으므로 일관되게 빠른 TTFB를 달성합니다. 일반적으로 정적 렌더링은 각 URL에 대해 별도의 HTML 파일을 미리 생성하는 것을 의미합니다. HTML 응답을 미리 생성하면 정적 렌더링을 여러 CDN에 배포하여 에지 캐싱을 활용할 수 있습니다.
정적 렌더링을 위한 솔루션은 다양한 형태와 크기로 제공됩니다. Gatsby와 같은 도구는 개발자가 애플리케이션이 빌드 단계로 생성되는 것이 아니라 동적으로 렌더링되는 것처럼 느끼도록 설계되었습니다. 11ty, Jekyll, Metalsmith와 같은 정적 사이트 생성 도구는 정적 특성을 수용하여 보다 템플릿 기반의 접근 방식을 제공합니다.
정적 렌더링의 단점 중 하나는 가능한 모든 URL에 대해 개별 HTML 파일을 생성해야 한다는 것입니다. 이러한 URL을 미리 예측해야 하고 고유 페이지가 많은 사이트의 경우 이 작업이 어렵거나 불가능할 수 있습니다.
React 사용자는 Gatsby, Next.js 정적 내보내기 또는 Navi에 익숙할 수 있으며, 이 모든 기능을 통해 구성요소에서 페이지를 편리하게 만들 수 있습니다. 하지만 정적 렌더링과 사전 렌더링은 다르게 작동합니다. 정적으로 렌더링된 페이지는 클라이언트 측 JavaScript를 많이 실행하지 않아도 상호작용이 가능하지만, 사전 렌더링은 클라이언트에서 부팅해야 페이지가 실제로 상호작용할 수 있는 단일 페이지 애플리케이션의 FCP를 개선합니다.
특정 솔루션이 정적 렌더링인지 사전 렌더링인지 확실하지 않은 경우 JavaScript를 사용 중지하고 테스트하려는 페이지를 로드해 보세요. 정적으로 렌더링된 페이지의 경우 JavaScript 없이도 대부분의 대화형 기능이 계속 존재합니다. 사전 렌더링된 페이지에는 JavaScript가 사용 중지된 링크와 같은 몇 가지 기본 기능이 있을 수 있지만 대부분의 페이지는 비활성 상태입니다.
또 다른 유용한 테스트는 Chrome DevTools에서 네트워크 제한을 사용하여 페이지가 상호작용 가능해지기 전에 다운로드되는 JavaScript의 양을 확인하는 것입니다. 사전 렌더링은 일반적으로 상호작용을 위해 더 많은 자바스크립트가 필요하며, 이 자바스크립트는 정적 렌더링에 사용되는 점진적 개선 접근 방식보다 더 복잡한 경향이 있습니다.
서버 측 렌더링과 정적 렌더링
서버 측 렌더링은 동적 특성으로 인해 상당한 컴퓨팅 오버헤드 비용이 발생할 수 있으므로 모든 경우에 가장 적합한 솔루션은 아닙니다. 많은 서버 측 렌더링 솔루션은 조기에 플러시하지 않거나, TTFB를 지연시키거나, 전송되는 데이터를 두 배로 늘립니다(예: 클라이언트에서 JavaScript가 사용하는 인라인 상태). React에서 renderToString()는 동기식이고 단일 스레드이므로 느릴 수 있습니다.
최신 React 서버 DOM API는 스트리밍을 지원하므로 HTML 응답의 초기 부분을 브라우저에 더 빨리 전송할 수 있으며, 나머지 부분은 서버에서 계속 생성됩니다.
서버 측 렌더링을 '올바르게' 수행하려면 구성요소 캐싱을 위한 솔루션을 찾거나 빌드하고, 메모리 소비를 관리하고, 메모이제이션 기법을 사용하고, 기타 문제를 해결해야 할 수 있습니다. 클라이언트에서 한 번, 서버에서 한 번, 동일한 앱을 두 번 처리하거나 다시 빌드하는 경우가 많습니다. 서버 측 렌더링을 사용하면 콘텐츠가 더 빨리 표시되지만, 그렇다고 해서 작업량이 줄어드는 것은 아닙니다. 서버에서 생성된 HTML 응답이 클라이언트에 도착한 후 클라이언트에서 처리해야 할 작업이 많으면 웹사이트의 TBT와 INP가 여전히 높아질 수 있습니다.
서버 측 렌더링은 각 URL에 대해 요청 시 HTML을 생성하지만, 정적 렌더링 콘텐츠를 제공하는 것보다 느릴 수 있습니다. 추가 작업을 수행할 수 있는 경우 서버 측 렌더링과 HTML 캐싱을 사용하면 서버 렌더링 시간을 크게 줄일 수 있습니다. 서버 측 렌더링의 장점은 정적 렌더링보다 더 많은 '실시간' 데이터를 가져오고 더 완전한 요청 집합에 응답할 수 있다는 것입니다. 맞춤설정이 필요한 페이지는 정적 렌더링에서 제대로 작동하지 않는 요청 유형의 구체적인 예입니다.
서버 측 렌더링은 PWA를 빌드할 때 흥미로운 결정을 내릴 수도 있습니다. 전체 페이지 서비스 워커 캐싱을 사용하는 것이 더 나은가요, 아니면 개별 콘텐츠를 서버에서 렌더링하는 것이 더 나은가요?
클라이언트 측 렌더링
클라이언트 측 렌더링은 자바스크립트를 사용하여 브라우저에서 직접 페이지를 렌더링하는 것을 의미합니다. 모든 로직, 데이터 가져오기, 템플릿, 라우팅은 서버가 아닌 클라이언트에서 처리됩니다. 실제 결과는 서버에서 사용자 기기로 더 많은 데이터가 전달되며, 이로 인해 장단점이 발생합니다.
클라이언트 측 렌더링은 휴대기기에서 빠르게 만들고 유지하기 어려울 수 있습니다.
엄격한 JavaScript 예산을 유지하고 가능한 한 적은 왕복으로 가치를 제공하기 위해 약간의 노력을 기울이면 클라이언트 측 렌더링이 순수 서버 측 렌더링의 성능을 거의 복제할 수 있습니다. <link rel=preload>를 사용하여 중요한 스크립트와 데이터를 전송하면 파서가 더 빠르게 작동하도록 할 수 있습니다. 또한 PRPL과 같은 패턴을 사용하여 초기 및 후속 탐색이 즉각적으로 이루어지도록 하는 것이 좋습니다.
클라이언트 측 렌더링의 주요 단점은 애플리케이션이 커짐에 따라 필요한 JavaScript의 양이 증가하여 페이지의 INP에 영향을 미칠 수 있다는 것입니다. 이는 새로운 JavaScript 라이브러리, 폴리필, 서드 파티 코드가 추가되면 특히 어려워집니다. 이들은 처리 능력을 두고 경쟁하며 페이지 콘텐츠를 렌더링하기 전에 처리해야 하는 경우가 많습니다.
클라이언트 측 렌더링을 사용하고 대규모 JavaScript 번들에 의존하는 환경에서는 적극적인 코드 분할을 고려하여 페이지 로드 중에 TBT 및 INP를 낮추고, JavaScript를 지연 로드하여 사용자가 필요로 하는 것만 필요할 때 제공해야 합니다. 상호작용이 거의 없거나 전혀 없는 환경의 경우 서버 측 렌더링이 이러한 문제에 대한 확장성이 더 높은 솔루션이 될 수 있습니다.
단일 페이지 애플리케이션을 빌드하는 경우 대부분의 페이지에서 공유하는 사용자 인터페이스의 핵심 부분을 식별하면 앱 셸 캐싱 기법을 적용할 수 있습니다. 서비스 워커와 함께 사용하면 페이지가 CacheStorage에서 앱 셸 HTML 및 종속 항목을 매우 빠르게 로드할 수 있으므로 반복 방문 시 체감 성능이 크게 향상될 수 있습니다.
서버 측 렌더링과 클라이언트 측 렌더링을 결합하는 리하이드레이션
하이드레이션은 클라이언트 측 렌더링과 서버 측 렌더링을 모두 수행하여 두 렌더링 간의 장단점을 완화하는 접근 방식입니다. 전체 페이지 로드 또는 새로고침과 같은 탐색 요청은 애플리케이션을 HTML로 렌더링하는 서버에서 처리됩니다. 그런 다음 렌더링에 사용되는 JavaScript 및 데이터가 결과 문서에 삽입됩니다. 신중하게 수행하면 서버 측 렌더링과 같은 빠른 FCP를 달성한 다음 클라이언트에서 다시 렌더링하여 '선택'합니다.
이는 효과적인 솔루션이지만 상당한 성능 저하가 발생할 수 있습니다.
리하이드레이션을 사용하는 서버 측 렌더링의 주요 단점은 FCP를 개선하더라도 TBT 및 INP에 상당한 부정적인 영향을 미칠 수 있다는 것입니다. 서버 측 렌더링 페이지는 로드되고 상호작용이 가능한 것처럼 보일 수 있지만 구성요소의 클라이언트 측 스크립트가 실행되고 이벤트 핸들러가 연결될 때까지는 실제로 입력에 응답할 수 없습니다. 모바일에서는 이 작업에 몇 분이 걸릴 수 있어 사용자가 혼란스러워하고 불만을 느낄 수 있습니다.
리하이드레이션 문제: 앱 하나에 두 개의 앱 가격이 청구됨
클라이언트 측 JavaScript가 서버에서 렌더링한 모든 데이터를 다시 요청하지 않고 서버가 중단한 지점부터 정확하게 이어받으려면 대부분의 서버 측 렌더링 솔루션은 UI의 데이터 종속 항목의 응답을 문서의 스크립트 태그로 직렬화합니다. 이로 인해 많은 HTML이 중복되므로 리하이드레이션은 상호작용 지연 이상의 문제를 일으킬 수 있습니다.
서버는 탐색 요청에 대한 응답으로 애플리케이션 UI의 설명을 반환하지만, UI를 구성하는 데 사용된 소스 데이터와 UI 구현의 전체 사본도 반환하며, 이 사본은 클라이언트에서 부팅됩니다. bundle.js가 로드 및 실행을 완료할 때까지 UI가 상호작용하지 않습니다.
서버 측 렌더링 및 리하이드레이션을 사용하는 실제 웹사이트에서 수집된 실적 측정항목에 따르면 이 방법이 최선의 옵션인 경우는 거의 없습니다. 가장 중요한 이유는 페이지가 준비된 것처럼 보이지만 상호작용 기능이 작동하지 않을 때 사용자 환경에 미치는 영향입니다.
리하이드레이션이 적용된 서버 측 렌더링을 사용하면 됩니다. 단기적으로는 캐시 가능한 콘텐츠에만 서버 측 렌더링을 사용하면 TTFB를 줄여 사전 렌더링과 유사한 결과를 얻을 수 있습니다. 점진적, 단계적 또는 부분적으로 리하이드레이션하는 것이 향후 이 기법을 더 실용적으로 만드는 열쇠가 될 수 있습니다.
서버 측 렌더링을 스트리밍하고 점진적으로 리하이드레이션
서버 측 렌더링은 지난 몇 년 동안 많은 발전을 이루었습니다.
스트리밍 서버 측 렌더링을 사용하면 브라우저가 수신되는 대로 점진적으로 렌더링할 수 있는 청크로 HTML을 전송할 수 있습니다. 이렇게 하면 마크업을 사용자에게 더 빠르게 전달하여 FCP를 가속화할 수 있습니다. React에서 스트림은 renderToString()와 달리 renderToPipeableStream()에서 비동기식이므로 백프레셔가 잘 처리됩니다.
점진적 리하이드레이션도 고려할 가치가 있습니다(React에서 구현함). 이 접근 방식을 사용하면 전체 애플리케이션을 한 번에 초기화하는 현재의 일반적인 접근 방식 대신 서버에서 렌더링된 애플리케이션의 개별 부분이 시간이 지남에 따라 '부팅'됩니다. 이렇게 하면 페이지의 우선순위가 낮은 부분의 클라이언트 측 업그레이드를 지연시켜 기본 스레드를 차단하지 않도록 할 수 있으므로 페이지를 상호작용 가능하게 만드는 데 필요한 JavaScript의 양을 줄일 수 있습니다. 이를 통해 사용자가 상호작용을 시작한 후 더 빨리 상호작용이 발생할 수 있습니다.
점진적 리하이드레이션은 가장 일반적인 서버 측 렌더링 리하이드레이션 문제 중 하나를 방지하는 데도 도움이 됩니다. 서버에서 렌더링된 DOM 트리가 소멸된 후 즉시 다시 빌드되는 경우가 많습니다. 이는 초기 동기식 클라이언트 측 렌더링에 아직 준비되지 않은 데이터(아직 확인되지 않은 Promise인 경우가 많음)가 필요했기 때문입니다.
부분 리하이드레이션
부분 리하이드레이션은 구현하기 어려운 것으로 입증되었습니다. 이 접근 방식은 페이지의 개별 부분(구성요소, 뷰 또는 트리)을 분석하고 상호작용이 거의 없거나 반응성이 없는 부분을 식별하는 점진적 리하이드레이션의 확장입니다. 이러한 대부분 정적인 부분 각각에 대해 해당 JavaScript 코드는 비활성 참조 및 장식 기능으로 변환되어 클라이언트 측 사용 공간을 거의 0으로 줄입니다.
부분 리하이드레이션 접근 방식에는 자체적인 문제와 절충점이 있습니다. 캐싱에 몇 가지 흥미로운 과제가 있으며, 클라이언트 측 탐색은 전체 페이지 로드 없이 애플리케이션의 비활성 부분에 대한 서버 렌더링 HTML을 사용할 수 있다고 가정할 수 없음을 의미합니다.
삼형 렌더링
서비스 워커를 사용할 수 있는 경우 트라이소모픽 렌더링을 고려하세요. 이 기법을 사용하면 초기 또는 JavaScript가 아닌 탐색에 스트리밍 서버 측 렌더링을 사용한 다음 서비스 워커가 설치된 후 탐색을 위한 HTML 렌더링을 수행하도록 할 수 있습니다. 이렇게 하면 캐시된 구성요소와 템플릿을 최신 상태로 유지하고 동일한 세션에서 새 뷰를 렌더링하기 위해 SPA 스타일 탐색을 사용 설정할 수 있습니다. 이 접근 방식은 서버, 클라이언트 페이지, 서비스 워커 간에 동일한 템플릿 및 라우팅 코드를 공유할 수 있는 경우에 가장 적합합니다.
검색엔진 최적화 고려사항
웹 렌더링 전략을 선택할 때 팀은 검색엔진 최적화의 영향을 고려하는 경우가 많습니다. 서버 측 렌더링은 크롤러가 해석할 수 있는 '완전한 모양'의 환경을 제공하는 데 널리 사용되는 선택입니다. 크롤러는 JavaScript를 이해할 수 있지만 렌더링 방식에 제한이 있는 경우가 많습니다. 클라이언트 측 렌더링은 작동할 수 있지만 추가 테스트와 오버헤드가 필요한 경우가 많습니다. 최근에는 아키텍처가 클라이언트 측 JavaScript에 크게 의존하는 경우 동적 렌더링도 고려해 볼 만한 옵션이 되었습니다.
결론
렌더링 접근 방식을 결정할 때는 병목 현상을 측정하고 파악하세요. 정적 렌더링 또는 서버 측 렌더링으로 대부분의 작업을 처리할 수 있는지 고려하세요. 대화형 환경을 구현하기 위해 최소한의 JavaScript로 대부분의 HTML을 전송해도 괜찮습니다. 다음은 서버-클라이언트 스펙트럼을 보여주는 유용한 인포그래픽입니다.
크레딧
리뷰와 영감을 주신 모든 분께 감사드립니다.
제프리 포스닉, 후세인 지르데, 슈비 패니커, 크리스 해럴슨, 세바스찬 마크바게에게 감사의 말을 전합니다.