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

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

다중 출처 사이트에서 프로그레시브 웹 앱을 빌드하기 위한 과제 및 해결 방법입니다.

데미안 렌줄리

배경

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

여러 출처의 좋은 사용과 잘못된 사용

사이트에서 다중 출처 아키텍처를 사용해야 하는 타당한 이유는 주로 독립적인 웹 애플리케이션 세트를 제공하거나 서로 완전히 격리된 환경을 만드는 것과 관련되어 있습니다. 피해야 할 사용 사례도 있습니다.

좋은 예

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

현지화 / 언어: 국가 코드 최상위 도메인을 사용하여 여러 국가에 게재할 사이트를 구분하거나 (예: 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)에서 설치 메시지를 수신하는 사용자는 start_url이 포함된 PWA를 다른 도메인 (예: https://www.example.com)에 설치할 수 없습니다. 즉, 하위 도메인에서 설치 메시지를 수신하는 사용자는 앱의 기본 URL이 아닌 하위 페이지의 PWA만 설치할 수 있습니다.

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

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

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

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

독립형 모드

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

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

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

결론

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

이미 이러한 방식으로 빌드된 기존 사이트의 경우 다중 출처 PWA가 올바르게 작동하도록 하는 것이 어려울 수 있지만, Google에서는 몇 가지 가능한 해결 방법을 살펴보았습니다. 각기 장단점이 있을 수 있으므로 웹사이트에서 어떤 접근 방식을 취할지 신중하게 결정하세요.

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

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