페이지 렌더링
페이지 렌더링 역사
static sites
모든 html 페이지들이 서버에 저장되어 있는 상태에서 사용자의 요청에 따라 html 파일들이 전송되어 보여지는 방식이다.
페이지에서 링크를 클릭할 때마다 서버에서 해당 html을 가져와서 페이지가 새로고침되기 때문에 사용성이 떨이진다고 할 수 있다.
iframe
iframe 태그가 생기면서 페이지 내에서 부분적으로 문서를 받아와서 업데이트하는 방식이 사용되었다.
fetch
xml http request가 개발되면서 html 문서 전체가 아닌 json같은 포맷을 사용하여 가벼운 데이터를 필요한 만큼 받아올 수 있게된다.
이렇게 json으로 가져온 데이터를 javascript를 통해서 html페이지를 동적으로 표현할 수 있게 되었다.
ajax
페이지를 동적으로 표현되는 방식이 공식적인 이름을 가지게 된다.
구글의 gamil이나 google maps 등을 시작으로 ajax 방식을 사용한 웹 어플리케이션이 등장하기 시작한다.
이렇게 동적으로 웹 어플리케이션을 만드는 것이 현재 널리 쓰이고 있는 spa이다.
spa
single page application
사용자가 하나의 웹 페이지에 머물면서 필요한 데이터를 때마다 서버에서 받아와 부분적으로 업데이트를 하는 방식이다.
공학의 발전으로 사용자의 장치 수준이 높아지면서 spa의 효율도 높아지게 되면서 csr의 시대가 온다.
csr
client side rendring
기술이 발전되면서 js에 다양한 프레임 워크를 통해서 이제 클라이언트에서 다 해결할 수 있게 된다.
사용자가 페이지를 시작할 때 동적으로 표현하기 위해 사용되는 모든 데이터를 다운받아서 사용하게 된다.
이 때문에 첫 화면을 보는데 시간이 오래 걸리는 문제점도 있다.
또한 검색 로봇이 크롤링 할 수 있는 html 정보가 없기 때문에 검색 엔진 최적화에 취약한 단점을 가진다.
이런 단점을 보완하기 위해서 ssr이 등장한다.
ssr
server side rendering
초창기 static sites에서 영감을 가지고 도입된 방식이다.
클라이언트에서 모든것을 처리하는 것이 아니라 서버에서 필요한 데이터를 모두 가져와서 html 파일을 만든 다음 이 페이지를 동적으로 제어할 수 있는 소스코드를 동봉해서 클라이언트에 보내진다.
따라서 csr보다 첫 페이지의 로딩 속도가 빠르며 html에 모든 컨텐츠가 담겨 있기 때문에 검색 엔진 최적화가 효율적으로 이루어질 수 있게 된다.
하지만 여전히 링크로 전환할 때마다 서버에 요청하기 때문에 페이지 전환시 깜빡임이 존재하고 이런 요청은 사용자가 많을수록 html을 만들고 보내는 동작 때문에 서버가 과부하에 걸리기 쉽다.
가장 치명적인 단점으로는 html이 먼저 도착하고 그 뒤에 동적인 제어를 담당하는 js파일이 전송되기 때문에 사용자 입장에서 페이지가 보이지만 클릭해도 반응이 없는 상황이 발생한다.
ssg
TTW와 TTI
time to viewable : 보여지는데 까지의 시간
time to interactive : 동작이 가능한데 까지의 시간
csr은 초기 속도가 느리지만 보여짐과 동시에 상호작용이 가능한 페이지를 만들 수 있다.
ssr은 빠르게 페이지를 보여줄 수 있지만 상호작용이 가능하기까지 시간간격이 존재한다.
tatic site generation
csr과 ssr의 장단점을 착안하여 만든 방식이다.
예를 들어서 csr에 특화된 라이브러리인 react를 gatsby라는 라이브러리와 함께 사용한 방식이 있다.
이 방식은 웹 페이지를 정적으로 생성해 서버에 배포하고 이후 추가적인 요청이나 로직은 js파일을 통해서 동적으로 처리한다.
결론
사용 목적이나 대상, 환경 등 여러 변수들에 대한 고려와 다양한 방식들의 적절히 섞어서 장점은 살리고 단점을 보완하는 유연한 개발을 하는것이 중요하다.