🌱 Static Sites
정적인 웹 사이트를 의미합니다. 서버에 이미 잘 만들어진 HTML 문서들이 있고 사용자가 브라우저에서 'www.hellow.com'과 같은 주소에 접속하면 서버에 이미 배포되어있는 HTML 문서를 브라우저에서는 받아오기만 하는 방식입니다.
장점
서버에서 이미 생성된 HTML을 그대로 제공하기 때문에 서버 요청 시간이 짧고 렌더링 속도가 매우 빠릅니다. 서버에서 실행되는 코드나 데이터베이스가 없기 때문에 보안이 상대적으로 취약하지 않죠. 그리고 정적 파일로 이루어져 있어 서버 자원 소모도 적으며, 비용도 저렴하게 유지할 수 있습니다.
단점
페이지 내에서 다른 링크를 클릭하면 다시 서버에서 해당 페이지의 HTML을 받아와 페이지 전체가 업데이트 됩니다. 그래서 페이지가 많아질 수록 각 페이지의 HTML을 미리 생성하고 배포해야하므로 규모가 큰 서비스라면 배포 프로세스가 느려지고 복잡해집니다. 그리고 콘텐츠 변경 시 수동으로 HTML 파일을 수정하거나 다시 배포해야해서 관리도 어렵죠.
제일 중요한 점은 정적 사이트이므로 자바스크립트가 없기 때문에 실시간 데이터는 물론, 유저가 이벤트를 발생시킴으로써 상호작용을 하기가 매우 어렵습니다.
🌱 iframe
유튜브 영상을 embed하는 HTML 태그입니다. 그래서 페이지 내에서 다른 문서(웹 페이지)를 가져와 표시하는 기능을 제공하는 것과 같죠. iframe에 로드된 콘텐츠는 호스트 페이지와는 별도로 동작합니다. 다른 도메인의 콘텐츠를 로드할 경우 CORS에 따라서 자바스크립트 직접 접근이 제한될 수 있습니다. 같은 도메인의 문서라면 자바스크립트로 iframe의 document 객체에 접근해 내용을 조작할 수 있습니다.
iframe은 앵간하면 사용을 자제해야 합니다. iframe을 로드할 때 별도의 네트워크 요청이 발생하고, 리소스(HTML, CSS, JS 등)를 다시 로드해야 합니다. 그리고 lazy-load 설정이 없으면, 페이지 로딩과 함께 즉시 콘텐츠를 불러옵니다(지연 시간 증가). iframe 내부에서 실행되는 스크립트는 부모 문서와 별도라, 독립된 렌더링 트리를 가집니다. 메인 스레드에서 스타일과 레이아웃을 계산할 때 더 많은 작업이 필요해집니다.
🌱 XHR
XMLHttpRequest
웹 브라우저에서 서버와 비동기적으로 통신하기 위해 사용하는 객체입니다.
HTML 문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아올 수 있습니다.
그 데이터를 자바스크립트를 이용해서 동적으로 HTML 요소를 생성해서 페이지에 업데이트하는 방식입니다.
데이터를 가져온 뒤, 자바스크립트로 DOM을 조작하여 웹 페이지를 동적으로 업데이트합니다.
장점
전체 페이지를 다시 로드하지 않아도 되므로 네트워크 트래픽과 로딩 시간이 줄어듭니다.
그리고 비동기적이라 요청과 응답이 진행되는 동안에도 사용자는 웹 페이지와 상호작용을 계속할 수 있습니다.
근황
초기 비동기 통신 기술이었고 현재는 fetch API와 axios와 같은 라이브러리에 대체되었습니다.
🌱 AJAX
Asynchronous JavaScript and XML
비동기 자바스크립트와 XML
XMLHttpRequest가 공식적인 이름을 가지게 된 것이 AJAX입니다.
웹 페이지를 새로고침하지 않고도 서버와 데이터를 주고받아 동적으로 콘텐츠를 업데이트할 수 있는 기술이죠.
Gmail, Google Maps 같은 어플리케이션이 AJAX 방식을 사용하고 있습니다.
AJAX는 아래와 같은 같은 핵심 요소로 구성되어 있습니다.
- HTML, CSS, JS
- XHR
- JSON
당연히 XHR과 마찬가지로 비동기적으로 동작하므로 서버 요청과 응답이 일어나도 페이지가 동작하며, 부분 업데이트가 가능하죠. XHR과 AJAX 덕분에 웹 사이트의 UX가 엄청나게 발전되었다고 보시면 됩니다.
🌱 SPA
Single Page Application
웹사이트가 하나의 HTML 페이지에서 동작하며, 서버와 비동기 통신을 통해 필요한 데이터를 받아와 페이지의 일부를 동적으로 업데이트하는 방식입니다. HTML은 하나이고, URL 변경 시에도 실제 페이지 이동 없이(새로고침 X) 콘텐츠가 동적으로 갱신됩니다.
장점
서버에서 필요한 데이터만 받아오기 때문에 네트워크 트래픽이 줄어듭니다. 페이지 새로고침이 없어 더 부드러운 사용자 경험을 제공합니다. 그리고 클라이언트 측에서 대부분의 작업을 처리하므로 백엔드의 역할이 단순해지고 API 중심의 개발로 전환됩니다.
단점
SPA는 기본적으로 클라이언트 사이드에서 렌더링됩니다. CSR이라고 하죠. 렌더링 속도의 경우 초기에는 느린데 이후에는 매우 빠른게 특징이죠. 모든 자바스크립트와 asset을 처음에 한 번에 로드하므로 초기 로딩 시간이 길어질 수 있습니다.
또 SEO가 매우 불리합니다. 검색 엔진이 콘텐츠를 제대로 인덱싱하지 못하기 때문입니다.
해결하기 위해서 SSR과 정적 pre-rendering이 추가로 요구되죠.
SPA를 구현하기 위해서는 React같은 라이브러리를 이용하는 게 대표적인데 라우팅, 상태 관리에서 복잡하기 때문에 상태 관리 라이브러리나 추가적인 패키지가 요구될 수도 있습니다. 그래서 SPA는 유저의 상호 작용이 많고 복잡한 UI를 요구하는 애플리케이션에 적합합니다.
🌱 CSR
Client Side Rendering
SPA에서 언급된 렌더링 방식이죠. 클라이언트 사이드에서 모든 걸 렌더링하고, 서버로부터 필요한 데이터만 받아와 부분적으로 업데이트합니다.
Virtual DOM을 기반으로 하는 현대 프론트엔드 라이브러리(프레임워크)들은 기본적으로 CSR입니다. SPA 트렌드와 유저 PC 성능 확장이 맞물리면서 클라이언트 사이드에서 많은 것을 처리하는 게 무리가 아니게 됐고 자바스크립트 표준화도 계속 발전되어감에 따라서 CSR 시대가 도래했죠.
메커니즘
서버에서 index라는 HTML 파일을 클라이언트에 보내줍니다. CSR에서 사용되는 가장 심플한 HTML을 보면 body 안에 id="root"만 있고 애플리케이션에서 필요한 자바스크립트의 링크만 포함되어있습니다. HTML은 텅 비어있으므로 처음에 접속하면 빈 화면만 보이는 것이죠.
그 다음 링크한 자바스크립트 코드를 서버로부터 다운로드 받습니다. 자바스크립트 코드에는 애플리케이션에서 필요한 로직들뿐만 아니라, 애플리케이션을 구동하는 프레임워크 또는 라이브러리의 소스 코드들도 다 포함되어있습니다. 사이즈가 크기 때문에 시간이 꽤 소요되는 것이죠. 추가로 필요한 데이터가 있다면 서버에 요청해서 데이터를 받아온 다음 이것을 기반으로 동적으로 HTML 태그를 생성하여 유저에게 최종적인 애플리케이션을 보여주게 됩니다.
단점
SPA에서 언급했던 단점과 모두 동일합니다.
SEO가 좋지 않고 첫 화면을 보는데에 시간이 소요됩니다.
🌱 SSR
Server Side Rendering
Static Site에서 영감을 받은 렌더링 방식입니다.
웹 사이트 접속 시, 서버로부터 필요한 데이터를 모두 가져와서 HTML 파일을 만들게 됩니다.
서버는 만들어진 HTML 파일을 동적으로 조금 제어할 수 있는 소스 코드와 함께 클라이언트에게 보내줍니다.
클라이언트에서는 만들어진 HTML 문서를 받아와서 바로 사용자에게 보여줄 수 있습니다.
CSR보다 좋은 점
페이지 로딩이 빨라졌습니다. 서버에서 모든 콘텐츠를 미리 완성시켜서 클라이언트로 보내주기 때문이죠.
그리고 모든 콘텐츠가 담겨있으므로 SEO도 유리합니다.
단점
Blinking 이슈가 존재합니다.
블링킹은 Static Site에서 발생했던 이슈인데, 사용자가 클릭을 하면 전체적인 웹 페이지를
다시 서버에서 받아오는 것과 같은 현상이 발생하는 거죠.
그리고 서버 사이드에서 렌더링을 하는 것은 과부하에 걸리기 쉽습니다. 유저가 많은 앱일수록 유저가 클릭을 할 때마다 서버에 요청하는 것이니 서버에서 필요한 데이터를 가지고 와서 HTML을 만들어야 하므로 서버에 과부하가 걸릴 수 있죠.
또 유저가 빠르게 웹 사이트를 확인할 수는 있지만 동적으로 처리하는 자바스크립트를 아직 다운로드 받지 못해서 버튼을 클릭했는데 반응이 없는 경우가 발생할 수 있습니다.
🌱 TTV, TTI
TTV
Time to View
TTI
Time to Interact
CSR
접속하게 되면 서버에게서 index 파일을 받아오고 이 파일은 비어져있으므로 유저에게는 아무것도 보이지 않고 링크되어있는 자바스크립트를 요청하게 됩니다. 최종적으로 동적인 HTML을 생성할 수 있는 웹 애플리케이션의 로직이 담긴 자바스크립트 파일을 받아오죠. 이 순간부터 웹 사이트가 유저에게 보여지고 사용자가 클릭이 가능하게 됩니다. CSR은 TTV와 TTI가 동시에 가능하게 되죠.
SSR
서버에서 이미 만들어진 index 파일을 받아오고 사용자가 바로 웹 사이트를 볼 수 있지만 동적으로 제어할 수 있는 자바스크립트 파일은 받아오지 않았으므로 유저가 클릭을 해도 아무런 처리를 하지 못 하는 상태입니다. 최종적으로 자바스크립트를 서버로부터 받아와야지만 그때부터 유저가 상호 작용을 할 수 있죠.
그래서 SSR의 경우 TTV와 TTI간 공백이 꽤 긴 편이라고 할 수 있습니다.
웹 사이트의 성능을 분석할 때 TTV와 TTI도 중요한 매트릭으로 사용할 수 있습니다.
렌더링 사이드에 따른 고려사항
CSR
최종적으로 번들링해서 유저에게 보내주는 자바스크립트 파일을 어떻게 하면 효율적으로 많이 분할하여 처음에 유저가 보기 위해 정말 필수적인 요소만 보낼 수 있을지 고민해봐야 합니다. 코드 스플리팅으로 필요할 때에 모듈이 import되게 만드는 방법말이죠.
SSR
유저가 보고 상호 작용 하는 시간의 공백을 줄이기 위해서 어떤 노력을 할 수 있을지 고민해봐야 합니다.
어떻게 조금 더 매끄러운 UX를 제공할 수 있을지 말이죠.
🌱 SSG
Static Site Generation
React를 Gatsby라는 라이브러리와 함께 사용하면 React로 만들었음에도 정적으로 미리 웹 사이트를 생성해서 서버에 배포해놓을 수 있습니다. 서버에서 HTML을 미리 만들어 두고 클라이언트에서 요청하면 바로 HTML을 보내줄 수 있겠죠. 그럼 TTV는 더욱 빠르고, SEO도 유리해집니다. 보안 측면에서도 좋구요. CD에서 캐시되어있는 상태라 렌더링 속도도 빠릅니다.
SSG로 생성된 웹 사이트가 모두 정적인 것은 아닙니다. 우리가 추가적으로 데이터를 서버에서 받아오거나 또는 동적으로 처리해야하는 로직이 있다면 자바스크립트 파일을 함께 가지고 있을 수 있기 때문에 동적인 요소도 충분히 추가할 수 있습니다.
SSG에 단점이 있다면 유저별로 정보 제공이 어렵습니다. 정적으로 웹 사이트를 생성해두는 것이니 당연히 동일한 정보를 제공할 수 밖에 없겠죠. 그래서 페이지가 유저마다 다른 정보를 보여줘야 한다면 SSG는 적합하지 않을 수 있습니다.
🌱 ISR
Incremental Static Regeneration
SSG와 같이 렌더링을 서버에서 합니다. 주기적으로 렌더링을 실행한다는 것이 차이점이죠.
NextJS를 사용하셨다면 getStaticProps에서 revalidate를 설정하는 것이 이 이유임을 아실겁니다.
마찬가지로 페이지 로딩 시간이 빠르고 SEO가 유리합니다. 보안, CDN 캐시도 동일합니다.
단점조차도 동일합니다.
🌱 Hybrid Rendering
두 개 이상의 렌더링 방법을 사용하는 방식입니다.
NextJS에서는 페이지별로 렌더링 방식을 선택해서 사용할 수 있습니다.
지금까지 여러가지 렌더링 유형에 대해서 알아봤습니다.
