단일 페이지 애플리케이션: 두 판 사이의 차이
편집 요약 없음 |
편집 요약 없음 |
||
12번째 줄: | 12번째 줄: | ||
그러나 전체 웹사이트를 SPA로 하는 경우는 별로 없고 효율도 나쁘다. SPA는 데이터를 받아서 [[자바스크립트]]로 DOM 트리를 변경해야 하는데 전체 내용이 다 바뀐다면 DOM 트리를 바꾸는 렌더링을 전부 클라이언트가 떠맡아야 한다. 같은 양이라고 한다면 [[HTML]]을 받아 뿌리는 것보다 JSON 데이터를 받아서 DOM 트리를 변경하는 게 클라이언트 쪽의 부담이 크다.<ref>즉, SPA는 기존에 서버가 해야 했던 일들의 일부를 클라이언트에게 떠넘기는 것이다.</ref> 따라서 페이지의 내용이 많이 바뀐다면 그냥 페이지를 새로 받아오는 게 특히 클라이언트 쪽은 부담이 덜하다. 페이지의 구조나 디자인은 별로 달라지지 않고 데이터만 바뀌는 부분이 SPA가 딱 적합한 곳이다. | 그러나 전체 웹사이트를 SPA로 하는 경우는 별로 없고 효율도 나쁘다. SPA는 데이터를 받아서 [[자바스크립트]]로 DOM 트리를 변경해야 하는데 전체 내용이 다 바뀐다면 DOM 트리를 바꾸는 렌더링을 전부 클라이언트가 떠맡아야 한다. 같은 양이라고 한다면 [[HTML]]을 받아 뿌리는 것보다 JSON 데이터를 받아서 DOM 트리를 변경하는 게 클라이언트 쪽의 부담이 크다.<ref>즉, SPA는 기존에 서버가 해야 했던 일들의 일부를 클라이언트에게 떠넘기는 것이다.</ref> 따라서 페이지의 내용이 많이 바뀐다면 그냥 페이지를 새로 받아오는 게 특히 클라이언트 쪽은 부담이 덜하다. 페이지의 구조나 디자인은 별로 달라지지 않고 데이터만 바뀌는 부분이 SPA가 딱 적합한 곳이다. | ||
검색엔진 최적화(SEO)에도 약점이 있는데, 단일 페이지 애플리케이션은 첫 진입점의 URL 말고는 그 페이지 안에서 내용만 [[자바스크립트]]로 바꾸므로 검색 엔진이 보기에는 페이지가 하나밖에 없는 것처럼 보일 수 있다. 검색 엔진은 그냥 HTML을 가져다가 안에 있는 텍스트를 분석할 뿐이지 그 안의 [[자바스크립트]]를 실행시켜 가면서 내용이 어떻게 달라지는지까지는 보지는 않는다. 하지만 최근에는 [[React]]나 [[Angular]] 같은 프레임워크들이 클라이언트에서 렌더링을 할지(CSR), 서버에서 렌더링을 할지(SSR)를 상황에 따라 선택할 수 있는 기능을 제공하면서 SEO 문제를 완화시켜 주고는 있지만 그래도 기존 페이지 방식에 비하면 약점이 있다. | |||
{{각주}} | {{각주}} |
2021년 5월 28일 (금) 22:38 판
Single page application (SPA).
웹 애플리케이션을 단 한 개의 페이지로만 구현한 것을 뜻한다. 페이지를 로드했을 때 그냥 정적인 내용만 보이거나, 간단한 자바스크립트 정도를 수행하는 정도를 넘어서 과거에는 여러 개의 웹 페이지가 필요했던 기능을 AJAX를 사용해서 페이지를 추가로 로드하지 않고 단 한 개의 페이지 안에서 처리하는 것을 뜻한다.
예를 들어 한 페이지에 주간 단위의 일정을 보여주는 웹 페이지가 있다고 가정해 보자. '다음 주' 링크를 누르면 기존 방식은 서버에 같은 페이지의 URL을 전달하고 웹 페이지를 요청한다. 이 때 매개변수로 시작 날짜를 전달할 것이다. 서버는 받은 URL과 매개변수로 페이지를 만들어서 클라이언트에 보내주고 클라이언트의 웹 브라우저는 받은 페이지를 렌더링해서 보여준다.
반면 SPA는 '다음 주' 링크를 눌렀다면 페이지 안에서 바꿔야 할 부분의 정보만 서버에 요청한다. 이는 보통은 JSON 또는 XML 형식이며 데이터 용량도 적고 어차피 데이터를 자바스크립트가 처리해야 하므로 대부분은 JSON을 사용한다. 서버가 데이터를 보내주면 웹 브라우저는 페이지를 다시 로드하지 않고 DOM 트리에서 바꿀 부분만을 변경함으로써 다음 주 일정을 보여준다.
AJAX가 등장함으로써 SPA도 등장했지만 본격 불을 당긴 계기는 이를 편리하게 구현할 수 있는 프레임워크인 jQuery일 것이다. 이후 React, Angular, Vue.js와 같은 프레임워크까지 등장하여 더더욱 편리하게, 그리고 대규모의 세련된 SPA를 구현하기가 더욱 쉬워졌다.
서버의 부담이라는 면에서 보면 SPA의 장점이 많다. 요청이 들어올 때마다 전체 웹 페이지를 보낼 필요 없이 JSON이나 XML 형식 데이터만 보내면 되므로 페이지를 만들고 전송하는 컴퓨팅 파워나 트래픽을 대폭 아낄 수 있기 때문이다. 요즈음은 웹 페이지에서 CSS, 자바스크립트 파일이 차지하는 비중도 꽤 많은데, 이를 포함한 정적인 자원들은 다시 로드할 필요가 없다는 점은 큰 장점이다.[1] 사용자 쪽에서 볼 때에도 기존 방식의 웹 애플리케이션은 페이지가 로딩될 때 잠깐이지만 빈 화면만 보게 될 수 있지만 SPA는 페이지를 다시 로딩하는 게 아니므로 그런 일이 없다. 다만 서버와 통신을 하고 데이터를 읽어들이고 있는 동안에는 이 상황을 사용자에게 알리기 위한 진행 중 표시 같은 것을 보여줄 필요가 있다.
그러나 전체 웹사이트를 SPA로 하는 경우는 별로 없고 효율도 나쁘다. SPA는 데이터를 받아서 자바스크립트로 DOM 트리를 변경해야 하는데 전체 내용이 다 바뀐다면 DOM 트리를 바꾸는 렌더링을 전부 클라이언트가 떠맡아야 한다. 같은 양이라고 한다면 HTML을 받아 뿌리는 것보다 JSON 데이터를 받아서 DOM 트리를 변경하는 게 클라이언트 쪽의 부담이 크다.[2] 따라서 페이지의 내용이 많이 바뀐다면 그냥 페이지를 새로 받아오는 게 특히 클라이언트 쪽은 부담이 덜하다. 페이지의 구조나 디자인은 별로 달라지지 않고 데이터만 바뀌는 부분이 SPA가 딱 적합한 곳이다.
검색엔진 최적화(SEO)에도 약점이 있는데, 단일 페이지 애플리케이션은 첫 진입점의 URL 말고는 그 페이지 안에서 내용만 자바스크립트로 바꾸므로 검색 엔진이 보기에는 페이지가 하나밖에 없는 것처럼 보일 수 있다. 검색 엔진은 그냥 HTML을 가져다가 안에 있는 텍스트를 분석할 뿐이지 그 안의 자바스크립트를 실행시켜 가면서 내용이 어떻게 달라지는지까지는 보지는 않는다. 하지만 최근에는 React나 Angular 같은 프레임워크들이 클라이언트에서 렌더링을 할지(CSR), 서버에서 렌더링을 할지(SSR)를 상황에 따라 선택할 수 있는 기능을 제공하면서 SEO 문제를 완화시켜 주고는 있지만 그래도 기존 페이지 방식에 비하면 약점이 있다.