설명서

AEM Site 캐시 최적화

Last update: Sat Apr 06 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

성능을 크게 향상하는 가장 빠른 방법 중 하나는 AEM 아키텍처 내에서 캐싱을 최적화하는 것입니다. 이 문서에서는 AEM 아키텍처 내에서 사용할 수 있는 다양한 캐시를 최적화하는 방법을 중점적으로 다룹니다.

설명 description

환경

Adobe Experience Manager

문제/증상

AEM 사이트 캐시를 최적화하는 방법

AEM 아키텍처 및 캐싱

모든 AEM 아키텍처에서 사용자가 사이트를 방문할 때 여러 캐시 레이어를 접하게 됩니다. 표준 AEM 아키텍처에서 고려해야 할 캐시 레이어가 4개 있습니다. 여기에는 웹 브라우저, CDN, 디스패처 및 AEM 인스턴스가 포함됩니다.

screenshot_2018-03-25160541

해결 방법 resolution

A. 브라우저 캐싱

사용자가 사이트를 다시 방문할 때 발생하는 첫 번째 캐시 수준은 자체 브라우저입니다. 브라우저 수준에서 캐싱은 일반적으로 캐시 제어: max-age=… 응답 머리글. 다음 max-age 설정은 사이트에서 파일 "다시 유효성 검사" 또는 요청을 다시 시도하기 전까지 파일을 캐시해야 하는 시간(초)을 브라우저에 알려줍니다. 이러한 캐시 개념 max-age 일반적으로 "캐시 만료" 또는 TTL("Time to Live")이라고 합니다.

에는 다양한 옵션(또는 "지시문")이 있습니다. Cache-Control 캐싱 발생 방식에 영향을 주는 헤더입니다. 다음은 몇 가지 일반적인 지시문입니다.

  1. private - Cache-Control 헤더에 private 지시문을 사용하면 파일이 CDN과 같은 중간 캐시에 캐싱되지 않고 브라우저에서만 캐싱됩니다. 페이지에 개인화된/사용자별 컨텐츠가 포함된 경우 이 지시문이 실제로 사용됩니다.

    사용 예: Cache-Control: max-age=300, private

  2. s-maxage - Cache-Control 헤더에 s-maxage 지시문을 사용하면 CDN처럼 공유 캐시에 대해 다른 TTL을 설정할 수 있습니다. 이 값을 설정하면 브라우저에서 max-age에 설정된 것을 사용하고 다른 캐시는 s-maxage 설정을 대신 준수합니다.

    사용 예: Cache-Control: max-age=600, s-maxage=300

최신 브라우저는 모두 Cache-Control 그러나 HTTP/1.0에는 더 이상 사용되지 않는 일부 이전 헤더가 있어 여전히 캐싱에 영향을 줄 수 있습니다. 이러한 헤더는 다음과 같습니다 만료 및 Pragma. 아주 오래된 브라우저를 지원하지 않아도 되는 경우에는 그러한 응답 헤더를 보내지 않습니다.

캐싱 외에, 유효성 재검사도 중요한 개념입니다. 유효성 재검사는 다음을 사용합니다. 마지막 수정일(응답) / If-Modified-Since (요청) 헤더 및 ETag (응답) / If-None-Match (요청) 헤더입니다.

브라우저 테스트에 대한 주의 사항:

Google Chrome에서 캐싱을 테스트할 때 https로 테스트하고 자체 서명된 인증서가 있으면 아무것도 캐싱되지 않습니다. Chrome은 신뢰할 수 없거나 잘못된 인증서가 있는 경우 응답을 캐싱하거나 유효성 재검사를 수행하지 않습니다.

디스패처에 대한 참고 사항:

AEM Dispatcher v4.2.3 및 이전 버전에는 /enableTTL 를 사용하는 캐시만 해당 max-age 지시문입니다. 이는 다음과 같은 경우에도 마찬가지입니다 비공개 또는 s-maxage 디렉티브가 설정되면 max-age 이(가) 설정되어 있습니다. 이 문제는 Dispatcher 4.2.4 이상 버전에서 해결되었습니다.

B. CDN 캐싱

A CDN 또는 "Content Delivery Network"는 사용자에게 가장 가까운 위치에서 콘텐츠를 캐싱하고 제공하도록 설계된 웹 서버의 분산 네트워크입니다. 이렇게 하면 네트워크 홉이 줄어들고 사용자의 컴퓨터에서 컨텐츠까지 거리가 줄어듭니다 "왕복 시간"(RTT). RTT는 브라우저에서 사이트에 요청을 보내고 응답을 받는 데 걸리는 시간입니다. CDN 공급자 공간의 경쟁으로 인해 CDN은 비용 면에서 매우 효과적입니다. 따라서 사이트에 CDN을 사용하기로 하는 결정을 쉽게 내릴 수 있습니다. 아직 CDN을 사용하지 않는 경우에는 반드시 CDN을 사이트에 통합해야 합니다.

여러 CDN 공급자가 있으며, 각 공급자는 서로 다른 기능과 구성을 제공합니다.

CDN 캐싱은 어떻게 작동합니까?

CDN은 브라우저와 유사한 규칙에 따라 콘텐츠를 캐시합니다. 다음을 사용합니다. Cache-Control HTTP 응답 헤더를 반환하고 일반적으로 만료 없는 경우 헤더 Cache-Control 헤더를 찾을 수 없습니다.

대부분의 CDN은 캐시의 수동 플러시를 트리거하는 방법을 제공합니다.  대부분의 경우 캐시 플러시는 파일이 있는 모든 Edge Server에 전달하는 데 약간의 지연(예: 15분)이 발생합니다.

CDN 사용량 최적화

CDN에서 파일을 최적으로 캐싱하는지 확인하기 위해 수행해야 하는 몇 가지 작업이 있습니다.

  1. 을 지원하는 CDN 사용 유효성 재검사 동안 부실함 및 stale-if-error 지시문 Cache-Control 머리글입니다.

    • 유효성 재검사 동안 부실함 - 이 지시문은 캐시 파일이 만료된 후 새 파일을 검색하는 동안 파일의 이전(이미 캐시됨) 버전을 제공하도록 CDN에 알려 줍니다.
    • stale-if-error - 마찬가지로, 이 지시문은 유효성 재검사 동안 원본이 오류로 응답할 때 파일의 이전(이미 캐시됨) 버전을 제공하도록 CDN에 알려 줍니다.

  2. GZip은 사전 압축되지 않은 모든 파일 유형에 대한 응답을 압축합니다.

    이 작업은 디스패처 수준에서 수행해야 합니다. 이렇게 하면 CDN으로 전송된 바이트 수가 줄어듭니다. CDN은 일반적으로 전송된 바이트 수에 의해 청구되므로 응답을 압축하면 비용이 줄어듭니다.

    • Dispatcher 수준에서 GZip 압축 활성화: Apache - mod_deflate 사용. mod_deflate에서 Vary를 사용할 때 주의하십시오. 경우에 따라 Vary 헤더로 인해 CDN 및 브라우저가 캐싱을 완전히 건너뛸 수 있습니다.

    • Microsoft IIS - 사용 동적 압축.

    • 이미 압축된 큰 파일 또는 파일의 gzip 압축을 허용하지 않습니다. 대부분의 이미지 및 비디오 형식은 이미 사전 압축되어 있습니다. 웹 서버 수준에서 즉시 압축하면 성능이 크게 저하됩니다.

      • Apache에서 다음 AddOutputFilterByType 지시문을 통해 이 작업을 수행할 수 있습니다. AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
      • IIS에서는 다음을 통해 이를 제어할 수 있습니다. < dynamicType> 구성.

    • CDN 공급자가 지원하는 경우 Edge-side 포함 (ESI) 그런 다음 이 기능을 활용합니다. AEM 구성 요소는 ESI를 사용하여 구분할 수 있습니다. 이렇게 하려면 Apache를 사용합니다 \[ Sling 동적 포함 항목\] 또는 사용자 지정 솔루션을 구현합니다. 이 방법은 매우 정적인 페이지가 있지만, 페이지의 일부 부분에서 더 동적인 컨텐츠를 제공하는 경우에 유용합니다. 이러한 경우 기본적으로 페이지를 여러 CDN 파일로 나눕니다. 이렇게 하면 다양한 기간에 페이지의 다양한 부분을 캐싱할 수 있습니다.

인기 있는 CDN 공급자

다음은 인기 있는 일부 CDN 공급자 목록입니다.

각각 다른 기능을 가진 몇 가지 더 있습니다.

주의:

다음 사항에 주의하십시오. 다름 응답 헤더. 어떤 경우에는, 다름 는 CDN과 브라우저가 모두 캐싱을 완전히 건너뛸 수 있습니다. 일반적으로 를 추가하지 마십시오 다름 를 제외하고 Vary: Accept-Encoding (응답이 gzip으로 압축된 경우에만 적용됨). 즉, 응답의 출력을 "변경"해야 하는 경우 다른 URL을 사용합니다.

예를 들어 모바일과 데스크탑에 대해 서로 다른 버전의 HTML이 있는 경우 다른 URL을 사용합니다. 이렇게 하면 CDN 및 브라우저에서 보다 효과적으로 캐싱할 수 있습니다.

C. AEM Dispatcher 캐싱

CDN 캐시가 만료된 경우 요청이 AEM Dispatcher 캐시에 도달합니다. 이 수준에서는 캐싱을 최적화하기 위해 수행할 수 있는 여러 가지 작업이 있습니다.

이 항목은 광범위하므로 다음을 참조하십시오. 이 문서 dispatcher 캐시를 최적화하는 방법에 대한 자세한 내용

D. AEM 게시 인스턴스

AEM 수준에는 다양한 캐시 레이어를 최적화하기 위해 수행해야 하는 몇 가지 작업이 있습니다.

  1. 기본적으로 AEM에서 설정하지 않은 다음 HTTP 응답 헤더를 설정합니다.

    1. 캐시 제어: max-age=… - 이 헤더를 설정하려면, ACS Commons - Dispatcher TTL 를 사용하거나 사용자 지정 코드를 구현하여 설정할 수 있습니다.
    2. 마지막 수정일 - 기사와 같이 페이지 콘텐츠가 상대적으로 정적인 경우 해당 last-modified 헤더를 cq:lastModified date/time(마지막으로 기사를 수정한 시간)으로 설정할 수 있습니다. 그러나 구성 요소 콘텐츠에 포함된 JCR 쿼리 결과와 함께 페이지가 동적인 경우 현재 날짜/시간을 사용하도록 설정하는 것이 가장 좋습니다.
    3. ETag - 대신 이 옵션을 사용하기로 결정한 경우 마지막 수정일, 다음을 쓸 수 있습니다. 복제 이벤트 리스너 는 페이지 활성화를 수신하고 페이지 콘텐츠의 md5 해시를 생성합니다. 작성자 인스턴스에서 페이지의 jcr:content 노드에 속성으로 설정할 수 있습니다. 페이지가 복제되면 게시 인스턴스로 전송됩니다. 컨텐츠가 비교적 정적인 페이지 구성 요소의 경우 이 작업이 수행될 수 있지만, 페이지가 다소 동적이거나 많은 컨텐츠를 참조하는 경우 ETag를 생략(또는 계산)해야 합니다.

  2. 사이트에 개인화된/동적 컨텐츠가 있는 경우:

    1. 사용 Apache Sling Dynamic Includes 을 눌러 컨텐츠를 분류하면 페이지의 서로 다른 부분이 서로 다른 기간에 캐싱될 수 있습니다.

      1. 캐싱은 다음 기술을 사용하여 수행할 수 있습니다.

        • CDN에서 ESI(Edge-side Includes)
        • 웹 서버에서 SSI(Server-side Includes)
        • 브라우저에서 비동기 Javascript 및 XML(AJAX)

      2. 페이지의 구성 요소는 서로 다른 기간에 캐싱할 수 있는 별도의 요청으로 나눌 수 있습니다. 상대적으로 정적인 페이지 부분은 훨씬 더 오랜 기간 동안 캐시될 수 있습니다.

    2. 다음 사용을 고려하십시오. ACS Commons의 HTTP 캐시 기능.

  3. 클라이언트 라이브러리를 최적화합니다.

    1. 클라이언트 라이브러리에서 축소를 활성화합니다.

    2. 클라이언트 라이브러리의 파일이 미리 축소된 경우 해당 클라이언트 라이브러리에서 축소를 비활성화합니다. cq:ClientLibraryFolder 노드를 편집합니다.

      1. String 유형의 jsProcessor 속성을 설정합니다.[ ] min:none 값 포함
      2. 문자열 유형의 cssProcessor 속성을 설정합니다.[ ] min:none 값 포함
      3. 자세한 내용은, 여기.

    3. 클라이언트 라이브러리 포함 js 및 css 파일을 축소하고 줄입니다.

    4. 구현 acs Commons의 versioned-clientlibs CDN 및 Dispatcher가 오랜 기간 동안 js 및 css 파일을 캐싱할 수 있도록 합니다.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f