Google I/O를 시청해 주셔서 감사합니다. 주문형 콘텐츠를 확인하세요.

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

미리 가져오기, 사전 렌더링, 서비스 워커 사전 캐싱

지난 몇 개의 모듈에서는 자바스크립트 로드 지연, 이미지 지연 로드 및 <iframe> 요소와 같은 개념을 알아봤습니다. 리소스 로드를 연기하면 잠재적으로 사용되지 않을 수 있는 리소스를 미리 로드하는 대신 필요한 시점에 리소스를 다운로드하여 초기 페이지 로드 중 네트워크 및 CPU 사용량이 줄어듭니다. 이렇게 하면 초기 페이지 로드 시간이 단축될 수 있지만, 후속 상호작용에서 페이지 로드에 필요한 리소스가 지금도 로드되지 않은 경우 지연이 발생할 수 있습니다.

예를 들어 페이지에 맞춤 날짜 선택 도구가 포함된 경우 사용자가 요소와 상호작용할 때까지 날짜 선택 도구의 리소스를 연기할 수 있습니다. 그러나 요청 시 날짜 선택 도구의 리소스를 로드하면 리소스가 다운로드되고 파싱되고 실행에 사용 가능해질 때까지 약간 지연될 수 있습니다. 사용자의 네트워크 연결, 기기 기능 또는 둘 다에 따라 다를 수 있습니다.

이는 약간 까다로운 균형입니다. 사용되지 않을 수 있는 리소스를 로드하여 대역폭을 낭비하고 싶지는 않지만 상호작용 및 후속 페이지 로드를 지연하는 것도 이상적이지 않을 수 있습니다. 다행히 이 두 가지 극단적 사이에서 더 나은 균형을 이루는 데 사용할 수 있는 도구가 많이 있습니다. 이 모듈에서는 리소스 미리 가져오기, 전체 페이지 사전 렌더링, 서비스 워커를 사용한 리소스 사전 캐싱 등 유용한 몇 가지 기법을 다룹니다.

가까운 미래에 필요한 리소스를 낮은 우선순위로 미리 가져오기

<link rel="prefetch"> 리소스 힌트를 사용하여 이미지, 스타일시트, 자바스크립트 리소스를 포함한 리소스를 사전에 가져올 수 있습니다. prefetch 힌트는 가까운 미래에 리소스가 필요할 가능성이 높다고 브라우저에 알립니다.

prefetch 힌트가 지정되면 브라우저는 현재 페이지에 필요한 리소스와 경합하지 않도록 가장 낮은 우선순위로 해당 리소스에 대한 요청을 시작할 수 있습니다.

참고: prefetch 리소스 힌트는 그저 힌트일 뿐입니다. 브라우저는 네트워크 품질, 시스템 수준 환경설정 또는 기타 요소에 관한 일련의 조건을 기반으로 prefetch 힌트를 적용할지 여부를 결정할 수 있습니다.

리소스를 미리 가져오면 사용자 환경이 개선될 수 있습니다. 사용자는 필요한 시점에 디스크 캐시에서 즉시 검색할 수 있기 때문에 가까운 미래에 필요한 리소스가 다운로드될 때까지 기다릴 필요가 없기 때문입니다.

<head>
  <!-- ... -->
  <link rel="prefetch" as="script" href="/date-picker.js">
  <link rel="prefetch" as="style" href="/date-picker.css">
  <!-- ... -->
</head>

위의 HTML 스니펫은 유휴 상태일 때 date-picker.js 및 date-picker.css를 미리 가져올 수 있음을 브라우저에 알립니다. 사용자가 JavaScript로 페이지와 상호작용할 때 리소스를 동적으로 미리 가져올 수도 있습니다.

prefetch은 플래그 뒤에서 사용할 수 있는 Safari를 제외한 모든 최신 브라우저에서 지원됩니다. 모든 브라우저에서 작동하는 방식으로 웹사이트의 리소스를 선제적으로 로드해야 하고 서비스 워커를 사용 중인 경우 이 모듈의 뒷부분에서 서비스 워커를 사용하여 리소스 미리 캐싱에 관한 내용을 읽어보세요.

향후 탐색 속도를 높이기 위해 페이지 미리 가져오기

HTML 문서를 가리킬 때 as="document" 속성을 지정하여 페이지 및 페이지의 모든 하위 리소스를 미리 가져올 수도 있습니다.

<link rel="prefetch" href="/page" as="document">

브라우저가 유휴 상태이면 /page에 대해 낮은 우선순위 요청을 시작할 수 있습니다.

중요: 일반적으로 <link rel="prefetch">를 사용하여 교차 출처 문서를 미리 가져오지 않는 것이 좋습니다. 중복 요청을 일으키는 교차 출처 문서 미리 가져오기와 관련된 미해결 문제가 있습니다. 또한 맞춤설정된 동일 출처 문서(예: 인증된 세션에 대해 동적으로 생성되는 HTML 응답)를 미리 가져오지 않아야 합니다. 이러한 리소스는 일반적으로 캐시되지 않으며 사용되지 않아 결국 대역폭을 낭비할 가능성이 높기 때문입니다.

Chromium 기반 브라우저에서는 Speculation Rules API를 사용하여 문서를 미리 가져올 수 있습니다. 추측 규칙은 페이지의 HTML에 포함되거나 자바스크립트를 통해 동적으로 추가되는 JSON 객체로 정의됩니다.

<script type="speculationrules">
{
  "prefetch": [{
    "source": "list",
    "urls": ["/page-a", "/page-b"]
  }]
}
</script>

JSON 객체는 하나 이상의 작업(현재 prefetch 및 prerender만 지원)과 해당 작업과 연결된 URL 목록을 설명합니다. 위의 HTML 스니펫에서 브라우저는 /page-a 및 /page-b를 미리 가져오도록 지시합니다. <link rel="prefetch">와 마찬가지로 예측 규칙은 브라우저가 특정 상황에서 무시할 수 있는 힌트입니다.

참고: <link rel="prefetch">는 리소스를 미리 가져와 HTTP 캐시에 저장하는 반면, 예측 규칙을 사용하여 로드된 미리 가져오기는 처리되어 메모리 캐시에 저장되므로 필요할 때 더 빠르게 검색할 수 있습니다.

빠른 링크와 같은 라이브러리는 사용자의 표시 영역에 표시된 페이지 링크를 동적으로 미리 가져오거나 사전 렌더링하여 페이지 탐색을 개선합니다. 이렇게 하면 페이지의 모든 링크를 미리 가져오는 것과 달리 사용자가 최종적으로 해당 페이지로 이동할 가능성이 높아집니다.

페이지 사전 렌더링

리소스를 미리 가져오는 것 외에도 사용자가 페이지로 이동하기 전에 페이지를 사전 렌더링하도록 브라우저에 힌트를 둘 수도 있습니다. 이렇게 하면 백그라운드에서 페이지와 리소스를 가져와 처리하므로 거의 즉각적인 페이지 로드를 제공할 수 있습니다. 사용자가 페이지로 이동하면 페이지가 포그라운드에 배치됩니다.

사전 렌더링은 Speculation Rules API를 통해 지원됩니다.

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/page-a", "page-b"]
    }
  ]
}
</script>

참고: Chrome에서는 <link rel="prerender" href="/page"> 리소스 힌트도 지원합니다. 하지만 Chrome 63부터는 페이지를 렌더링하고 자바스크립트를 실행하는 대신 페이지에 필요한 리소스를 가져오는 NoState Prefetch가 시작됩니다.

미리 가져오기 및 사전 렌더링 데모

서비스 워커 사전 캐싱

서비스 워커를 사용하여 리소스를 추측하여 미리 가져올 수도 있습니다. 서비스 워커 사전 캐싱은 Cache API를 사용하여 리소스를 가져오고 저장할 수 있으므로 브라우저에서 네트워크로 이동하지 않고도 Cache API를 사용하여 요청을 처리할 수 있습니다. 서비스 워커 사전 캐싱은 캐시 전용 전략이라고 하는 매우 효과적인 서비스 워커 캐싱 전략을 사용합니다. 이 패턴은 리소스가 서비스 워커 캐시에 배치되면 요청 시 거의 즉시 리소스를 가져오기 때문에 매우 효과적입니다.

페이지에서 서비스 워커 및 캐시로의 서비스 워커 캐싱 흐름을 보여줍니다. — 캐시 전용 전략은 서비스 워커를 설치하는 동안 네트워크에서 사용 가능한 리소스만 가져옵니다. 설치 후에는 캐시된 리소스를 서비스 워커 캐시에서만 검색할 수 있습니다.

서비스 워커를 사용하여 리소스를 사전 캐시하려면 Workbox를 사용하면 됩니다. 하지만 원하는 경우 직접 코드를 작성하여 미리 결정된 파일 집합을 캐시할 수 있습니다. 어떤 경우든 서비스 워커를 사용하여 리소스를 사전 캐시하기로 결정했다면 서비스 워커가 설치될 때 사전 캐싱이 발생한다는 점을 아는 것이 중요합니다. 설치 후 사전 캐시된 리소스는 웹사이트에서 서비스 워커가 제어하는 모든 페이지에서 가져올 수 있습니다.

Workbox는 사전 캐시 매니페스트를 사용하여 사전 캐시되어야 하는 리소스를 결정합니다. 사전 캐시 매니페스트는 사전 캐시될 리소스의 '정보 소스' 역할을 하는 파일 및 버전 관리 정보의 목록입니다.

[{  
    url: 'script.ffaa4455.js',
    revision: null
}, {
    url: '/index.html',
    revision: '518747aa'
}]

위의 코드는 script.ffaa4455.js 및 /index.html, 이렇게 두 개의 파일을 포함하는 매니페스트의 예시입니다. 리소스가 파일 자체에 버전 정보를 포함하는 경우 (파일 해시라고 함) 파일의 버전이 이미 지정되었으므로 revision 속성을 null로 남겨둘 수 있습니다 (예: 앞의 코드에서 script.ffaa4455.js 리소스의 경우 ffaa4455). 버전이 지정되지 않은 리소스의 경우 빌드 시간에 버전을 생성할 수 있습니다.

설정하고 나면 서비스 워커를 사용해 정적 페이지나 하위 리소스를 사전 캐시하여 후속 페이지 탐색 속도를 높일 수 있습니다.

workbox.precaching.precacheAndRoute([
  '/styles/product-page.ac29.css',
  '/styles/product-page.39a1.js',
]);

예를 들어 전자상거래 제품 등록정보 페이지에서 서비스 워커를 사용하면 제품 세부정보 페이지를 렌더링하는 데 필요한 CSS 및 자바스크립트를 사전 캐시할 수 있으므로 제품 세부정보 페이지로 훨씬 빠르게 이동할 수 있습니다. 앞의 예에서는 product-page.ac29.css와 product-page.39a1.js가 사전 캐시됩니다. workbox-precaching에서 사용할 수 있는 precacheAndRoute 메서드는 필요할 때마다 사전 캐시된 리소스를 서비스 워커 API에서 가져오는 데 필요한 핸들러를 자동으로 등록합니다.

서비스 워커가 널리 지원되므로 필요한 최신 브라우저에서 미리 캐싱하는 서비스 워커를 사용할 수 있습니다.

서비스 워커와 HTTP 캐시에서 사용하는 Cache 인터페이스는 동일하지 않습니다. Cache 인터페이스는 자바스크립트로 제어되는 상위 수준 캐시이고, HTTP 캐시는 Cache-Control 헤더로 제어되는 하위 수준 캐시입니다.

리소스 힌트 또는 예측 규칙을 사용하여 리소스를 미리 가져오거나 사전 렌더링하는 것과 마찬가지로 서비스 워커 사전 캐싱은 네트워크 대역폭, 저장용량, CPU를 사용합니다. 사용할 가능성이 높은 리소스만 사전 캐시하고 사전 캐시 매니페스트에 너무 많은 리소스를 지정하는 것이 좋습니다. 확실하지 않은 경우에는 너무 적게 미리 캐시하고, 런타임 캐싱을 통해 다양한 패턴 중 하나를 사용하여 서비스 워커 캐시를 채우며 속도와 리소스의 최신 상태를 유지하는 것이 좋습니다. 리소스를 사전 캐싱할 때 수행해야 할 작업과 하지 말아야 할 작업에 대한 자세한 내용은 사전 캐싱 권장사항 및 금지사항을 참조하세요.

학습한 내용 테스트

prefetch 힌트는 어떤 우선순위로 발생하나요?

높음.

다시 시도해 보세요.

보통

다시 시도해 보세요.

낮음.

정답입니다.

페이지 미리 가져오기와 사전 렌더링의 차이점은 무엇인가요?

페이지의 미리 가져오기와 사전 렌더링은 모두 페이지 및 모든 하위 리소스를 가져오는 반면, 미리 가져오기는 페이지와 페이지의 모든 리소스만 가져오는 반면, 사전 렌더링은 사용자가 이동할 때까지 전체 페이지를 백그라운드에 렌더링하여 한 단계 더 이동합니다.

정답입니다.

거의 동일합니다. 사전 렌더링만 페이지의 모든 하위 리소스를 가져오는 반면 미리 가져오기는 가져오지 않습니다.

다시 시도해 보세요.

서비스 워커 캐시와 HTTP 캐시가 동일합니다.

참

다시 시도해 보세요.

거짓

정답입니다.

다음: 웹 작업자 개요

이제 향후 페이지로의 탐색 속도를 높일 때 미리 가져오기, 사전 렌더링, 서비스 워커 사전 캐싱이 얼마나 유용한지 알았으므로 이를 통해 웹사이트와 사용자에게 어떻게 유익한지 결정할 수 있습니다.

다음으로 웹 작업자의 개요를 살펴보고, 웹 작업자가 기본 스레드에서 비용이 많이 드는 작업을 없애고 기본 스레드에 사용자 상호작용을 위한 공간을 더 많이 확보하는 방법을 알아봅니다. 기본 스레드에 대기 공간을 더 많이 제공하기 위해 무엇을 할 수 있는지 궁금하다면 다음 두 모듈을 시간을 할애해 보세요.