WordPress 사이트에 대한 W3 총 캐시 설정을 구성하는 방법

백만 개 이상의 활성 설치가 있는 W3 Total Cache는 WordPress 저장소에서 가장 인기 있는 캐싱 및 최적화 플러그인 중 하나입니다. 비교적 간단하고 간소화된 인터페이스를 제공하는 다른 WordPress 최적화 플러그인과 달리 W3 Total Cache는 WordPress 사이트의 캐싱 구성을 완벽하게 제어합니다.

W3TC 설정의 세분화로 인해 WordPress 사이트에 대한 궁극적인 제어를 원하는 고급 사용자 및 개발자에게 이상적인 플러그인입니다. 이 기사에서는 W3 Total Cache의 설정을 자세히 살펴보고 WordPress 사이트의 성능을 향상시키기 위한 권장 구성을 제공합니다.

Kinsta 사용자인 경우 호스팅 스택에 이미 많은 최적화 기능이 내장되어 있기 때문에 W3 Total Cache에서 특정 설정을 구성할 필요가 없습니다. 예를 들어 NGINX를 통한 서버 수준 페이지 캐싱은 모든 Kinsta 사이트에서 기본적으로 활성화되어 있습니다. , 따라서 W3 Total Cache에서 활성화할 필요가 없습니다. Kinsta 호스팅 사이트에서 W3TC를 설정하는 경우 아래 설정 지침에 특히 주의하십시오. 특정 설정이 필요하지 않거나 Kinsta와 호환되지 않는 경우 알려 드리겠습니다.

W3 토탈 캐시 설치 방법

사이트에 W3 Total Cache가 설치되어 있지 않은 경우 WordPress 대시보드에서 바로 설치할 수 있습니다. "플러그인 추가" 페이지에서 "W3 Total Cache"를 검색하여 설치하십시오.

BoldGrid의 웹사이트에서 구입할 수 있는 W3 Total Cache의 Pro 버전도 있습니다. Pro 버전에는 REST API 캐싱, Google Maps 캐싱 및 추가 확장과 같은 몇 가지 추가 기능이 있습니다. 이 기사에서는 WordPress 플러그인 저장소의 무료 버전을 사용합니다.

W3 총 캐시 설정은 어디에 저장됩니까?

W3 Total Cache를 설치하면 WordPress 관리 대시보드의 사이드바에 "성능" 탭이 표시됩니다. "성능" 탭을 클릭하면 "일반 설정", "페이지 캐시", "축소" 등과 같은 다양한 하위 메뉴가 표시됩니다.

WordPress 관리 도구 모음의 "성능" 탭을 사용하여 W3 총 캐시 설정에 액세스할 수도 있습니다.

W3 총 캐시를 제거하는 방법

W3 Total Cache를 구성하는 방법에 대해 알아보기 전에 캐시를 제거하거나 지우는 방법을 빠르게 살펴보겠습니다. 관리 도구 모음의 "성능" 탭 위로 마우스를 가져가면 두 가지 제거 옵션이 표시됩니다.

1. 모든 캐시 제거 – 모든 캐시를 한 번에 제거합니다.
2. 모듈 제거 – 개별 캐시(예: 축소된 자산, 페이지 캐시, 개체 캐시 등)를 제거합니다.

W3 총 캐시 일반 설정

W3 Total Cache의 "일반 설정" 메뉴로 들어가 몇 가지 기본 설정을 구성해 보겠습니다.

페이지 캐시

기본적으로 WordPress 사이트에 대한 모든 단일 요청은 실시간으로 렌더링됩니다. 전자 상거래 상점이나 토론 포럼과 같은 특정 종류의 사이트에서는 동적 렌더링이 이상적입니다. 그러나 블로그, 뉴스 사이트 및 동적 콘텐츠가 필요하지 않은 기타 사이트의 경우 페이지 캐싱 레이어를 추가하면 성능이 향상되고 서버 부하가 감소할 수 있습니다.

사이트가 Kinsta에서 호스팅되는 경우 페이지 캐싱에 대해 걱정할 필요가 없습니다. 사이트 페이지를 정적 HTML 파일에 자동으로 캐시하는 고성능 서버 수준 구성이 있습니다. 호스트가 페이지 캐싱을 제공하지 않는 경우 W3 Total Cache 플러그인에서 페이지 캐싱을 활성화할 수 있습니다.

작게 하다

HTML, CSS 및 JavaScript 자산을 축소하면 불필요한 공백을 제거하여 사이트 페이지의 전체 크기를 줄일 수 있습니다. 대부분의 WordPress 사이트의 경우 W3 Total Cache의 "Minify" 기능을 활성화하고 "Minify Mode"에 대해 "Auto" 옵션을 선택하는 것이 좋습니다.

경우에 따라 자산을 축소하면 CSS 또는 JavaScript 코드가 중단될 수 있으며, 이로 인해 프런트엔드에서 눈에 띄는 오류가 발생하는 경우가 많습니다. 자산을 축소한 후 사이트에서 비정상적인 문제가 발견되면 개발자와 협력하여 문제를 일으키는 자산을 식별하는 것이 좋습니다. 그런 다음 수동 모드에서 "축소" 기능을 사용할 수 있습니다. 이 기능을 사용하면 특정 CSS 및 JavaScript 파일에 대한 축소를 우회할 수 있습니다.

Opcode 캐시

WordPress는 PHP 작업자가 백그라운드에서 지속적으로 코드를 실행하는 동적 CMS입니다. Opcode 캐시는 컴파일된 PHP 코드를 저장하여 사이트 속도를 높이는 데 도움이 되므로 동일한 코드가 필요한 후속 요청이 더 빨라집니다.

사이트가 Kinsta에서 호스팅되는 경우 W3 Total Cache에서 opcode 캐싱 레이어를 활성화하는 것에 대해 걱정할 필요가 없습니다. 모든 라이브 환경에서 opcode 캐시인 OPcache를 활성화합니다. OPcache는 컴파일된 PHP 코드가 캐시되지 않고 사이트 개발 및 디버깅을 방해하지 않도록 하기 위해 스테이징 환경에서 비활성화됩니다.

호스트가 opcode 캐시를 제공하지 않는 경우 W3 Total Cache에서 활성화하는 것이 좋습니다. opcode 캐시 기능은 W3TC의 Pro 버전에서만 사용할 수 있습니다.

데이터베이스 캐시

W3TC의 데이터베이스는 MySQL 데이터베이스 쿼리의 결과를 저장합니다. 이 기능이 유용해 보이지만 비활성화된 상태로 유지하고 대신 개체 캐시를 사용하는 것이 좋습니다.

경우에 따라 데이터베이스 캐시 기능으로 인해 CPU 사용량이 높아질 수 있습니다. 이는 데이터베이스 쿼리 결과를 저장하여 절약된 CPU 양이 이 기능에 필요한 CPU 증가로 인해 상쇄될 수 있음을 의미합니다.

개체 캐시

WordPress의 컨텍스트에서 개체 캐시는 완료된 데이터베이스 쿼리의 결과를 저장합니다. WordPress에는 실제로 객체 캐시가 내장되어 있지만 단일 페이지 로드에 대한 데이터만 유지합니다. 이렇게 하면 페이지 로드가 동일한 데이터베이스 쿼리를 실행하는 CPU 리소스를 낭비할 필요가 없도록 하기 때문에 보다 효율적인 페이지 렌더링이 가능합니다.

WordPress의 기본 개체 캐시는 의심할 여지 없이 성능에 도움이 되지만 페이지 로드 간에 데이터를 유지하는 개체 캐시는 훨씬 더 좋습니다! W3TC의 "개체 캐시" 기능은 /wp-content 디렉토리에 사용자 정의 캐싱 스크립트를 추가하고 WordPress의 개체 캐시 동작을 변경하여 데이터를 지속적으로(여러 페이지 로드에 걸쳐) 유지합니다.

사이트가 Kinsta에서 호스팅되지 않는 경우 데이터베이스 쿼리를 활용하는 요청의 속도를 높이려면 WordPress 사이트에서 W3TC의 개체 캐시 기능을 활성화하는 것이 좋습니다.

사이트가 Kinsta에서 호스팅되는 경우 Redis 애드온으로 구동되는 고성능 개체 캐싱 레이어를 제공합니다. Redis는 데이터베이스 및 메시지 브로커 애플리케이션에 자주 사용되는 오픈 소스 인메모리 데이터 구조 저장소입니다.

Redis는 RAM에 데이터를 캐시하므로 WordPress는 기존 개체 캐시 구성보다 훨씬 빠른 영구 개체 캐시에서 캐시된 데이터에 액세스할 수 있습니다.

브라우저 캐시

브라우저 캐싱은 CSS, JavaScript, 이미지 및 글꼴과 같은 정적 자산을 로컬로 저장하여 WordPress 사이트 속도를 상당히 높일 수 있습니다. 브라우저 캐싱은 만료 기간을 사용하여 자산을 캐시할 기간을 결정합니다. 최신 웹에서 대부분의 개발자는 정적 자산의 만료 기간을 1년으로 지정합니다.

Kinsta에서 호스팅되는 사이트의 경우 정적 파일에 대해 1년의 캐시 기간을 적용합니다. 이것은 Kinsta에서 호스팅되는 정적 파일의 cache-control 헤더를 확인하여 확인할 수 있습니다. 웹 호스트가 브라우저 캐싱에 대해 "미래 만료 시간"을 적용하지 않는 경우 W3 Total Cache에서 "브라우저 캐시" 기능을 활성화하고 만료 기간을 구성할 수 있습니다.

CDN(콘텐츠 전송 네트워크)

CDN 또는 콘텐츠 전송 네트워크를 사용하여 전 세계의 데이터 센터로 정적 파일을 오프로드하는 경우 W3 Total Cache를 구성하여 "테마 파일, 미디어 라이브러리 첨부 파일, CSS, JS" 등에 대한 URL을 재작성할 수 있습니다. CDN 호스트 이름.

사이트가 Kinsta에서 호스팅되는 경우 KeyCDN에서 제공하는 고성능 콘텐츠 전송 네트워크인 Kinsta CDN을 사용하는 것이 좋습니다. Kinsta CDN이 활성화되면 정적 파일 URL이 Kinsta CDN에서 제공되도록 자동으로 다시 작성됩니다.

다른 CDN 공급자를 사용하거나 사이트가 Kinsta에서 호스팅되지 않는 경우 W3 Total Cache에서 "CDN" 기능을 활성화하고 CDN URL을 추가할 수 있습니다.

리버스 프록시

역방향 프록시는 웹 서버와 WordPress 사이에 위치하며 들어오는 요청에 대해 다양한 논리 기반 조작을 수행하는 데 사용할 수 있습니다. W3TC는 백엔드 로드를 줄이기 위한 목적으로 데이터를 캐싱하고 제공하기 위해 널리 사용되는 "HTTP 가속기"인 Varnish를 지원합니다.

Varnish를 사용하려면 먼저 Varnish 패키지를 호스트에서 설치해야 합니다. Kinsta 고객인 경우 당사 인프라가 Varnish와 함께 작동하도록 설계되지 않았으므로 역방향 프록시 옵션을 활성화하지 마십시오.

사용자 경험

W3TC의 "사용자 경험" 최적화를 통해 지연 로딩을 활성화하고, 이모티콘을 비활성화하고, wp-embed.js 스크립트를 비활성화할 수 있습니다. 페이지 로드 속도를 높이려면 WordPress 사이트에서 지연 로드를 활성화하는 것이 좋습니다. 브라우저 네이티브 또는 플러그인 기반 지연 로딩을 아직 사용하지 않는 경우 지연 로딩을 위해 W3 Total Cache를 사용하는 것이 좋습니다.

오늘날 대부분의 운영 체제에는 이모티콘 지원 기능이 내장되어 있습니다. 따라서 이모티콘을 많이 사용하지 않는 경우 WordPress에 포함된 이모티콘 스크립트를 비활성화할 수 있습니다. W3TC를 사용하여 wp-emoji-release.min.js 를 제거하면 HTTP 요청을 줄이고 페이지 로드에서 ~10KB를 제거하는 데 도움이 됩니다.

마찬가지로 WordPress 게시물을 포함하지 않으면 W3 Total Cache로 wp-embed.js 를 비활성화할 수 있습니다. 이 스크립트를 비활성화해도 YouTube 비디오, SoundCloud 스트림 등을 포함하기 위한 oEmbed 기능에는 영향을 미치지 않습니다.

여러 가지 잡다한

W3 Total Cache에는 구성할 수 있는 몇 가지 기타 설정도 있습니다. WordPress에 Google Page Speed ​​대시보드 위젯을 표시하려면 Page Speed ​​API 키를 입력하면 됩니다. WordPress 사이트의 각 페이지에 대한 메뉴 표시줄에 페이지 속도 등급을 표시하는 옵션도 있습니다.

"NGINX 서버 구성 파일 경로", "파일 잠금 활성화", "NFS에 대한 디스크 강화 페이지 최적화 및 디스크 캐싱 최소화"와 같은 다른 설정의 경우 변경해야 할 특별한 이유가 없는 한 기본 설정으로 두는 것이 좋습니다.

디버그

사이트에서 문제를 해결하는 경우 W3 Total Cache에는 특정 캐싱 레이어 및 최적화 설정을 비활성화할 수 있는 편리한 "디버그" 메뉴가 있습니다. 예를 들어 사이트에서 시각적 결함이 발견되면 "축소" 옵션에 대해 디버그 모드를 활성화할 수 있습니다. 그러면 문제 해결에 도움이 되도록 페이지의 소스 코드에 HTML 주석을 삽입할 수 있습니다.

디버그 모드 기능은 서버 리소스에 추가 부하를 주기 때문에 스테이징 환경이나 트래픽이 적은 시간에만 사용하는 것이 좋습니다. 또한 문제 해결을 마친 후에는 디버그 모드를 비활성화해야 합니다!

가져오기/내보내기 설정

설정 구성을 마친 후 W3TC의 "가져오기/내보내기" 기능을 사용하여 구성 백업을 생성할 수 있습니다. W3 Total Cache에는 많은 설정이 있으므로 전체 백업을 내보낼 수 있어 안심할 수 있습니다. 또한 수동으로 구성할 필요 없이 여러 사이트에서 사용자 지정 W3TC 구성을 쉽게 복제할 수 있습니다.

W3 총 캐시 설정 - 페이지 캐시

W3 Total Cache의 "페이지 캐시" 설정에 대해 알아보겠습니다. 사이트가 Kinsta에서 호스팅되는 경우 페이지 캐싱에 대해 걱정할 필요가 없음을 기억하십시오. 따라서 이 섹션을 건너뛰어도 됩니다.

• 캐시 프론트 페이지 – 대부분의 사이트에서 프론트 페이지는 일반적으로 가장 많은 트래픽을 수신하는 페이지입니다. 따라서 이 설정을 활성화하는 것이 좋습니다.
• 캐시 피드 – WordPress는 Feedburner와 같은 외부 앱 및 서비스가 사이트 콘텐츠를 표시할 수 있도록 하는 다양한 RSS 피드를 생성합니다. 요즘은 RSS가 예전만큼 인기가 없지만 이 설정을 활성화하는 것이 좋습니다.
• 캐시 SSL(HTTPS 요청) – 웹 서버가 들어오는 모든 요청에 ​​대해 HTTPS를 강제 실행하지 않는 경우 이 설정을 활성화하면 성능에 긍정적인 영향을 미칠 수 있습니다. 웹 서버 수준에서 이미 HTTPS를 강제 실행하고 있다면 이를 활성화할 필요가 없습니다.
• 쿼리 문자열 변수가 있는 캐시 URI – 쿼리 문자열은 URL 끝에 추가되는 매개변수입니다(예: /?version=123). 쿼리 문자열은 종종 WordPress 데이터베이스에서 특정 데이터를 요청하고 표시하는 데 사용됩니다. 일반적으로 쿼리 문자열의 목적은 페이지의 고유한 버전을 요청하는 것이므로 캐시하려는 특정 쿼리 문자열이 없는 한 이 기능을 비활성화 상태로 유지하는 것이 좋습니다.
• 캐시 404(찾을 수 없음) 페이지 – 기본적으로 W3TC는 이 옵션을 비활성화 상태로 유지합니다. 그 이유는 "Disk Enhanced" 페이지 캐싱 방법을 사용하는 경우 캐싱 동작 때문일 수 있습니다. 해당 옵션을 선택하면 404페이지가 200 응답 코드를 반환합니다. 이상적으로는 404 페이지가 404 응답 코드를 반환해야 하므로 캐싱 구성으로 이 설정을 테스트하여 호환되는지 확인하는 것이 좋습니다.
• 로그인한 사용자의 페이지를 캐시하지 않음 – 이 옵션을 활성화하는 것이 좋습니다. 로그인한 사용자는 일반적으로 페이지 업데이트 작업을 하고 있습니다. 캐싱이 활성화되면 사용자는 페이지 업데이트를 확인하기 위해 캐시를 지속적으로 지워야 합니다.
• 특정 사용자 역할의 페이지를 캐시하지 않음 – 이 옵션을 사용하면 특정 WordPress 사용자 역할에 대한 캐시를 우회할 수 있습니다. "로그인한 사용자의 페이지를 캐시하지 않음" 옵션이 이미 활성화된 경우 이 옵션은 캐시 동작에 영향을 미치지 않습니다.

별칭

W3 Total Cache의 "별칭" 기능을 사용하면 다른 도메인에서 사용할 수 있는 동일한 WordPres 콘텐츠를 캐시할 수 있습니다. 이 기능을 활성화하지 않는 것이 좋습니다. 다른 도메인(예: domain.com 및 www.domain.com)을 통해 WordPress 사이트에 액세스할 수 있는 경우 Google 및 기타 검색 엔진의 중복 콘텐츠 불이익을 피하기 위해 요청을 기본 도메인으로 전달하도록 301 리디렉션 규칙을 설정하는 것이 가장 좋습니다.

캐시 미리 로드

"캐시 미리 로드" 기능은 사이트맵을 크롤링하고 사이트 페이지에 페이지 캐시를 미리 로드하도록 요청합니다. 대부분의 사이트에서는 잠재적인 성능 이점을 상쇄하는 서버 리소스 스파이크를 유발할 수 있으므로 캐시 미리 로드를 비활성화하는 것이 좋습니다.

캐시 사전 로드를 활성화하려는 경우 W3TC를 사용하여 사이트맵 URL, 업데이트 간격 및 간격당 페이지를 지정할 수 있습니다. CPU 스파이크 가능성을 줄이기 위해 "업데이트 간격"과 "내부 페이지당 페이지 수"를 너무 높게 설정하지 않았는지 확인하십시오.

퍼지 정책

W3TC의 "제거 정책"을 사용하면 게시물이 게시되거나 편집된 후 자동으로 제거하려는 페이지와 피드를 지정할 수 있습니다. 대부분의 사이트에서 기본 설정(첫 페이지, 게시물 페이지 및 블로그 피드)이면 충분합니다. 제거 정책에 페이지를 추가하려는 경우 다양한 옵션을 구성할 수 있습니다.

REST API

WordPress에 포함된 REST API를 사용하면 JSON 형식 데이터를 쿼리할 수 있습니다. REST API는 다양한 플러그인에서 사용되며 헤드리스 WordPress 설정에 중요합니다. REST API의 정확한 사용 사례에 따라 쿼리 결과를 캐싱하는 것이 좋습니다. REST API 캐싱은 "필요한 경우 알 수 있습니다" 범주에 속하므로 REST API 캐싱을 활성화할지 여부가 확실하지 않은 경우 "캐시하지 않음"으로 두는 것이 좋습니다.

고급의

W3TC의 "고급" 페이지 캐시 옵션에서 "수락된 쿼리 문자열", "거부된 사용자 에이전트", 세분화된 캐시 우회 설정 등을 포함한 다양한 설정을 사용자 지정할 수 있습니다. 예를 들어 특정 카테고리나 태그 아래에 게시물을 캐시하지 않도록 W3 Total Cache를 구성해야 하는 경우 "고급" 옵션에서 이를 수행할 수 있습니다.

이러한 설정은 사이트별로 다를 수 있으므로 제공할 수 있는 "권장 설정"이 없습니다. 즉, 사이트 페이지 캐싱 동작의 매우 구체적인 측면을 사용자 지정하려는 경우 고급 옵션을 확인하십시오.

W3 총 캐시 설정 - 축소

다음으로 W3 Total Cache의 "Minify" 설정을 살펴보겠습니다.

• URL 구조 다시 쓰기 – 이 설정은 축소된 자산의 URL 구조에 영향을 줍니다. URL이 "예쁘게" 보이도록 활성화된 상태로 유지하는 것이 좋습니다.
• 로그인한 사용자에 대해 축소 비활성화 – 문제 해결 또는 디버깅을 수행하는 경우 로그인한 사용자에 대해 축소를 비활성화하는 것이 도움이 될 수 있습니다. 그렇지 않으면 이 옵션을 비활성화된 상태로 유지하는 것이 좋습니다.

HTML 및 XML

"HTML 및 XML" 섹션에서 HTML 축소 설정을 구성할 수 있습니다.

• 인라인 CSS 축소 – 인라인 CSS에서 공백을 제거하려면 이 옵션을 활성화하는 것이 좋습니다.
• 인라인 JS 축소 – 인라인 JavaScript에서 공백을 제거하려면 이 옵션을 활성화하는 것이 좋습니다. 경우에 따라 JS 축소로 인해 코드 오류가 발생할 수 있습니다. 이 옵션을 활성화하면 사이트 기능이 중단되면 비활성화하십시오.
• 피드 축소 안 함 – 이 옵션을 비활성화된 상태로 유지하는 것이 좋습니다. 피드는 RSS 리더 및 기타 유사한 서비스에서만 사용되므로 피드를 축소할 필요가 없습니다.
• 줄 바꿈 제거 – 이 옵션은 기본적으로 비활성화되어 있으며 사이트가 올바르게 렌더링되도록 활성화하지 않는 것이 좋습니다.

JS

"JS" 섹션에서 JavaScript 축소 설정을 구성할 수 있습니다.

• 영역에서의 작업 – 이 옵션을 사용하면 축소된 JavaScript의 "포함 유형"을 선택할 수 있습니다. 이전 JS 파일의 경우 그리고 후에 , "차단", "비차단", "비동기를 사용한 비차단" 및 "지연을 사용한 비차단" 중에서 선택할 수 있습니다. 비차단 로드 방법은 일반적으로 더 나은 성능을 제공하지만 모든 JavaScript 코드와 항상 100% 호환되는 것은 아닙니다. 또한 "async"와 "defer"는 사용 사례가 매우 다릅니다. 따라서 비차단 JavaScript의 단점을 모르는 경우 기본 "차단" 방법을 사용하는 것이 좋습니다.
• 축소 또는 결합만 – JavaScript에 대한 두 가지 최적화 모드 중에서 선택할 수 있습니다. "Minify"를 선택하면 JS 파일이 결합되고 축소됩니다. "Combine Only"를 선택하면 결과로 결합된 JS 파일이 축소되지 않습니다. 축소 관련 문제가 발생하고 문제를 일으키는 스크립트를 찾기 위해 디버그하지 않으려는 경우 "결합만" 옵션을 선택하면 오류가 수정될 수 있습니다.
• HTTP/2 푸시 – 서버가 HTTP/2 서버 푸시를 지원하는 경우 이 옵션을 활성화하면 페이지 로드 시간을 줄이는 데 도움이 될 수 있습니다. HTTP/2 서버 푸시는 요청되기 전에 방문자에게 파일을 푸시합니다. 서버 푸시는 종종 오용되기 때문에 프로덕션 환경에서 이 옵션을 활성화하기 전에 적절한 테스트를 수행하는 것이 좋습니다. 서버 푸시는 더 큰 JavaScript 파일에 적합하지 않으며 방문자의 브라우저 캐시에서 직접 JS 파일을 로드하는 것보다 이점이 더 큰지 확인하고 싶을 것입니다.

CSS

"CSS" 섹션에서 CSS 축소 설정을 구성할 수 있습니다.

• 결합 전용 – JavaScript 파일과 달리 CSS는 일반적으로 축소 관련 문제를 겪지 않습니다. 따라서 "결합만"을 활성화하지 않는 것이 좋습니다.
• 보존된 주석 제거 – 이 설정은 CSS 파일에서 주석을 제거합니다. 파일 크기를 최대한 줄이려면 이 옵션을 활성화하는 것이 좋습니다.
• 줄 바꿈 제거 – 이 설정은 CSS 파일에서 줄 바꿈을 제거합니다. 이 옵션도 활성화하는 것이 좋습니다. "줄 바꿈 제거"를 활성화한 후 디스플레이 문제를 발견하면 비활성화하십시오.

고급의

"고급" 섹션에는 축소 동작을 사용자 지정하기 위한 몇 가지 추가 설정이 포함되어 있습니다.

• 외부 파일 업데이트 간격 – W3TC를 사용하면 CSS와 JS 파일 업데이트 사이의 시간을 지정할 수 있습니다. 기본 설정인 86400초를 사용하면 자산이 24시간마다 다운로드되고 축소됩니다. 사이트가 자주 변경되지 않는 경우 자유롭게 기간을 더 길게 설정할 수 있습니다.
• Garbage Collection Interval – 이 기간 설정은 만료된 캐시 데이터가 삭제되는 빈도를 지정합니다. 기본 설정은 24시간입니다. 사이트에 저장 공간이 부족한 경우 "가비지 수집 간격"을 낮추는 것이 좋습니다.

"고급" 섹션의 나머지 부분에는 축소해서는 안 되는 자산 파일을 지정할 수 있는 입력 필드가 포함되어 있습니다. 특정 사용자 에이전트에 축소되지 않은 파일을 제공할 수 있는 "거부된 사용자 에이전트" 필드도 있습니다. 마지막으로 W3 Total Cache의 축소 프로세스에 포함될 외부 자산 파일을 추가할 수 있습니다.

W3 총 캐시 설정 - 개체 캐시

다음 목록은 W3TC의 "개체 캐시" 설정입니다. 대부분의 사이트에서 기본 설정은 잘 작동하지만 상관없이 살펴보겠습니다.

• 캐시 개체의 기본 수명 – 변경되지 않은 캐시 항목의 만료 시간입니다. 기간이 길수록 개체 캐시가 커집니다. 서버의 저장 용량이 걱정된다면 기본값을 유지하거나 낮추는 것이 좋습니다.
• Garbage Collection Interval – 이 설정은 만료된 캐시 데이터가 폐기되는 빈도를 지정합니다. 대부분의 사이트에서 기본값인 3,600초(1시간)가 적당합니다.
• 전역 그룹 - 이 설정을 사용하면 단일 다중 사이트 네트워크의 사이트 간에 공유 캐싱 그룹을 구성할 수 있습니다. 특별한 이유가 없는 한 이 설정을 기본 상태로 두는 것이 좋습니다.
• 비영구 그룹 – 이 설정을 사용하면 캐시하지 않을 개체 그룹을 선택할 수 있습니다. 다시 말하지만 기본 구성을 고수하는 것이 좋습니다.
• wp-admin 요청에 대한 캐싱 활성화 – 이 옵션은 기본적으로 비활성화되어 있으며 부작용이 발생할 수 있으므로 활성화하지 않는 것이 좋습니다. 또한 대부분의 WordPress 사이트 방문자는 wp-admin 대시보드와 상호 작용하지 않습니다.

W3 총 캐시 설정 - 브라우저 캐시

Kinsta를 포함한 대부분의 WordPress 호스트는 이미 웹 서버 수준에서 적절한 브라우저 캐싱 헤더를 구현합니다. 호스트가 그렇지 않거나 브라우저 캐싱 동작을 추가로 사용자 지정하려는 경우 W3 Total Cache를 사용하여 그렇게 할 수 있습니다.

"브라우저 캐시" 설정에서 "일반", "CSS 및 JS", "HTML 및 XML" 및 "미디어 및 기타 파일" 섹션에 대한 기본 설정은 대부분의 WordPress 사이트에 적합합니다. 이 페이지에는 많은 설정이 있으므로 브라우저 캐싱 동작을 변경하기 전에 개발자와 상의하는 것이 좋습니다. 다음은 브라우저 캐싱과 관련하여 주의해야 할 몇 가지 주요 설정입니다.

• 헤더 수명 만료 - 효율적인 브라우저 캐싱을 위해서는 "헤더 수명 만료"를 길게 구성하는 것이 중요합니다. Kinsta에서는 CSS, JS, 이미지 및 글꼴과 같은 정적 자산에 대해 1년 수명을 적용합니다. W3TC를 사용하여 브라우저 캐싱을 구성하는 경우 이 값을 31536000 (1년)으로 설정해야 합니다.
• 캐시 제어 정책 – 브라우저에서 정적 자산을 캐시할 수 있도록 하려면 "캐시 제어 정책"이 "public, max_age=EXPIRES SECONDS"로 설정되어 있는지 확인하십시오.
• HTTP(gzip) 압축 활성화 – GZIP 압축은 방문자에게 보내기 전에 HTML 페이지 및 자산의 파일 크기를 크게 줄이므로 호스트의 서버 구성이 GZIP을 지원하는 경우 이 옵션을 활성화해야 합니다. 사이트가 Kinsta에서 호스팅되는 경우 기본 구성의 일부로 이미 활성화되어 있기 때문에 W3TC에서 GZIP 압축을 활성화할 필요가 없습니다.
• 정적 리소스에서 쿼리 문자열 제거 – 쿼리 문자열은 요청 매개변수를 지정하거나 웹 서버가 새로운 자산을 전달하도록 하기 위해 URL 경로 끝에 추가되는 추가 문자열입니다. 쿼리 문자열은 ? , 대부분의 웹 서버는 쿼리 문자열이 있는 요청에 대해 캐시를 우회하도록 구성되어 있습니다. 페이지 요청에서 쿼리 문자열을 제거하면 이러한 요청이 페이지를 렌더링하는 데 PHP를 사용하기 때문에 서버 로드를 줄이는 데 도움이 됩니다. W3 Total Cache의 정적 리소스에서 쿼리 문자열을 제거하는 것은 권장하지 않습니다. 쿼리 문자열은 방문자에게 최신 버전의 CSS 및 JS 파일을 전달하는 데 도움이 되기 때문입니다.

"브라우저 캐시" 설정 페이지에는 콘텐츠 보안 정책(CSP) 및 X-XSS 보호와 같은 보안 헤더와 관련된 다양한 설정도 포함되어 있습니다. 잘못된 구성은 사이트의 사용자 경험에 직접적인 영향을 줄 수 있으므로 항상 자격을 갖춘 개발자와 협력하여 이러한 설정을 검토하는 것이 좋습니다. 예를 들어 적절한 SSL 인증서 및 HTTPS 구성 없이 HSTS 헤더를 활성화하면 사이트에 액세스할 수 없게 될 수 있습니다.

W3 총 캐시 설정 - 사용자 에이전트 그룹

W3 Total Cache의 "사용자 에이전트 그룹" 기능은 사용자의 장치 유형에 따라 트래픽을 리디렉션해야 하는 경우 매우 강력합니다. 예를 들어 사용자가 휴대전화에서 사이트를 방문하는 경우 다른 테마로 렌더링하도록 사이트를 구성할 수 있습니다. 마찬가지로 모바일 사이트가 고유한 하위 도메인에 있는 경우 사용자를 완전히 다른 사이트로 리디렉션할 수 있습니다.

반응형 웹 디자인 시대에 이 특정 기능에 대한 사용 사례는 많지 않습니다. 오늘날 가장 좋은 방법은 여러 테마나 모바일 전용 하위 도메인에 의존하는 대신 처음부터 사이트를 반응형으로 만드는 것입니다.

W3 총 캐시 설정 - 리퍼러 그룹

HTTP 리퍼러는 요청이 시작된 위치에 대한 정보를 제공하는 선택적 HTTP 헤더입니다. 예를 들어 방문자가 Google 검색 목록에서 사이트를 클릭하는 경우 HTTP 리퍼러는 google.com 입니다.

W3 Total Cache에서 "Referrer Groups"를 사용하여 요청의 HTTP 참조 페이지를 기반으로 사용자 지정 캐싱 동작을 정의할 수 있습니다. 예를 들어 검색 엔진으로 구성된 리퍼러 그룹을 만들고 해당 도메인의 요청에 대해서만 캐싱 동작을 사용자 지정할 수 있습니다.

위에서 언급한 "사용자 에이전트 그룹"과 유사하게 "리퍼러 그룹" 기능을 사용하여 요청을 다른 도메인으로 리디렉션할 수도 있습니다. 대부분의 WordPress 사이트는 리퍼러 그룹을 설정할 필요가 없으므로 구성하지 않는 것이 좋습니다.

W3 총 캐시 설정 - 쿠키 그룹

W3 Total Cache가 지원하는 최신 캐싱 그룹은 "쿠키 그룹"입니다. 이 기능을 사용하면 요청의 쿠키를 기반으로 고유한 캐싱 버킷 및 동작을 생성할 수 있습니다. "사용자 에이전트 그룹" 및 "참조 그룹"과 유사하게, 대부분의 사이트는 사용자 지정 쿠키 기반 캐싱 구성을 설정할 필요가 없습니다. 사이트에 쿠키 기반 캐싱이 필요한 경우 개발자와 협력하여 올바르게 구성하는 것이 좋습니다.

W3 총 캐시 설정 - CDN

이제 W3 Total Cache의 CDN 설정으로 넘어가 보겠습니다.

• 호스트 첨부 파일 – CDN에서 WordPress 미디어 라이브러리의 자산을 제공하려면 이 옵션을 활성화합니다.
• Host wp-includes/ Files – CDN의 wp-includes 폴더에 있는 파일을 제공하려면 이 옵션을 활성화합니다.
• 테마 파일 호스팅 – CDN에서 테마 파일을 제공하려면 이 옵션을 활성화합니다.
• 축소된 CSS 및 JS 파일 호스트 – CDN에서 W3TC의 축소된 CSS 및 JS 파일을 제공하려면 이 옵션을 활성화합니다.
• 사용자 지정 파일 호스트 – 미디어 라이브러리나 테마 폴더에 없는 파일이 있는 경우 W3TC에 파일 경로를 추가하여 CDN에서 제공할 수 있습니다.
• 표준 헤더 추가 – rel=”canonical” 태그는 검색 엔진이 원본 소스 또는 URL을 식별하는 데 도움이 됩니다. CDN은 일반적으로 다른 도메인을 사용하므로 표준 태그를 추가하면 검색 엔진에 원본 자산의 위치를 ​​알립니다. 즉, 최신 검색 엔진은 사이트의 SEO 순위에 영향을 주지 않고 CDN을 식별할 수 있을 만큼 똑똑하기 때문에 이 설정을 비활성화 상태로 유지해도 됩니다.

고급의

• 수동으로 CDN 제거만 - W3TC가 캐시 제거를 자동으로 처리하도록 하려면 이 옵션을 비활성화 상태로 유지하는 것이 좋습니다.
• SSL 페이지에서 CDN 비활성화 – 이 설정을 비활성화된 상태로 유지합니다. CDN을 사용하는 경우 HTTP 및 HTTPS 페이지 모두에서 활성화하는 것이 가장 좋습니다.
• 관리 페이지에서 미디어 라이브러리용 CDN 링크 사용 – 미디어 라이브러리의 URL을 다시 쓰기 때문에 이 옵션을 활성화하지 않는 것이 좋습니다.
• CORS 헤더 추가 – CDN 자산이 다른 도메인에 표시될 수 있도록 이 설정을 활성화된 상태로 유지합니다.
• 다음 역할에 대해 CDN 비활성화 - 이 옵션을 사용하면 특정 WordPress 사용자 역할에 대해 CDN을 비활성화할 수 있습니다. 대부분의 경우 이 옵션을 비활성화된 상태로 유지하는 것이 가장 좋습니다.
• wp-includes 업로드할 파일 형식 – 이 필드는 CDN에서 제공될 wp-includes 의 파일 형식을 지정합니다. 파일 형식의 기본 목록은 대부분의 사이트에 적합합니다. wp-includes 폴더에 사용자 정의 파일이 있는 경우 필요에 따라 자유롭게 형식을 추가할 수 있습니다.
• 업로드할 테마 파일 형식 – 이 필드는 CDN에서 제공될 WordPress 테마 폴더의 파일 형식을 지정합니다. 기본 목록에는 널리 사용되는 모든 자산, 이미지 및 글꼴 형식이 포함되어 있습니다. 필요한 경우 추가 형식을 자유롭게 추가하십시오.
• 사용자 지정 파일 목록 – "사용자 지정 파일 호스트"를 활성화한 경우 이 필드에 파일 목록을 추가하여 CDN에서 제공할 수 있습니다.
• 거부된 사용자 에이전트 – 이 필드를 사용하면 CDN에서 자산을 제공하지 않을 사용자 에이전트를 지정할 수 있습니다. CDN이 제대로 활용되고 있는지 확인하려면 이 필드를 비워 두는 것이 좋습니다.
• 거부된 파일 – 이 필드를 사용하면 CDN에서 제공해서는 안 되는 파일을 지정할 수 있습니다. 사용 중인 서비스가 루트 도메인에서 자산을 제공해야 하는 경우 "거부된 파일" 필드에 파일 경로를 추가할 수 있습니다.

W3 총 캐시 설정 - 사용자 경험

다음으로 W3 Total Cache에서 "사용자 경험" 또는 지연 로딩 설정을 사용자 지정해 보겠습니다.

• HTML 이미지 태그 처리 – 이미지가 지연 로드되도록 하려면 이 옵션을 활성화합니다.
• 배경 이미지 처리 – CSS에서 이미지를 표시하기 위해 '배경'을 사용하는 경우 이 옵션을 활성화하면 해당 이미지가 지연 로드될 수 있습니다.
• 단어 제외 – 이 필드에서 지연 로딩을 우회할 텍스트를 지정할 수 있습니다. 예를 들어 이 필드에 no-lazy-load 를 추가하면 <img src="image.jpg"> 로 표시된 이미지는 지연 로드되지 않습니다.
• 스크립트 포함 방법 – 이 설정을 사용하면 지연 로드 스크립트의 로드 방법을 사용자 지정할 수 있습니다. 기본 async 방법은 대부분의 사이트에 가장 적합한 옵션입니다. 사이트가 단일 방문 페이지로만 구성된 경우 inline 방법을 사용하여 페이지를 로드하기 위한 HTTP 요청 수를 줄일 수 있습니다.

W3 총 캐시에 사용 가능한 확장

W3 Total Cache는 타사 서비스와 통합할 수 있는 다양한 확장 기능을 제공합니다. W3TC에는 현재 다음 서비스에 대한 확장이 있습니다.

• 앰프
• 클라우드플레어
• 구글 피드버너
• 조각 캐시
• 창세기 프레임워크
• 새로운 유물
• 스웜파이
• 요스트 SEO
• WPML

사이트에서 이러한 서비스를 사용하는 경우 W3 Total Cache와의 적절한 호환성을 보장하기 위해 관련 확장을 설정하는 것이 좋습니다. 이 섹션에서는 W3 Total Cache용 Cloudflare 확장을 살펴보겠습니다.

Cloudflare 확장으로 W3 총 캐시를 설정하는 방법

Cloudflare를 W3 Total Cache와 통합하려면 Cloudflare 대시보드에서 계정 이메일과 API 키라는 두 가지 정보가 필요합니다. 계정 이메일은 Cloudflare에 로그인하는 데 사용하는 이메일 주소입니다. Cloudflare API 키를 설정하는 방법을 살펴보겠습니다.

Cloudflare 대시보드에서 "개요" 탭을 클릭합니다. 그런 다음 아래로 스크롤하여 오른쪽 사이드바에서 API 토큰 가져오기를 클릭합니다.

아래로 스크롤하고 "Global API Key" 옆에 있는 보기 를 클릭하여 Cloudflare API 키를 가져옵니다. Be careful not to share this API key anywhere outside W3 Total Cache because it can be used to control your Cloudflare account.

Next, activate the Cloudflare extension in W3 Total Cache's “Extensions” page and click “Settings”. In the “Credentials” section, click on the Authorize button.

In the subsequent popup, input your Cloudflare account email and API key. If you receive an error message, double-check to make sure your email address and API key are correct. After the credentials are authorized, you should see additional Cloudflare settings on the page.

Let's go over the Cloudflare settings in W3 Total Cache.

• Widget Statistics Interval – This specifies the time period covered for W3TC's Cloudflare widget. The default setting is 30 minutes. If you'd like to see a longer time period, feel free to increase it.
• Cache Time – This specifies the amount of time that widget data from Cloudflare is cached. If you don't plan on using the widget much, we recommend increasing this number to reduce the number of requests to Cloudflare from your site.
• Page Caching – If you've configured Cloudflare to cache HTML pages for your WordPress site, enable this option to automatically clear the Cloudflare cache after post modifications and updates.

Cloudflare Caching

This section lets you customize Cloudflare's caching settings.

• Development Mode – Keep this option disabled unless you need to put Cloudflare in Development Mode. When Cloudflare is in Development Mode, edge caching, minification, and image optimization is disabled for three hours. This allows you to see updates to CSS and JS files immediately and is useful for troubleshooting.
• Cache Level – For most sites, we recommend using the “Standard” cache level, which serves a different resource each time the query string changes. If you're 100% sure that your WordPress site does not make use of query strings to serve dynamic content, you can also use the “Ignore Query String” setting as well.
• Browser Cache TTL – We recommend setting Cloudflare's browser cache TTL to 31536000 seconds, which is equal to 1 year.
• Challenge TTL – Cloudflare offers a variety of security-related services, and visitor challenges is one of them. If Cloudflare detects a malicious user or strange behavior, it will serve a challenge message in the form of a Captcha. The “Challenge TTL” setting specifies how long a user will have access to your site after completing a challenge. With the default setting of 3600 seconds, a visitor who was subject to a challenge will be able to use your site for 1 hour before another challenge.
• Edge Cache TTL – This setting controls how long assets will be cached at Cloudflare's edge servers. We recommend setting this to the maximum value of 31536000 seconds, or 1 year.

Cloudflare Content Processing

Let's dive into the Cloudflare content processing settings in W3 Total Cache.

• Rocket Loader – Cloudflare's Rocket Loader speeds up JavaScript loading for your WordPress site. We recommend enabling Rocket Loader if your site has a lot of JS.
• Minify JS/CSS/HTML – If you've already enabled minification for HTML, CSS, and JavaScript in W3 Total Cache, feel free to keep these options in the Cloudflare extension settings disabled, as there is no need to minify assets that have already been minified.
• Server Side Exclude (SSE) – This option allows you to hide sensitive information from suspicious visitors (deemed by Cloudflare). Server-side excludes are useful for hiding information like email address, phone numbers, and other personal information on your site. To use SSE, enable it and wrap sensitive information in <!--sse--><!--/sse--> tags in your HTML code or PHP theme template.
• Email Obfuscation – When this option is enabled, Cloudflare will automatically obfuscate email addresses on your WordPress site with JavaScript. While obfuscation is not going to get rid of email spam completely, we recommend enabling this option because it does deter basic bots from scraping email addresses from your site.

Cloudflare Image Processing

Let's go over Cloudflare's image processing settings.

• Hotlink Protection – Enabling hotlink protection will prevent other sites from embedding your images. If you're running into bandwidth limits due to unauthorized external embeds, enabling “Hotlink Protection” can help you reduce bandwidth usage.
• Mirage (Pro Only) – Mirage optimizes image delivery to low-bandwidth devices and networks. This feature is only available on Cloudflare Pro plan and above.
• Polish (Pro Only) – Polish optimizes your site's images, and can be configured to serve WEBP images to supported browsers. This feature is only available on Cloudflare Pro plan and above.

Cloudflare Protection

Cloudflare's primary feature is a sophisticated firewall that can help protect you against DDoS attacks and malicious actors. Let's go over Cloudflare's security settings.

• Security Level – This setting controls the sensitivity of Cloudflare's firewall and security rules. We recommend setting the “Security Level” to “Medium” for most sites.
• Browser Integrity Check – This feature looks out for bad behavior and suspicious user agents. If it detects a potentially malicious user or spammer, Cloudflare will automatically serve a challenge. We recommend enabling this feature.
• Always Online – This option will serve static HTML pages of your site if your origin goes down. We recommend enabling it if you've configured Cloudflare to cache HTML.
• Web Application Firewall – Cloudflare's WAF, or web application firewall, will scan incoming traffic and filter out “illegitimate traffic” from reaching your site. We recommend enabling this feature.
• Advanced DDoS Protection – This feature is enabled by default, and cannot be disabled as long as Cloudflare's proxy is active. DDoS protection helps shield your site from “distributed denial of service” attacks.
• Max Upload – This sets the maximum allowed file size for uploads to your site. You'll want to make sure that this setting is either equal to or greater than your upload file size setting in WordPress.

Cloudflare SSL

Lastly, you'll want to make sure your Cloudflare SSL settings are configured correctly. Let's go over the right configuration in this section.

• SSL – If your site is hosted on Kinsta, we recommend using either the “Full” or “Full (Strict)” SSL option. The “Flexible” option is not compatible with our infrastructure. “Full Strict” requires an SSL from a valid certificate authority, while the “Full” option also supports self-signed SSLs. The “Flexible” option does not require an SSL certificate on the origin server – we don't recommend this option because it is the most insecure.
• TLS 1.2 Only – TLS, or Transport Layer Security, is a secure protocol for transferring data over a network. Some PCI compliance standards require dropping support for TLS 1.1 and below. If that is a requirement for your site, you can enable the “TLS 1.2 Only” setting in Cloudflare to set the minimum TLS version to 1.2.

추천 자료: WordPress용 Cloudflare APO 설정 방법.

W3 Total Cache WooCommerce 설정

WooCommerce는 WordPress 사이트에서 가장 인기 있는 전자 상거래 플랫폼입니다. WooCommerce 기반 상점에서 W3 Total Cache를 사용하는 경우 고객 세부 정보를 캐싱하지 않도록 구성이 올바른지 확인해야 합니다.

WooCommerce 쿠키 우회

WooCommerce 전용 쿠키가 있는 페이지에 대한 페이지 캐싱을 우회하려면 W3TC의 "페이지 캐시" 설정으로 이동하여 "거부된 쿠키"까지 아래로 스크롤한 다음 아래 4가지 항목을 추가하십시오.

• woocommerce_items_in_cart
• woocommerce_cart_hash
• wp_woocommerce_session_
• wordpress_logged_in

안전을 위해 장바구니 페이지, 결제 페이지 및 계정 페이지와 같은 WooCommerce 전용 URL도 우회하는 것이 좋습니다. 캐싱에서 이러한 페이지를 우회하려면 W3TC의 "페이지 캐시" 설정으로 이동하여 "다음 페이지를 캐시하지 않음" 섹션에 URL을 추가하십시오.

W3 Total Cache의 모든 설정을 재설정하는 방법

어떤 경우에는 W3TC 구성으로 다시 시작해야 할 수도 있습니다. W3 Total Cache를 기본 설정으로 되돌리는 방법은 다음과 같습니다. W3TC의 "일반 설정" 메뉴로 이동하여 "가져오기/내보내기 설정" 섹션으로 스크롤한 다음 기본 설정 복원 을 클릭합니다.

요약

보시다시피 W3 Total Cache 플러그인에는 기능과 설정이 가득합니다. 페이지 캐싱에서 자산 최소화, Cloudflare 통합에 이르기까지 W3TC는 WordPress 사이트의 성능을 높이는 데 필요한 모든 것을 갖추고 있습니다!

이 기사에서는 W3TC용 권장 구성 플러그인을 살펴보았습니다. 좋아하는 WordPress 최적화 플러그인이 있습니까? 아래 의견에 알려주십시오!