이 문서에서는 이전에 사전 캐싱을 다루었지만 이를 올바르게 수행하는 방법에 대해서는 충분하지 않습니다. 이 작업이 중요합니다. 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에 해당 자산을 제외하고 이를 처리할 런타임 캐싱 경로를 생성하도록 지시하는 것이 가장 좋습니다. 어느 쪽이든 사전 캐싱은 이 문서의 뒷부분에서 자세히 설명하므로 향후 사전 캐싱 로직에 이 원칙을 적용할 수 있습니다.