애플리케이션 셸은 사용자 인터페이스를 지원하는 최소한의 HTML, CSS, JavaScript입니다. 앱 셸은 다음을 충족해야 합니다.
- 로드 속도가 빠릅니다.
- 캐시됨
- 콘텐츠를 동적으로 표시
애플리케이션 셸은 안정적으로 우수한 성능을 달성하기 위한 비결입니다. 앱의 셸은 네이티브 앱을 빌드할 때 앱 스토어에 게시하는 코드 번들이라고 생각하면 됩니다. 셸은 시작하는 데 필요한 로드이지만 전체가 아닐 수도 있습니다. UI는 로컬로 유지되고 API를 통해 콘텐츠가 동적으로 가져옵니다.
배경
Alex Russell의 프로그레시브 웹 앱 도움말에서는 웹 앱이 사용 및 사용자 동의를 통해 점진적으로 변경되어 오프라인 지원, 푸시 알림, 홈 화면에 추가할 수 있는 기능을 갖춘 더 많은 네이티브 앱과 같은 환경을 제공하는 방법을 설명합니다. 이는 서비스 워커의 기능과 성능 이점, 캐싱 기능에 따라 크게 달라집니다. 이를 통해 속도에 집중하여 웹 앱에 네이티브 애플리케이션에서 익숙하게 보던 것과 동일한 즉시 로드 및 정기 업데이트를 제공할 수 있습니다.
이러한 기능을 최대한 활용하려면 웹사이트에 대한 새로운 사고방식, 즉 애플리케이션 셸 아키텍처가 필요합니다.
서비스 워커 증강 애플리케이션 셸 아키텍처를 사용하여 앱을 구성하는 방법을 자세히 알아보겠습니다. 클라이언트 측 렌더링과 서버 측 렌더링을 모두 살펴보고 지금 바로 사용해 볼 수 있는 엔드 투 엔드 샘플을 공유합니다.
이 점을 강조하기 위해 아래 예에서는 이 아키텍처를 사용하는 앱의 첫 번째 로드를 보여줍니다. 화면 하단에 '앱을 오프라인에서 사용할 수 있습니다'라는 토스트가 표시됩니다. 나중에 셸 업데이트를 사용할 수 있게 되면 사용자에게 새 버전을 새로고침하라고 알릴 수 있습니다.
서비스 워커란 무엇인가요?
서비스 워커는 웹페이지와 별개로 백그라운드에서 실행되는 스크립트입니다. 라우터는 제공하는 페이지에서 이루어진 네트워크 요청 및 서버의 푸시 알림을 비롯한 이벤트에 응답합니다. 서비스 워커는 의도적으로 짧은 수명을 갖습니다. 이벤트를 수신하면 깨어나고 이벤트를 처리해야 하는 동안만 실행됩니다.
또한 서비스 워커는 일반 탐색 컨텍스트의 JavaScript에 비해 제한된 API 집합을 보유하고 있습니다. 이는 웹의 작업자에 표준으로 적용됩니다. 서비스 워커는 DOM에 액세스할 수 없지만 Cache API와 같은 항목에 액세스할 수 있으며 Fetch API를 사용하여 네트워크 요청을 실행할 수 있습니다. IndexedDB API 및 postMessage()는 서비스 워커와 이 워커가 제어하는 페이지 간의 데이터 지속성 및 메시지 전송에도 사용할 수 있습니다. 서버에서 전송된 푸시 이벤트는 Notification API를 호출하여 사용자 참여도를 높일 수 있습니다.
서비스 워커는 페이지에서 이루어진 네트워크 요청 (서비스 워커에서 가져오기 이벤트를 트리거함)을 가로채고 네트워크에서 가져온 응답이나 로컬 캐시에서 가져온 응답 또는 프로그래매틱 방식으로 생성된 응답을 반환할 수 있습니다. 사실상 브라우저의 프로그래매틱 프록시입니다. 좋은 점은 응답의 출처와 관계없이 웹페이지에 서비스 워커가 관여하지 않은 것처럼 보입니다.
서비스 워커에 대해 자세히 알아보려면 서비스 워커 소개를 참고하세요.
성능 이점
서비스 워커는 오프라인 캐싱에 강력하지만 사이트 또는 웹 앱을 반복 방문할 때 즉시 로드되는 형태로 상당한 성능 향상도 제공합니다. 애플리케이션 셸을 캐시하여 오프라인에서 작동하도록 하고 JavaScript를 사용하여 콘텐츠를 채울 수 있습니다.
이렇게 하면 재방문 시 콘텐츠가 네트워크에서 가져온 것이더라도 네트워크 없이 화면에 의미 있는 픽셀을 표시할 수 있습니다. 툴바와 카드를 즉시 표시한 다음 나머지 콘텐츠를 점진적으로 로드한다고 생각하면 됩니다.
실제 기기에서 이 아키텍처를 테스트하기 위해 WebPageTest.org에서 애플리케이션 셸 샘플을 실행하고 아래에 결과를 표시했습니다.
테스트 1: Chrome Dev를 사용하여 Nexus 5로 케이블을 연결한 상태에서 테스트
앱의 첫 번째 뷰는 네트워크에서 모든 리소스를 가져와야 하며 1.2초가 지나야 의미 있는 페인트를 실행합니다. 서비스 워커 캐싱 덕분에 재방문 시 의미 있는 페인팅이 실행되고 0.5초 만에 완전히 로드됩니다.
테스트 2: Chrome 개발자를 사용하여 Nexus 5에서 3G로 테스트
약간 느린 3G 연결을 사용하여 샘플을 테스트할 수도 있습니다. 이번에는 첫 방문 시 유의미한 첫 페인트가 2.5초가 걸렸습니다. 페이지를 완전히 로드하는 데 7.1초가 걸립니다. 서비스 워커 캐싱을 사용하면 재방문 시 의미 있는 페인팅이 실행되고 0.8초 만에 완전히 로드됩니다.
다른 관점에서도 비슷한 결과를 확인할 수 있습니다. 애플리케이션 셸에서 유의미한 첫 페인트를 실행하는 데 걸리는 3초를 비교해 보세요.
서비스 워커 캐시에서 동일한 페이지를 로드할 때 걸리는 0.9초에 비해 최종 사용자의 시간이 2초 이상 절약됩니다.
애플리케이션 셸 아키텍처를 사용하는 자체 애플리케이션에서도 유사하고 안정적인 성능을 얻을 수 있습니다.
서비스 워커를 사용하려면 앱 구조를 다시 생각해야 하나요?
서비스 워커는 애플리케이션 아키텍처의 약간의 미묘한 변경사항을 의미합니다. 모든 애플리케이션을 HTML 문자열로 스쿼시하는 대신 AJAX 스타일로 작업하는 것이 유용할 수 있습니다. 여기에는 항상 캐시되고 네트워크 없이도 항상 부팅할 수 있는 셸과 정기적으로 새로고침되고 별도로 관리되는 콘텐츠가 있습니다.
이번 분할의 의미는 매우 큽니다. 첫 방문 시 서버에서 콘텐츠를 렌더링하고 클라이언트에 서비스 워커를 설치할 수 있습니다. 이후 방문 시에는 데이터를 요청하기만 하면 됩니다.
점진적 개선은 어떨까요?
현재 일부 브라우저에서만 서비스 워커를 지원하지만 애플리케이션 콘텐츠 셸 아키텍처는 점진적 개선을 사용하여 모든 사용자가 콘텐츠에 액세스할 수 있도록 합니다. 예를 들어 샘플 프로젝트를 살펴보겠습니다.
아래에서 Chrome, Firefox Nightly, Safari에서 렌더링된 전체 버전을 확인할 수 있습니다. 맨 왼쪽에는 서비스 워커 없이 서버에서 콘텐츠가 렌더링되는 Safari 버전이 표시됩니다. 오른쪽에는 서비스 워커를 사용하는 Chrome 및 Firefox Nightly 버전이 표시됩니다.
이 아키텍처를 사용해야 하는 경우는 언제인가요?
애플리케이션 셸 아키텍처는 동적인 앱과 사이트에 가장 적합합니다. 사이트가 작고 정적인 경우 애플리케이션 셸이 필요하지 않으며 서비스 워커 oninstall 단계에서 전체 사이트를 캐시하면 됩니다. 프로젝트에 가장 적합한 접근 방식을 사용하세요. 이미 많은 JavaScript 프레임워크에서 애플리케이션 로직을 콘텐츠에서 분리하도록 권장하고 있으므로 이 패턴을 더 간단하게 적용할 수 있습니다.
아직 이 패턴을 사용하는 프로덕션 앱이 있나요?
애플리케이션 셸 아키텍처는 전체 애플리케이션의 UI를 몇 가지만 변경하면 실행할 수 있으며 Google의 I/O 2015 프로그레시브 웹 앱 및 Google의 Inbox와 같은 대규모 사이트에 적합합니다.
오프라인 애플리케이션 셸은 성능 향상에 큰 도움이 되며 Jake Archibald의 오프라인 위키백과 앱과 Flipkart Lite의 프로그레시브 웹 앱에서도 잘 설명되어 있습니다.
아키텍처 설명
첫 로드 환경에서의 목표는 의미 있는 콘텐츠를 최대한 빨리 사용자 화면에 표시하는 것입니다.
첫 로드 및 다른 페이지 로드
일반적으로 애플리케이션 셸 아키텍처는 다음을 실행합니다.
초기 로드에 우선순위를 두되 서비스 워커가 애플리케이션 셸을 캐시하도록 하여 재방문 시 네트워크에서 셸을 다시 가져올 필요가 없도록 합니다.
나머지는 지연 로드 또는 백그라운드 로드합니다. 동적 콘텐츠에 읽기 전달 캐싱을 사용하는 것이 좋습니다.
정적 콘텐츠를 관리하는 서비스 워커를 안정적으로 캐시하고 업데이트하는 등 sw-precache와 같은 서비스 워커 도구를 사용합니다. sw-precache에 관해서는 나중에 자세히 설명하겠습니다.
이렇게 하려면 다음 단계를 따르세요.
서버는 클라이언트가 렌더링할 수 있는 HTML 콘텐츠를 전송하고, 먼 미래의 HTTP 캐시 만료 헤더를 사용하여 서비스 워커 지원이 없는 브라우저를 고려합니다. 해시를 사용하여 파일 이름을 제공하여 '버전 관리'와 애플리케이션 수명 주기 후반의 간편한 업데이트를 모두 지원합니다.
페이지는 문서
<head>내<style>태그에 인라인 CSS 스타일을 포함하여 애플리케이션 셸의 빠른 첫 번째 페인트를 제공합니다. 각 페이지는 현재 뷰에 필요한 JavaScript를 비동기식으로 로드합니다. CSS는 비동기식으로 로드할 수 없으므로 파서 기반의 동기식보다는 비동기식인 JavaScript를 사용하여 스타일을 요청할 수 있습니다.requestAnimationFrame()를 활용하여 빠른 캐시 히트가 발생하여 스타일이 실수로 중요한 렌더링 경로의 일부가 되는 경우를 방지할 수도 있습니다.requestAnimationFrame()는 스타일이 로드되기 전에 첫 번째 프레임을 강제로 페인트합니다. Filament Group의 loadCSS와 같은 프로젝트를 사용하여 JavaScript를 통해 CSS를 비동기식으로 요청하는 방법도 있습니다.서비스 워커는 애플리케이션 셸의 캐시된 항목을 저장하므로, 네트워크에서 업데이트를 사용할 수 없는 한 재방문 시 셸을 서비스 워커 캐시에서 완전히 로드할 수 있습니다.
실제 구현
애플리케이션 셸 아키텍처, 클라이언트용 기본 ES2015 JavaScript, 서버용 Express.js를 사용하여 완전히 작동하는 샘플을 작성했습니다. 물론 클라이언트 또는 서버 부분에 자체 스택 (예: PHP, Ruby, Python)을 사용할 수도 있습니다.
서비스 워커 수명 주기
애플리케이션 셸 프로젝트의 경우 다음과 같은 서비스 워커 수명 주기를 제공하는 sw-precache를 사용합니다.
| 이벤트 | 작업 |
|---|---|
| 설치 | 애플리케이션 셸 및 기타 단일 페이지 앱 리소스를 캐시합니다. |
| 활성화 | 오래된 캐시를 삭제합니다. |
| 가져오기 | URL에 단일 페이지 웹 앱을 제공하고 애셋 및 사전 정의된 부분에 캐시를 사용합니다. 다른 요청에는 네트워크를 사용합니다. |
서버 비트
이 아키텍처에서 서버 측 구성요소 (이 경우 Express로 작성됨)는 콘텐츠와 프레젠테이션을 별도로 처리할 수 있어야 합니다. 콘텐츠를 HTML 레이아웃에 추가하여 페이지를 정적 렌더링할 수도 있고 별도로 게재하여 동적으로 로드할 수도 있습니다.
서버 측 설정은 당사에서 데모 앱에 사용하는 설정과 크게 다를 수 있습니다. 이 웹 앱 패턴은 대부분의 서버 설정에서 실행할 수 있지만, 약간의 아키텍처 재구성이 필요합니다. 다음 모델이 효과적이라는 것을 확인했습니다.
엔드포인트는 사용자 대상 URL (색인/와일드 카드), 애플리케이션 셸 (서비스 워커), HTML 부분이라는 애플리케이션의 세 부분에 대해 정의됩니다.
각 엔드포인트에는 핸들바 레이아웃을 가져오는 컨트롤러가 있으며, 이 레이아웃은 핸들바 부분 뷰를 가져올 수 있습니다. 간단히 말해 부분은 최종 페이지에 복사되는 HTML 청크인 뷰입니다. 참고: 고급 데이터 동기화를 실행하는 JavaScript 프레임워크는 애플리케이션 셸 아키텍처로 더 쉽게 포팅할 수 있습니다. 부분 템플릿 대신 데이터 결합 및 동기화를 사용하는 경향이 있습니다.
사용자에게 처음에는 콘텐츠가 포함된 정적 페이지가 게재됩니다. 이 페이지는 지원되는 경우 애플리케이션 셸과 종속 항목 (CSS, JS 등)을 캐시하는 서비스 워커를 등록합니다.
그러면 앱 셸이 단일 페이지 웹 앱으로 작동하여 JavaScript를 사용하여 특정 URL의 콘텐츠에서 XHR을 실행합니다. XHR 호출은 /partials* 엔드포인트로 이루어지며, 이 엔드포인트는 콘텐츠를 표시하는 데 필요한 작은 HTML, CSS, JS 청크를 반환합니다. 참고: 이 문제에 접근하는 방법에는 여러 가지가 있으며 XHR은 그중 하나일 뿐입니다. 일부 애플리케이션은 초기 렌더링을 위해 데이터를 인라인 처리 (JSON을 사용할 수 있음)하므로 평면화된 HTML 의미에서 '정적'이 아닙니다.
서비스 워커 지원이 없는 브라우저에는 항상 대체 환경이 제공되어야 합니다. 이 데모에서는 기본 정적 서버 측 렌더링으로 대체하지만 이는 여러 옵션 중 하나에 불과합니다. 서비스 워커 측면을 사용하면 캐시된 애플리케이션 셸을 사용하여 단일 페이지 애플리케이션 스타일 앱의 성능을 개선할 수 있는 새로운 기회가 제공됩니다.
파일 버전 관리
파일 버전 관리 및 업데이트를 처리하는 방법이 문제로 떠오릅니다. 이는 애플리케이션별이며 옵션은 다음과 같습니다.
먼저 네트워크를 사용하고 그렇지 않으면 캐시된 버전을 사용합니다.
네트워크 전용이며 오프라인 상태에서는 실패합니다.
이전 버전을 캐시하고 나중에 업데이트합니다.
애플리케이션 셸 자체의 경우 서비스 워커 설정에 캐시 우선 접근 방식을 사용해야 합니다. 애플리케이션 셸을 캐시하지 않으면 아키텍처를 올바르게 채택하지 않은 것입니다.
도구
Google에서는 애플리케이션 셸을 미리 캐시하거나 일반적인 캐싱 패턴을 더 쉽게 설정할 수 있는 다양한 서비스 워커 도우미 라이브러리를 유지 관리합니다.
애플리케이션 셸에 sw-precache 사용
sw-precache를 사용하여 애플리케이션 셸을 캐시하면 파일 버전, 설치/활성화 질문, 앱 셸의 가져오기 시나리오와 관련된 문제를 처리할 수 있습니다. sw-precache를 애플리케이션의 빌드 프로세스에 배치하고 구성 가능한 와일드 카드를 사용하여 정적 리소스를 가져옵니다. 서비스 워커 스크립트를 수동으로 직접 만드는 대신 sw-precache가 캐시 우선 가져오기 핸들러를 사용하여 안전하고 효율적으로 캐시를 관리하는 스크립트를 생성하도록 합니다.
앱을 처음 방문하면 필요한 모든 리소스의 미리 캐싱이 트리거됩니다. 이는 앱 스토어에서 네이티브 앱을 설치하는 환경과 유사합니다. 사용자가 앱으로 돌아오면 업데이트된 리소스만 다운로드됩니다. 이 데모에서는 '앱 업데이트. 새로고침하여 새 버전을 확인하세요.' 이 패턴은 사용자에게 최신 버전으로 새로고침할 수 있다고 알리는 간단한 방법입니다.
런타임 캐싱에 sw-toolbox 사용
리소스에 따라 다양한 전략을 사용하여 런타임 캐싱에 sw-toolbox를 사용합니다.
이미지의 cacheFirst와 함께 N maxEntries의 맞춤 만료 정책이 있는 전용 이름이 지정된 캐시
원하는 콘텐츠 최신성에 따라 networkFirst 또는 API 요청의 경우 가장 빠른 속도 Fastest를 사용해도 되지만 자주 업데이트되는 특정 API 피드가 있는 경우 networkFirst를 사용하세요.
결론
애플리케이션 셸 아키텍처는 몇 가지 이점이 있지만 일부 애플리케이션 클래스에만 적합합니다. 이 모델은 아직 초기 단계이므로 이 아키텍처의 노력과 전반적인 성능 이점을 평가하는 것이 좋습니다.
실험에서는 클라이언트와 서버 간의 템플릿 공유를 활용하여 두 애플리케이션 레이어를 빌드하는 작업을 최소화했습니다. 이를 통해 점진적 개선이 여전히 핵심 기능으로 남아 있습니다.
이미 앱에서 서비스 워커를 사용하고자 하는 경우 아키텍처를 살펴보고 자체 프로젝트에 적합한지 평가하세요.
검토자: 제프 포스닉, 폴 루이스, 알렉스 러셀, 세스 톰슨, 롭 도슨, 테일러 새비지, 조 미들리님, 감사합니다.