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

캐시가 마음에 드네요 ❤️

사이트를 두 번 로드하는 사용자는 HTTP 캐시를 사용하므로 그것은 잘 작동합니다.

Sam Thorogood

이 게시물은 확장판의 일부인 캐시 유지하기 동영상의 컴패니언입니다 Chrome Dev Summit 2020의 콘텐츠. 다음 동영상도 확인해 보세요.

사용자가 사이트를 두 번 로드할 때 브라우저는 HTTP 캐시를 통해 로드 속도를 높입니다. 그러나 네트워크상에서 캐싱에 대한 표준은 1999년으로 거슬러 올라갑니다. 이들은 상당히 광범위하게 정의되어 있습니다. CSS 또는 이미지와 같은 파일을 네트워크에서 다시 가져올 수 있는지 여부 캐시에서 로드하는 것은 약간 부정확한 과학입니다.

이 게시물에서는 합리적이고 현대적인 캐싱 기본 사항에 대해 이야기하겠습니다. 실제로는 캐싱을 전혀 수행하지 않습니다. 하지만 이것은 기본값일 뿐이며 '사용 중지'하는 것보다 더 미묘한 차이를 보겠습니다. 꼭 확인해 보세요.

목표

사이트가 두 번째로 로드되는 경우 두 가지 목표가 있습니다.

사용자가 최신 버전을 사용하도록 합니다. 뭔가를 변경한 경우 해당 내용이 즉시 반영되어야 합니다.
네트워크에서 가능한 한 적게 가져오기 #1 수행

넓은 의미에서, 고객에게 가장 작은 변경 사항만 전송하는 것이 좋습니다. 광고를 다시 게재할 수 있습니다. 그리고 사이트에서 가장 우수한 실적을 변경사항을 효율적으로 배포하는 것은 어렵습니다 (자세한 내용은 아래 및 합니다.

하지만 캐싱을 고려할 때 다른 손잡이도 있습니다. 사용자의 브라우저의 HTTP 캐시가 네트워크 요청이 전혀 필요하지 않습니다. 또는 서비스 워커를 만들어 다른 사람이 어떤 작업을 할 수 있는지 확인해야 합니다. 이는 극단적인 옵션으로, 유효하며 앱과 같은 오프라인 중심의 많은 웹 환경에서 사용할 수 있지만, 그렇다고 해서 캐시 전용 극단에서, 심지어 완전히 네트워크 전용 극단까지도 할 수 있습니다.

배경

웹 개발자인 우리 모두는 '오래된 캐시'가 있다는 개념에 익숙합니다. 하지만 본능적으로 이 문제를 해결하는 데 사용할 수 있는 도구가 있다는 것을 알고 있습니다. 시크릿 창을 열거나, 브라우저 브라우저 및 Chrome 웹 브라우저에서 개발자 도구를 사용하여 사이트 데이터를 지울 수도 있습니다.

인터넷을 이용하는 일반 사용자들은 이러한 고급스러움을 누릴 수 없습니다. 따라서 핵심 목표가 몇 가지 있습니다. 또한 나쁜 시간이 발생하지 않도록 하는 것이 매우 중요합니다. 문제가 있습니다. (Google Ad Manager에 대한 자세한 설명을 듣고 싶다면 web.dev/live 사이트가 멈출 뻔 했습니다!)

배경 설명을 들자면, '캐시 비활성'이 발생하는 일반적인 이유는 다음과 같습니다. 실제로는 캐싱에 대한 1999년 기본값입니다. Last-Modified 헤더를 사용합니다.

사용자의 브라우저에서 다양한 애셋이 캐시되는 기간을 보여주는 다이어그램 — 여러 시간에 생성된 확장 소재 (회색)가 다음 기간 동안 캐시됩니다. 두 번째 로드 시 캐시된 애셋과 최신 애셋의 조합을 가져올 수 있음

로드하는 모든 파일은 브라우저에서 볼 수 있습니다. 예를 들어 index.html가 1개월 전에 생성되었다면 약 3일 동안 브라우저에 의해 캐시됩니다.

당시에는 선의의 아이디어였지만 오늘날 웹사이트의 특성이 통합되어 있기 때문에 이러한 기본 동작이 사용자가 여러 버전의 웹사이트 (예: 화요일에 출시된 JS, 금요일에 출시된 CSS는 릴리스)이 될 수 있습니다. 해당 파일이 정확히 동시에 업데이트되지 않았기 때문입니다.

조명이 밝은 길

최신 캐싱 기본값은 실제로 캐싱을 하지 않고 콘텐츠 제공을 위한 CDN . 사용자는 사이트를 로드할 때마다 네트워크로 이동하여 최신 버전인지 확인할 수 있습니다 이 요청은 지연 시간이 짧습니다. 지리적으로 각 최종 사용자와 가까운 CDN에서 제공됩니다

다음 헤더로 웹 요청에 응답하도록 웹 호스트를 구성할 수 있습니다.

Cache-Control: max-age=0,must-revalidate,public

기본적으로 다음과 같습니다. 파일이 유효하지 않으며 다시 사용할 수 있기 전에 네트워크에서 데이터를 삭제해야 하며, 그러지 않으면 'suggested').

참고: max-age=0,must-revalidate 대신 no-cache를 지정할 수도 있습니다. 이는 동일합니다. 하지만 no-cache은 '이 파일을 캐시하지 않음'으로 해석될 수 있지만 그렇지 않은 경우에도 혼동을 야기하는 이름입니다. 읽기가 많은 경우에는 MDN의 Cache-Control을 참조하세요.

이 유효성 검사 프로세스는 전송되는 바이트 수가 비교적 저렴합니다. 큰 이미지 파일이 변경되지 않은 경우 브라우저에 작은 304 하지만 사용자가 해당 응답을 찾으려면 여전히 네트워크로 이동해야 하므로 지연 시간이 발생합니다. 있습니다. 그리고 이것이 이 접근 방식의 가장 큰 단점입니다. 그것은 매우 잘 작동할 수 있습니다 빠르게 연결할 수 있으며 선택한 CDN이 인터넷 속도가 느린 사용자에게 적합하지 않습니다. 빈약한 인프라를 사용할 수 있습니다.

그럼에도 불구하고, 이 방법은 널리 사용되는 CDN인 Netlify의 기본값 거의 모든 CDN에서 구성할 수 있습니다. Firebase 호스팅의 경우 다음을 포함할 수 있습니다. 이 헤더 호스팅 섹션에서 다음과 같습니다.

"headers": [
  // Be sure to put this last, to not override other headers
  {
    "source": "**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=0,must-revalidate,public"
    }
  }
]

따라서 지금도 합리적인 기본값으로 제안하기는 하지만, 그것은 단지 기본값일 뿐입니다. 계속 읽고 기본값을 업그레이드하는 방법을 알아보세요.

지문 인식 URL

애셋, 이미지 등의 이름에 파일 콘텐츠의 해시를 포함 모든 광고 소재에 대해 이러한 파일이 항상 고유한 예를 들어 sitecode.af12de.js라는 파일이 생성됩니다. 날짜 응답하므로 이렇게 하면 최종 사용자의 브라우저에서 헤더:

Cache-Control: max-age=31536000,immutable

이 값은 연도(초)입니다. 사양에 따르면 이는 '영원'과 같습니다

이러한 해시를 직접 생성하지 마세요. 너무 많은 수동 작업이 필요합니다. 나 에서 Webpack, Rollup 등의 도구를 사용하여 이 작업을 수행할 수 있습니다. 반드시 도구 보고서에서 이에 관해 자세히 알아보세요.

지문 인식 URL의 이점을 누릴 수 있는 것은 JavaScript만이 아닙니다. 아이콘, CSS 및 기타 불변 데이터 파일과 같은 자산의 이름을 있습니다. (코드에 대해 좀 더 자세히 알아보려면 위의 동영상을 시청하세요. 사이트를 변경할 때마다 더 적은 수의 코드를 제공할 수 있습니다.)

참고: 위의 Cache-Control 추천에 immutable 키워드가 포함되어 있습니다. 이 키워드가 없으면 긴 Cache-Control는 추천 단어로만 간주되며 일부 브라우저는 여전히 이를 무시하고 서버로 이동합니다. (2017년에 Chrome은 동작을 변경하여 항상 변경 불가능한 키워드가 사용 설정된 것처럼 작동하므로 지금은 Safari와 Firefox에만 필요합니다.)

사이트가 캐싱에 접근하는 방식에 관계없이, 이러한 종류의 지문 파일은 파일은 빌드하는 모든 사이트에 매우 중요합니다. 대부분의 사이트는 항상 변경되는 것은 아닙니다

물론 사용자에게 표시되는 '친숙한' 페이지의 이름을 변경할 수는 없습니다. index.html 파일을 index.abcd12.html에 전송하는 것은 불가능합니다. 사용자가 사이트를 로드할 때마다 새 URL로 이동하도록 유도합니다. 이러한 '친절한' URL 이렇게 하면 이름을 바꾸고 캐시할 수 없으므로 지상입니다.

중간층

캐싱의 경우 분명 중간 정도의 공간이 있습니다. 나는 두 가지 극단적인 옵션을 제시했고 캐시 없음 또는 영구 캐시합니다. 그리고 다음과 같이 한 시간 동안 캐시하려는 파일의 개수입니다. '친절함' URL을 입력합니다.

이러한 '친구'를 캐시하고 싶다면 URL과 해당 HTML의 어떤 종속 항목이 포함되는지, 캐시될 수 있는 방법 및 URL을 한동안 캐싱하는 것이 영향을 받을 수 있습니다. 인코더-디코더 아키텍처를 생성한 에는 다음과 같은 이미지가 포함됩니다.

<img src="/images/foo.jpeg" loading="lazy" />

이 지연 로드를 삭제하거나 변경하여 사이트를 업데이트하거나 변경하는 경우 사용자는 HTML의 캐시된 버전을 보는 사용자는 잘못된 정보나 - 원본 이미지를 /images/foo.jpeg 캐시했기 때문입니다. 다시 방문하는 것입니다.

주의하면 영향을 받지 않을 수 있습니다. 그러나 전반적으로 최종 사용자가 캐시하면 해당 사이트는 더 이상 구성할 수 있습니다 최종 사용자의 Google Cloud 프로젝트 캐시 안에 있는 부분에 있습니다.

일반적으로 캐싱에 관한 대부분의 가이드는 이러한 종류의 1시간, 몇 시간 등으로 캐시할지 여부를 결정합니다. 설정 방법 3600초 동안 캐시하는 이와 같은 헤더를 사용하거나 시간):

Cache-Control: max-age=3600,immutable,public

마지막으로 한 가지 더 있습니다. 시의적절한 콘텐츠를 제작한다면 일반적으로 뉴스 기사처럼 사용자가 액세스하면 안 된다고 생각합니다. 캐시되므로 위의 적절한 기본값을 사용해야 합니다. 우리는 종종 항상 최신 뷰를 보고자 하는 사용자의 욕구보다 캐싱의 가치를 과대평가하세요 뉴스 기사나 최근 사건에 대한 비판적인 업데이트와 같은 이벤트를 처리합니다.

HTML이 아닌 옵션

HTML 외에 중간 위치에 게재되는 파일을 위한 몇 가지 다른 옵션 포함:

일반적으로 다른 애셋에 영향을 미치지 않는 애셋을 찾습니다.
- 예를 들어 CSS를 사용하면 HTML의 렌더링됨
시기적절한 기사의 일부로 사용되는 큰 이미지
- 사용자는 기사를 하나도 방문하지 않을 것입니다. 너무 많기 때문에 사진이나 히어로 이미지를 영원히 간직하지 마세요. 폐기물 저장
그 자체로 수명이 있는 것을 나타내는 애셋
- 날씨에 대한 JSON 데이터는 매시간 게시될 수도 있으므로 이전 결과를 한 시간 동안 캐시할 수 있으며 창에 변경되지 않습니다.
- 오픈소스 프로젝트의 빌드에는 속도가 제한될 수 있으므로 상태가 변경될 수 있으므로 빌드 상태 이미지를

요약

사용자가 사이트를 두 번째로 로드하면 이미 이들은 다시 돌아와 여러분이 제공하는 것을 더 많이 얻기를 원합니다. 이 시간 항상 로드 시간을 줄이는 것만이 아니고 사용할 수 있는 다양한 옵션이 추가되어 빠르고 최신 환경을 제공해야 합니다

캐싱은 웹에서 새로운 개념은 아니지만 기본: 캐싱 전략을 개선하기 위해 한 가지를 사용하고 강력하게 선택하는 것이 좋습니다. 활용할 수 있습니다 읽어주셔서 감사합니다.

참고 항목

HTTP 캐시에 대한 일반적인 가이드는 HTTP 캐시로 불필요한 네트워크 요청을 방지합니다.