rendering

아래 소개들은 정적 페이지가 아닌 서버로부터 데이터를 패칭하는 페이지를 기준으로 작성되었습니다.

SSR(Server Side Rendering)

ex) php, jsp, asp

Flow

사용자가 웹 페이지에 방문한다(request)
request를 받은 서버는 해당 페이지에 필요한 데이터를 패칭 하기위해 REST API 엔드포인트에 다시 request를 보낸다.
엔드포인트에서 response가 오면, 서버는 html 파일에 응답받은 데이터 정보를 포함해서 사용자에게 response 해준다.
사용자가 페이지를 이동할 경우 위 동작을 반복한다.

SSR의 장점

SEO에 친화적이다

서버가 데이터를 다 그려서 응답해주기 때문에 검색 엔진이 웹 페이지 정보를 잘 수집해갈 수 있습니다.

CSR에 비해 클라이언트에 부담이 덜하다

런타임에 JavaScript를 이용해 콘텐츠를 그리는 CSR과 달리 SSR은 서버가 콘텐츠를 그려서 응답 해주기 때문에 기기 성능에 크게 영향을 받지않고 웹 페이지를 제공할 수 있습니다.

SSR의 단점

라우팅 시 TTFB(Time to First Byte)가 느리다

서버가 데이터를 패칭하고 해당 데이터를 기반으로 html 파일을 생성해서 사용자에게 응답 해주기 때문에 다른 렌더링 방식들보다 TTFB가 느립니다.

서버 호스팅이 필요하다

클라이언트에서 javaScript를 이용해 렌더링하는 CSR와 미리 빌드 타임에 정적인 html파일을 생성한 뒤 응답해주는 Static Rendering에 비해 SSR은 서버 사이드에서 html파일 안 내용을 생성하기 때문에 서버 호스팅이 필요합니다.

Client Side Rendering

ex) react, vue, angular

Flow

사용자가 웹 페이지에 방문한다(request)
script, meta, link등의 태그를 포함하고 있는 빈 콘텐츠의 index.html을 response한다.
브라우저가 index.html에 있는 javaScript 번들 파일을 패칭한 뒤 파싱하고 실행해서 콘텐츠를 렌더링한다.
해당 페이지에 필요한 데이터를 패칭 하기위해 REST API/gql 엔드포인트에 request를 보낸다.
엔드포인트에서 response가 오면, 해당 데이터를 기반으로 콘텐츠를 브라우저에 렌더링한다.
사용자가 페이지를 이동할 경우 서버에 추가족안 html파일 요청 없이 이미 받은 javaScript를 이용해 렌더링합니다.

CSR의 장점

페이지 간의 이동 속도(반응성)가 빠르다

라우팅시 api를 제외하고 추가적인 서버 요청 없이 클라이언트단에서 javaScript로 렌더링하기 때문에 SSR에 비해 라우팅 속도(반응성)가 빠릅니다.

별도의 웹용 서버가 필요 없다

클라이언트단에서 라우팅을 처리하기 때문에 s3와 같은 스토리지에 빌드된 파일만 올려놓으면 별도의 서버 호스팅 없이 웹 사이트를 사용자에게 제공 가능합니다.

CSR의 단점

초기 로딩이 느리다

javaScript로 웹 페이지를 렌더링하기 때문에 콘텐츠를 표시 해주기위해선 html을 다 불러온 뒤 추가적으로 javaScript를 이용해 콘텐츠를 렌더링하는 작업이 필요합니다.

SEO에 친화적이지 않다

크롤러가 요청을 보냈을 때 빈 콘텐츠의 html 파일을 응답 해준 뒤 클라이언트에서 javaScript를 이용해 웹 페이지를 렌더링하기 때문에 구글을 제외한 나머지 검색 엔진들은 빈 페이지로 인식하게 됩니다.

사용자의 기기 성능에 영향 받는다

클라이언트에서 javaScript를 이용해 웹 페이지를 렌더링하기 때문에 저 성능 기기의 경우 초기 로딩 시 성능 이슈가 있을 수 있습니다.

Universal Rendering

ex) Next.js, Nuxt.js, Angular Universal

Flow

사용자가 웹 페이지에 방문한다(request)
request를 받은 서버는 해당 페이지에 필요한 데이터를 패칭 하기위해 REST API/GraphQL 엔드포인트에 다시 request를 보낸다.
엔드포인트에서 response가 오면, 서버는 html 파일에 응답받은 데이터 정보를 포함해서 사용자에게 response 해준다.
이 상태에서 초기 콘텐츠들은 다 렌더링 되었지만 아직 javaScript 번들이 패칭중이기 때문에 인터렉션이 불가능합니다.(Dehydrate 상태)
javaScript 번들이 다 파싱되면 hydration을 진행하고 그 이후 부터는CSR와 동일하게 동작합니다.

Universal Rendering의 장점

초기 로딩시에는 ssr처럼 작동하고, 그 이후에는 csr처럼 작동해서 ssr과 csr 장단점을 보안할 수 있습니다.

Universal Rendering의 단점

Universal Rendering을 직접 구현하기보다는 프레임워크를 사용해야하는 경우가 많으므로, 해당 프레임워크에 대한 러닝커브가 있습니다.
서버 호스팅이 필요 없는 Static Rendering, Client Side Rendering과 달리 Server Side Rendering과 같이 별도의 서버 호스팅이 필요합니다

Static Rendering

ex) Gatsby, Next.js, Hugo, Jekyll

Flow

빌드 타임에 REST API/GraphQL 엔드포인트에 request를 보내서 데이터를 받아온 뒤 html파일로 프리렌더링 해놓는다.
사용자가 웹 페이지에 방문한다(request)
미리 만들어 놓은 html파일을 제공해준다.

Static Rendering의 장점

빌드 타임에 프리렌더링 해놓기 때문에 페이지 로딩/응답 속도가 빠르다.

Static Rendering의 단점

빌드 타임에 프리렌더링 해놓기 때문에 빌드 타임 이후에 진행되는 데이터 변경을 페이지에 반영하지 못합니다(프리렌더링 시 api을 호출 할 때 기준)

Reference

Last updated 3 years ago

아래 소개들은 정적 페이지가 아닌 서버로부터 데이터를 패칭하는 페이지를 기준으로 작성되었습니다.

SSR(Server Side Rendering)

ex) php, jsp, asp

Flow

사용자가 웹 페이지에 방문한다(request)
request를 받은 서버는 해당 페이지에 필요한 데이터를 패칭 하기위해 REST API 엔드포인트에 다시 request를 보낸다.
엔드포인트에서 response가 오면, 서버는 html 파일에 응답받은 데이터 정보를 포함해서 사용자에게 response 해준다.
사용자가 페이지를 이동할 경우 위 동작을 반복한다.

SSR의 장점

SEO에 친화적이다

서버가 데이터를 다 그려서 응답해주기 때문에 검색 엔진이 웹 페이지 정보를 잘 수집해갈 수 있습니다.

CSR에 비해 클라이언트에 부담이 덜하다

런타임에 JavaScript를 이용해 콘텐츠를 그리는 CSR과 달리 SSR은 서버가 콘텐츠를 그려서 응답 해주기 때문에 기기 성능에 크게 영향을 받지않고 웹 페이지를 제공할 수 있습니다.

SSR의 단점

라우팅 시 TTFB(Time to First Byte)가 느리다

서버가 데이터를 패칭하고 해당 데이터를 기반으로 html 파일을 생성해서 사용자에게 응답 해주기 때문에 다른 렌더링 방식들보다 TTFB가 느립니다.

서버 호스팅이 필요하다

클라이언트에서 javaScript를 이용해 렌더링하는 CSR와 미리 빌드 타임에 정적인 html파일을 생성한 뒤 응답해주는 Static Rendering에 비해 SSR은 서버 사이드에서 html파일 안 내용을 생성하기 때문에 서버 호스팅이 필요합니다.

Client Side Rendering

ex) react, vue, angular

Flow

사용자가 웹 페이지에 방문한다(request)
script, meta, link등의 태그를 포함하고 있는 빈 콘텐츠의 index.html을 response한다.
브라우저가 index.html에 있는 javaScript 번들 파일을 패칭한 뒤 파싱하고 실행해서 콘텐츠를 렌더링한다.
해당 페이지에 필요한 데이터를 패칭 하기위해 REST API/gql 엔드포인트에 request를 보낸다.
엔드포인트에서 response가 오면, 해당 데이터를 기반으로 콘텐츠를 브라우저에 렌더링한다.
사용자가 페이지를 이동할 경우 서버에 추가족안 html파일 요청 없이 이미 받은 javaScript를 이용해 렌더링합니다.

CSR의 장점

페이지 간의 이동 속도(반응성)가 빠르다

라우팅시 api를 제외하고 추가적인 서버 요청 없이 클라이언트단에서 javaScript로 렌더링하기 때문에 SSR에 비해 라우팅 속도(반응성)가 빠릅니다.

별도의 웹용 서버가 필요 없다

클라이언트단에서 라우팅을 처리하기 때문에 s3와 같은 스토리지에 빌드된 파일만 올려놓으면 별도의 서버 호스팅 없이 웹 사이트를 사용자에게 제공 가능합니다.

CSR의 단점

초기 로딩이 느리다

javaScript로 웹 페이지를 렌더링하기 때문에 콘텐츠를 표시 해주기위해선 html을 다 불러온 뒤 추가적으로 javaScript를 이용해 콘텐츠를 렌더링하는 작업이 필요합니다.

SEO에 친화적이지 않다

크롤러가 요청을 보냈을 때 빈 콘텐츠의 html 파일을 응답 해준 뒤 클라이언트에서 javaScript를 이용해 웹 페이지를 렌더링하기 때문에 구글을 제외한 나머지 검색 엔진들은 빈 페이지로 인식하게 됩니다.

사용자의 기기 성능에 영향 받는다

클라이언트에서 javaScript를 이용해 웹 페이지를 렌더링하기 때문에 저 성능 기기의 경우 초기 로딩 시 성능 이슈가 있을 수 있습니다.

Universal Rendering

ex) Next.js, Nuxt.js, Angular Universal

Flow

사용자가 웹 페이지에 방문한다(request)
request를 받은 서버는 해당 페이지에 필요한 데이터를 패칭 하기위해 REST API/GraphQL 엔드포인트에 다시 request를 보낸다.
엔드포인트에서 response가 오면, 서버는 html 파일에 응답받은 데이터 정보를 포함해서 사용자에게 response 해준다.
이 상태에서 초기 콘텐츠들은 다 렌더링 되었지만 아직 javaScript 번들이 패칭중이기 때문에 인터렉션이 불가능합니다.(Dehydrate 상태)
javaScript 번들이 다 파싱되면 hydration을 진행하고 그 이후 부터는CSR와 동일하게 동작합니다.

Universal Rendering의 장점

초기 로딩시에는 ssr처럼 작동하고, 그 이후에는 csr처럼 작동해서 ssr과 csr 장단점을 보안할 수 있습니다.

Universal Rendering의 단점

Universal Rendering을 직접 구현하기보다는 프레임워크를 사용해야하는 경우가 많으므로, 해당 프레임워크에 대한 러닝커브가 있습니다.
서버 호스팅이 필요 없는 Static Rendering, Client Side Rendering과 달리 Server Side Rendering과 같이 별도의 서버 호스팅이 필요합니다

Static Rendering

ex) Gatsby, Next.js, Hugo, Jekyll

Flow

빌드 타임에 REST API/GraphQL 엔드포인트에 request를 보내서 데이터를 받아온 뒤 html파일로 프리렌더링 해놓는다.
사용자가 웹 페이지에 방문한다(request)
미리 만들어 놓은 html파일을 제공해준다.

Static Rendering의 장점

빌드 타임에 프리렌더링 해놓기 때문에 페이지 로딩/응답 속도가 빠르다.

Static Rendering의 단점

빌드 타임에 프리렌더링 해놓기 때문에 빌드 타임 이후에 진행되는 데이터 변경을 페이지에 반영하지 못합니다(프리렌더링 시 api을 호출 할 때 기준)

Reference

Last updated 3 years ago