웹 앱용 클라이언트 측 vs. 서버 측 vs. 사전 렌더링

최근 프론트엔드 커뮤니티에서 일이 벌어지고 있습니다. 서버 측 렌더링은 React와 내장된 서버 측 수화 기능 덕분에 점점 더 많은 관심을 받고 있습니다. 그러나 초고속 TTFB(time-to-first-byte) 점수로 사용자에게 빠른 경험을 제공하는 유일한 솔루션은 아닙니다. 사전 렌더링도 꽤 좋은 전략입니다. 이러한 솔루션과 완전한 클라이언트 렌더링 애플리케이션의 차이점은 무엇입니까?

클라이언트 렌더링 애플리케이션

Angular, Ember.js 및 Backbone과 같은 프레임워크가 존재하기 때문에 프론트엔드 개발자는 모든 것을 클라이언트 측에서 렌더링하는 경향이 있습니다. Google과 JavaScript를 "읽는" 기능 덕분에 꽤 잘 작동하고 SEO에도 적합합니다.

클라이언트 측 렌더링 솔루션을 사용하면 요청을 단일 HTML 파일로 리디렉션하면 모든 JavaScript를 가져와 브라우저가 콘텐츠를 렌더링하기 전에 모든 것을 컴파일할 때까지 서버가 콘텐츠 없이(또는 로딩 화면과 함께) 요청을 전달합니다.

훌륭하고 안정적인 인터넷 연결에서 꽤 빠르고 잘 작동합니다. 그러나 훨씬 더 나을 수 있으며 그렇게 하는 것이 어려울 필요는 없습니다. 그것이 바로 다음 섹션에서 보게 될 것입니다.

서버 측 렌더링(SSR)

SSR 솔루션은 우리가 몇 년 전에 많이 사용했지만 클라이언트 측 렌더링 솔루션을 선호하는 경향이 있습니다.

이전 서버 측 렌더링 솔루션을 사용하여 웹 페이지(예: PHP)를 구축하면 서버가 모든 것을 컴파일하고 데이터를 포함하고 완전히 채워진 HTML 페이지를 클라이언트에 전달합니다. 빠르고 효과적이었습니다.

그러나… 다른 경로로 이동할 때마다 서버는 모든 작업을 다시 수행해야 했습니다. PHP 파일을 가져와 컴파일하고 HTML을 전달하고 모든 CSS와 JS가 페이지 로드를 수백 ms로 지연시키거나 심지어 전체 초.

SSR 솔루션으로 첫 페이지 로드를 수행한 다음 프레임워크를 사용하여 AJAX로 동적 라우팅을 수행하여 필요한 데이터만 가져올 수 있다면 어떨까요?

이것이 React가 사용하기 쉬운 솔루션인 The RenderToString 메서드로 이 문제를 대중화했기 때문에 SSR이 커뮤니티 내에서 점점 더 주목을 받고 있는 이유입니다.

이 새로운 종류의 웹 애플리케이션을 범용 앱 또는 동형 앱 이라고 합니다. 이 용어의 정확한 의미와 이들 간의 관계에 대해서는 여전히 논란이 있지만 많은 사람들이 혼용하여 사용합니다.

어쨌든 이 솔루션의 장점은 동일한 코드로 앱 서버 측과 클라이언트 측을 개발할 수 있고 사용자 지정 데이터로 사용자에게 정말 빠른 경험을 제공할 수 있다는 것입니다. 단점은 서버를 실행해야 한다는 것입니다.

SSR은 서버의 안정적인 인터넷 연결을 활용하여 데이터를 가져오고 맞춤 콘텐츠로 페이지를 미리 채우는 데 사용됩니다. 즉, 서버 자체의 인터넷 연결이 라이파이를 사용하는 사용자의 인터넷 연결보다 우수하므로 사용자에게 전달하기 전에 데이터를 미리 가져오고 병합할 수 있습니다.

미리 채워진 데이터로 SSR 앱을 사용하면 클라이언트에서 렌더링된 앱이 소셜 공유 및 OpenGraph 시스템과 관련된 문제를 해결할 수도 있습니다. 예를 들어 클라이언트에 전달할 index.html 파일이 하나만 있는 경우에는 한 가지 유형의 메타데이터(대부분 홈페이지 메타데이터)만 갖게 됩니다. 이것은 다른 경로를 공유하고 싶을 때 컨텍스트화되지 않으므로 사용자가 전 세계와 공유하고 싶어하는 적절한 사용자 콘텐츠(설명 및 미리보기 사진)와 함께 다른 사이트에 경로가 표시되지 않습니다.

사전 렌더링

범용 앱의 필수 서버는 일부 사용자에게는 방해가 될 수 있으며 소규모 애플리케이션에는 과도할 수 있습니다. 이것이 사전 렌더링이 정말 좋은 대안이 될 수 있는 이유입니다.

Preact 및 사전 선택된 모든 경로를 컴파일하여 완전히 채워진 HTML 파일을 정적 서버에 저장할 수 있는 자체 CLI를 사용하여 이 솔루션을 발견했습니다. 이를 통해 Node.js 없이도 Preact/React 수화 기능 덕분에 사용자에게 초고속 경험을 제공할 수 있습니다.

문제는 이것이 SSR이 아니기 때문에 이 시점에서 표시할 사용자별 데이터가 없다는 것입니다. 첫 번째 요청에서 있는 그대로 전송된 정적(그리고 다소 일반적인) 파일일 뿐입니다. 따라서 사용자별 데이터가 있는 경우 여기에 아름답게 디자인된 스켈레톤을 통합하여 사용자에게 데이터가 오는 것을 보여주고 사용자의 불만을 피할 수 있습니다.

또 다른 문제가 있습니다. 이 기술이 작동하려면 프록시나 사용자를 올바른 파일로 리디렉션할 무언가가 필요합니다.

왜요?

단일 페이지 애플리케이션의 경우 모든 요청을 루트 파일로 리디렉션해야 하며 프레임워크는 기본 제공 라우팅 시스템으로 사용자를 리디렉션합니다. 따라서 첫 번째 페이지 로드는 항상 동일한 루트 파일입니다.

사전 렌더링 솔루션이 작동하려면 일부 경로에 특정 파일이 필요하고 항상 루트 index.html 파일이 필요한 것은 아님을 프록시에 알려야 합니다.

예를 들어 4개의 경로( / , /about , /jobs 및 blog )가 있고 모두 다른 레이아웃을 가지고 있다고 가정합니다. 사용자에게 스켈레톤을 전달한 다음 React/Preact/etc를 허용할 4개의 다른 HTML 파일이 필요합니다. 데이터로 재수화하십시오. 따라서 이러한 모든 경로를 루트 index.html 파일로 리디렉션하면 페이지가 로드되는 동안 불쾌하고 결함이 있는 느낌이 들게 되어 사용자가 로드를 완료하고 레이아웃을 교체할 때까지 잘못된 페이지의 골격을 보게 됩니다. 예를 들어 사용자가 Pinterest와 같은 갤러리가 있는 다른 페이지를 요청했을 때 단 하나의 열만 있는 홈페이지 골격을 볼 수 있습니다.

해결 방법은 프록시에 네 가지 경로 각각에 특정 파일이 필요하다고 알려주는 것입니다.

• https://my-website.com → 루트 index.html 파일로 리디렉션
• https://my-website.com/about → /about/index.html 파일로 리디렉션
• https://my-website.com/jobs → /jobs/index.html 파일로 리디렉션
• https://my-website.com/blog → /blog/index.html 파일로 리디렉션

이것이 이 솔루션이 소규모 애플리케이션에 유용할 수 있는 이유입니다. 수백 페이지가 있다면 얼마나 고통스러울지 알 수 있습니다.

엄밀히 말하면 이 방법은 필수 사항이 아닙니다. 정적 파일을 직접 사용할 수 있습니다. 예를 들어 https://my-website.com/about/ 은 디렉터리 내에서 index.html 을 자동으로 검색하기 때문에 리디렉션 없이 작동합니다. 하지만 매개변수 URL이 있는 경우 이 프록시가 필요합니다. https://my-website.com/profile/guillaume 은 요청을 자체 레이아웃으로 /profile/index.html 로 리디렉션해야 합니다. 왜냐하면 profile/guillaume/index.html 존재하지 않으며 404 오류가 발생합니다.

간단히 말해서 위에서 설명한 렌더링 전략에는 세 가지 기본 보기가 있습니다. 로드 화면, 스켈레톤 및 최종적으로 렌더링된 전체 페이지입니다.

전략에 따라 때로는 이 세 가지 보기를 모두 사용하고 때로는 완전히 렌더링된 페이지로 바로 이동합니다. 하나의 사용 사례에서만 다른 접근 방식을 사용해야 합니다.

클라이언트 전용 렌더링으로는 충분하지 않은 경우가 많습니다.

클라이언트 렌더링 응용 프로그램은 사용자를 위해 더 잘할 수 있기 때문에 지금 피해야 하는 것입니다. 그리고 이 경우 더 나은 작업은 사전 렌더링 솔루션만큼 쉽습니다. 클라이언트 전용 렌더링보다 확실히 개선되었으며 완전히 서버 측 렌더링된 응용 프로그램보다 구현하기 쉽습니다.

SSR/범용 응용 프로그램은 여러 페이지가 포함된 대규모 응용 프로그램이 있는 경우 정말 강력할 수 있습니다. 소셜 크롤러와 대화할 때 콘텐츠에 집중하고 관련성을 높일 수 있습니다. 이는 검색 엔진 로봇의 경우에도 마찬가지입니다. 이제 검색 엔진 로봇은 순위를 매길 때 사이트의 성능을 고려합니다.

SPA를 사전 렌더링 및 SSR 버전으로 변환하고 성능을 비교하는 후속 자습서를 계속 지켜봐 주시기 바랍니다.