한 페이지 분량의 응용 프로그램

Single-page application

Single-Page Application(SPA; 싱글 페이지응용 프로그램)은 웹 브라우저가 새로운 페이지 전체를 로드하는 기본 방식이 아니라 웹 서버에서 새로운 데이터를 사용하여 현재 웹 페이지를 동적으로 다시 작성하여 사용자와 대화하는 웹 응용 프로그램 또는 웹 사이트입니다.목표는 웹 사이트를 보다 네이티브 앱처럼 느끼게 하는 빠른 전환입니다.

SPA에서는 페이지 새로고침은 발생하지 않습니다.대신 필요한 HTML, JavaScript 및 CSS 코드는 모두 브라우저에 의해1 페이지 [1]로드로 취득되거나 보통 사용자의 조작에 따라 적절한 리소스가 동적으로 로드되어 페이지에 추가됩니다.

역사

단일 페이지 애플리케이션이라는 [2]용어의 기원은 불분명하지만, 이 개념은 적어도 2003년에 논의되었다.웨일즈 카디프 대학의 프로그래밍 학생인 Stuart Morris는 2002년 [3]4월에 동일한 목표와 기능을 가진 Self-Contained 웹사이트를 slashdotslash.com에 작성했으며, 같은 해 말에는 Lucas Birdeau, Kevin Hakman, Michael Peachy 및 Clifford Yeh가 미국 특허 8,178에 한 페이지 분량의 애플리케이션 구현에 대해 설명했습니다.[4]

JavaScript는 웹 브라우저에서 사용자 인터페이스(UI)를 표시하고 애플리케이션 로직을 실행하며 웹 서버와 통신하기 위해 사용할 수 있습니다.SPA 구축을 지원하는 성숙한 무료 라이브러리를 사용할 수 있으므로 개발자가 작성해야 하는 JavaScript 코드 양을 줄일 수 있습니다.

기술적 접근법

애플리케이션이 서버 통신을 필요로 하는 경우에도 브라우저가 단일 페이지를 유지할 수 있도록 하는 다양한 기술을 사용할 수 있습니다.

문서 해시

HTML 작성자는 요소 ID를 사용하여 HTML 문서의 다른 섹션을 표시하거나 숨길 수 있습니다.그런 다음 작성자는 CSS를 사용하여 '#target' 셀렉터를 사용하여 브라우저가 탐색한 페이지의 섹션만 표시할 수 있습니다.

JavaScript

웹 브라우저 JavaScript 프레임워크와 라이브러리(AngularJs, Ember.js, ExtJs, Knockout.js, Meteor.js, React, Vue.js 및 Svelte 등)는 SPA 원칙을 채택하고 있습니다.ExtJ 이외에는 모두 무료입니다.

  • AngularJS는 완전한 클라이언트 측 프레임워크입니다.각진JS의 템플릿은 양방향 UI 데이터 바인딩을 기반으로 합니다.데이터 바인딩은 모델이 변경될 때마다 자동으로 보기를 업데이트하고 보기가 변경될 때마다 모델을 업데이트하는 방법입니다.HTML 템플릿은 브라우저에서 컴파일됩니다.컴파일 스텝은 순수 HTML을 생성하여 브라우저가 라이브 뷰로 다시 렌더링합니다.후속 페이지 보기에 대해 이 단계를 반복합니다.기존의 서버측 HTML 프로그래밍에서는 컨트롤러와 모델과 같은 개념이 서버 프로세스 내에서 상호작용하여 새로운 HTML 뷰를 생성합니다.각진 상태JS 프레임워크, 컨트롤러 및 모델 상태는 클라이언트 브라우저 내에서 유지됩니다.따라서 서버와의 상호작용 없이 새 페이지를 생성할 수 있습니다.
  • Ember.js는 모델 뷰 컨트롤러(MVC) 소프트웨어 아키텍처 패턴을 기반으로 하는 클라이언트 측 JavaScript 웹 응용 프로그램 프레임워크입니다.개발자는 이를 통해 리치 오브젝트 모델, 선언적인 양방향 데이터 바인딩, 계산된 속성, Handlebars.js에 의한 템플릿 자동 갱신 및 애플리케이션 상태 관리를 위한 라우터를 제공하는 프레임워크에 공통의 관용어와 베스트 프랙티스를 통합함으로써 확장 가능한 단일 페이지 애플리케이션을 작성할 수 있습니다.
  • ExtJS는 MVC 응용 프로그램을 만들 수 있는 클라이언트 측 프레임워크이기도 합니다.자체 이벤트 시스템, 창 및 레이아웃 관리, 상태 관리(스토어), 다양한 UI 구성 요소(그레이드, 대화창, 양식 요소 등)가 있습니다.다이내믹 로더 또는 스태틱 로더를 갖춘 자체 클래스 시스템이 있습니다.ExtJ를 사용하여 빌드된 애플리케이션은 자체(브라우저에 상태 포함) 또는 서버(내부 저장소를 채우기 위해 사용되는 REST API 포함)와 함께 존재할 수 있습니다.ExtJ는 localStorage를 사용하는 기능만 내장되어 있기 때문에 대규모 애플리케이션에는 상태를 저장할 서버가 필요합니다.
  • Knocko.js는 Model-ViewModel 패턴을 기반으로 템플릿을 사용하는 클라이언트 측 프레임워크입니다.
  • Meteor.js는 SPA 전용으로 설계된 풀스택(클라이언트-서버) JavaScript 프레임워크입니다.Angular, Ember 또는 ReactJs보다 [5]간단한 데이터 바인딩을 특징으로 하며 Distributed Data[6] Protocol 및 Publish-Subscribe 패턴을 사용하여 개발자가 동기화 코드를 작성할 필요 없이 실시간으로 데이터 변경사항을 클라이언트에 자동으로 전파합니다.완전한 스택 반응성을 통해 데이터베이스에서 템플릿에 이르기까지 모든 계층이 필요할 때 자동으로 업데이트됩니다.서버 사이드[7] 렌더링과 같은 생태계 패키지는 검색 엔진 최적화 문제를 해결합니다.
  • React는 사용자 인터페이스를 구축하기 위한 JavaScript 라이브러리입니다.Facebook, Instagram 및 개인 개발자와 기업 커뮤니티에 의해 관리된다.React는 JS와 HTML(HTML의 서브셋)이 혼재된 새로운 언어를 사용합니다.여러 회사는 상태 관리 기능을 추가하는 React with Redux(JavaScript 라이브러리)를 사용합니다.이것에 의해, 개발자는 복잡한 애플리케이션을 [8]작성할 수 있습니다.
  • Vue.js는 사용자 인터페이스를 구축하기 위한 JavaScript 프레임워크입니다.Vue 개발자는 상태 관리를 위한 Vuex도 제공합니다.
  • Svelte는 Svelte 코드를 JavaScript DOM(Document Object Model) 조작에 컴파일하는 사용자 인터페이스를 구축하기 위한 프레임워크로, 클라이언트에 프레임워크를 번들할 필요가 없으며 애플리케이션 개발 구문을 단순화할 수 있습니다.

아약스

2006년 현재 가장 두드러진 기술은 아약스였다.[1]Ajax는 JavaScript의 XMLHttpRequest 또는 최신 fetch()(2017년 이후) 또는 사용되지 않는 ActiveX 개체와 같은 XML 또는 JSON 데이터에 대한 서버에 대한 비동기 요청을 사용합니다.대부분의 SPA 프레임워크와는 달리 Ajax에서는 직접 JavaScript 또는 jQuery 등의 JavaScript 라이브러리를 사용하여 DOM을 조작하고 HTML 요소를 편집합니다.Ajax는 jQuery와 같은 라이브러리에 의해 더욱 대중화되었는데, 이것은 구문을 더 단순하게 제공하고 역사적으로 다양한 동작을 가지고 있던 다른 브라우저에 걸쳐 Ajax 동작을 정규화한다.

웹 소켓

WebSockets는 HTML5 사양의 일부인 양방향 실시간 클라이언트-서버 통신 기술입니다.실시간 통신의 경우 성능과[9] 단순성 측면에서 Ajax보다 사용이 우수합니다.

서버에서 전송된 이벤트

SSE(Server-sent Events)는 서버가 브라우저 클라이언트에 대한 데이터 전송을 시작할 수 있는 기술입니다.초기 접속이 확립되면 클라이언트에 의해 닫힐 때까지 이벤트스트림은 열린 상태로 유지됩니다.SSE는 기존 HTTP를 통해 전송되며 자동 재연결, 이벤트 ID, 임의 [10]이벤트 전송 기능 등 WebSocket에 없는 다양한 기능을 갖추고 있습니다.

브라우저 플러그인

이 방식은 오래된 방식이지만 Silverlight, Flash, Java 애플릿 등의 브라우저 플러그인 기술을 사용하여 서버에 대한 비동기 호출을 수행할 수도 있습니다.

데이터 전송(XML, JSON 및 Ajax)

서버에 대한 요청은 일반적으로 원시 데이터(예: XML 또는 JSON) 또는 새 HTML이 반환됩니다.서버에 의해 HTML이 반환되는 경우 클라이언트의 JavaScript는 DOM(Document Object Model)의 일부 영역을 업데이트합니다.원시 데이터가 반환되면 종종 클라이언트 측 JavaScript XML / (XSL) 프로세스(JSON의 경우 템플릿)를 사용하여 원시 데이터를 HTML로 변환한 다음 DOM의 일부 영역을 업데이트하는 데 사용됩니다.

서버 아키텍처

신서버 아키텍처

SPA는 서버에서 클라이언트로 로직을 이동하며 웹 서버의 역할은 순수 데이터 API 또는 웹 서비스로 발전합니다.이러한 아키텍처의 변화는, 「신 서버 아키텍처」라고 불리는 것으로, 복잡성이 서버로부터 클라이언트로 이동해, 결과적으로 시스템의 전체적인 복잡성이 경감되는 것을 강조합니다.

씩 스테이트풀한 서버 아키텍처

서버는 페이지의 클라이언트 상태에 대한 메모리에 필요한 상태를 유지합니다.이와 같이, 요구가 서버에 도달하면(통상은 유저의 액션), 서버는, 클라이언트를 새로운 희망 상태로 하기 위해서, 구체적인 변경을 포함한 적절한 HTML 및/또는 JavaScript 를 송신합니다(통상, 클라이언트 DOM 의 일부를 추가/삭제/업데이트 합니다).동시에 서버 상태가 갱신됩니다.대부분의 논리는 서버에서 실행되며 HTML도 일반적으로 서버에서 렌더링됩니다.서버는 웹 브라우저를 시뮬레이트하여 이벤트를 수신하고 서버 상태의 델타 변경을 실행하여 클라이언트에 자동으로 전파됩니다.

이 방법에서는 서버 메모리와 서버 프로세싱이 더 필요하지만 a) 어플리케이션은 보통 서버에서 완전히 코드화되어 있고 b) 서버 내의 데이터와 UI 상태는 커스텀 클라이언트/서버 통신 브리지 없이 동일한 메모리 공간에서 공유되기 때문에 개발 모델을 단순화할 수 있다는 장점이 있습니다.

씩 스테이트리스 서버 아키텍처

이것은 스테이트 풀 서버 어프로치의 변종입니다.클라이언트 페이지는 현재 상태를 나타내는 데이터를 보통 Ajax 요청을 통해 서버로 보냅니다.이 데이터를 사용하여 서버는 수정이 필요한 페이지 부분의 클라이언트 상태를 재구성할 수 있으며 필요한 데이터 또는 코드(예를 들어 JSON 또는 JavaScript)를 생성할 수 있습니다.이 데이터 또는 코드는 클라이언트에 반환되어 새로운 상태로 전환됩니다.보통 페이지 DOM 트리는 r의 동기를 부여한 클라이언트액션에 따라 변경됩니다.등가.

이 방법에서는 서버에 더 많은 데이터를 전송해야 하며 서버 내의 클라이언트 페이지 상태를 부분적으로 또는 완전히 재구성하기 위해 요청당 더 많은 계산 리소스가 필요할 수 있습니다.이와 동시에 서버 내에 클라이언트별 페이지 데이터가 보관되어 있지 않기 때문에 세션 데이터 공유나 서버 어피니티 없이 Ajax 요청을 다른 서버 노드로 디스패치할 수 있기 때문에 이 접근방식은 더욱 쉽게 확장할 수 있습니다.

로컬로 실행

일부 SPA는 파일 URI 방식을 사용하여 로컬파일에서 실행할 수 있습니다.이를 통해 사용자는 서버 접속에 의존하지 않고 서버에서SPA를 다운로드하여 로컬스토리지 디바이스에서 파일을 실행할 수 있습니다.이러한 SPA가 데이터를 저장 및 업데이트하려면 브라우저 기반의 웹 스토리지를 사용해야 합니다.이러한 애플리케이션은 HTML5에서 [11]이용할 수 있는 고도의 기능을 이용할 수 있습니다.

SPA 모델의 과제

SPA는 원래 브라우저용으로 설계된 상태 비저장 페이지 리드로 모델에서 발전한 것이기 때문에 몇 가지 새로운 과제가 대두되고 있습니다.생각할 수 있는 솔루션(복잡성, 포괄성, 작성자 제어가 다양함)은 다음과 같습니다.[12]

  • 클라이언트측 JavaScript 라이브러리.
  • SPA [13][14][15]모델에 특화된 서버 측 웹 프레임워크.
  • SPA 모델용으로 설계된 브라우저와 HTML5 [16]사양의 진화.

검색 엔진 최적화

일부 인기 있는 웹 검색 [17]엔진의 크롤러에서 JavaScript가 실행되지 않기 때문에 SEO(검색 엔진 최적화)는 SPA [18]모델을 채택하고자 하는 일반 웹 사이트에 문제를 제기해 왔습니다.

2009년에서 2015년 사이에 Google Webmaster Central은 상태 저장 AJAX 페이지의 단편 식별자에 첫 번째 느낌표를 사용하는 "AJAX 크롤링 [19][20]방식"을 제안하고 권장했습니다.#!검색 엔진의 크롤러에서 관련 메타데이터를 추출할 수 있도록 SPA 사이트에서 특별한 동작을 구현해야 합니다.이 URL 해시 방식을 지원하지 않는 검색 엔진의 경우 SPA의 해시 URL은 표시되지 않습니다.이러한 "해시방" URI는 브라우저에서 JavaScript가 활성화되지 않은 사용자가 페이지에 액세스할 수 없도록 만들기 때문에 W3C의 Jeni Tennison을 포함한 많은 작가들에 의해 문제가 있다고 여겨져 왔습니다.브라우저가 Referrer [21]헤더 내에서 fragment ID를 전송할 수 없기 때문에 HTTP Referrer 헤더도 끊습니다.2015년 구글은 해시방 AJAX 크롤링 [22]제안을 철회했다.

또는 응용 프로그램은 서버에 첫 페이지를 로드하고 클라이언트에 후속 페이지 업데이트를 렌더링할 수 있습니다.렌더링 코드를 서버와 클라이언트의 다른 언어 또는 프레임워크로 작성해야 하는 경우가 있기 때문에 이 작업은 일반적으로 어렵습니다.논리가 필요 없는 템플릿을 사용하거나, 어떤 언어에서 다른 언어로 교차 컴파일하거나, 서버와 클라이언트에서 동일한 언어를 사용하면 공유할 수 있는 코드의 양을 늘릴 수 있습니다.

2018년 구글은 크롤러에게 인덱싱 [23]목적으로 자바스크립트 이외의 무거운 버전의 페이지를 제공하고자 하는 사이트를 위한 또 다른 옵션으로 다이내믹 렌더링을 도입했습니다.동적 렌더링은 클라이언트 측으로 렌더링된 페이지 버전과 특정 사용자 에이전트의 사전 렌더링 버전을 전환합니다.이 방법에서는 웹 서버가 (사용자 에이전트를 통해) 크롤러를 검출하여 렌더러로 라우팅하고, 렌더러에서 HTML 컨텐츠의 더 단순한 버전을 제공합니다.

SPA에서는 SEO의 호환성이 중요하지 않기 때문에 일반적으로 SPA는 검색 엔진인덱스가 필요하거나 바람직한 컨텍스트에서는 사용되지 않습니다.사용 사례에는 인증 시스템 뒤에 숨겨진 개인 데이터를 표면화하는 애플리케이션이 포함됩니다.이러한 응용 프로그램이 소비자 제품인 경우 응용 프로그램 랜딩 페이지 및 마케팅 사이트에 고전적인 "페이지 리드로" 모델이 사용되는 경우가 많습니다. 이 모델은 응용 프로그램이 검색 엔진 쿼리에 히트한 것으로 나타나기에 충분한 메타데이터를 제공합니다.SPA 주변에는 블로그, 지원 포럼 및 기타 기존 페이지 리드로우 아티팩트가 배치되어 있어 관련 용어를 사용하여 검색 엔진을 시드할 수 있습니다.

2021년, 특히 Google에서는 플레인 SPA에 대한 SEO 호환성은 간단하며 몇 가지 간단한 조건만 [24]충족하면 됩니다.선택적 프리렌더링을 사용하는 고급 SPA에 대한 실용적인 가이드도 제공됩니다.[25]

서버와 클라이언트 간에 공유할 수 있는 코드의 양을 늘리는 방법 중 하나는 콧수염이나 핸들바와 같은 논리가 필요 없는 템플릿 언어를 사용하는 것입니다.이러한 템플릿은 서버의 Ruby, 클라이언트의 JavaScript 등 다양한 호스트 언어에서 렌더링할 수 있습니다.그러나 일반적으로 템플릿을 공유하기 위해서는 올바른 템플릿을 선택하고 데이터를 입력하기 위해 사용되는 비즈니스 로직을 복제해야 합니다.템플릿에서 렌더링하면 큰 템플릿 내의 텍스트 입력 값 등 페이지의 일부만 업데이트할 경우 성능에 부정적인 영향을 미칠 수 있습니다.전체 템플릿을 바꾸면 변경된 값만 업데이트할 수 없는 사용자의 선택 또는 커서 위치가 방해될 수도 있습니다.이러한 문제를 피하기 위해 응용프로그램은 UI 데이터 바인딩 또는 세분화된 DOM 조작을 사용하여 전체 템플릿을 다시 렌더링하는 대신 페이지의 적절한 부분만 업데이트할 수 있습니다.랭킹을 설정합니다.[26]

클라이언트/서버 코드 파티셔닝

브라우저 이력

SPA가 정의상 '1페이지'인 경우 모델은 '앞으로' 또는 '뒤로' 버튼을 사용하여 브라우저의 페이지 이력 네비게이션 설계를 변경합니다.이로 인해 사용자가 뒤로 버튼을 누르면 SPA 내의 이전 화면 상태를 예상할 수 있지만, 대신 응용 프로그램의 단일 페이지가 언로드되고 브라우저 이력의 이전 페이지가 표시됩니다.

SPA의 기존 솔루션은 브라우저 URL의 해시 프래그먼트 식별자를 현재 화면 상태에 따라 변경하는 것이었습니다.이는 JavaScript를 사용하여 실행할 수 있으며 브라우저 내에서 URL 이력 이벤트가 작성됩니다.SPA가 URL 해시 내에 포함된 정보에서 동일한 화면 상태를 부활시킬 수 있는 한 예상되는 백버튼 동작은 유지됩니다.

이 문제에 더욱 대응하기 위해 HTML5 사양에서는 실제 URL 및 브라우저 이력에 대한 프로그램 액세스를 제공하는 pushState 및 replaceState가 도입되었습니다.

분석

Google Analytics와 같은 분석 도구는 새 페이지 로드에 의해 시작된 브라우저의 전체 새 페이지 로드에 크게 의존합니다.SPA는 이 방법으로 동작하지 않습니다.

첫 번째 페이지 로드 후 이후의 모든 페이지 및 콘텐츠 변경은 응용 프로그램에 의해 내부적으로 처리되며, 분석 패키지를 업데이트하는 함수를 호출하기만 하면 됩니다.해당 함수를 호출할 수 없는 경우 브라우저는 새로운 페이지 로드를 트리거하지 않으며 브라우저 이력에 아무것도 추가되지 않으며 분석 패키지는 누가 사이트에서 무엇을 수행하는지 알 수 없습니다.

보안 검사

검색 엔진 크롤러에서 발생하는 문제와 마찬가지로 DST 도구는 이러한 JavaScript가 풍부한 응용 프로그램에서 어려움을 겪을 수 있습니다.문제에는 하이퍼텍스트링크 부족, 메모리 사용량 및 SPA에 의해 로드된 리소스가 일반적으로 Application Programming Interface 또는 API에 의해 이용 가능하게 되는 경우가 있습니다.단일 페이지 애플리케이션은 크로스 사이트 스크립팅(XSS) 등의 기존 웹 페이지와 동일한 보안 리스크에 노출되어 있을 뿐만 아니라 API를 통한 데이터 노출, 클라이언트 측 로직 및 서버 측 [27]보안의 클라이언트 측 적용 등 다양한 고유한 취약성에 노출되어 있습니다.단일 페이지 애플리케이션을 효과적으로 스캔하려면 DST 스캐너가 클라이언트 측 애플리케이션을 신뢰성 있고 반복 가능한 방법으로 탐색할 수 있어야 합니다.이것에 의해, 애플리케이션의 모든 영역을 검출해, 애플리케이션이 리모트 서버에 송신하는 모든 요구(API 요구등)를 대행 수신할 수 있습니다.이러한 조치를 취할 수 있는 상업적 도구는 거의 없지만 그러한 도구는 분명히 존재합니다.[citation needed]

SPA에 페이지 로드 추가

HTML5 이력 API를 사용하여 SPA에 페이지로드 이벤트를 추가할 수 있습니다.이것에 의해, 분석의 통합에 도움이 됩니다.이를 관리하고 모든 것이 정확하게 추적되도록 하는 데 어려움이 있습니다. 여기에는 누락된 보고서와 이중 항목이 있는지 확인하는 작업이 포함됩니다.일부 프레임워크는 대부분의 주요 분석 제공업체를 대상으로 무료 분석 통합을 제공합니다.개발자는 이를 애플리케이션에 통합하여 모든 것이 제대로 작동하는지 확인할 수 있지만 처음부터 모든 작업을 [26]수행할 필요는 없습니다.

페이지 로드 속도 향상

SPA의 초기 부하를 고속화하는 방법에는 SPA 랜딩 페이지/인덱스 페이지의 선택적 프리렌더링, 캐싱 및 필요에 따라 저속 로드 모듈을 포함한 다양한 코드 분할 기법 등이 있습니다.그러나 적어도 일부 애플리케이션 코드를 다운로드해야 한다는 사실에서 벗어날 수 없으며 페이지가 [26]동적일 경우 데이터용 API를 찾을 수 있습니다.이것은 "지금 지불하라, 아니면 나중에 지불하라"는 트레이드오프 시나리오입니다.성능 및 대기 시간에 대한 문제는 개발자가 결정해야 하는 사항입니다.

페이지 라이프 사이클

SPA는 첫 번째 페이지 로드에서 완전히 로드된 후 페이지 영역이 서버에서 로드된 새 페이지 조각으로 교체 또는 업데이트됩니다.사용되지 않는 기능의 과도한 다운로드를 피하기 위해 SPA는 필요에 따라 페이지의 작은 조각 또는 전체 화면 모듈 중 하나를 순차적으로 다운로드합니다.

이와 같이 SPA의 "상태"와 기존 웹사이트의 "페이지"는 유사합니다.같은 페이지의 "상태 탐색"은 페이지 탐색과 유사하기 때문에 이론적으로 어떤 페이지 기반 웹 사이트도 변경된 부분만 같은 페이지에서 한 페이지 대체로 변환할 수 있습니다.

웹상의 SPA 접근법은 네이티브데스크탑애플리케이션에서 널리 사용되는Single-Document Interface(SDI; 싱글도큐먼트인터페이스) 프레젠테이션 기술과 비슷합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Flanagan, David, "JavaScript - The Definitive Guide", 제5판, 오라일리, 세바스토폴, CA, 2006, 페이지 497
  2. ^ "Inner-Browsing: Extending Web Browsing the Navigation Paradigm". Retrieved February 3, 2011.
  3. ^ "Slashdotslash.com: A self contained website using DHTML". Retrieved July 6, 2012.
  4. ^ "US patent 8,136,109". Retrieved April 12, 2002.
  5. ^ "Meteor Blaze". GitHub. 6 May 2022. Blaze is a powerful library for creating user interfaces by writing reactive HTML templates.
  6. ^ 2012년 3월 21일 DDP 소개
  7. ^ "Server Side Rendering for Meteor". Archived from the original on March 20, 2015. Retrieved January 31, 2015.
  8. ^ "Single-page applications vs. multiple-page applications: pros, cons, pitfalls - BLAKIT - IT Solutions". blak-it.com. BLAKIT - IT Solutions. October 17, 2017. Retrieved October 19, 2017.
  9. ^ "Real-Time Monitoring using AJAX and WebSockets". www.computer.org. Retrieved June 1, 2016.
  10. ^ "Server-Sent Events". W3C. July 17, 2013.
  11. ^ "Unhosted web apps".
  12. ^ "The Single Page Interface Manifesto". Retrieved April 25, 2014.
  13. ^ "Derby". Retrieved December 11, 2011.
  14. ^ "Sails.js". GitHub. Retrieved February 20, 2013.
  15. ^ "Tutorial: Single Page Interface Web Site With ItsNat". Retrieved January 13, 2011.
  16. ^ HTML5
  17. ^ "What the user sees, what the crawler sees". Retrieved January 6, 2014. the browser can execute JavaScript and produce content on the fly - the crawler cannot
  18. ^ "Making Ajax Applications Crawlable". Retrieved January 6, 2014. Historically, Ajax applications have been difficult for search engines to process because Ajax content is produced
  19. ^ "Proposal for making AJAX crawlable". Google. October 7, 2009. Retrieved July 13, 2011.
  20. ^ "(Specifications) Making AJAX Applications Crawlable". Google Inc. Retrieved March 4, 2013.
  21. ^ "Hash URIs". W3C Blog. May 12, 2011. Retrieved July 13, 2011.
  22. ^ "Deprecating our AJAX crawling scheme". Official Google Webmaster Central Blog. Retrieved February 23, 2017.
  23. ^ "Implement dynamic rendering". Google Search Central. October 13, 2018. Retrieved January 7, 2021.
  24. ^ "Fix a single-page app for Google Search". Google Codelabs. Retrieved 2021-12-15.
  25. ^ "Single Page Application: Dispelling SEO Myths Hacker Noon". hackernoon.com. Retrieved 2021-12-15.
  26. ^ a b c 홈즈, 시몬(2015).Mongo, Express, Angular 및 Node를 통한 MEANGE.매니닝 출판물ISBN 978-1-6172-9203-3
  27. ^ "Single Page Applications (SPA)". Appcheck Ltd.{{cite web}}: CS1 maint :url-status (링크)

외부 링크