웹 사이트의 렌더링 동작 방식을 이해해보자!

🔗 클라이언트/서버

- 클라이언트

인터넷을 통해 서버에 데이터 요청을 하는 주체를 말합니다.

우리가 사용하는 핸드본, 웹 브라우저 등이 클라이언트가 될 수 있습니다.

- 서버

클라이언트가 보낸 요청을 받아서 처리한 후 결과를 다시 전송해주는 주체를 말합니다.

📜 웹 페이지 발전사

1. static sites

우리가 웹페이지에 접속하면 보게 되는 화면들은 어디서 오는 것인지 생각해보신적 있으신가요? 웹을 공부하다 보면 CSR, SSR 등의 용어를 들어본 적 있지만 정확한 개념을 알아볼 기회가 없었을 경우가 많았을 것입니다.

1990년대 중반까진 웹사이트 대부분은 정적인 웹사이트(static sites)였습니다.

서버에 여러 개의 html 문서들이 저장되어 있고, 사용자가 웹페이지에 접속할 때마다 서버로 부터 문서를 불러오는 것이죠!

그렇지만 현재는 이러한 방식을 거의 사용하고 있지 않습니다! 왜 그럴까요?

정적인 웹사이트를 구성하게 되면 한 페이지당 하나의 html 문서를 서버로 부터 불러와야 하기 때문에, 페이지 내에서 사용자가 다른 링크를 클릭하면 다시 서버 문서를 받아와야 한다는 점입니다. 그러면 속도가 느려지겠죠?

2. ajax

이러한 불편함을 극복하고자 iframe태그나 XMLHttpRequest(fetch api)가 개발되었고, 부분적으로 원하는 데이터를 받아올 수 있게 되었습니다.

iframe : 전체 페이지 html 문서가 아닌 부분적인 문서만 받아올 수 있다.
XMLHttpRequest : json 형식으로 데이터를 받아올 수 있다.

2005년 ajax라는 것이 등장하여, api를 통해 받아온 json 데이터를 js를 이용하여 페이지를 업데이트 시키는 방식이 가능해졌습니다.

그리고 이것이 바로 SPA(single page application) 방식입니다.

url이 바뀌어도 html을 또 받아오기 싫다! 라는 생각에서 나온 것이죠. gmail, google maps 등이 ajax로 만들어진 웹 어플리케이션이라고 합니다.

이전의 정적인 페이지가 아닌, 동적으로 페이지를 구성해서 서버로 부터 페이지를 한번만 받아오고, 그 이후는 필요한 부분만 받아서 계속 업데이트 시키는 것이죠!

다른 링크를 타고 가지 않아도 계속 다른 화면을 사용자가 볼 수 있는 것입니다.

💻 CSR(client side rendering)

컴퓨터의 성능이 발전하면서 Vue, React와 같은 여러 프레임워크들이 등장했고, CSR방식이 사용되게 되었습니다. CSR의 특징은 클라이언트가 화면 렌더링을 담당한다는 것입니다.

CSR 방식에서는 아무것도 존재하지 않는 html 문서를 다운받습니다. 그 후 이 문서안에 링크된 js(bundle.js) 파일을 서버에 요청하여 다운받습니다.

<!DOCTYPE html>
<html lang="kr">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" href="%PUBLIC_URL%/favicon.ico" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="theme-color" content="#000000" />
    <meta
      name="description"
      content="Web site created using create-react-app"
    />
    <link rel="apple-touch-icon" href="%PUBLIC_URL%/logo192.png" />
    <link rel="manifest" href="%PUBLIC_URL%/manifest.json" />
    <title>React App</title>
  </head>
  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
  </body>
</html>

클라이언트는 받은 js파일을 통해 웹 페이지를 렌더링합니다. 동적으로 태그들을 생성하여 html 문서를 구성하게 되는 것이죠.

이런 CSR의 가장 큰 단점은 두 가지 정도를 말할 수 있습니다.

1) 사용자가 첫 화면을 보기까지의 로딩이 오래 걸릴 수 있다

서버로 부터 다운받는 js 파일 안에는 웹 어플리케이션을 실행하는 데 필요한 코드와 프레임워크, 라이브러리 등의 소스코드들까지 포함되어 있습니다.

당연히 이를 다 합친 파일의 용량은 클수밖에 없겠죠? 그래서 서버로 부터 다운로드 받는데 시간이 소요될 것입니다.

2) SEO(search engine optimization)에서 좋은 성능을 내지 못한다

구글이나 네이버 같은 검색 사이트들은 search engine을 사용하여 웹 사이트의 html에 등록된 title, description을 조사하고, 포함된 링크들까지 등록하여 웹사이트 검색을 빠르게 할 수 있도록 합니다.

https://www.cookieparking.com/

쿠키파킹 | 성장하는 사람들의 지식 습관

매일 새 탭에서 확인하는, All-in-one Web Clipping 서비스입니다. Cookieparking의 Chrome 확장 앱을 활용하면, 다양한 플랫폼에서 발견한 수많은 콘텐츠를 쉽고 빠르게 Web Clipping하고, 새 탭을 열 때마다 간

www.cookieparking.com

그래서 이 search engine에 잘 걸릴 수 있도록 최적화하는 것을 SEO라고 합니다.

그렇지만 SPA 방식의 경우 각각의 페이지에 대한 정보를 html에 등록할 수 없기 때문에 SEO에서 좋은 성능을 내지 못할 것입니다.

🗄 SSR(server side rendering)

그래서 SEO에 취약한 문제점을 극복하고자 90년대 static sites에서 영감을 받은 SSR이 등장하게 되었습니다.

데이터가 필요할 때마다 클라이언트가 서버에 데이터를 요청하는 방식 대신, 서버가 미리 필요한 데이터를 바탕으로 html 파일을 만들고, 만들어진 html을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에게 보내주는 방식입니다.

그러니 당연하게도 CSR 방식보다 초기 로딩 속도가 빠르겠죠.

그리고 모든 컨텐츠가 html에 담겨져 있기 때문에 좋은 SEO를 가질 수 있을 것입니다.

그렇지만 SSR에도 단점이 존재합니다.

1) blinking issue

static sites 처럼 사용자가 다른 링크로 가게 되면 전체적인 html 문서를 다시 받아와야 하는 blinking issue가 발생합니다.

2) 서버 과부하

사용자가 많은 웹 어플리케이션일 수록 사용자가 클릭할 때마다 서버가 html 문서를 만들어야 하기 때문에 서버에 과부하가 걸리기 쉽습니다.

3) 웹이 반응하지 않음

html을 받았음에도, 동적으로 웹을 제어하는 js 파일을 받지 못해서, 사용자가 웹 어플리케이션을 클릭해도 웹이 반응하지 않는 문제가 발생합니다. 이것이 SSR의 가장 치명적인 단점입니다.

이 문제에 대해 더 자세이 알기 위해셔는 TTV, TTI에 대해 알아야 합니다.

- TTV(time to view)

사용자가 웹사이트를 볼 수 있는 시간

- TTI(time to interact)

사용자가 웹사이트와 인터렉션(클릭 등...)을 할 수 있는 시간

1) CSR의 경우

사용자가 사이트에 접속을 하면, 서버는 비어있는 html 문서를 넘겨줍니다.

그러면 클라이언트는 html에 링크된 js 파일을 서버에 요청할 것이고, 서버는 이 js 파일을 클라이언트에게 줄 것입니다.

클라이언트가 js 파일을 받은 뒤에야 브라우저 화면에 웹페이지가 뜨게 되고, 사용자가 웹과 인터렉션을 할 수 있는 것이죠.

즉, CSR에서는 TTV와 TTI가 같은 것입니다!

2) SSR의 경우

사용자가 사이트에 접속을 하면, 서버는 이미 만들어진 html 문서를 클라이언트에게 넘겨줍니다. 그래서 사용자가 화면을 바로 볼 수 있습니다.

하지만 아직 js 파일은 받아오지 못했지 때문에 인터렉션은 할 수 없는 상태가 됩니다.

즉, TTV와 TTI 간의 시간차가 존재하는 것이죠.

그렇기 때문에 CSR은 처음 로딩속도를 줄이기 위해 js파일을 분할하여 꼭 필요한 정보부터 보내기 위한 고민을 해야하고, SSR의 경우 TTV와 TTI간의 시간차를 줄이기 위한 고민을 해야 한답니다.

그런데 만약 같은 내용의 페이지인데, 클라이언트가 요청할 때마다 서버가 같은 페이지를 만들어서 준다면 굉장히 비효율적이겠죠??

그래서 SSG 방식이 등장하게 되었습니다!

🎉 SSG(static site generation)

우리 초반에 static site에 대해 알아봤던 것 기억하시나요? 바로 이러한 static site들을 생성하는 것이 바로 SSG 방식입니다.

SSR과 SSG의 차이점이라고 하면 SSR은 사용자가 접속을 함과 동시에 서버에서 완성된 html 파일을 만들어서 주는 방식이고, SSG는 미리 서버에 html 파일을 만들어놓고, 그것을 사용자에게 보여준다는 것입니다.

즉, 사용자와 인터렉션을 통해 데이터가 변하지 않는 페이지(ex: about 페이지)의 경우에는 미리 서버에서 html 파일을 만들어 놓고, 클라이언트가 요청할 때마다 이 파일을 주는 방식을 사용하는 것입니다.

이 경우 CSR, SSR 보다 렌더링 속도가 훨씬 빠르겠죠!

React.js의 경우 대표적인 CSR 프레임워크 입니다.

Gatsby라는 라이브러리와 함께 사용한다면, React로 만든 웹 페이지들을 정적으로 생성을 해놓고 서버에 저장(배포)가 가능합니다.

서버에 저장한 html은 js파일도 함께 가진 상태이기 때문에 페이지를 동적으로 조작할 수도 있답니다!

그리고 요즘 많이 사용되는 것이 바로 NEXT.js입니다.

NEXT.js에서도 미리 html 파일을 만들어놓는 방식을 사용하고 있답니다.

다만 특이한점은 NEXT.js는 SSR, SSG 방식을 모두 사용할 수 있습니다.

그러면 대체 언제 SSR/SSG를 써야 하는 걸까요?

SSR

- 표시된 데이터가 항상 최신의 데이터일 때

- 자주 변경할 수 있는 사용자별 혹은 동적 데이터 일 때,

SSG

- 정적인 정보를 항상 보여주는 페이지일 때

- 상호작용 데이터가 존재하지 않을 때.

따라서 블로그와 같이 정적인 페이지는 SSG 방식으로 만드는 것이 훨씬 효율적이겠죠?

저작자표시