웹 캐싱 기본 사항: 용어, HTTP 헤더 및 캐싱 전략

소개

지능형 콘텐츠 캐싱은 사이트 방문자의 경험을 개선하는 가장 효과적인 방법 중 하나입니다. 캐싱 또는 이전 요청의 콘텐츠를 임시로 저장하는 것은 HTTP 프로토콜 내에서 구현되는 핵심 콘텐츠 전달 전략의 일부입니다. 전달 경로 전체의 구성 요소는 콘텐츠에 대해 선언된 캐싱 정책에 따라 모든 항목을 캐시하여 후속 요청 속도를 높일 수 있습니다.

이 가이드에서는 웹 콘텐츠 캐싱의 몇 가지 기본 개념에 대해 설명합니다. 이것은 주로 인터넷 전체의 캐시가 콘텐츠를 올바르게 처리할 수 있도록 캐싱 정책을 선택하는 방법을 다룹니다. 캐싱이 제공하는 이점, 주의해야 할 부작용, 성능과 유연성의 최상의 조합을 제공하기 위해 사용할 다양한 전략에 대해 이야기하겠습니다.

캐싱이란 무엇입니까?

캐싱은 후속 요청을 더 빠르게 하기 위해 재사용 가능한 응답을 저장하는 용어입니다. 다양한 유형의 캐싱을 사용할 수 있으며 각 유형에는 고유한 특성이 있습니다. 애플리케이션 캐시와 메모리 캐시는 모두 특정 응답 속도를 높이는 기능으로 유명합니다.

이 가이드의 초점인 웹 캐싱은 다른 유형의 캐시입니다. 웹 캐싱은 HTTP 프로토콜의 핵심 설계 기능으로 네트워크 트래픽을 최소화하면서 시스템 전체의 응답성을 향상시킵니다. 캐시는 원본 서버에서 브라우저까지 콘텐츠 여정의 모든 수준에서 발견됩니다.

웹 캐싱은 특정 규칙에 따라 요청에 대한 HTTP 응답을 캐싱하여 작동합니다. 캐시된 콘텐츠에 대한 후속 요청은 요청을 웹 서버로 다시 보내는 대신 사용자에게 더 가까운 캐시에서 이행될 수 있습니다.

이익

효과적인 캐싱은 콘텐츠 소비자와 콘텐츠 제공자 모두에게 도움이 됩니다. 캐싱이 콘텐츠 제공에 가져다주는 몇 가지 이점은 다음과 같습니다.

네트워크 비용 감소: 콘텐츠 소비자와 콘텐츠 출처 사이의 네트워크 경로의 다양한 지점에서 콘텐츠를 캐시할 수 있습니다. 콘텐츠가 소비자에게 더 가깝게 캐시되면 요청으로 인해 캐시를 넘어서는 많은 추가 네트워크 활동이 발생하지 않습니다.
응답성 향상: 캐싱을 사용하면 전체 네트워크 왕복이 필요하지 않기 때문에 콘텐츠를 더 빠르게 검색할 수 있습니다. 브라우저 캐시와 같이 사용자 가까이에 유지되는 캐시는 이러한 검색을 거의 즉각적으로 수행할 수 있습니다.
동일한 하드웨어에서 향상된 성능: 콘텐츠가 시작된 서버의 경우 공격적인 캐싱을 허용하여 동일한 하드웨어에서 더 많은 성능을 얻을 수 있습니다. 콘텐츠 소유자는 전송 경로를 따라 강력한 서버를 활용하여 특정 콘텐츠 로드를 처리할 수 있습니다.
네트워크 중단 시 콘텐츠 가용성: 특정 정책을 사용하면 캐싱을 사용하여 원본 서버에서 짧은 시간 동안 콘텐츠를 사용할 수 없는 경우에도 최종 사용자에게 콘텐츠를 제공할 수 있습니다.

술어

캐싱을 다룰 때 생소할 수 있는 몇 가지 용어가 있습니다. 더 일반적인 것 중 일부는 다음과 같습니다.

원본 서버: 원본 서버는 콘텐츠의 원래 위치입니다. 웹 서버 관리자 역할을 하는 경우 제어하는 시스템입니다. 요청 경로를 따라 캐시에서 검색할 수 없는 콘텐츠를 제공하고 모든 콘텐츠에 대한 캐싱 정책을 설정하는 일을 담당합니다.
캐시 적중률: 캐시의 효율성은 캐시 적중률 또는 적중률 측면에서 측정됩니다. 총 요청 수에 대한 캐시에서 검색할 수 있는 요청 수의 비율입니다. 높은 캐시 적중률은 높은 비율의 콘텐츠를 캐시에서 검색할 수 있음을 의미합니다. 이것은 일반적으로 대부분의 관리자가 원하는 결과입니다.
신선도: 신선도는 캐시 내의 항목이 여전히 클라이언트에 제공할 후보로 간주되는지 여부를 설명하는 데 사용되는 용어입니다. 캐시의 콘텐츠는 캐싱 정책에 지정된 최신 기간 내에 있는 경우에만 응답하는 데 사용됩니다.
오래된 콘텐츠: 캐시의 항목은 캐싱 정책의 캐시 신선도 설정에 따라 만료됩니다. 만료된 콘텐츠는 "부실\합니다. 일반적으로 만료된 콘텐츠는 클라이언트 요청에 응답하는 데 사용할 수 없습니다. 새 콘텐츠를 검색하거나 적어도 캐시된 콘텐츠가 여전히 정확한지 확인하려면 원본 서버에 다시 연락해야 합니다.
검증: 만료 시간을 새로 고치기 위해 캐시의 오래된 항목을 검증할 수 있습니다. 유효성 검사에는 캐시된 콘텐츠가 항목의 최신 버전을 나타내는지 확인하기 위해 원본 서버에 체크인하는 작업이 포함됩니다.
무효화: 무효화는 지정된 만료 날짜 전에 캐시에서 콘텐츠를 제거하는 프로세스입니다. 원본 서버에서 항목이 변경되었고 캐시에 오래된 항목이 있으면 클라이언트에 심각한 문제가 발생할 수 있는 경우에 필요합니다.

다른 많은 캐싱 용어가 있지만 위의 용어가 시작하는 데 도움이 될 것입니다.

무엇을 캐시할 수 있습니까?

특정 콘텐츠는 다른 콘텐츠보다 더 쉽게 캐싱할 수 있습니다. 대부분의 사이트에서 매우 캐시 친화적인 콘텐츠는 다음과 같습니다.

로고 및 브랜드 이미지
일반적으로 회전하지 않는 이미지(예: 탐색 아이콘)
스타일 시트
일반 자바스크립트 파일
다운로드 가능한 콘텐츠
미디어 파일

이러한 항목은 자주 변경되지 않는 경향이 있으므로 더 오랜 기간 동안 캐시되는 이점을 얻을 수 있습니다.

캐싱에서 주의해야 할 몇 가지 항목은 다음과 같습니다.

HTML 페이지
이미지 회전
자주 수정되는 Javascript 및 CSS
인증 쿠키로 요청한 콘텐츠

거의 캐시되지 않아야 하는 일부 항목은 다음과 같습니다.

민감한 데이터(은행 정보 등)와 관련된 자산
사용자별로 자주 변경되는 콘텐츠

위의 일반 규칙 외에도 다양한 유형의 콘텐츠를 적절하게 캐시할 수 있는 정책을 지정할 수 있습니다. 예를 들어, 인증된 사용자 모두가 사이트의 동일한 보기를 보는 경우 해당 보기를 어디에나 캐시할 수 있습니다. 인증된 사용자가 얼마 동안 유효한 사이트의 사용자에 민감한 보기를 보는 경우 사용자의 브라우저에 캐시하도록 지시할 수 있지만 중간 캐시에 보기를 저장하지 않도록 지시할 수 있습니다.

웹 콘텐츠가 캐시되는 위치

콘텐츠는 전달 체인 전체의 다양한 지점에서 캐시될 수 있습니다.

브라우저 캐시: 웹 브라우저 자체는 작은 캐시를 유지합니다. 일반적으로 브라우저는 캐시할 가장 중요한 항목을 지시하는 정책을 설정합니다. 이는 사용자별 콘텐츠이거나 다운로드 비용이 많이 들고 다시 요청될 가능성이 있는 콘텐츠일 수 있습니다.
중간 캐싱 프록시: 클라이언트와 인프라 사이에 있는 모든 서버는 원하는 대로 특정 콘텐츠를 캐싱할 수 있습니다. 이러한 캐시는 ISP 또는 기타 독립 당사자가 관리할 수 있습니다.
역방향 캐시: 서버 인프라는 백엔드 서비스를 위한 자체 캐시를 구현할 수 있습니다. 이렇게 하면 각 요청에서 백엔드 서버를 누르는 대신 접점에서 콘텐츠를 제공할 수 있습니다.

이러한 각 위치는 자체 캐싱 정책 및 콘텐츠 원본에 설정된 정책에 따라 항목을 캐시할 수 있으며 자주 수행합니다.

캐싱 헤더

캐싱 정책은 두 가지 요소에 따라 달라집니다. 캐싱 엔터티 자체가 허용 가능한 콘텐츠를 캐싱할지 여부를 결정하게 됩니다. 캐시할 수 있는 것보다 적게 캐시하도록 결정할 수 있지만 더 이상은 안 됩니다.

대부분의 캐싱 동작은 콘텐츠 소유자가 설정한 캐싱 정책에 따라 결정됩니다. 이러한 정책은 주로 특정 HTTP 헤더를 사용하여 설명됩니다.

HTTP 프로토콜의 다양한 반복을 통해 다양한 수준의 정교함을 가진 몇 가지 다른 캐시 중심 헤더가 발생했습니다. 여전히주의를 기울여야 할 사항은 다음과 같습니다.

Expires: Expires 헤더는 범위가 상당히 제한되어 있지만 매우 간단합니다. 기본적으로 콘텐츠가 만료되는 미래의 시간을 설정합니다. 이 시점에서 동일한 콘텐츠에 대한 모든 요청은 원본 서버로 돌아가야 합니다. 이 헤더는 폴백으로만 사용하는 것이 가장 좋습니다.
Cache-Control: 이것은 Expires 헤더를 보다 현대적으로 대체합니다. 그것은 잘 지원되며 훨씬 더 유연한 디자인을 구현합니다. 거의 모든 경우에 만료보다 선호되지만 두 값을 모두 설정해도 문제가 되지 않을 수 있습니다. 나중에 Cache-Control로 설정할 수 있는 옵션의 세부 사항에 대해 논의할 것입니다.
Etag: Etag 헤더는 캐시 유효성 검사와 함께 사용됩니다. 원본은 콘텐츠를 처음 제공할 때 항목에 고유한 Etag를 제공할 수 있습니다. 캐시가 만료 시 보유한 콘텐츠의 유효성을 검사해야 하는 경우 콘텐츠에 대해 가지고 있는 Etag를 다시 보낼 수 있습니다. 원본은 콘텐츠가 동일하다고 캐시에 알리거나 업데이트된 콘텐츠(새 Etag 포함)를 보냅니다.
Last-Modified: 이 헤더는 항목이 마지막으로 수정된 시간을 지정합니다. 이는 최신 콘텐츠를 보장하기 위한 유효성 검사 전략의 일부로 사용될 수 있습니다.
Content-Length: 캐싱과 구체적으로 관련되지는 않지만 Content-Length 헤더는 캐싱 정책을 정의할 때 설정하는 것이 중요합니다. 특정 소프트웨어는 공간을 예약해야 하는 콘텐츠의 크기를 사전에 알지 못하는 경우 콘텐츠 캐시를 거부합니다.
Vary: 캐시는 일반적으로 요청된 호스트와 리소스 경로를 캐시 항목을 저장하는 키로 사용합니다. Vary 헤더는 동일한 항목에 대한 요청인지 여부를 결정할 때 추가 헤더에 주의하도록 캐시에 지시하는 데 사용할 수 있습니다. 이것은 Accept-Encoding 헤더를 통해 캐시에 키를 지정하는 데 가장 일반적으로 사용되므로 캐시는 압축된 콘텐츠와 압축되지 않은 콘텐츠를 구분할 수 있습니다.

Vary 헤더에 대한 여담

Vary 헤더는 캐시의 항목을 희석하는 대신 동일한 콘텐츠의 다른 버전을 저장할 수 있는 기능을 제공합니다.

Accept-Encoding의 경우 Vary 헤더를 설정하면 압축된 콘텐츠와 압축되지 않은 콘텐츠 간에 중요한 구분이 이루어집니다. 이는 압축 콘텐츠를 처리할 수 없는 브라우저에 이러한 항목을 올바르게 제공하는 데 필요하며 기본 사용성을 제공하는 데 필요합니다. Accept-Encoding이 Vary의 좋은 후보가 될 수 있음을 알려주는 한 가지 특성은 가능한 값이 2개 또는 3개뿐이라는 것입니다.

User-Agent와 같은 항목은 언뜻 보기에 사이트의 다른 버전을 제공하기 위해 모바일과 데스크톱 브라우저를 구별하는 좋은 방법으로 보일 수 있습니다. 그러나 User-Agent 문자열은 표준이 아니므로 결과적으로 캐시 적중률이 매우 낮은 중간 캐시에 동일한 콘텐츠의 여러 버전이 있을 수 있습니다. Vary 헤더는 특히 제어하는 중간 캐시에서 요청을 정규화할 수 있는 기능이 없는 경우(예를 들어 콘텐츠 전송 네트워크를 활용하는 경우 가능할 수 있음) 드물게 사용되어야 합니다. .

캐시 제어 플래그가 캐싱에 미치는 영향

위에서 Cache-Control 헤더가 최신 캐시 정책 사양에 어떻게 사용되는지 언급했습니다. 이 헤더를 사용하여 다양한 정책 지침을 설정할 수 있으며 여러 지침은 쉼표로 구분됩니다.

콘텐츠의 캐싱 정책을 지정하는 데 사용할 수 있는 일부 캐시 제어 옵션은 다음과 같습니다.

no-cache: 이 명령은 캐시된 콘텐츠가 클라이언트에 제공되기 전에 각 요청에서 재검증되어야 함을 지정합니다. 이는 사실상 콘텐츠를 오래된 것으로 즉시 표시하지만 재검증 기술을 사용하여 전체 항목을 다시 다운로드하지 않도록 합니다.
no-store: 이 명령은 콘텐츠를 어떤 방식으로도 캐시할 수 없음을 나타냅니다. 응답이 민감한 데이터를 나타내는 경우 설정하기에 적합합니다.
public: 이는 콘텐츠를 공개로 표시합니다. 즉, 브라우저 및 모든 중간 캐시에 의해 캐시될 수 있습니다. HTTP 인증을 사용하는 요청의 경우 응답은 기본적으로 비공개로 표시됩니다. 이 헤더는 해당 설정을 재정의합니다.
비공개: 콘텐츠를 비공개로 표시합니다. 비공개 콘텐츠는 사용자의 브라우저에 저장될 수 있지만 중간 당사자가 캐시해서는 안 됩니다. 이는 종종 사용자별 데이터에 사용됩니다.
max-age: 이 설정은 원본 서버에서 콘텐츠를 재검증하거나 다시 다운로드하기 전에 콘텐츠를 캐시할 수 있는 최대 수명을 구성합니다. 본질적으로 이는 최신 브라우징을 위해 Expires 헤더를 대체하며 콘텐츠의 최신성을 결정하는 기준이 됩니다. 이 옵션은 최대 유효 신선도 시간이 1년(31536000초)인 초 단위로 값을 가져옵니다.
s-maxage: 콘텐츠를 캐시할 수 있는 시간을 나타내는 점에서 max-age 설정과 매우 유사합니다. 차이점은 이 옵션이 중간 캐시에만 적용된다는 것입니다. 이것을 위와 결합하면 보다 유연한 정책 구성이 가능합니다.
must-revalidate: 이것은 max-age, s-maxage 또는 Expires 로 표시되는 신선도 정보를 나타냅니다. 헤더를 엄격히 준수해야 합니다. 오래된 콘텐츠는 어떤 상황에서도 제공될 수 없습니다. 이렇게 하면 네트워크 중단 및 유사한 시나리오의 경우 캐시된 콘텐츠가 사용되지 않습니다.
proxy-revalidate: 위의 설정과 동일하게 작동하지만 중간 프록시에만 적용됩니다. 이 경우 사용자의 브라우저는 네트워크 중단 시 오래된 콘텐츠를 제공하는 데 잠재적으로 사용될 수 있지만 중간 캐시는 이러한 목적으로 사용할 수 없습니다.
no-transform: 이 옵션은 어떤 상황에서도 성능상의 이유로 받은 콘텐츠를 수정할 수 없음을 캐시에 알립니다. 이는 예를 들어 캐시가 압축된 원본 서버에서 수신하지 않은 콘텐츠의 압축된 버전을 보낼 수 없으며 허용되지 않음을 의미합니다.

이들은 다양한 캐싱 동작을 달성하기 위해 다양한 방식으로 결합될 수 있습니다. 일부 상호 배타적인 값은 다음과 같습니다.

no-cache, no-store 및 둘 중 하나가 없음으로 표시되는 일반 캐싱 동작
공개 및 비공개

no-store 옵션은 둘 다 존재하는 경우 no-cache를 대체합니다. 인증되지 않은 요청에 대한 응답의 경우 public이 암시됩니다. 인증된 요청에 대한 응답의 경우 private이 암시됩니다. Cache-Control 헤더에 반대 옵션을 포함하여 재정의할 수 있습니다.

캐싱 전략 개발

완벽한 세상에서는 모든 것이 적극적으로 캐시될 수 있으며 서버는 가끔 콘텐츠를 확인하기 위해 접속할 것입니다. 그러나 이것은 실제로 자주 발생하지 않으므로 장기 캐싱 구현과 변화하는 사이트의 요구에 응답하는 것 사이의 균형을 목표로 하는 정상적인 캐싱 정책을 설정해야 합니다.

일반적인 문제

콘텐츠가 생성되는 방식(사용자별로 동적으로 생성됨) 또는 콘텐츠의 특성(예: 민감한 은행 정보)으로 인해 캐싱을 구현할 수 없거나 구현해서는 안 되는 경우가 많이 있습니다. 캐싱을 설정할 때 많은 관리자가 직면하는 또 다른 문제는 새 버전이 게시되었음에도 불구하고 콘텐츠의 이전 버전이 아직 오래되지 않은 야생 상태에 있다는 것입니다.

둘 다 캐시 성능과 제공하는 콘텐츠의 정확성에 심각한 영향을 미칠 수 있는 자주 발생하는 문제입니다. 그러나 이러한 문제를 예상하는 캐싱 정책을 개발하여 이러한 문제를 완화할 수 있습니다.

일반 권장 사항

상황에 따라 사용하는 캐싱 전략이 결정되지만 다음 권장 사항은 몇 가지 합리적인 결정을 내리는 데 도움이 될 수 있습니다.

사용하는 특정 헤더에 대해 걱정하기 전에 캐시 적중률을 높이기 위해 취할 수 있는 특정 단계가 있습니다. 몇 가지 아이디어는 다음과 같습니다.

이미지, css 및 공유 콘텐츠를 위한 특정 디렉토리 설정: 콘텐츠를 전용 디렉토리에 배치하면 사이트의 모든 페이지에서 쉽게 참조할 수 있습니다.
동일한 URL을 사용하여 동일한 항목 참조: 요청된 콘텐츠에 대한 경로와 호스트 모두에서 키를 캐시하므로 모든 페이지에서 동일한 방식으로 콘텐츠를 참조해야 합니다. 이전 권장 사항을 사용하면 이 작업이 훨씬 쉬워집니다.
가능한 경우 CSS 이미지 스프라이트 사용: 아이콘 및 탐색과 같은 항목에 대한 CSS 이미지 스프라이트는 사이트를 렌더링하는 데 필요한 왕복 횟수를 줄이고 사이트에서 해당 단일 스프라이트를 오랫동안 캐시할 수 있도록 합니다.
가능한 경우 로컬에서 스크립트 및 외부 리소스 호스트: javascript 스크립트 및 기타 외부 리소스를 활용하는 경우 올바른 헤더가 업스트림에 제공되지 않는 경우 자체 서버에서 해당 리소스를 호스팅하는 것이 좋습니다. 로컬 복사본을 업데이트할 수 있도록 리소스 업스트림에 대한 모든 업데이트를 알고 있어야 합니다.
Fingerprint 캐시 항목: CSS 및 Javascript 파일과 같은 정적 콘텐츠의 경우 각 항목을 핑거프린트하는 것이 적절할 수 있습니다. 즉, 리소스가 수정되는 경우 새 리소스 이름을 요청할 수 있도록 파일 이름(주로 파일의 해시)에 고유 식별자를 추가하여 요청이 캐시를 올바르게 우회하도록 합니다. 지문을 만들고 HTML 문서 내에서 지문에 대한 참조를 수정하는 데 도움이 되는 다양한 도구가 있습니다.

다른 항목에 대한 올바른 헤더를 선택하는 것과 관련하여 다음을 일반적인 참조로 사용할 수 있습니다.

모든 캐시가 일반 자산을 저장하도록 허용: 정적 콘텐츠 및 사용자별로 지정되지 않은 콘텐츠는 전달 체인의 모든 지점에서 캐시될 수 있으며 캐시되어야 합니다. 이렇게 하면 중간 캐시가 여러 사용자의 콘텐츠로 응답할 수 있습니다.
브라우저가 사용자별 자산을 캐싱하도록 허용: 사용자별 콘텐츠의 경우 사용자 브라우저 내에서 캐싱을 허용하는 것이 허용되고 유용한 경우가 많습니다. 이 콘텐츠는 중간 캐싱 프록시에 캐싱하기에 적합하지 않지만 브라우저 캐싱을 통해 사용자가 후속 방문 중에 즉시 검색할 수 있습니다.
시간에 민감한 필수 콘텐츠에 대한 예외 만들기: 시간에 민감한 콘텐츠가 있는 경우 중요한 상황에서 오래된 콘텐츠가 제공되지 않도록 위의 규칙에 대한 예외를 만드세요. 예를 들어 사이트에 장바구니가 있는 경우 장바구니의 항목이 즉시 반영되어야 합니다. 콘텐츠의 특성에 따라 no-cache 또는 no-store 옵션을 Cache-Control 헤더에 설정하여 이를 달성할 수 있습니다. .
항상 유효성 검사기 제공: 유효성 검사기를 사용하면 전체 리소스를 다시 다운로드하지 않고도 오래된 콘텐츠를 새로 고칠 수 있습니다. Etag 및 Last-Modified 헤더를 설정하면 캐시가 콘텐츠의 유효성을 검사하고 원본에서 수정되지 않은 경우 다시 제공하여 로드를 더욱 줄일 수 있습니다.
지원 콘텐츠에 대해 긴 신선도 설정: 캐싱을 효과적으로 활용하려면 요청을 이행하기 위해 지원 콘텐츠로 요청된 요소의 신선도 설정이 긴 경우가 많습니다. 이는 일반적으로 사용자가 요청한 HTML 페이지를 렌더링하기 위해 가져온 이미지 및 CSS와 같은 항목에 적합합니다. 핑거프린팅과 결합된 확장된 신선도 시간을 설정하면 캐시가 이러한 리소스를 오랜 기간 동안 저장할 수 있습니다. 자산이 변경되면 수정된 지문이 캐시된 항목을 무효화하고 새 콘텐츠의 다운로드를 트리거합니다. 그때까지는 지원 항목을 먼 미래까지 캐시할 수 있습니다.
상위 콘텐츠에 대해 짧은 새로 고침 시간 설정: 위 체계가 작동하려면 포함 항목의 새로 고침 시간이 상대적으로 짧아야 합니다. 그렇지 않으면 전혀 캐시되지 않을 수 있습니다. 이것은 일반적으로 다른 보조 콘텐츠를 호출하는 HTML 페이지입니다. HTML 자체는 자주 다운로드되므로 변경 사항에 신속하게 대응할 수 있습니다. 그런 다음 지원 콘텐츠를 적극적으로 캐시할 수 있습니다.

핵심은 향후 변경 사항이 있을 때 항목을 무효화할 수 있는 기회를 남기면서 가능하면 공격적인 캐싱을 선호하는 균형을 맞추는 것입니다. 귀하의 사이트는 다음과 같은 조합을 가질 수 있습니다.

적극적으로 캐시된 항목
갱신 시간이 짧고 재검증할 수 있는 캐시된 항목
캐시하면 안 되는 항목

목표는 허용 가능한 정확도 수준을 유지하면서 가능한 경우 콘텐츠를 첫 번째 범주로 이동하는 것입니다.

결론

시간을 들여 사이트에 적절한 캐싱 정책이 있는지 확인하면 사이트에 상당한 영향을 미칠 수 있습니다. 캐싱을 사용하면 동일한 콘텐츠를 반복적으로 제공하는 것과 관련된 대역폭 비용을 줄일 수 있습니다. 또한 서버는 동일한 하드웨어로 더 많은 양의 트래픽을 처리할 수 있습니다. 아마도 가장 중요한 것은 고객이 사이트에서 더 빠른 경험을 하게 되어 더 자주 사이트를 방문하게 될 수 있다는 것입니다. 효과적인 웹 캐싱이 만병통치약은 아니지만 적절한 캐싱 정책을 설정하면 최소한의 작업으로 상당한 이점을 얻을 수 있습니다.