이 페이지는 Cloud Translation API를 통해 번역되었습니다.

다중 출처 사이트의 프로그레시브 웹 앱

다중 출처 사이트에서 프로그레시브 웹 앱을 빌드할 때의 과제 및 해결 방법

Demián Renzulli

배경

과거에는 멀티 오리진 아키텍처를 사용하면 몇 가지 이점이 있었지만 프로그레시브 웹 앱의 경우 이러한 접근 방식에는 많은 문제가 있습니다. 특히 동일 출처 정책은 서비스 워커 및 캐시, 권한과 같은 항목을 공유하고 여러 출처에서 독립형 환경을 구현하는 데 제한을 가합니다. 이 도움말에서는 여러 출처의 장단점을 설명하고, 다중 출처 사이트에서 프로그레시브 웹 앱을 빌드하는 데 따르는 문제점과 해결 방법을 설명합니다.

여러 출처의 장단점

사이트가 멀티 오리진 아키텍처를 채택하는 데는 몇 가지 타당한 이유가 있습니다. 주로 독립적인 웹 애플리케이션 집합을 제공하거나 서로 완전히 격리된 환경을 만들기 위해서입니다. 또한 피해야 하는 용도도 있습니다.

좋은 예

먼저 유용한 이유를 살펴보겠습니다.

현지화 / 언어: 국가 코드 최상위 도메인을 사용하여 다른 국가에 게재할 사이트를 분리하거나 (예: https://www.google.com.ar) 하위 도메인을 사용하여 다른 위치를 타겟팅하는 사이트를 분할합니다 (예: https://newyork.craigslist.org) 또는 특정 언어 (예: https://en.wikipedia.org)로 콘텐츠를 제공하는 데 사용할 수 있습니다.
독립적인 웹 앱: 여러 하위 도메인을 사용하여 주요 출처의 사이트와 목적이 크게 다른 환경을 제공합니다. 예를 들어 뉴스 사이트에서 십자말풀이 웹 앱을 의도적으로 https://crosswords.example.com에서 제공하고 독립적인 PWA로 설치 및 사용할 수 있습니다. 이때 기본 웹사이트와 리소스나 기능을 공유하지 않아도 됩니다.

나쁜 것

이와 같은 작업을 하지 않는다면 멀티 오리진 아키텍처를 사용하면 프로그레시브 웹 앱을 빌드할 때 불리할 수 있습니다.

그럼에도 불구하고 많은 사이트가 특별한 이유나 '기존' 사유로 인해 계속해서 이러한 방식으로 구조화되고 있습니다. 일례로 통합 환경에 포함되어야 하는 사이트의 일부를 임의로 분리하기 위해 하위 도메인을 사용하는 경우가 있습니다.

예를 들어 다음 패턴은 사용하지 않는 것이 좋습니다.

사이트 섹션: 하위 도메인에서 사이트의 여러 섹션을 구분합니다. 뉴스 사이트의 홈페이지는 https://www.example.com에, 스포츠 섹션은 https://sports.example.com에, 정치 섹션은 https://politics.example.com에 자주 표시됩니다. 전자상거래 사이트의 경우 제품 카테고리에는 https://category.example.com을, 제품 페이지에는 https://product.example.com를 사용합니다.
사용자 플로우: 하위 도메인의 로그인 또는 구매 흐름 페이지와 같이 사이트의 여러 작은 부분을 분리하는 방법도 있습니다. 예를 들어 https://login.example.com 및 https://checkout.example.com를 사용합니다.

단일 출처로 이전할 수 없는 경우를 위해 프로그레시브 웹 앱을 빌드할 때 고려할 수 있는 과제 목록 및 가능한 경우 해결 방법을 살펴보겠습니다.

다양한 출처의 PWA 관련 과제 및 해결 방법

여러 출처에서 웹사이트를 빌드하는 경우 통합 PWA 환경을 제공하기가 까다롭습니다. 주된 이유는 여러 가지 제약조건이 적용되는 동일 출처 정책 때문입니다. 한 번에 하나씩 살펴보겠습니다.

서비스 워커

서비스 워커 스크립트 URL의 출처는 register()를 호출하는 페이지의 출처와 같아야 합니다. 즉, 예를 들어 https://www.example.com의 페이지는 https://section.example.com에 있는 서비스 워커 URL로 register()를 호출할 수 없습니다.

또 다른 고려사항은 서비스 워커가 자신이 속한 원본과 경로에서 호스팅되는 페이지만 제어할 수 있다는 것입니다. 즉, 서비스 워커가 https://www.example.com에서 호스팅되는 경우 (범위 매개변수에 정의된 경로에 따라) 해당 출처의 URL만 제어할 수 있으며 https://section.example.com에 있는 것과 같은 다른 하위 도메인의 페이지는 제어하지 않습니다.

이 경우 유일한 해결 방법은 여러 서비스 워커 (원본당 하나)를 사용하는 것입니다.

캐싱

Cache 객체, IndexingDB, localStorage도 단일 출처로 제한됩니다. 즉, https://www.example.com에 속한 캐시(예: https://www.section.example.com)에 액세스할 수 없습니다.

다음과 같은 상황에서 캐시를 올바르게 관리하기 위해 수행할 수 있는 작업은 다음과 같습니다.

브라우저 캐싱 활용: 항상 기존 브라우저 캐싱 권장사항을 따르는 것이 좋습니다. 이 기법은 서비스 워커의 캐시로는 수행할 수 없는 캐시된 리소스를 출처 전체에서 재사용한다는 추가적인 이점을 제공합니다. 서비스 워커와 함께 HTTP 캐시를 사용하는 방법에 대한 권장사항은 이 게시물을 참조하세요.
서비스 워커 설치를 경량으로 유지: 여러 서비스 워커를 유지관리하는 경우 사용자가 새로운 출처로 이동할 때마다 많은 설치 비용을 지불하지 않도록 합니다. 즉, 절대적으로 필요한 리소스만 사전 캐시합니다.

권한

권한 범위도 출처로 지정됩니다. 즉, 사용자가 원본 https://section.example.com에 특정 권한을 부여한 경우 https://www.example.com와 같은 다른 출처로 이전되지 않습니다.

출처 간에 권한을 공유할 수 있는 방법은 없으므로 특정 기능이 필요한 하위 도메인 (예: 위치)별로 권한을 요청하는 방법밖에 없습니다. 웹 푸시와 같은 경우 쿠키를 유지 관리하여 다른 하위 도메인의 사용자가 권한을 수락했는지 추적하여 다시 요청하지 않도록 할 수 있습니다.

설치

PWA를 설치하려면 각 출처에 자체에 상대적인 start_url가 있는 자체 매니페스트가 있어야 합니다. 즉, 지정된 출처 (https://section.example.com)에서 설치 메시지를 수신하는 사용자는 다른 출처 (예: https://www.example.com)에 start_url를 사용하여 PWA를 설치할 수 없습니다. 즉, 하위 도메인에서 설치 메시지를 받는 사용자는 앱의 기본 URL이 아닌 하위 페이지의 PWA만 설치할 수 있습니다.

또한 각 하위 도메인이 설치 기준을 충족하고 사용자에게 PWA를 설치하라는 메시지를 표시하는 경우 사이트를 탐색할 때 동일한 사용자에게 여러 설치 메시지가 표시될 수 있는 문제도 있습니다.

이 문제를 완화하려면 프롬프트가 기본 출처에만 표시되도록 하면 됩니다. 사용자가 설치 기준을 충족하는 하위 도메인을 방문하는 경우

beforeinstallprompt 이벤트 수신 대기.
메시지가 표시되지 않도록 하고 event.preventDefault()를 호출합니다.

이렇게 하면 사이트의 의도치 않은 부분에 메시지가 표시되지 않도록 하면서 예를 들어 기본 출처 (예: 홈페이지)에 메시지를 계속 표시할 수 있습니다.

독립형 모드

독립형 창에서 탐색하는 동안 사용자가 PWA 매니페스트에 설정된 범위를 벗어나면 브라우저가 다르게 작동합니다. 동작은 각 브라우저 버전 및 공급업체에 따라 다릅니다. 예를 들어 최신 Chrome 버전에서는 사용자가 독립형 모드에서 범위를 벗어날 때 Chrome 맞춤 탭이 열립니다.

대부분의 경우 이 문제에 대한 해결책은 없지만 하위 도메인에서 호스팅되는 환경의 일부 (예: 로그인 워크플로)에 해결 방법을 적용할 수 있습니다.

새 URL(https://login.example.com)이 전체 화면 iframe 내에서 열릴 수 있습니다.
작업이 iframe 내에서 완료되면 (예: 로그인 프로세스) postMessage()를 사용하여 iframe의 결과 정보를 상위 페이지로 다시 전달할 수 있습니다.
마지막 단계로, 기본 페이지에서 메시지를 수신하면 리스너의 등록을 취소할 수 있으며 최종적으로 DOM에서 iframe을 제거합니다.

결론

동일한 출처 정책은 일관된 PWA 환경을 달성하고자 하는 여러 출처를 기반으로 구축된 사이트에 많은 제한을 가합니다. 따라서 사용자에게 최상의 환경을 제공하기 위해서는 사이트를 서로 다른 출처로 나누지 않는 것이 좋습니다.

이미 이러한 방식으로 빌드된 기존 사이트의 경우 멀티 출처 PWA가 올바르게 작동하기가 어려울 수 있지만 몇 가지 잠재적인 해결 방법을 살펴보았습니다. 사이트마다 장단점이 있으므로 웹사이트에서 어떤 접근 방식을 취할지 결정할 때 자신의 판단에 따라 판단하세요.

장기 전략이나 사이트 재설계를 평가할 때는 멀티 출처 아키텍처를 유지해야 하는 중요한 이유가 없다면 단일 출처로 이전하는 것이 좋습니다.

기술 리뷰와 제안에 감사의 말을 전합니다. 페니 맥클란, 폴 코벨, 도미닉 응, 알베르토 메디나, 피트 르페이지, 조 메들리, 체니 차이, 마틴 쉬얼, 안드레 반다라.