W3 Total Cache 플러그인 설정에 대한 전체 가이드

W3 Total Cache – WordPress 웹사이트 캐싱에 가장 널리 사용되는 두 가지 플러그인 중 하나입니다. 오늘은 W3 Total Cache Plugin을 완벽하게 구성하고 설정하는 방법을 자세히 알려드리겠습니다!

W3 Total Cache 설치 자체는 간단하지만 플러그인은 말 그대로 엄청난 수의 옵션으로 당신을 폭격하기 시작합니다. 여기에는 천사가 울게 만들기에 충분합니다. 브라우저 캐싱과 개체 캐싱, 조각 캐싱이 있으므로 그렇지 않은 경우 웹 개발자 당신의 머리는 돌아 다닐 것입니다.

그리고 당신을 정말로 짜증나게 할 또 다른 사실은 당신이 모든 옵션을 선택하고 켤 수 없다는 것입니다. 대부분의 사람들과 마찬가지로 간단한 가상 호스팅이 있는 경우 전체 사이트 속도가 크게 느려질 수 있습니다. 따라서 필요한 캐싱 유형만 선택하여 설정해야 합니다.

1. 일반 설정 W3 총 캐시

W3 Total Cache 설정에는 두 단계가 있습니다. 먼저 일반 설정 탭을 구성해야 합니다. 여기에서 10가지 이상의 다양한 W3 Total Cache 기능을 활성화하거나 비활성화할 수 있습니다. 그런 다음 각 모듈에 대한 설정이 있는 개별 페이지에 액세스할 수 있습니다.

W3 Total Cache를 설치한 후 먼저 일반 설정으로 이동해야 합니다.

우선 일반 설정 탭을 여는 것부터 시작하겠습니다. 일반 설정 페이지에 표시되는 각 옵션을 구성하는 방법은 다음과 같습니다.

1.1 일반

첫 번째 확인란은 모든 W3 Total Cache 옵션을 빠르게 활성화하거나 비활성화할 수 있도록 하기 위한 것입니다. 이 버튼을 누르고 클릭하는 것은 정말 대단한 일이지만 해서는 안 됩니다.

모든 기능이 필요하지 않기 때문에 모든 기능을 별도로 구성하는 것이 항상 좋습니다.

또한 여기에서 미리보기 모드를 켤 수 있습니다. 이 모드에서 모든 변경 사항은 사용자가 확실히 승인할 때까지 실제 라이브 사이트에 영향을 미치지 않습니다. 업로드된 라이브 사이트에서 작업하는 경우 이 모드를 사용해야 합니다. 그러나 새로운 WordPress 설치에서 W3 Total Cache를 설정하거나 사이트에 트래픽이 충분하지 않은 경우 이 모드를 무시하십시오.

1.2 페이지 캐시

다음 확인란은 페이지 캐시입니다. 페이지 캐시가 필요한 것입니다. 페이지 캐싱만으로도 이미 사이트의 성능을 크게 향상시킬 수 있습니다. 이 옵션을 활성화한 후 페이지 캐싱 방식(페이지 캐싱 방식)을 선택해야 합니다.

방법은 호스팅에 따라 다릅니다.

• 가상 호스팅의 경우: 디스크: 고급을 선택합니다.
• 전용 서버 또는 VPS의 경우: Opcode 캐싱 방법 중 하나를 사용할 수 있습니다.

페이지 캐시 방법, 여기에서 페이지 캐시 방법을 선택할 수 있습니다. 기본 – 표준 캐싱, 고급 – 향상된 캐싱, Memcached – 여러 서버용 캐싱. 일반 사이트의 경우 기본적으로 그대로 둡니다.

어떤 종류의 호스팅을 사용하고 있는지 확실하지 않다면 아마도 가상 호스팅이 있을 것입니다. 따라서 확실하지 않은 경우 디스크: 고급 방법을 선택하십시오.

그리고 나중에 관리자 패널의 행 아래에 있는 다음 항목에 대해 자세히 설명하므로 모든 페이지 캐시를 한 번에 사용자 정의해 보겠습니다.

글쎄, 페이지가 캐시됩니다. 여기서는 대부분의 설정이 기본적으로 남아 있지만 조정해야 할 몇 가지 중요한 사항이 있습니다.

먼저 SSL을 사용하는 경우 Cache SSL(https) 요청을 확인해야 합니다. 또한 SSL 사용 여부에 관계없이 캐시 피드 옆의 확인란을 선택합니다.

캐시 프론트 페이지 – WordPress 항목을 캐시하려면 선택합니다.

피드 캐시: 사이트, 카테고리, 태그, 댓글 – 사이트에서 RSS 피드를 사용하는 경우 캐시에 체크 표시를 합니다.

SSL(https) 요청 캐시 – SSL 보안 인증서 https를 사용하는 경우 체크합니다.

쿼리 문자열 변수가 있는 캐시 URI - 사이트의 검색 결과가 있는 페이지 캐싱을 활성화할 수 있습니다.

캐시 404(찾을 수 없음) 페이지 – 페이지 404 오류의 캐싱을 활성화하지만 필수는 아닙니다.

로그인한 사용자의 페이지를 캐시하지 마십시오 . 승인된 사용자에 대한 확인 표시가 있는 페이지는 캐시되지 않습니다. 사이트에 등록이 없으면 활성화하지 마십시오.

다음 사용자 역할에 대해 페이지를 캐시하지 마십시오 . 페이지를 캐시하지 않을 특정 사용자 역할을 선택할 수 있습니다. 사용자 역할 옆의 확인란을 선택합니다. 설정을 저장합니다.

약간 아래로 스크롤하여 자동으로 페이지 캐시 준비 옵션을 활성화합니다. 또한 이벤트 게시 시 포스트 캐시 미리 로드를 선택해야 합니다. 여기에서 숫자를 기본값으로 둘 수 있습니다. Sitemap URL도 추가했는지 확인합니다.

업데이트 간격, 여기에서 새 페이지 캐시가 생성되는 시간 간격을 지정하십시오. 간격이 작을수록 사이트의 부하가 커집니다. 가장 좋은 옵션은 거의 매일 84600입니다.

간격당 페이지 수, 여기에서 한 세션 동안 캐시할 페이지 수를 지정할 수 있습니다. 많은 페이지를 지정하지 마십시오. 페이지가 많을수록 사이트에 다시 로드가 커질수록 기본적으로 떠나는 것이 좋습니다.

사이트맵 URL – 사용하는 경우 여기에 XML 카드의 URL을 입력합니다.

이벤트 게시 시 포스트 캐시 미리 로드 – 여기에 체크하여 새 게시 항목을 캐시합니다.

게시물 작성, 편집 또는 댓글 게시 시 제거할 페이지 및 피드를 지정합니다. 추가 옵션을 사용하면 서버 성능이 저하될 수 있으므로 기본값을 사용하는 것이 좋습니다. 여기에 새 게시물을 만들 때 업데이트될 페이지와 채널을 표시할 수 있습니다. 예를 들어, "댓글 페이지 게시"를 선택하면 페이지에 새 댓글을 추가할 때 페이지가 업데이트됩니다. 모든 값을 표시하는 것은 사이트에 심각한 부하를 줄 수 있으므로 주요 요소만 표시하는 것은 권장되지 않습니다.

제거할 피드 유형을 지정합니다. 여기에서 사이트에서 사용할 수 있는 업데이트에 대한 피드 유형을 확인할 수 있습니다.

한 번에 업데이트해야 하는 페이지 제한 인 퍼지 제한 은 기본적으로 그대로 둡니다.

추가 페이지, 위에 나열되지 않은 업데이트에 대한 추가 페이지를 지정할 수 있습니다.

사이트맵 제거는 여기에서 XML 맵에 대한 정규식을 지정했습니다. 사용하는 경우 기본값으로 두십시오.

늦은 초기화 는 조각난 캐싱에서 WordPress 기능에 대한 지원을 제공합니다. 기능을 활성화하면 서버의 응답 시간이 늘어날 수 있으므로 비활성화하는 것이 좋습니다.

늦은 캐싱 은 초기화 중에 항목 추출을 연기하여 사용자 정의 필터를 통해 페이지 캐싱의 키를 덮어씁니다. 동작.

호환 모드, 확인란을 선택하여 호환 모드를 활성화합니다. 이 기능을 활성화하면 플러그인과 사이트의 호환성에 대한 대가로 사이트 성능이 약 20% 감소합니다. 호환성 문제가 발생하지 않으면 이 기능을 활성화하지 마십시오.

Charset 을 선택하면 UTF-8 인코딩이 비활성화됩니다. 인코딩에 문제가 있는 경우에만 텍스트 대신 낙서가 표시되는지 확인하세요.

HEAD 요청을 거부 하면 HTTP HEAD 요청 캐싱을 비활성화할 수 있습니다. 대부분의 사이트에서 이 기능이 활성화되어 있지 않으므로 건너뜁니다.

가비지 수집 간격, 만료된 캐시를 지우는 기간을 지정합니다. 매일 권장되는 값은 84600입니다.

댓글 쿠키 수명, 여기에 쿠키 수명이 지정되어 있으며 하루에 한 번 권장되는 값은 84600입니다.

허용되는 쿼리 문자열, 항상 캐시해야 하는 URL을 여기에서 지정할 수 있습니다.

거부된 사용자 에이전트 는 여기에서 페이지를 캐시할 필요가 없는 사용자 지정 에이전트(예: Google)를 지정할 수 있습니다.

거부된 쿠키, 캐시되지 않을 페이지 쿠키를 여기에 지정하십시오.

다음 페이지를 캐시하지 마십시오 . 캐시되지 않을 사이트의 디렉토리 또는 섹션 주소를 지정할 수 있습니다.

이러한 범주와 연결된 페이지를 캐시하지 않음 - 지정된 범주 슬러그에 속한 모든 페이지를 항상 무시합니다.

이러한 태그를 사용하는 페이지를 캐시하지 않음 – 지정된 태그 슬러그 아래에 있는 모든 페이지를 항상 무시합니다.

이 작성자의 페이지를 캐시하지 않음 – 항상 지정된 작성자 사용자 이름으로 제출된 모든 페이지를 무시합니다.

이러한 사용자 정의 필드를 사용하는 페이지를 캐시하지 않음 – 항상 지정된 사용자 정의 필드 아래에 있는 모든 페이지를 무시합니다. 등호로 이름-값 쌍을 구분합니다(예: 이름=값).

캐시 예외 목록, 캐싱에서 닫힌 섹션에 있더라도 캐싱될 페이지의 주소를 여기에 지정하십시오.

비 후행 슬래시 페이지 는 슬래시 끝이 없더라도 페이지의 데이터를 캐시합니다. 주소 끝에 슬래시가 있습니다.

페이지 머리글을 지정하면 캐싱을 위해 추가 페이지 머리글을 지정할 수 있습니다.

어디에서나 수행한 작업에 대해 확신이 없으면 모든 것을 그대로 두되 모든 변경 사항을 저장했는지 확인하십시오.

1.3 축소

다음 항목으로 이동: 축소. 축소는 기능 손실 없이 HTML, CSS 및 JavaScript 파일의 기본 압축 및 최적화입니다. 줄 바꿈, 긴 공백과 같은 불필요한 정보를 제거하여 효과를 얻습니다. 이것이 축소된 코드가 사람이 읽기 어려운 이유입니다.

세부 사항에 대해 설명하지 않고 축소는 Google PageSpeed에서 항상 권장하는 것이므로 무시할 수 없습니다.

이 옵션을 활성화하면 W3 Total Cache 에 Hang on! 경고가 표시됩니다. 사이트에 문제가 있을 수 있습니다. 그리고 실제로 나타날 수 있으므로 웹 사이트의 축소를 미세 조정해야 합니다.

축소 모드를 자동 모드로 설정하는 것부터 시작하겠습니다. 특히 사용자 정의 JavaScript를 사용하는 경우 웹 사이트 오작동이 발생할 가능성이 적습니다. 사이트가 정상적으로 작동하지 않으면 설정을 가지고 놀아보십시오. 이러한 경우 일반적인 권장 사항은 축소를 위해 Autooptimize 플러그인으로 전환하거나 W3 Total Cache에서 이 옵션을 아예 끄는 것입니다. 축소 기능이 내장된 CloudFlare CDN 서비스를 사용할 수도 있습니다. 그러나 절대적으로 동시에 두 개의 플러그인을 사용하지 마십시오. 불필요합니다. 축소를 위한 하나의 솔루션 또는 다른 하나.

W3 Total Cache 최소화를 먼저 시도하십시오. 이 방법이 사이트가 이전처럼 일관되고 안정적으로 작동한다는 것을 보장하지는 않습니다.

자동으로 압축할 파일을 최소화하려면 자동 축소 모드를 선택하는 것이 좋습니다. 수동 모드에서는 압축할 파일을 지정해야 합니다.

나머지 설정은 기본적으로 그대로 두고 저장합니다.

축소의 긍정적인 효과는 설정을 위한 노력의 가치가 있습니다.

축소 섹션은 설정하기가 쉽지 않을 수 있습니다. 결국, 당신이 무언가를 시도하지 않는 동안, 당신은 그것이 당신의 사이트에 어떤 영향을 미칠지 모릅니다. 따라서 기본 설정으로 시작하는 것이 좋습니다. 그러나 문제가 발생하면 설정에서 약간 작동합니다.

문제를 해결하기 위해 W3 Total Cache 축소의 설정으로 플레이를 시도할 수 있습니다. 그러나 개발자 자신이 아닌 이상 쉽지 않기 때문에 문제에 대해 깊이 들어가야 합니다.

URL 구조 재작성, URL 구조 덮어쓰기, 기본값으로 두십시오.

로그인한 사용자에 대해 축소를 비활성화하고 등록된 사용자에 대해 축소를 비활성화합니다. 등록된 사용자가 많은 경우 축소를 끄지 마십시오.

파일 축소 시 오류가 있는 경우 이메일로 알림을 받으려면 오류 알림 최소화, 여기에서 지정 – 이메일 알림.

HTML 축소 설정 , 활성화 – 축소를 활성화하려면 확인란을 선택하고, 인라인 CSS 축소 – CSS 파일을 축소하려면 확인란을 선택하고, 인라인 JS 축소 – JS 파일을 축소하려면 확인 표시를 하고, 피드를 축소하지 않음 – 확인란을 선택한 경우 , RSS 피드가 축소되지 않음, 줄 바꿈 제거 - 파일의 빈 공간을 삭제하려면 확인란을 선택합니다.

무시된 댓글 줄기, 이러한 용어가 포함된 댓글은 삭제되지 않습니다. google_ad_ 구글 광고.

JS 축소 설정, JavaScript 파일 축소 활성화, 권장 기본값.

CSS 축소 설정, CSS 파일 축소 활성화, 권장 기본값.

자동 파일 이름 길이 테스트 축소 비활성화, 테스트 파일 이름 길이 자동 축소 비활성화, 기본적으로 그대로 둡니다.

외부 파일 을 다운로드하고 업데이트하는 간격으로 외부 파일을 업데이트합니다. 기본적으로 86400 - 하루에 한 번 그대로 둡니다.

가비지 수집 간격, 만료된 캐시 데이터 제거. 기본적으로 86400 - 하루에 한 번 그대로 둡니다.

다음 페이지를 축소하지 마십시오. 축소할 필요가 없는 사이트의 페이지 또는 섹션을 여기에 지정하십시오.

다음 JS 파일을 축소하지 마십시오. 축소할 필요가 없는 JS 파일을 여기에 지정하십시오.

다음 CSS 파일을 축소하지 마십시오. 여기에 축소할 필요가 없는 CSS 파일을 지정하십시오.

거부된 사용자 에이전트 는 축소된 콘텐츠를 수신하지 않을 사용자 지정 에이전트(예: Google, Bing 등)를 여기에 지정합니다.

외부 파일/라이브러리를 포함 하고 여기에 결합해야 하는 외부 파일/라이브러리를 지정합니다. 설정을 저장합니다.

기본적으로 W3 총 캐시 최소화 설정이 문제를 일으키는 경우 자동 최적화로 전환하는 것이 훨씬 쉽습니다. CloudFlare를 사용하는 경우 내장된 CloudFlare 축소를 활용할 수도 있습니다.

따라서 Autooptimize 또는 CloudFlare로 전환하는 경우 일반 설정 탭에서 축소를 비활성화했는지 확인하십시오.

1.4 Opcode 캐시

W3 Total Cache의 최신 버전에는 Opcode 캐싱이 포함됩니다. Opcode 캐시는 W3 Total Cache의 프로 버전에서만 사용할 수 있습니다. 프로 버전이 있는 경우 설정과 테스트 성능을 모두 활성화하십시오. Opcode 캐시는 PHP를 캐시하는 데 사용됩니다. WordPress의 일부는 정기적으로 실행되는 PHP로 작성되었습니다. Opcode 캐시는 성능 향상을 위해 이러한 코드 블록을 캐시할 수 있습니다.

그러나 가상 호스팅이 있는 경우 이 옵션을 활성화하지 못할 수도 있습니다. 대부분의 사용자는 이 옵션을 사용할 수 없으므로 주의를 기울이지 마십시오.

1.5 데이터베이스 캐시

W3 Total Cache의 개발자에 따르면 W3TC는 스위스 칼입니다. 일반적으로 개체 캐시와 데이터베이스 캐시를 디스크에 캐싱하는 것은 권장되지 않습니다.

데이터베이스 캐싱은 데이터베이스에서 프로세서/메모리로 프로세스 실행을 이동하여 사이트를 잠재적으로 향상시킬 수 있습니다. 그러나 문제가 있습니다. 대부분의 가상 호스팅에서 데이터베이스는 프로세서나 메모리보다 부하에 더 잘 작동합니다. 따라서 데이터베이스 캐싱은 서버의 다른 측면에 과부하를 주어 사이트 속도를 저하시킬 수 있습니다.

데이터베이스 캐시 방법 – 기본적으로 일반 사이트에 대한 캐싱 방법이 떠납니다. Memcached – 서버가 여러 개인 경우.

어쨌든 가상 호스팅이 있는 경우 데이터베이스 캐싱을 비활성화된 상태로 두는 것이 좋습니다.

그러나 우리는 또한 다음 행을 통해 당신을 안내할 것입니다:

로그인한 사용자에 대한 쿼리를 캐시 하지 않음, 등록된 사용자에 대한 요청을 캐시하지 않음, 기본적으로 WordPress 동작을 유지하려면 활성화해야 합니다.

캐시 개체의 최대 수명, 여기에서 개체 캐시의 최대 수명을 지정할 수 있습니다. 값이 낮을수록 서버의 부하가 커집니다. 이러한 모든 값에 대해 하루에 한 번(84,600) 기간으로 설정하는 것이 좋습니다.

가비지 수집 간격, 여기에 가비지 수집 간격, 오래된 파일을 지정합니다. 권장 - 하루에 한 번 84 600.

다음 페이지를 절대 캐시하지 말고 여기에 캐시해서는 안 되는 페이지나 섹션을 지정하십시오.

무시된 쿼리 스템, 이 데이터가 포함된 요청을 캐시하지 마십시오.

쿼리 단어를 거부 하고 이러한 단어나 정규 표현식이 포함된 요청을 캐시하지 마십시오.

상수 거부 – 지정된 상수가 정의되면 캐싱을 비활성화합니다.

1.6 개체 캐시

개체 캐싱은 WordPress 사이트를 향상시키거나 WordPress 관리 영역의 작업 속도를 크게 늦출 수 있습니다.

WordPress 관리자가 느린 이유를 이해하려면 우선 개체 캐싱을 비활성화해야 합니다. 그렇기 때문에 개체 캐싱을 비활성화하는 것이 좋습니다. 물론이 모든 것을 테스트 할 수 있지만 가상 호스팅이있는 경우 이러한 종류의 캐시는 유용하지 않을 수 있으며 관리자의 작업 속도가 느려질 가능성이 큽니다.

그러나 여기에는 한 가지 예외가 있습니다. 매우 동적인 프로젝트(예: BuddyPress, bbPress 등)가 있는 경우 개체 캐싱을 고려할 수 있습니다.

그리고 기본적으로 개체 캐시 방법을 그대로 두십시오!

관리자 패널별 세부정보는 다음과 같습니다.

캐시 개체의 수명과 가비지 수집 간격을 설정할 수 있습니다. 기본적으로 시간을 그대로 둡니다. 아래 설정은 다중 사이트와 관련이 있으므로 대부분의 사용자가 건드릴 필요도 없습니다.

캐시 개체 의 기본 수명, 개체 캐시의 기본 수명입니다. 하루에 한 번 84 600을 지정하는 것이 좋습니다.

가비지 수집 간격, 가비지 수집 간격. 하루에 한 번 84 600을 지정하는 것이 좋습니다.

글로벌 그룹 은 네트워크 모드에서 캐싱을 위한 글로벌 그룹을 지정하고 기본값을 그대로 둡니다.

비영구적 그룹은 여기에서 캐시하지 않아야 하는 그룹을 지정합니다.

wp-admin 요청에 대한 캐싱을 활성화합니다. 이 옵션을 활성화하면 wp-admin 성능이 향상되지만 부작용이 발생할 수 있습니다.

데이터베이스에 임시 항목을 저장하고 외부 캐시를 사용하는 경우에도 데이터베이스에 임시 항목을 저장하는 데 사용합니다. 이렇게 하면 개체 캐시 정리/만료 후에도 일시적인 값이 유지됩니다.

1.7 브라우저 캐시

Google PageSpeed ​​Insights를 통해 사이트를 실행한 적이 있다면 브라우저 캐싱 활용이 이 도구에서 가장 좋아하는 메시지라는 것을 알고 있을 것입니다. 그리고 여기에서 이 강화를 적용할 수 있습니다.

브라우저 캐싱은 방문자의 브라우저에서 데이터를 캐싱하여 웹사이트 성능을 향상시키는 간단한 방법입니다. 모든 것이 게스트 컴퓨터의 로컬 데이터 저장소에 따라 달라지므로 사이트 속도가 느려지는 것을 두려워하지 마십시오.

어떤 호스팅을 사용하든 어쨌든 이러한 종류의 캐싱을 활성화해야 합니다!

이제 브라우저 캐시를 철저히 구성해야 합니다.

브라우저 캐싱의 경우 아래 처음 6개를 활성화해야 합니다.

• Last-Modified 헤더 설정
• 만료 헤더 설정
• 캐시 제어 헤더 설정
• 엔티티 태그(eTag) 설정
• W3 총 캐시 헤더 설정
• HTTP(gzip) 압축 활성화

아래로 스크롤하여 WordPress의 정적 개체에 대한 404 오류 처리 안 함을 선택합니다. 나머지는 모두 그대로 두는 것이 좋습니다.

Last-Modified 헤더를 설정 합니다. 여기에 체크 표시가 있어야 브라우저가 사이트에서 마지막으로 변경된 제목 세트에 액세스할 수 있습니다.

만료 헤더 를 설정하면 더 빈번한 파일 캐싱을 위해 브라우저를 자극하도록 만료 헤더를 설정할 수 있지만 필수는 아닙니다. 사이트에 대한 요청 수가 증가하므로 활성화하지 않는 것이 좋습니다.

캐시 제어 헤더 를 설정하면 헤더 제어 캐시 기능을 활성화할 수 있으며, 이 기능은 필요하지 않고 htaccess 파일에 추가됩니다.

엔터티 태그(eTag)를 설정 하고 eTag 태그를 헤드라인에 추가하여 브라우저를 자극할 필요는 없습니다.

W3 Total Cache 헤더를 설정하고 공통 헤더 캐시를 설정하며 필요하지 않습니다.

HTTP(gzip) 압축을 활성화하고, GZIP 압축을 활성화하고, gzip 압축을 이미 활성화했는지 확인한 다음, 이 옵션을 비활성화합니다.

설정 변경 후 개체 캐싱 방지, 변경 후 개체 캐싱 방지, 활성화할 필요가 없습니다.

정적 리소스, "?"가 있는 리소스에서 쿼리 문자열 제거 URL의 일부 프록시 캐싱 서버에서 캐시되지 않습니다.

캐싱 방지 예외 목록, 캐싱을 금지하는 예외 목록.

정적 파일에 대한 쿠키를 설정하지 마십시오 . 활성화할 필요가 없는 정적 파일에 대한 쿠키를 설치하지 마십시오.

WordPress를 사용하여 정적 개체에 대한 404 오류를 처리하지 마십시오 . 활성화할 필요가 없는 WordPress를 사용하여 정적 개체에 대해 404 오류를 처리하지 마십시오.

404 오류 예외 목록, 404 오류 에 대한 예외 목록.

개체의 URL 구조를 다시 작성 하고 브라우저에서 캐싱으로부터 보호하는 각 파일에 대해 고유한 URI를 생성합니다.

CSS 및 JS 파일의 마지막 헤더 변경 세트인 Set Last-Modified 헤더를 활성화해야 합니다.

만료 헤더를 설정 하고 확인란을 선택하여 CSS 및 JS 파일의 만료 헤더에 대한 만료 시간을 지정할 필요는 없습니다.

CSS 및 JS 파일에 대한 캐시 제어를 활성화하는 캐시 제어 헤더를 설정할 필요가 없습니다.

캐시 제어 정책, 기본적으로 그대로 둡니다.

ETag(엔티티 태그) 설정 , CSS 및 JS 파일 헤더에 ETag 태그 추가, 필요하지 않습니다.

CSS 및 JS 파일 헤더에 대한 공통 캐시 인 W3 Total Cache 헤더를 설정 하지 않아도 됩니다.

HTTP(gzip) 압축 을 활성화합니다. 사이트에서 이미 gzip 압축을 사용하는 경우 위 링크를 활성화할 필요가 없습니다.

설정 변경 후 객체 캐싱 방지, CSS 및 JS 파일 변경 후 객체 캐싱 금지, 포함할 필요는 없습니다.

정적 리소스, "?"가 있는 리소스에서 쿼리 문자열 제거 URL의 일부 프록시 캐싱 서버에서 캐시되지 않습니다.

정적 파일에 대한 쿠키를 비활성화 하고 정적 CSS 및 JS 파일에 대한 쿠키를 생성하지 마십시오. 필요하지 않습니다.

HTML 및 XML 파일의 마지막 헤더 변경 세트인 Set Last-Modified 헤드를 활성화해야 합니다.

만료 헤더를 설정 하고 상자를 선택하여 만료 헤더의 수명을 나타냅니다. 권장 시간 84,600초.

캐시 컨트롤 헤더 설정, 컨트롤의 헤더 캐시를 설정할 수 있으며, HTML 및 XML 파일에 대한 캐시 컨트롤은 필요하지 않습니다.

캐시 제어 정책, 캐시 관리 정책은 기본적으로 그대로 둡니다.

엔티티 태그(ETag)를 설정 하면 제목에 ETag 태그를 추가하여 브라우저를 장려할 수 있습니다.

W3 Total Cache 헤더를 설정하고 헤더에 대해 W3 Total Cache를 설정합니다. 필요하지 않습니다.

HTTP(gzip) 압축 활성화, 사이트에서 현재 사용하지 않는 경우에만 gzip 압축 활성화

미디어 기타 파일, 여기에서 기능을 활성화할 수 있습니다. - 만료 헤더 설정, 미디어 파일 캐시의 수명을 지정하려면 기본 수명을 그대로 둡니다. 사이트에서 GZIP 압축이 이미 활성화되어 있는 경우 HTTP(gzip) 압축 활성화 기능을 비활성화합니다. 나머지 설정은 기본적으로 그대로 둡니다. 변경 사항을 저장합니다.

1.8 CDN

CDN을 사용하는 경우 이 옵션을 사용하여 W3 Total Cache에 연결할 수 있습니다. 드롭다운 메뉴에서 CDN 서버를 찾거나 목록에 옵션이 없는 경우 일반 미러를 선택할 수 있습니다.

CloudFlare를 사용하는 경우 여기에서 통합할 필요가 없습니다. 대신 CloudFlare 확장을 추가해야 합니다. 확장 탭에서 이 작업을 수행할 수 있습니다.

CDN을 사용하지 않는 경우 이 상자에 체크 표시를 하지 마십시오. 이미 CDN 공급자가 있는 경우에만 이 옵션을 활성화하십시오.

CDN 유형, 여기에서 CDN 기능을 활성화한 서비스 이름을 선택해야 합니다.

불행히도 설정은 사용 중인 CDN과 사용 여부에 따라 다르기 때문에 이에 대한 정확한 지침을 제공할 수 없습니다. 그러나 운 좋게도 W3 Total Cache는 매우 인기 있는 솔루션이기 때문에 대부분의 CDN 공급자는 구성 프로세스에 대한 자세한 지침을 제공합니다.

이를 염두에 두고 CloudFlare를 WordPress CDN으로 사용하는 경우 확장 탭에서 CloudFlare 확장을 추가해야 합니다.

1.9 역방향 프록시

대부분의 WordPress 사이트는 이 옵션을 무시해야 합니다. 리버스 프록시는 너무 고급스럽고 예리해서 사용할 수 있다면 이 가이드를 읽을 필요가 없을 것입니다!

그러나 다음과 같은 경우:

varnish를 통한 역방향 프록시 캐싱 활성화 – 사이트에서 사용하는 경우 varnish 캐싱을 활성화할 수 있습니다. Varnish는 Facebook과 같이 트래픽이 매우 많은 초대형 사이트용으로 설계되었습니다.

바니시 서버 – 여기에서 바니시용 서버의 IP 주소를 지정해야 합니다.

1.10 모니터링, 조각 캐시, 기타 및 라이선스

New Relic 은 서버 모니터링 기능, 사용자 모니터링, 모바일 모니터링을 연결할 수 있습니다. 이 기능을 사용하면 서버 프로세스 및 사용자 동작 등을 모니터링할 수 있습니다. 이 기능을 활성화할 필요는 없습니다. 모니터링은 유료 기능입니다.

라이선스, 라이선스, 플러그인의 Pro 버전을 구입했다면 여기에 라이선스 키를 입력하고 설정을 저장해야 합니다. 무료 버전의 경우 이 필드를 건너뛰십시오.

Google Page Speed ​​대시보드 위젯 을 활성화하면 Google Page Speed ​​지원을 활성화하여 관리자 패널의 메인 페이지에 서비스 결과가 표시된 위젯을 가질 수 있습니다. 기능을 활성화하려면 API 키를 입력해야 합니다. 탭을 클릭하고 여기에서 API 키를 클릭합니다.

재작성 규칙을 확인하고 이 규칙을 선택하십시오.

파일 잠금을 활성화합니다 . NFS 시스템에서는 파일 잠금을 활성화하지 않는 것이 좋습니다. 그대로 두십시오.

디스크 확장 페이지 최적화 및 NFS용 디스크 캐싱 최소화, 호스팅에서 NFS 네트워크 파일 시스템을 사용하는 경우 이 옵션을 활성화할 수 있습니다. 성능을 향상시키기 위해.

Edge 모드를 활성화 하고 이 탭을 클릭하지 마십시오. 실험적인 플러그인 기능을 확인하면 오류가 발생할 수 있습니다. 설정을 저장합니다.

1.11 디버그 모니터링, 프래그먼트 캐시, 기타 및 라이선스

W3 Total Cache에 문제가 있는 경우 디버그 옵션을 활성화할 수 있지만 일시적으로만 가능합니다. 일반적인 사용을 위해서는 이 모든 상자를 비활성화하십시오. 문제를 해결하는 데 사용되지 않으면 중복 코드가 생성되기 때문입니다.

가져오기/내보내기, 다른 사이트 또는 다른 사이트에서 플러그인 설정을 내보내거나 가져올 수 있습니다. 다른 사이트에서 내보내려면 버튼을 클릭하십시오 – 파일 선택. 다른 사이트로 가져오려면 버튼을 클릭하십시오 – 다운로드.

항상 변경 사항을 저장하는 것을 잊지 마십시오.

2. W3 총 캐시 확장

CloudFlare 확장은 이미 언급되었지만 W3 Total Cache에는 다른 많은 도구에 대한 확장도 포함되어 있습니다.

예를 들어 다음과 같은 확장이 있습니다.

• Google AMP 페이지
• 클라우드플레어
• 피드버너
• 제네시스 프레임워크(제네시스를 사용하는 경우 반드시 설치)
• 요스트 SEO
• WPML(번역에 WPML을 사용하는 경우 설치하십시오).

각 확장에는 몇 가지 구성이 필요합니다. 예를 들어 CloudFlare를 활성화하면 API 활성화 키를 입력해야 합니다. 그런 다음 W3 Total Cache에서 직접 CloudFlare 기능으로 작업할 수 있습니다.

3. 기타 설정

사용자 에이전트 그룹, 여기에서 선택한 각 장치 또는 장치 그룹에 대해 캐시를 생성하기 위한 사용자 에이전트 그룹을 생성할 수 있습니다. 지정된 장치가 감지될 때 리디렉션이 수행될 제목 또는 도메인을 지정할 수 있습니다.

리퍼러 그룹 은 위와 동일하며 검색 엔진, 브라우저에만 해당됩니다.

모니터링, 모니터링 기능을 구성합니다. 이 기능은 중요하지 않습니다.

이 플러그인 작업에 대한 FAQ, 질문 및 답변.

지원, 여기에서 플러그인 지원에 편지를 쓸 수 있습니다. 질문의 주제를 선택할 수도 있습니다.

플러그인의 성능에 대한 데이터를 설치합니다 . 이 플러그인을 설치한 후 사이트에 변경된 사항은 다음과 같습니다.

사용할 수 있는 추가 플러그인 기능 정보 .

4. 너무 복잡합니까? 다른 캐싱 플러그인을 선택하십시오

W3 Total Cache – 플러그인은 확실히 강력하고 숙련된 사용자에게 훌륭한 솔루션이 될 것이지만 초보자에게는 보다 사용자 친화적인 캐싱 플러그인을 사용하는 것이 좋습니다! 예를 들어 Cache Enabler, WP Super Cache 또는 멋진 WP-Rocket이 있습니다. W3 Total Cache를 설정하는 데 1시간이 소요되는 반면 Cache Enabler의 경우에는 1분이면 됩니다!

Cache Enabler는 그 자체로 데이터베이스 캐시, 객체 캐시 등에 대한 구성 옵션이 없습니다. 그러나 일반 WordPress 사용자는 이 기능이 필요하지 않습니다. 감사합니다. 최적화에 행운을 빕니다!

WordPress 웹사이트에서 W3 Total Cache 플러그인을 설정하는 데 도움이 되었기를 바랍니다. 아래 의견에서 이 플러그인에 대한 경험을 공유하십시오.