이 문서에서는 이전에 사전 캐싱을 다루었지만 올바르게 처리하는 방법에 대해서는 충분히 다루지 않았습니다. Workbox 사용 여부에 상관없이, 사전 캐시가 너무 많아 데이터와 대역폭이 낭비될 가능성이 높기 때문에 이것이 중요합니다. 사전 캐싱 페이로드가 사용자 환경에 미치는 영향에 주의를 기울여야 합니다.
이 문서를 읽고 있을 경우 일반적인 가이드라인이라는 점을 유념하시기 바랍니다. 애플리케이션 아키텍처 및 요구사항에 따라 여기에 제안된 것과 다른 작업을 수행해야 할 수도 있지만 이러한 가이드라인이 좋은 기본값 역할을 합니다.
권장사항: 중요한 정적 자산 사전 캐시
가장 좋은 사전 캐싱 후보는 중요한 정적 자산이지만, '중요' 자산으로 간주되는 것은 무엇인가요? 개발자의 관점에서는 전체 애플리케이션을 '중요'하다고 생각하고 싶을 수 있지만, 가장 중요한 것은 사용자의 관점입니다. 중요한 애셋은 사용자 환경을 제공하는 데 절대적으로 필요한 애셋이라고 생각하면 됩니다.
- 전역 스타일시트.
- 전역 기능을 제공하는 JavaScript 파일입니다.
- 애플리케이션 셸 HTML(아키텍처에 적용되는 경우)
주의: 다음은 일반적인 가이드라인이며 엄격한 권장사항이 아닙니다. 애셋을 사전 캐싱할 때는 적당히 사전 캐싱하는 것이 좋습니다.
권장사항: 다중 페이지 웹사이트의 오프라인 대체를 사전 캐시
일반적인 멀티 페이지 웹사이트의 경우 탐색 요청을 처리하기 위해 네트워크 우선 또는 네트워크 전용 캐싱 전략을 사용할 수 있습니다.
이러한 경우, 사용자가 오프라인일 때 탐색을 요청할 때 서비스 워커가 사전 캐시하고 오프라인 대체 페이지로 응답하도록 해야 합니다. Workbox에서 이를 수행하는 한 가지 방법은 오프라인 대체와 함께 네트워크 전용 전략을 사용하여 탐색 미리 로드도 활용하는 것입니다.
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
이렇게 하면 사용자가 오프라인으로 전환되어 캐시에 없는 페이지로 이동하는 경우에도 일부 오프라인 콘텐츠를 얻게 됩니다.
할 수도 있습니다: 추측에 기반한 사전 캐싱
그건 "어쩌면" 그러나 특정 시나리오에서만 사용되는 애셋을 미리 캐시하면 잠재적인 이점이 있습니다. 이런 식으로 생각해 보세요. 사용자는 사전 데이터 다운로드가 추가로 발생하게 되며, 이러한 자산에 대한 향후 요청을 가속화하는 추측에 의한 이점을 얻게 됩니다.
주의사항은 매우 신중해야 한다는 것입니다. 이렇게 하면 데이터를 낭비하기 쉬우며 데이터 기반 의사 결정을 내려야 합니다. 또한 자주 변경되는 애셋을 추측하여 사전 캐싱하지 마세요. 사전 캐싱 코드가 새 버전을 감지할 때마다 사용자가 추가 데이터 사용량을 사용하게 됩니다. 애널리틱스에서 사용자 흐름을 관찰하여 사용자가 이동하는 경향이 있는 위치를 확인하세요. 추측에 기반하여 자산을 사전 캐싱하는 것이 의심스럽다면 그렇게 하지 않는 좋은 신호일 수 있습니다.
금지: 정적 HTML을 사전 캐시
이 가이드라인은 개별 HTML 파일이 동적으로 생성되거나 애플리케이션 백엔드에 의해 제공되는 것이 아니라 정적 사이트 생성기에 의해 생성되거나 수동으로 생성되는 정적 사이트에 더 적용됩니다. 이것이 아키텍처에 해당하는 경우 웹사이트의 모든 HTML 파일을 사전 캐시하지 않는 것이 가장 좋습니다.
전체 사이트의 HTML 파일을 미리 캐시할 때 발생하는 한 가지 문제는 현재 사전 캐시된 마크업이 서비스 워커가 업데이트될 때까지 나중에 항상 캐시에서 제공된다는 점입니다. 이는 성능에는 좋지만 웹사이트의 HTML이 자주 변경되는 경우 심각한 캐시 급변이 발생할 수 있습니다.
하지만 이 규칙에는 몇 가지 예외가 있습니다. 정적 HTML 파일 몇 개가 포함된 소규모 웹사이트를 배포하는 경우 이러한 페이지를 모두 미리 캐시하여 오프라인에서 사용할 수 있도록 하는 것이 좋습니다. 유난히 큰 웹사이트의 경우 중요도가 높은 몇 개의 페이지와 오프라인 대체를 예측적으로 사전 캐싱해 보고, 런타임 캐싱을 통해 다른 페이지를 캐시합니다.
하지 말아야 할 일: 반응형 이미지 또는 파비콘 사전 캐시
이 방법은 일반적인 가이드라인이라기보다는 규칙에 가깝습니다. 반응형 이미지는 복잡한 문제를 해결하기 위한 복잡한 솔루션입니다. 화면 크기, 픽셀 밀도, 대체 형식 지원 등 다양한 기기를 사용하는 사용자가 많기 때문입니다. 반응형 이미지 전체 세트를 사전 캐시한다면 사용자가 결국 이미지 중 하나만 다운로드하게 될 수도 있는 상황에서 여러 이미지를 사전 캐시하게 될 수 있습니다.
파비콘 역시 유사한 상황을 보여주며, 웹사이트에서 다양한 시나리오에 맞게 전체 파비콘을 배포하는 경우가 많습니다. 대부분의 경우 하나의 파비콘만 요청되므로 전체 파비콘 세트를 미리 캐시하는 것은 마찬가지로 낭비입니다.
사용자를 위해 반응형 이미지와 파비콘 세트를 사전 캐시하지 않습니다. 런타임 캐싱을 사용하세요. 이미지를 사전 캐시해야 하는 경우, 반응형 이미지 또는 파비콘 세트의 일부가 아닌 널리 사용되는 이미지를 사전 캐시하세요. SVG는 데이터 사용 측면에서 위험성이 적으며, 주어진 화면의 픽셀 밀도와 상관없이 단일 SVG가 최적으로 렌더링됩니다.
금지사항: 폴리필 사전 캐시
API에 대한 다양한 브라우저 지원은 웹 개발자에게 있어 지속적인 과제이며, 폴리필은 이러한 문제를 해결하는 방법 중 하나입니다. 폴리필의 성능 비용을 최소화하는 한 가지 방법은 기능 검사를 수행하고 폴리필이 필요한 브라우저에만 폴리필을 로드하는 것입니다.
조건부로 폴리필을 로드하는 것은 현재 환경과 관련하여 런타임 중에 발생하므로, 폴리필을 사전 캐싱하는 것은 쉽지 않습니다. 일부 사용자는 이점을 누릴 수 있지만 다른 사용자는 불필요한 폴리필을 위해 대역폭을 낭비하게 됩니다.
폴리필을 사전 캐시하지 않습니다. 데이터 낭비를 방지해야 하는 브라우저에서만 캐시되도록 런타임 캐싱을 사용합니다.
결론
사전 캐싱에는 사용자에게 실제로 필요한 자산이 사전에 미리 고려되어야 하지만, 향후 성능과 안정성에 우선순위를 두는 방식으로 제대로 할 수 있습니다.
특정 애셋을 사전 캐시해야 하는지 잘 모르겠다면 가장 좋은 방법은 해당 애셋을 제외하고 이를 처리할 런타임 캐싱 경로를 만들도록 Workbox에 지시하는 것입니다. 어느 쪽이든 프리캐싱에 대해서는 이 문서의 뒷부분에서 자세히 다루므로 나중에 사전 캐싱 로직에 이 원칙을 적용할 수 있습니다.