SPA란 Single Page Application의 약자로, 하나의 페이지(html)에 변경된 정보, 또는 영역을 동적으로 변경하는 것을 말합니다. 그렇다면 하나의 페이지를 동적으로 변경한다는 것이 무엇일까요?
태초에 MPA(Multi Page Application)가 있었습니다. Multi Page 즉, 여러 개의 페이지를 갖고 있는 웹 표현방식입니다.
예를 들어 사이트 구성은 헤더, 메인, 푸터로 이루어져있고 페이지는 메인 화면, 게시판, 회원 정보 열람 페이지로 이루어진 어떤 사이트가 있다고 가정해봅시다. MPA라면 메인 화면, 게시판, 회원 정보 열람 페이지를 모두 독립된 페이지로 서버에 갖고 있다가 사용자가 링크를 클릭하면 아래의 이미지처럼 해당 링크에 맞는 각각의 완성된 페이지를 전송합니다.
때문에 MPA 즉, 전통적인 웹 페이지는 SSR(Server-Side Rendering)로 동작합니다. 서버가 각각의 페이지를 갖고 있다가 클라이언트의 요청이 있으면 해당 페이지를 전송해주는 형태입니다. 따라서 MPA는 SSR 방식의 장단점을 모두 갖고 있습니다.
초기 로딩 속도가 빠르다.
첫 화면에 진입했을 때 메인 화면에 해당하는 페이지만 보내주는 형태로 동작하다보니 초기 로딩 속도가 빠릅니다.
SEO에 유리하다.
페이지가 변경될 때마다 서버에서 새로운 페이지를 보내주는데, 이 페이지는 html 기반이기 때문에 크롤링을 통해 색인이 가능합니다. 또한, 매번 새로운 페이지를 전달받기 때문에 각 페이지에 해당하는 적절한 meta 정보를 갖고 있어 SEO에 유리합니다.
페이지를 이동할 때마다 화면이 깜빡인다.
초기 로딩 속도가 느린 장점을 바꿔서 말하면 페이지를 이동할 때마다 처음 화면에 진입하는 것과 마찬가지로 페이지를 새롭게 받아와야 한다는 뜻이기 때문에 페이지가 변경되는 과정에서 화면이 한 번 깜빡이는 것처럼(새로고침) 보이게 됩니다.
페이지 이동 속도가 느리다.
같은 이유로 페이지 이동 속도가 느립니다. 매번 새로운 페이지를 받아오기 때문입니다.
MPA가 가진 단점은 사용자의 사이트 경험을 부정적으로 만드는 요인이 됩니다. 특정 버튼을 눌러서 해당 영역만 변경되는 동작이 있다고 가정해봅시다. 사용자는 당연히 버튼을 누르면 해당 영역만 변경되는 것을 기대합니다. 그런데 MPA는 어떤 버튼을 누르든 페이지가 한 번 깜빡이면서 새롭게 페이지를 로드합니다. 이러한 문제를 SPA가 해결해줄 수 있습니다.
SPA는 MPA와 달리 Single Page 즉, 하나의 페이지를 갖고 있습니다. 변경되지 않아도 되는 영역은 두고 변경되어야 하는 영역만 선택적으로 바꿈으로써 사용자 경험을 개선한 방식입니다. MPA에서 설명했던 웹이라면 서버는 페이지가 변경될 때마다 헤더와 푸터를 제외한 변경된 페이지 정보를 전송하게 됩니다.
게시판에서도 특정 영역의 화면 변경이 필요하다면 아래의 이미지처럼 특정 영역만을 변경하게 됩니다.
SPA는 CSR(Client-Side Rendering)로 동작합니다. 서버가 전체 페이지를 갖고 있다가 전달해주는 형태가 아니기 때문에 MPA와는 다른 장단점을 갖게 됩니다.
페이지 이동 속도가 빠르다.
SPA는 사용자의 요청에 따라 특정 영역만 변경하는 방식을 채택하기 때문에 MPA 방식처럼 화면에 변화가 있을 때마다 새로고침 되면서 화면이 깜빡이는 등의 변화가 없습니다. 따라서 사용자의 입장에서는 빠르게 페이지가 이동한다는 느낌을 받게 됩니다.
서버 부담이 감소한다.
사용자의 요청이 있는 특정 영역에 대한 변경 내용만을 서버가 보내주면 되기 때문에 MPA 방식보다 서버의 부담이 줄어듭니다.
초기 로딩 속도가 느리다.
SPA는 대부분 자바스크립트로 동작하기 때문에 페이지가 로딩될 때 모든 자바스크립트 파일을 받아와야 한다는 한계가 있습니다. 초기 로딩 화면에 해당하는 페이지만 받아오면 되었던 MPA와는 달리 모든 자바스크립트 파일을 가져와야 하는 SPA의 특성상 초기 로딩 속도가 상대적으로 느립니다.
SEO에 불리하다.
SPA는 변경되지 않는 정보들 즉, meta 정보와 같은 헤더 정보들은 고정되어 있고 특정 영역의 변화만을 반영하는 방식이기 떄문에 크롤러는 SPA로 만들어진 페이지를 하나의 페이지로 인식합니다. 또한 자바스크립트가 화면의 거의 모든 동작을 책임지고 있기 때문에 자바스크립트를 크롤링할 수 없는 크롤러의 경우 색인할 수 있는 정보를 습득할 수 없습니다.
SPA가 가진 단점 중에 역시 가장 큰 것은 SEO에 불리하다는 점일 겁니다. 사이트 노출이 필요하지 않은 웹사이트는 SEO를 신경쓰지 않아도 되겠지만 그렇지 않은 웹사이트가 세상에는 훨씬 더 많습니다. 그래서 SPA로 만든 사이트는 이러한 단점을 극복하기 위해 다음과 같은 방식을 취할 수 있습니다.
동적 렌더링
동적 렌더링이란 상대가 누군지에 따라 렌더링 방식을 다르게 하는 방법입니다. 사용자에겐 기존에 만들어진 CSR 형태의 웹사이트를 제공하고, 크롤러에게는 SSR 형태로 이미 구축된 웹페이지를 전송하는 것입니다. 하지만 최근에 구글에서 동적 렌더링을 권장하지 않는다는 발표가 있었습니다.
History API 사용하기
SPA에도 주소를 부여하는 History API를 사용하는 방법이 있습니다. 정적 사이트를 이용할 때와 같은 주소를 부여할 수 있는 방법입니다.
SSR 사용하기
SPA를 지원하는 많은 프레임워크와 라이브러리가 기존의 CSR 방식을 개선한 SSR 방식의 프레임워크와 라이브러리를 제공합니다. 흔히 알고 있는 Next.js, Nuxt, Angular Universal, SvelteKit 등이 있습니다.
최근 SPA와 관련된 질문을 받고 제가 SPA를 정확하게 이해하고 있지 않다는 사실을 알게 되었습니다. 뒤죽박죽 섞여있던 개념들이, 포스팅을 작성하면서 정돈된 것 같습니다.
SPA(Single Page Application) 이란?
Single Page Application & Routing
SPA의 SEO, 어떻게 해야할까?
SSR(서버사이드 렌더링)과 CSR(클라이언트 사이드 렌더링)
구글 검색은 동적 렌더링을 더 이상 권장하지 않습니다.