SPA

• Single Page Application
• 페이지가 1개인 어플리케이션

들어가기 전 단어 정리 😶‍🌫️

• SEO(Search Engine Optimization) : 검색 엔진 최적화, 특정 컨텐츠를 검색 결과의 상위에 표시, 웹 사이이트가 검색 결과에 더 잘 보이도록 최적화 하는 과정
  • 검색 엔진은 웹을 크롤링하면서 페이지에서 페이지로 링크를 따라가, 찾은 콘텐츠의 색인을 생성한다.
  • 만약 자바스크립트를 읽지 못하는 검색엔진(네이버, 다음 등)이라면 크롤링이 될 수 없어 색인되지 않는 문제가 발생할 수 있다. (페이지가 검색결과에 잘 나타나지 않을 수 있다.)
  • 페이지가 검색결과에 잘 나타나지 않으면, 사용자의 유입이 적을 수 있다.
• Rendering : 서버로부터 받은 리소스를 브라우저 화면에 표시하는 작업
• AJAX(Asynchronous Javascript and XML) : JS와 XML을 이용한 비동기적 정보 교환 기법 (요즘에는 XML을 잘 쓰지 않고, JSON을 다룬다.), 서버와 브라우저가 데이터를 교환할 수 있는 통신 방식
• 라우팅(Routing) :
  • 어떤 화면(view)에서 다른 화면으로 전환하는 네비게이션을 관리하기 위한 기능
  • 사용자가 요청한 URL 또는 이벤트를 해석하여 새로운 페이지로 전환하기 위한 데이터를 얻기 위해, 서버에 필요한 데이터를 요청하여 화면을 전환
  • 화면을 전환하는 경우
    1. 주소창에 URL을 입력
    2. 웹 페이지의 링크를 클릭
    3. 뒤로 가기, 앞으로 가기 버튼을 클릭

전통적인 웹의 문제

전통적인 웹은 여러 페이지로 구성이 되어 있었다.
-> 유저가 요청할 떄마다 페이지가 새로고침이 되고, 페이지가 로딩될 때마다 서버로부터 리소르를 전달받아 해석 후 렌더링을 한다.
(어떻게 보여질지도 서버에서 담당)

-> 웹이 제공하는 정보가 점차 많아지면서 전통적인 방식은 속도적인 측면에서 문제가 발생하기 시작했다. (렌더링을 위해 서버 자원이 사용되어, 불필요한 트래픽 사용)

렌더링 방식 😎

SSR (Server Side Rendering)

• 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 보여주는 방식 (서버에서 렌더링을 수행)
  • 서버에서 렌더링을 수행하고 데이터가 담겨있는 페이지를 넘겨준다.
• 모든 데이터가 담겨있는 페이지를 서버가 클라이언트에게 넘겨준다.
• SEO를 구성하기 쉽다. (JS를 이용한 렌더링이 아니기때문에 HTML에 모든 컨텐츠가 저장되어 있어 SEO를 구성하기 쉽다.)
• [단점] 매번 페이지를 요청할 때마다 새로고침된다. (UX가 좋지 않다, 많은 상호작용이 필요한 서비스인 경우에는 적절하지 않다.)
• 전통적인 링크 방식

클라이언트 : 서버에게 페이지 요청
서버 : 데이터가 매핑된 페이지를 클라이언트에게 전달

.. 클라이언트의 요청시 마다 새로고침

CSR (Client Side Rendering)

• 최초 한번 서버에게 요청하여 전체 페이지를 로딩한다.
• 사용자의 요청이 올때마다 리소스만 서버에서 제공하고 해석하고 렌더링하는 작업은 클라이언트에서 맡는다. (HTML을 그리는 역할을 클라이언트가 JS로 수행)
• 트래픽을 감소시킬 수 있고, 더 나은 UX를 제공
• [단점] 자바스크립트를 해석하지 못하는 크롤러에서는 페이지의 정보를 제대로 받아갈 수 없음 (SEO관련 문제)
• [단점] 자바스크립트가 실행되기 전까지는 페이지가 비어있다.
• [단점] 유저가 방문하지 않을 수 있는 페이지관련 렌더링 스크립트도 불러오기 때문에 필요한 페이지보다 자바스크립트 파일이 더 무거울 수 있다.
• AJAX나 hash, PJAX 방식으로 라우팅

클라이언트 : 최초 요청 (HTML, CSS, JS등 각종 리소스를 받아온다.)
서버 : HTML로 응답 (전체 페이지를 구성하는 스크립트, 페이지를 구성하는 프레임)

클라이언트 : 서버에게 API 요청 (필요한 데이터에 대한)
서버 : JSON Data 응답
클라이언트 : 받아온 Data를 통해 HTML을 그림

SSR VS CSR

• CSR은 초기 요청때, 많은 리소스를 가져오기 때문에 SSR보다 렌더링 속도가 느리다. 하지만 페이지를 전환할 때 서버에서 다시 페이지를 받아오는 것이 아니기 때문에 SSR보다 CSR이 더 빠르다.

SPA

• SPA는 주로 CSR의 방식을 사용한다.
• 전체 페이지를 하나의 페이지에 담고, 동적으로 화면을 바꾼다.
• 첫 로딩시에만 전체 페이지를 가져오고, 필요한 데이터만 서버에서 JSON 형태로 받아 동적으로 렌더링
• 대표적인 SPA 라이브러리 React, Vue, Angular
  • 이들은 자바스크립트를 통한 빈번한 DOM조작을 줄이기 위해 Virtual DOM을 사용 (빈번한 DOM 조작은 브라우저의 성능을 저하시킴)
• HTML5의 History API를 이용
  • 페이지 이동이 일어난 것처럼 작동
  • 서버로 페이지 요청을 하지 않고, history.state에 저장된 정보로 ajax 요청만 보냄

라우팅 🚃

• 화면을 전환하는 기능

전통적인 링크 방식

• link tag로 동작 (링크를 클릭하면 link태그의 href값이 URL path에 추가되어 해당 리소스(href 값)를 서버에 요청)
  • 페이지마다 고유의 URL이 존재
  • history 관리에 문제 없음

AJAX 방식

• link tag의 기본 동작을 prevent하고 AJAX나 hash방식 사용하여 필요한 리소스만 서버에게 요청
  • URL을 변경시키지 않으므로 주소가 변경되지 않는다. (= history 관리가 되지 않는다.)
  • [단점] history 관리가 되지 않으므로 뒤로 가기, 앞으로 가기가 동작하지 않는다.
  • [큰 단점] 주소가 변경되지 않으므로 새로고침을 클릭하면 항상 첫페이지가 다시 로딩된다. (SEO에 있어 취약)

Hash 방식

• AJAX 방식은 history 관리가 되지 않는 단점이 있는데 이를 보완한 것이 hash 방식 (hash방식은 history 관리가 가능)
• fragment identifier(#service)의 고유 기능인 앵커(anchor)를 사용
  • hash는 요청을 위한 것이 아니라 웹 페이지 내부에서의 이동을 위한 것 (즉, 서버에 새로운 요청을 보내지 않는다!)
  • 서버에 새로운 요청을 보내지 않으면서, 페이지마다 고유한 URL을 가지므로 history를 관리할 수 있가.
• [단점] URI에 불필요한 #이 들어간다!
• [큰 단점] SEO에 있어서 취약

PJAX 방식

• HTML5의 Histroy API인 pushState와 popstate 이벤트를 사용
• link의 이벤트를 prevent하고, URI path로 서버 요청, pushState메서드를 통해 주소창의 URL을 변경하고, 해당 URL을 history entry에 추가
• [문제] 문제는 새로고침이다. 새로고침을 하게 되면 https://localhost:8080/about와 같은 요청이 서버로 전달되는데 서버에 해당 URL에 대한 리소스가 있어야 화면이 표시될 수 있다. (없다면 404)

모든 AJAX 어플리케이션이 SPA일 필요는 없다. 😶

표준 웹 애플리케이션

클라이언트 : 페이지 요청
서버 : HTML 응답

.. 요청마다 페이지 re-load

AJAX 웹 어플리케이션

클라이언트 : 초기 요청
서버 : HTML 페이지 로드
클라이언트 : AJAX 요청
서버 : JSON 데이터
클라이언트 : POST 요청
서버 : HTML 페이지 리로드

.. POST 요청시에는 페이지를 리로드한다.

SPA

클라이언트 : 초기 요청
서버 : HTML 페이지 로드
클라이언트 : AJAX 요청
서버 : JSON 데이터
클라이언트 : AJAX 요청
서버 : JSON 데이터

.. 페이지가 하나이므로 리로드하지 않는다.

참고

• SPA - 우테코 LMS
• 라우팅 - 우테코 LMS
• SEO - MDN
• SPA, CSR과 SSR, SEO
• SPA기반 웹사이트의 SEO
• SPA 그리고 SSR과 CSR
• SSR vs SPA
• what is spa
• AJAX