SPA 이해하기
SPA
SPA는 'Single Page Application'의 약자로 단일 페이지 애플리케이션을 말한다. 웹 사이트 전체 페이지를 하나의 페이지에 담아 동적으로 화면을 변경해 표시하는 기술이다. React를 예시로 최초 한 번 페이지를 전체 로딩한 이후에는 데이터만 변경할 수 있는데, 하나의 html 파일로만 동작함을 확인할 수 있다.
과거 웹 사이트는 지금과 달리 문서에 전달되는 정보의 양이 적었다. 그래서 페이지의 일부 영역만 변경되어도 서버에서 새로운 페이지를 재렌더링하여 전송하는 방식(ex. SSR)을 사용했다. 하지만 웹 시장이 발전됨에 따라 한 페이지의 정보량이 커졌고, 서버에서 매 번 새로운 페이지를 전송하는 것이 버거워졌다. 이를 해결하기 위해 등장한 기술이 바로 SPA이다.
SPA의 경우 렌더링 역할을 서버에게 넘기지 않고 브라우저에서 처리하는 방식이다. 웹 애플리케이션에 필요한 모든 정적 리소스를 최초에 한 번 다운로드 하고, 새로운 페이지 요청 시 페이지 갱신에 필요한 데이터만을 전달받아 변경 사항이 일어나는 부분만 갱신한다.
MPA와 비교하기
MPA는 'Multiple Page Application'의 약자로 여러 개의 페이지로 구성된 애플리케이션이다. SPA와 MPA의 차이점은 로딩방식에 있다. MPA 또는 전통적인 방식에서는 클라이언트가 서버에 최초 요청을 하게 되면 정적인 페이지의 모든 소스를 가져온다. 이후 다른 페이지나 게시물로 이동하기 위해 사용자가 클릭을 하면 클라이언트는 서버에 요청한 페이지의 대부분의 게시물이 전과 같더라도 새로운 정적 페이지 전체를 보낸다. 즉, 요청할 때마다 정적 리소스를 다운로드하며, 매 번 전체 페이지가 리렌더링된다.
반면에 SPA는 클라이언트가 서버에 최초로 요청을 하게 되면 HTML, CSS, JS등 사이트에 필요한 모든 소스를 가져오고, 다음 요청에는 AJAX를 이용해 변경에 필요한 부분만 가져오는 방식이다. 즉, 최초 요청 이후 요청에 대하여 매번 전체를 가져올지, 일부만 가져와 기존의 것을 변경해 보이는지 차이다.
SSR, CSR 이해하기
처음에 이해하기 어려웠던 부분은 SPA, MPA, SSR, CSR 개념을 접하면서 SPA와 비교되는 개념은 무엇인지 파악하기 힘들었다. 네 가지 모두 다른 개념이며, MPA가 SSR 방식을 채택한 것이고 SPA가 CSR 방식을 채택한 것으로 이해했다.
SSR은 'Server Side Rendering'의 약자로 SPA가 등장하기 전 웹 애플리케이션을 구성하던 방식으로 화면에 보여질 리소스를 서버에 요청하고, 서버로 부터 받아온 리소스를 렌더링 했다. 즉, 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 페이지를 보여주는 방식이다. 해당 방식은 요청할 때마다 서버에게 새로운 페이지를 요청하며, 매 번 새로고침이 발생한다.
CSR은 'Client Side Rendering'의 약자로 클라이언트 측에서 최초 한 번 서버에서 전체 페이지를 로딩하여 보여준다. 이후에는 사용자의 요청이 올 때마다 소스를 서버에서 제공하여 클라이언트가 해석하고 렌더링하는 방식이다. CSR은 웹 서버에 처음 요청할 때 데이터가 없는 문서를 반환한 후 HTML 및 정적 파일들이 로드된다. 이 때 데이터가 있으면 데이터 또한 서버에 요청하여 화면에 나타낸다. 브라우저가 서버에 HTML, 정적 파일을 요청한 후 로드되면 사용자의 상호작용에 따라 JavaScript를 통해 동적으로 렌더링한다.
SPA 장점
- 필요한 부분만 리렌더링 한다.
- 새로운 페이지 요청 시 전체를 리렌더링 하지 않고, 변경되는 부분만 갱신하기에 트래픽 감소와 렌더링에서 좋은 효율을 가진다.
- 갱신되는 부분만 리렌더링 하므로 새로고침이 발생하지 않고, 화면 깜빡임 없이 빠른 화면 이동이 가능하다.
- 트래픽 감소, 속도, 반응성이 향상되어 앱처럼 자연스러운 사용자 경험(UX)를 제공한다.
- 모듈화 또는 컴포넌트 개발이 용이하다.
SPA 단점
- 웹 애플리케이션에 필요한 정적 리소스를 한 번에 다운로드 하기 때문에 초기 구동 속도가 느리다.
- 구조 상 데이터 처리를 클라이언트 측에서 하는 경우가 많은데 해당 로직은 JavaScript를 통해 구현되며, 코드가 외부에 노출되는 보안적인 문제가 있다.
- SSR은 사용자 정보를 서버 측에서 세션으로 관리하지만, CSR은 쿠키를 제외하고 사용자 정보를 저장할 공간이 마땅하지 않다.
- DOM 조작이 빈번하게 일어나 브라우저의 성능을 저하시킨다.
- 이를 해결하기 위해서 Virtual DOM 개념이 등장했다.
- 검색엔진 최적화(SEO)가 어렵다.
SEO 부적합 이유
- SPA는 하나의 페이지에 여러 페이지를 클라이언트 사이드에서 자바스크립트로 구현하는 방식이기 때문에 자바스크립트를 읽지 못하는 검색엔진에 대해서 크롤링이 되지 않는 문제가 발생할 수 있다.
- 크롤러는 이미 알려진 페이지를 크롤링한다. 하나의 페이지에 들어갔을 때 발견되는 URL을 대기열에 저장하고 저장된 URL을 기반으로 다시 크롤링하고 대기열에 저장하고를 반복하여 크롤링한다. 그러나 SPA 방식의 웹 사이트 경우 기본적으로 사이트 내의 페이지로 향하는 href 속성을 HTML에서 사용하지 않고 JavaScript로 페이지 이동을 구현하기 때문에 크롤러가 사이트에 있는 모든 페이지의 내용을 크롤링하지 못하는 경우가 발생할 수 있다.
- Meta Data는 SPA의 본질적 특성에서 발생하는 문제이다. MPA와 같이 <head> 부분에 메타 태그를 삽입하지만, 사이트 내 다른 페이지로 이동하여도 HTML은 변동되지 않기에 모든 페이지에서 동일한 메타 데이터를 삽입하게 되는 상황이 발생한다.
SEO 해결
- SSR(Server Side Rendering)
- 사이트 구축 이전에 SEO 구축이 필요한 상황이라면 SPA가 아닌 SSR 방식으로 구축한다.
- SPA는 CSR(Client-Side Rendering) 방식으로 구현된다. 서버에서는 HTML, JS 등 모든 리소스를 다운 받은 후 클라이언트 단에서 렌더링 하는 방식을 취한다. 그래서 SPA이지만 크롤링에 더 친화적인 SSR 방식으로 사이트를 구축하는 것이 적합하다.
- SSR 프레임워크로는 React의 Next.js, Vue의 Nuxt, Angular의 Universal이 있다.
- 동적 렌더링(Dynamic Rendering)
- 서버에서 요청하는 자가 사람인지 크롤러인지 판단하여 사람에게는 HTML, JS 등을 제공하고, 크롤러에게는 사전에 렌더링된 HTML 버전의 페이지를 보여주는 방식이다.
- 이미 SPA의 CSR 방식으로 구현되어 있거나, SSR을 사용하지 못한다면, 동적 렌더링을 통해 SEO할 수 있다.
- 동적 렌더링 방법으로는 react-helmet, prerender-spa-plugin, prerender.io, puppeteer, rendertron 등이 있다.
- History API
- SPA방식의 웹 사이트에서 주소가 바뀌지 않는 문제를 해결하기 위해 SPA이지만 주소를 부여하는 기능의 API이다.
- History API와 pushState() 방법을 통해 특수문자로 된 주소가 아닌 정적인 URL과 같은 주소를 설정할 수 있게 되었다.
SPA 선택
- 본인이 만들고자 하는 서비스가 사용자에게 빠른 인터렉션을 제공해야 하는 서비스라면 React, Vue와 같은 SPA 프레임워크로 개발하는 것이 좋다.
- E-Commerce나 정보를 제공하는 많은 콘텐츠를 담는 서비스라면 SPA 보다는 MPA 방식으로 구성하는게 속도, SEO 측면에서도 유리할 수 있다.
Ref