캐시 적중률 극대화

스토어프런트 성능을 개선하는 가장 좋은 방법 중 하나는 캐시 적중률을 극대화하는 것입니다. Managed Runtime의 CDN 캐시에서 이행할 수 있는 모든 요청은 캐시 적중으로 간주됩니다. 서버 측에서 페이지를 렌더링하고 백엔드 시스템과 API에 요청을 보내는 데 드는 비용이 절감되므로, 각 캐시 적중 시마다 사용자의 페이지 로딩 속도를 높일 수 있습니다.

이 가이드에서는 최적의 캐시 수명 설정, 조건부 렌더링, 쿼리 문자열 필터링 등 캐시 적중률을 극대화하는 세 가지 기법을 다룹니다. 그럼 각각의 기법을 자세히 살펴보겠습니다.

HTTP 요청을 캐싱하는 최적의 시간은 요청 내용에 따라 달라집니다. 거의 변경되지 않는 컨텐츠 페이지를 로드하는 요청은 오랫동안 안전하게 캐싱될 수 있습니다. 반면 새 제품으로 자주 업데이트되는 제품 목록 페이지에는 15분 등 짧은 캐시 수명이 요구될 수 있습니다. 캐시 적중률을 극대화하려면 가능한 한 긴 캐시 수명을 선택하십시오.

HTTP 응답의 cache-control 헤더는 페이지 요청에 대한 응답을 CDN 캐시에 저장하는 기간을 결정합니다. PWA Kit 프로젝트에서 페이지 응답의 캐시 수명은 기본적으로 600초(10분)입니다. 캐시 수명을 페이지별로 맞춤화하거나 모든 페이지에 대해 맞춤화할 수 있습니다.

페이지 구성요소의 getProps 기능을 사용하면 res라는 오브젝트를 사용하여 HTTP 응답을 맞춤화할 수 있습니다. 페이지의 캐시 수명을 설정하려면 res 오브젝트의 set 메서드를 사용하여 Cache-Control 헤더를 설정하고 max-age 지시문 값을 초 단위로 지정합니다.

예를 들어 이 ProductList 구성요소는 캐시 수명을 기본값인 600초에서 900초로 늘립니다.

app/ssr.js의 모든 페이지에 대해 캐시 수명을 설정할 수 있습니다. defaultCacheTimeSeconds의 값을 새로 설정하여 기본 캐시 수명을 변경할 수 있습니다. HTTP 헤더를 보다 세부적으로 제어해야 하는 경우, 다음과 같이 맞춤형 헤더를 설정하는 Express 핸들러를 추가합니다.

Network(네트워크) 탭에서, Chrome의 DevTools로 네트워크 요청을 검사하여 응답 헤더에 캐시 컨트롤이 있는지 테스트할 수 있습니다. 또는 터미널에서 모든 응답 헤더를 출력하는 다음 curl 명령을 실행할 수 있습니다. 예제 명령의 <URL>을 필수 쿼리 문자열을 포함하여, 테스트할 전체 URL로 바꿉니다.

페이지가 CDN의 캐싱에 적합하도록 하려면, 서버 측에서 다음 유형의 컨텐츠를 렌더링하지 않도록 조건 코드를 추가해야 합니다.

• 사용자 이름, 카트 내 품목 수, 선호 결제 방법 등 개인화된 컨텐츠. 개인화된 콘텐츠는 특정 사용자 이외의 다른 사용자에게는 부적절하고 관련이 없습니다. 특정 사용자에 대한 응답을 캐싱해도 캐시 적중률이 높아지지는 않습니다.
• 제품 가격, 재고 잔량, 판촉 등 자주 변경되는 컨텐츠. 페이지에 이미 오래된 정보가 포함되어 있으면 사용자를 혼란스럽게 할 수 있으므로, 이 컨텐츠는 캐싱에 적합하지 않습니다.

서버 측에서 클라이언트의 일반적인 기반으로서 렌더링되는 페이지를 떠올려보십시오. 서버의 페이지 버전을 사용자의 기기에 빠르게 로드한 후 브라우저는 자주 변경되는 개인화된 컨텐츠를 렌더링합니다.

렌더링이 클라이언트 측과 서버 측 중 어느 쪽에서 이루어지고 있는지 확인하려면 window 오브젝트가 있는지 확인합니다. 이 오브젝트는 클라이언트 측에만 존재합니다. 다음 예제에서는 이 기법을 사용하여 클라이언트 측에서만 가격을 렌더링합니다.

대부분의 스토어프런트 앱은 URL의 쿼리 문자열을 사용하여 앱 상태를 나타내는 매개변수와 값을 저장합니다. 예를 들어 사용자가 "sweaters"를 검색할 때 ?search=sweaters와 같이 검색어를 쿼리 문자열에 포함할 수 있습니다. 쿼리 문자열은 사용자 작업을 추적하는 데에도 많이 사용됩니다. 예를 들어 고유한 쿼리 문자열을 이메일의 각 링크에 추가하여 상호 작용을 추적할 수 있습니다. user=juanita&source=email.

모든 쿼리 문자열 매개변수가 캐싱과 관련이 있는 것은 아닙니다. Managed Runtime에는 캐싱된 응답을 찾기 전에 요청의 쿼리 문자열을 수정할 수 있는 요청 프로세서라는 엣지 기능이 포함되어 있습니다. 요청 프로세서를 사용하여 유사한 URL을 동일한 캐시 응답에 매핑하여 캐시 적중률을 높일 수 있습니다.

요청 프로세서를 맞춤화하려면 app/request-processor.js에 정의된 processRequest 함수를 편집합니다.

다음 예제에서는 쿼리 문자열에서 gclid 및 utm_campaign 매개변수를 필터링하는 요청 프로세서를 정의합니다. 이러한 매개변수는 일반적으로 Google 마케팅 캠페인과 연관되어 있으며, 클라이언트 측에서만 유용합니다. 이 매개변수는 쿼리 문자열 작업을 간소화하기 위해 PWA Kit React SDK에서 QueryParameters 클래스를 가져옵니다.

캐시에서 해당 오브젝트를 검색하는 데 사용되는 전체 URL에는 요청 프로세서에서 반환되는 쿼리 문자열 버전이 포함됩니다. 해당 URL에 대한 응답이 캐싱되지 않으면 동일한 수정 버전의 URL이 Express 앱에 전달됩니다.

이 방식을 사용할 때는 두 가지를 주의하십시오.

첫째, 앱이 필터링된 매개변수를 렌더링에 사용하지 않는지 확인하십시오. 예를 들어 위에서 search 매개변수를 필터링한 경우 올바른 검색 결과를 표시하기 어렵습니다.

둘째, 리디렉션할 것으로 예상되는 요청에서 매개변수를 필터링할 때 주의하십시오. 코드가 필터링된 매개변수에 액세스할 수 없는 경우 해당 매개변수를 리디렉션에도 사용할 수 없습니다. 요청은 www.example.com?lang=en에 대한 요청을 www.example.com/en과 같은 로캘별 경로로 리디렉션하는 홈 페이지 구성 요소라고 할 수 있습니다. lang 매개변수를 필터링하면 올바른 로캘로 리디렉션할 수 없습니다.

다음 순서를 고려하십시오.

1. 요청 프로세서가 www.example.com/?gclid=123에 대한 요청을 처리합니다.
2. 요청 프로세서가 gclid 쿼리 문자열 매개변수를 필터링합니다.
3. 요청이 전체 URL www.example.com을 사용하여 애플리케이션에 전달됩니다.
4. 애플리케이션이 www.example.com/en에 리디렉션을 반환합니다.

이 마지막 단계에서는 원래 gclid 매개변수가 손실되었기 때문에, 사용자가 리디렉션된 후에는 브라우저에서 사용할 수 없습니다. 이 문제를 해결하려면 리디렉션할 것으로 예상되는 요청의 쿼리 문자열을 필터링하지 마십시오.

이제 다양한 기법을 사용하여 페이지 요청에 대한 캐시 적중률을 개선하는 방법을 알게 되었습니다.

API 요청 캐싱 및 프록시의 기타 이점에 대해 알아보려면 요청 프록싱 가이드를 참조하십시오.