SPA(Single Page Application)란?
싱글페이지 에플리케이션이란 렌더링과 라우팅에 필요한 대부분의 기능을 서버가 아닌 브라우저의 자바스크립트에 의존하는 방식을 의미한다.
사이트 렌더링에 필요한 내부의 내용을 모두 자바스크립트 코드로 삽입한 이후에 렌더링한다. 또 페이지 전환 시에도 새로운 HTML 페이지를 요청하는게 아니라 자바스크립트에서 다음 페이지의 렌더링에 필요한 정보만 HTTP요청 등으로 가져온 다음 그 결과를 바탕으로 내부에 DOM을 추가, 수정, 삭제하는 방법으로 페이지가 전환된다.
즉, 최초에 서버에서 최소한의 데이터를 불러온 이후부터는 이미 가지고 있는 자바스크립트 리소스와 브라우저 API를 기반으로 모든 작동이 이뤄진다.
최초에 로딩해야 할 자바스크립트 리소스가 커지는 단점이 있지만 한 번 로딩된 이후에는 서버를 거쳐 필요한 리소스를 받아올 일이 적어지기 때문에 사용자에게 훌륭한 UI/UX를 제공한다는 장점이 있다.
페이지 전환을 모두 자바스크립트로 한다면 최초에 한 번 모든 리소스를 다운로드하고 나면 이후 페이지를 전환할 때 추가로 리소르를 다운로드하는 시간이 필요 없어진다. 페이지 전체를 새로 렌더링하는 것이 아니라 페이지 전환에 필요한 일부 영역만 다시 그리게 되므로 훨씬 더 매끄러운 UI를 보여줄 수 있다.
SSR(Server Side Rendering)란?
서버 사이드 렌더링은 최초에 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 사용자에게 화면을 제공하는 방식이다.
웹페이지 렌더링의 책임을 어디에 두느냐 ?
자바스크립트 번들 -> SPA
서버 -> SSR클라이언트 렌더링은 사용자 기기의 성능에 영향을 받지만 서버 사이드 렌더링은 서버에서 제공하기 때문에 비교적 안정적인 렌더링이 가능하다.
SSR의 장점
최초 페이지 진입이 비교적 빠르다.
사용자가 최초 페이지에 진입했을 때 페이지에 유의미한 정보가 그려지는 시간이 더 빨라질 수 있다.
why ?
일반적으로 서버에서 HTTP 요청을 수행하는 것이 더 빠르고, HTML을 그리는 작업도 서버에서 해당 HTML을 문자열로 미리 그려서 내려주는 것이 클라이언트에서 기존 HTML에 삽입하는 것보다 더 빠르기 때문.
검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다.
검색 엔진 로봇은 페이지를 보는 것이 아닌 페이지의 정적인 정보를 가져오는 것이 목적이므로 자바스크립트를 다운로드하거나 실행할 필요가 없다.
SPA는 대부분의 작동이 자바스크립트에 의존한다.
즉, 검색 엔진에 제공할 정보를 서버에서 가공해서 HTML 응답으로 제공할 수 있으므로 검색 엔진 최적화에 대응하기가 매우 용이하다.
누적 레이아웃 이동이 적다.
누적 레이아웃 이동이란 ?
사용자에게 페이지를 보여준 이후에 뒤늦게 어떤 HTML 정보가 추가되거나 삭제되어 마치 화면이 덜컥거리는 것과 같은 부정적인 사용자 경험을 말한다.
SSR은 API요청이 완전히 완료된 이후에 완성된 페이지를 제공하므로 누적 레이아웃 이동에 관한 문제는 SPA보다 비교적 자유롭다.
사용자의 디바이스 성능에 비교적 자유롭다.
자바스크립트 리소스 실행은 사용자의 디바이스에서만 실행되므로 절대적으로 사용자 디바이스 성능에 의존적이다.
그러나 서버 사이드 렌더링을 수행하면 이러한 부담을 서버에 나눌 수 있으므로 조금 더 자유로워질 수 있다.
보안에 좀 더 안전하다.
API호출과 같은 인증 같이 사용자에게 노출되면 안되는 민감한 작업도 포함되므로 정상적인 비즈니스 로직을 거치지 않은 상황에서 인증이나 API가 호출되는 것을 항상 방지할 준비가 돼 있어야 한다.
SSR의 경우 인증 혹은 민감한 작업을 서버에서 수행하고 그 결과만 브라우저에 제공해 이러한 보안 위협을 피할 수 있다는 장점이 있다.
SSR의 단점
소스코드를 작성할 때 항상 서버를 고려해야 한다.
서버에서도 실행될 가능성이 있는 코드라면 window에 대한 접근을 최소화해야 하고, window 사용이 불가피하다면 해당 코드가 서버 사이드에서 실행되지 않도록 처리해야 한다. 이러한 서버에 대한 고려는 작성한 코드뿐만 아니라 외부에서 의존하고 있는 라이브러리도 마찬가지이다.
적절한 서버가 구축되어 있어야 한다.
SSR은 사용자의 요청을 받아 렌더링을 수행할 서버가 필요하다.
서버를 구축하는 것은 절대 쉬운 일이 아니다.
서비스 지연에 따른 문제.
SSR은 서버에서 사용자에게 보여줄 페이지에 대한 렌더링 작업이 끝나기까지는 사용자에게 그 어떤 정보도 제공할 수 없다.
병목 현상이 심해진다면 더 안좋은 사용자 경험을 제공하게 된다.
SPA 그리고 SSR 무엇이 옳을까?
1. 가장 뛰어난 싱글 페이지 애플리케이션은 가장 뛰어난 멀티 페이지 애플리케이션보다 낫다.
최초 페이지 진입 시에 보여줘야 할 정보만 최적화해 요청해서 렌더링하고, 이미지와 같은 중요성 떨어지는 리소스는 게으른 로딩으로 렌더링에 방해되지 않도록 처리하며, 코드 분할 또한 칼같이 지켜서 불필요한 자바스크립트 리소스의 다운로드 및 실행을 방지, 라우팅이 발생하면 변경이 필요한 HTML 영역만 교체해 사용자의 피로감을 최소화 할 수 있다.
2. 평균적인 SPA은 평균적인 MPA보다 느리다.
일반적인 SPA은 렌더링과 라우팅에 최적화가 되어 있지 않다면 사용자 기기에 따라 성능이 들쑥날쑥하고, 적절한 성능 최적화도 되어 있지 않을 가능성이 높으므로 멀티 페이지 애플리케이션 대비 성능이 아쉬울 가능성이 크다 (그리고 이러한 최적화는 매우 어렵다.)
현대의 서버 사이드 렌더링
요즘의 서버 사이드 렌더링은 먼저, 최초 웹사이트 진입 시에는 서버 사이드 렌더링 방식으로 서버에서 완성된 HTML을 제공받고, 이후 라우팅에서는 서버에서 내려받은 자바스크립트를 바탕으로 마치 싱글 페이지 애플리케이션처럼 작동한다.
1. 초기 페이지 진입이 빠르다.
2. 라우팅을 SPA방식처럼 작동시켜서 빠르다.
SPA와 SSR 모두 알아야 한다.
웹페이지에서 사용자에게 제공하고 싶은 내용이 무엇인지, 또 어떤 우선순위에 따라 페이지의 내용을 보여줄지를 잘 설계하는 것이 중요하다.
