Web의 발전과 상식

Single Page Application , Client Side Rendering, Server Side Rendering , Static Site Generation, Time To View , Time To Interact에 대해서 한번 정리해보려고 한다.

 

 

웹의 역사

 

 대부분 예전 웹사이트는 Static Sites로 구성되어 있었습니다. 서버에 문서들이 존재하고 클라이언트가 서버에 요청하면 해당 웹페이지를 응답해주는 방식이었습니다. 이 방식은 모든 클라이언트 요청에 대해서 서버와 통신해 문서를 보여주는 형식입니다. 이 방식은 해당 문서가 무겁다면 로딩 시간이 길고, 요청마다 page전체가 업데이트되어야 한다는 점이었습니다. 

 

 96년쯤 문서 내에 또 다른 문서를 넣을 수 있는 <iframe> 태그가 도입이 되었고, 페이지 내에서 부분적으로 문서를 받아와서 업데이트할 수 있게 됩니다. 요즘도 간간히 쓰이는 방식입니다.

 

그 이후 우리가 많이 사용하는 비동기 통신의 원조인 XMLHttpRequest api가 개발이 되어 html문서 전체가 아니라 json과 같은 포맷으로 서버에서 필요한 데이터만을 받아올 수 있게 되었고 받아온 데이터를 웹상에서 실행 가능한 자바스크립트를 통해서 동적으로 html요소를 생성해 페이지에 업데이트할 수 있게 되었습니다.

 

이러한 방식이 공식적으로 AJAX로 인정되고 구글에서도 AJAX를 이용해 여러 웹 애플리케이션을 만들기 시작합니다.

이것이 현재 널리 사용되고 있는 SPA입니다. 

 

 이후 사용자들의 PC 성능과 JavaScript의 표준화가 잘되었고, 발달된 커뮤니티를 기반으로 Angular, React , Vue와 같은 프레임워크가 나오면서 클라이언트 사이드 렌더링 CSR시대로 넘어갑니다.

 

 CSR는 클라이언트 측에서 웹 생성을 전부 도맡아 하는 것을 의미하는데요, React의 튜토리얼을 참고하자면 index.html 파일의 body태그 안을 보면 id가 root인 div태그와 구동에 필요한 js파일만 첨부한 것을 보실 수 있습니다.

그래서 웹이 실행되면 서버는 태그 된 자바스크립트 파일을 보내주게 됩니다.

이 자바스크립 파일 안에는 애플리케이션에서 사용되는 로직뿐만 아니라 프레임워크와 라이브러리 소스코드도 포함되어 있습니다. 그렇기에 초기 로딩에는 조금 느리다는 단점이 있습니다. 이후 필요한 데이터를 서버에서 받아온 다음 데이터를 기반으로 동적으로 html을 생성해서 웹페이지를 클라이언트에게 보여줍니다.

 사실 CSR의 가장 큰 고민거리는 검색엔진에 노출되는 것입니다. 보통 검색 엔진들이 HTML의 바디 태그, meta태그를 보며 검색에 맞는 페이지를 노출시켜주는데 body가 텅텅 비었으니 노출이 안 되는 문제점을 가지고 있습니다. 개선에 많은 노력을 하고 있지만 아직도 Low SEO(Search Engine Optimization)이 좋다고 할 수는 없습니다.

 

이러한 CSR의 단점을 극복하기위해 SSR 서버 사이드 렌더링이 나왔습니다. 

서버 사이드 렌더링은 서버에서 필요한 모든 정보를 가져와서 HTML 파일을 생성하고 이렇게 만들어진 파일과 용량이 적은 js파일과 함께 클라이언트에게 보내줍니다. 

이러한 방식은 초기 로딩이 늦다는 단점을 극복하고, 검색엔진에 노출을 잘 된다는 점입니다.

 하지만 여기서도 단점이 존재하는데 Blinking issue 이전 Static page와 같이 깜빡깜빡거린다는 점이 있으며, 서버에서 모든 데이터와 html 파일을 맵핑하고 전송하기에 서버가 과부하가 걸리기 쉽다는 점과 초기 로딩이 빨라 HTML 파일은 로딩이 됐지만 JS파일이 로드가 안돼 사용자와 상호작용이 안될 수도 있습니다.

 

SSG는 이러한 두가지를 혼합해서 사용할 수 있게 해 주는데 예를 들면 Gatsby + React나 Nest.js 같은 프레임워크와 라이브러리를 혼용해서 사용하는 것을 말합니다. 

 

이러한 여러가지 웹 트렌드는 자신의 웹 애플리케이션을 잘 분석한 다음 필요함에 따라 선택하고 구성하는 것이 가장 좋다고 생각합니다.