WP 수퍼 캐시

설명

이 플러그인은 동적 워드프레스 블로그에서 정적 html 파일을 생성합니다. html 파일이 생성되면 웹서버는 상대적으로 무겁고 비용이 많이 드는 워드프레스 PHP 스크립트를 처리하는 대신 해당 파일을 서비스합니다.

정적 HTML 파일은 대다수의 사용자에게 제공됩니다:

  • 로그인하지 않은 사용자.
  • 블로그에 댓글을 남기지 않은 사용자.
  • 또는 비밀번호로 보호된 글을 본 적이 없는 사용자도 마찬가지입니다.

방문자의 99%에게 정적 HTML 파일이 제공됩니다. 하나의 캐시된 파일은 수천 번 제공될 수 있습니다. 다른 방문자에게는 해당 방문자에 맞는 맞춤형 캐시 파일이 제공됩니다. 방문자가 로그인했거나 댓글을 남긴 경우 해당 세부 정보가 표시되고 캐시됩니다.

플러그인은 캐시된 파일을 3가지 방식으로 제공합니다(속도에 따라 순위가 매겨짐):

  1. 전문가. 가장 빠른 방법은 Apache mod_rewrite(또는 웹 서버에서 지원하는 유사한 모듈)를 사용하여 “수퍼 캐시된” 정적 html 파일을 제공하는 것입니다. 이 방법은 PHP를 완전히 우회하며 매우 빠릅니다. 서버에 트래픽이 폭주하는 경우 요청이 “가벼워지므로” 대처할 가능성이 더 높습니다. 하지만 이 방법을 사용하려면 사용자 정의 퍼머링크가 있는 경우 설치되어 있는 Apache mod_rewrite 모듈과 잘못 수정하면 사이트가 다운될 수 있는 .htaccess 파일을 수정해야 하므로 위험할 수 있습니다.
  2. 간단합니다. 수퍼캐시된 정적 파일은 PHP에서 제공할 수 있으며 플러그인 사용 시 권장되는 방식입니다. 플러그인은 “수퍼캐시된” 파일이 존재할 경우 이를 제공하며 mod_rewrite 메서드만큼 빠릅니다. .htaccess 파일을 변경할 필요가 없으므로 구성하기가 더 쉽습니다. 여전히 사용자 정의 퍼머링크가 필요합니다. 이 캐싱 모드에서는 페이지의 일부를 동적으로 유지할 수 있습니다.
  3. WP-Cache 캐싱. 주로 알려진 사용자, 매개변수가 있는 URL 및 피드에 대한 페이지를 캐시하는 데 사용됩니다. 알려진 사용자란 로그인한 사용자, 댓글을 남긴 방문자 또는 사용자별 맞춤 데이터를 표시해야 하는 사용자를 말합니다. 가장 유연한 캐싱 방법이지만 약간 느립니다. 수퍼캐싱이 비활성화되어 있으면 알 수 없는 사용자의 방문도 WP 캐시 캐싱이 캐시합니다. 이 모드에서도 페이지에 동적 부분을 포함할 수 있습니다. 이 모드는 항상 활성화되어 있지만 알려진 사용자, 매개변수가 있는 URL 또는 피드에 대한 캐싱을 개별적으로 비활성화할 수 있습니다. WP 캐시 캐싱만 사용하려면 wp-config.php에서 상수 “DISABLE_SUPERCACHE”를 1로 설정하세요.

PHP 파일 편집에 익숙하지 않다면 간편 모드를 사용하세요. 설정하기 쉽고 매우 빠릅니다.

권장 설정

  1. 간단한 캐싱.
  2. 페이지 압축.
  3. 알려진 사용자에 대한 페이지를 캐시하지 않습니다.
  4. 캐시 재구축.
  5. CDN 지원.
  6. 추가 홈페이지 검사.

가비지 컬렉션은 오래되고 오래된 캐시 파일을 정리하는 작업입니다. 만료 시간에 대한 정확한 값은 없지만 1800초가 좋은 시작점입니다.

“거부된 사용자 에이전트” 텍스트 상자의 내용을 삭제하고 검색 엔진이 파일을 캐시하도록 허용하는 것도 고려해 보세요.

가능한 한 많은 글을 미리 로드하고 ‘미리 로드 모드’를 활성화합니다. 캐시된 오래된 파일의 가비지 수집이 비활성화됩니다. 사이드바 위젯 업데이트에 신경 쓰지 않는다면 모든 글이 자주 다시 불러오지 않도록 미리 로드 간격을 2880분(2일)으로 설정하세요. 사전로드가 발생하면 새로 고쳐지는 글의 캐시 파일이 삭제된 다음 다시 생성됩니다. 그 후 오래된 캐시 파일을 정리하기 위해 모든 오래된 파일의 가비지 컬렉션이 수행됩니다.↵
사전 로드 모드가 활성화되어 있어도 글이 수정되거나 댓글이 작성되면 캐시 파일이 삭제됩니다.

개발

  • 이 플러그인의 활발한 개발은 GitHub에서 처리되고 있습니다.
  • 플러그인을 다른 언어로 번역하는 방법은 번역 페이지에서 확인할 수 있습니다.

문서

아래 내용보다 더 자세한 정보가 필요한 경우 위키 또는 개발자 문서에서 확인할 수 있습니다.

미리 로드

사전 로딩을 통해 사이트의 글, 카테고리 및 태그에 대한 캐시 파일을 생성할 수 있습니다. 사전 로딩은 다른 사이트 방문자와 마찬가지로 사이트의 각 페이지를 방문하여 캐시된 페이지를 생성합니다. 이 기능의 순차적 특성으로 인해 글이 많은 경우 전체 사이트를 미리 로드하는 데 다소 시간이 걸릴 수 있습니다↵.
사전 로딩의 효율성을 높이려면 오래된 캐시 파일이 삭제되지 않도록 가비지 컬렉션을 비활성화하면 유용할 수 있습니다. 설정에서 ‘미리 로드 모드’를 활성화하면 됩니다. 하지만 댓글을 제출하거나 글을 수정하여 페이지를 업데이트하면 캐시의 일부가 지워질 수 있다는 점에 유의하세요.

가비지 컬렉션

캐시 디렉토리는 시간이 지남에 따라 가득 차서 서버의 공간을 차지합니다. 공간이 제한되어 있거나 용량에 따라 요금이 청구되는 경우 또는 사이트의 캐시된 페이지가 부실해질까 걱정된다면 가비지 컬렉션을 수행해야 합니다. 가비지 컬렉션은 정기적으로 수행��며 캐시 디렉터리에서 오래된 파일을 삭제합니다. 고급 설정 페이지에서 ↵ 다음을 지정할 수 있습니다.
1. 캐시 시간 초과. 캐시 파일을 새 파일로 간주하는 기간입니다. 이 시간이 지나면 오래된 파일로 간주되어 삭제할 수 있습니다.↵
2. 스케줄러. 가비지 컬렉션을 수행할 빈도를 설정합니다.↵.
3. 알림 이메일. 가비지 컬렉션 작업 진행 상황에 대한 알림을 받을 수 있습니다 ↵.
가비지 컬렉션에 대한 옳고 그름의 설정은 없습니다. 회원님의 사이트에 따라 다릅니다.↵
사이트에서 정기적으로 업데이트 또는 댓글을 받는 경우 시간 제한을 1800초로 설정하고 타이머를 600초로 설정하세요.
사이트가 대부분 정적인 경우 시간 제한을 0으로 입력하여 가비지 수집을 비활성화하거나 매우 큰 시간 제한 값을 사용할 수 있습니다.

캐시 디렉터리(일반적으로 wp-content/cache/)는 임시 파일만 저장합니다. 중요한 파일이나 중요한 파일이나 디렉터리에 대한 심볼릭 링크를 해당 디렉터리에 넣지 마세요. 플러그인에 쓰기 권한이 있는 경우 삭제됩니다.

CDN

CDN(콘텐츠 전송 네트워크)은 일반적으로 전 세계에 위치한 컴퓨터 네트워크로, 회원님과 가까운 서버를 사용하여 웹사이트의 콘텐츠를 더 빠르게 제공합니다. 이미지, 자바스크립트, CSS 파일과 같은 정적 파일은 이러한 네트워크를 통해 제공되어 사이트 로딩 속도를 높일 수 있습니다. 도메인의 하위 도메인을 사용하여 정적 파일을 서비스하는 ‘가난한 사람의 CDN’을 만들 수도 있습니다.

OSSDL CDN 오프링커가 WP 수퍼 캐시에 통합되어 기본적인 CDN 지원을 제공합니다. 이 기능은 서버의 wp-content 및 wp-includes에 있는 파일(.php 파일 제외)의 URL을 다른 호스트 네임을 가리키도록 다시 작성하는 방식으로 작동합니다. 많은 CDN이 origin pull를 지원합니다. 즉, CDN은 파일이 처음 요청될 때 서버에서 자동으로 파일을 다운로드하고 구성 가능한 시간 동안 파일을 계속 제공한 후 서버에서 다시 다운로드합니다.

플러그인 설정 페이지의 “CDN” 탭에서 이 기능을 구성합니다. 이는 고급 기술이며 웹서버 또는 CDN의 작동 방식에 대한 기본적인 이해가 필요합니다. CDN을 구성한 후에는 반드시 파일 캐시를 지워야 합니다.

REST API

이제 이 플러그인의 설정에 액세스할 수 있는 REST API 엔드포인트가 있습니다. 이를 사용하려면 설정 페이지를 볼 수 있는 권한이 있는 관리자 사용자로 인증받아야 합니다. 아직 문서화되어 있지 않지만 이와 관련된 모든 코드는 “rest” 디렉토리에서 찾을 수 있습니다.

사용자 정의 캐싱

이제 add_cacheaction() 함수를 사용하여 캐싱 프로세스에 연결할 수 있습니다.

세 가지 후크를 사용할 수 있습니다:

  1. ‘wp_cache_get_cookies_values’ – WP 캐시에서 사용하는 키를 수정합니다.
  2. ‘add_cacheaction’ – 2단계에서 실행됩니다. 플러그인이 워드프레스 훅을 추��할 수 있도록 합니다.
  3. ‘cache_admin_page’ – 관리자 페이지에서 실행됩니다. 새 구성 옵션을 추가하는 등 해당 페이지를 수정하는 데 사용합니다.

일반 워드프레스 필터도 하나 있습니다. “do_createsupercache” 필터↵를 사용하세요.
를 사용하여 캐싱 전 검사를 사용자 정의할 수 있습니다. 이 필터는 하나의 매개변수를 허용합니다↵.
WP-Cache의 wp_cache_get_cookies_values() 함수의 출력입니다.

WP 수퍼 캐시에는 자체 플러그인 시스템이 있습니다. 이 코드는 WP 수퍼 캐시가 로드될 때 로드되며 캐싱 수행 방식을 변경하는 데 사용할 수 있습니다. 이는 대부분의 워드프레스가 로드되기 전이므로 일부 기능을 사용할 수 없습니다. 플러그인은 PHP가 로드할 수 있는 모든 곳에 위치할 수 있습니다. 직접 플러그인을 추가할 수도 있습니다:

  • 플러그인을 wp-content/plugins/wp-super-cache-plugins 디렉토리에 넣거나
  • wpsc_add_plugin( $name )을 호출하면 됩니다. 여기서 $name은 전체 파일 이름과 플러그인 경로입니다. 해당 함수를 한 번만 호출하면 추가할 수 있습니다. 로드된 플러그인 목록에서 제거하려면 wpsc_delete_plugin( $name )을 사용합니다.

WP 수퍼 캐시가 “알려진 사용자”를 식별하는 데 사용하는 쿠키는 이제 플러그인 구성의 목록에 해당 쿠키의 이름을 추가하여 수정할 수 있습니다. 새 쿠키를 추가하려면 wpsc_add_cookie( $name )를 사용하고 쿠키를 제거하려면 wpsc_delete_cookie( $name )를 사용합니다. 쿠키 이름은 플러그인에서 사용하는 mod_rewrite 규칙도 수정하지만 .htaccess 파일 업데이트의 복잡성을 피하기 위해 단순 모드 캐싱을 사용하는 것이 좋습니다.↵
쿠키 이름과 값은 사용자를 구분하는 데 사용되므로 예를 들어 사이트의 사용자 유형별로 하나의 쿠키를 사용하지만 다른 값을 가질 수 있습니다. 이들에게는 서로 다른 캐시 파일이 제공됩니다.

플러그인/검색엔진.php는 제 친구에게 광고 금지 플러그인에 사용하는 예시를 참조하세요.

문제 해결

플러그인을 설치했을 때 문제가 해결되지 않는다면 몇 가지 확인해야 할 사항이 있습니다:

  1. 웹 서버에서 wp-content를 쓸 수 있나요?
  2. Wp-content/wp-cache-config.php가 있나요? 없는 경우 wp-super-cache/wp-cache-config-sample.php 파일을 wp-content/wp-cache-config.php에 복사하고 WPCACHEHOME이 올바른 위치를 가리키는지 확인합니다.
  3. Wp-content/advanced-cache.php가 있나요? 없는 경우 wp-super-cache/advanced-cache.php를 wp-content/에 복사해야 합니다. 파일을 편집하고 경로가 wp-super-cache 폴더를 가리키도록 변경해야 합니다.
  4. 페이지가 전혀 캐시되지 않는 경우 위의 조언에 따라 wp-content/advanced-cache.php를 삭제하고 다시 생성하세요.
  5. 다음 줄이 wp-config.php에 있고 “require_once(ABSPATH.’wp-settings.php’);” 줄 위에 있는지 확인합니다:

    define( 'WP_CACHE', true );
    
  6. 설정->WP 수퍼 캐시 페이지로 돌아가서 캐시를 활성화합니다.
  7. Wp-content/cache/supercache/를 살펴보세요. 거기에 디렉터리와 파일이 있나요?
  8. Php error_log에 뭔가 있나요?
  9. 수퍼 캐시가 설치된 후에도 브라우저에서 파일을 저장하라는 메시지가 계속 표시되면 수퍼 캐시 압축을 비활성화해야 합니다. 설정-> WP 수퍼 캐시 페이지로 이동하여 비활성화합니다.
  10. PHP의 안전 모드가 활성화되어 있으면 플러그인이 제대로 작동하지 않습니다. 이 모드는 관리자가 비활성화해야 합니다.
  11. 페이지가 무작위로 수퍼 캐싱되는 경우도 있고 그렇지 않은 경우도 있는 경우 URL에 ‘www’ 접두사를 넣거나 넣지 않고 블로그를 볼 수 있습니다. 한 가지 방법을 선택하고 이전 워드프레스를 사용하는 경우 웹 사이트 환경설정 적용 플러그인을 설치해야 합니다. 최신 버전은 자동으로 리디렉션됩니다(어쨌든 항상 최신 버전의 워드프레스를 실행해야 합니다!).
  12. 드림호스트의 비공개 서버 사용자는 CPU 사용량 증가에 대한 오류가 발생하는 경우 wp-content/wp-cache-config.php를 편집하고 캐시 디렉터리를 “/tmp/”로 설정해야 합니다. 자세한 내용은 이 토론을 참조하세요.
  13. “키 0x152b를 획득하지 못했습니다.”와 같은 파일 잠금 오류: 권한이 거부되었습니다…” 또는 “WP 수퍼 캐시에 의해 페이지가 캐시되지 않았습니다. 뮤텍스 잠금을 얻을 수 없습니다.”와 같은 오류는 파일 잠금을 사용해야 할 수 있다는 신호입니다. wp-content/wp-cache-config.php를 편집하고 “$use_flock = true” 주석 처리를 해제하거나 $sem_id를 다른 값으로 설정하세요. 최후의 수단으로 관리자 화면에서 파일 잠금을 비활성화할 수도 있습니다.
  14. 거친 파일 잠금을 사용하는 경우 웹 서버에서 cache/wp_cache_mutex.lock에 쓰기 가능한지 확인하세요.
  15. 캐시 폴더는 NFS, Samba 또는 NAS 공유에 넣을 수 없습니다. 로컬 디스크에 있어야 합니다. 캐시 폴더가 로컬 컴퓨터에 없으면 파일 잠금 및 만료된 파일 삭제가 제대로 작동하지 않습니다.
  16. 워드프레스에서 wp-cron.php를 찾을 수 없는 경우 이전 캐시 파일의 가비지 컬렉션이 작동하지 않습니다. 호스트 이름이 127.0.0.1로 확인되면 가비지 수집이 작동하지 않을 수 있습니다. 액세스 로그에서 wp-cron.php 항목을 확인하세요. 404(파일을 찾을 수 없음) 또는 200 코드가 반환되나요? 404이거나 wp-cron.php가 보이지 않는다면 워드프레스가 잘못된 ���치에서 해당 스크립트를 찾고 있을 수 있습니다. 서버 관리자에게 문의하여 이 문제를 해결하거나 유닉스 서버에서 /etc/hosts를 편집하여 다음 줄을 제거해야 합니다. 호스트 네임은 네트워크/인터넷의 다른 서버가 사용하는 외부 IP 주소로 확인되어야 합니다. 자세한 내용은 http://yoast.com/wp-cron-issues/ 을 참조하세요. “127.0.0.1 localhost localhost.localdomain”과 같은 줄은 괜찮습니다.

    127.0.0.1 example.com
    
  17. 수퍼캐시를 통해 방문자에게 이전 페이지가 제공되고 있다면 Apache 모듈(또는 Apache를 사용하지 않는 경우 이에 상응하는 모듈)이 누락된 것일 수 있습니다. mod_mime, mod_headers, mod_expires의 세 가지 모듈이 필요합니다. 마지막 두 모듈은 브라우저가 사이트의 기존 페이지의 새 버전을 로드하는 데 특히 중요합니다.
  18. “WP 수퍼 캐시가 설치되었지만 손상되었습니다.”라는 오류 메시지가 표시됩니다. wp-content/advanced-cache.php의 wp-cache-phase1.php 경로를 수정해야 합니다!”라는 오류 메시지가 모든 페이지 끝에 표시됩니다. 즐겨 사용하는 편집기에서 wp-content/advanced-cache.php 파일을 엽니다. wp-cache-phase1.php 경로가 맞나요? 이 파일은 일반적으로 wp-content/plugins/wp-super-cache/에 있습니다. 경로가 올바르지 않으면 캐싱 엔진이 로드되지 않습니다.
  19. 캐싱이 작동하지 않습니다. 다시 로드할 때 블로그의 타임스탬프가 계속 변경됩니다. .htaccess 규칙의 경로가 수퍼캐시 디렉터리가 있는 위치와 일치하는지 확인하세요. 하드코딩해야 할 수도 있습니다. 수퍼 캐시 모드를 비활성화해 보세요.
  20. 수퍼캐시 캐시 파일이 생성되었지만 제공되지 않는 경우 모든 wp-content/cache/supercache 폴더(및 각 wp-content 캐시 및 수퍼캐시 폴더) 및 wp-content/cache/.htaccess에 대한 권한을 확인하세요. PHP가 Apache와 다른 사용자로 실행되고 권한이 엄격한 경우 Apache가 PHP 생성 캐시 파일을 읽지 못할 수 있습니다. 이 문제를 해결하려면 wp-config.php에 다음 줄을 추가한 다음(WP_CACHE 정의 위에 추가하세요.) 캐시를 지워야 합니다.

    umask( 0022 );
    
  21. 플러그인에서 압축을 활성화한 후 브라우저에 가비지가 표시되면 웹 서버에서 압축이 이미 활성화되어 있을 수 있습니다. Apache에서는 mod_deflate를 비활성화해야 하며, PHP에서는 zlib 압축이 활성화되어 있을 수 있습니다. 세 가지 방법으로 비활성화할 수 있습니다. 루트 액세스 권한이 있는 경우 php.ini를 편집하고 zlib.output_compression 설정을 찾아서 “꺼짐”으로 설정하거나 이 줄을 .htaccess에 추가합니다:

    php_flag zlib.output_compression off
    

    그래도 문제가 해결되지 않으면 wp-config.php에 이 줄을 추가하세요:

    ini_set('zlib.output_compression', 0);
    
  22. 사이트를 방문했을 때 ‘죽음의 하얀 화면’ 또는 빈 페이지가 표시되는 것은 거의 대부분 PHP 오류로 인해 발생하지만 APC로 인해 발생할 수도 있습니다. 문제가 있는 경우 해당 PHP 확장 프로그램을 비활성화하고 eAccelerator 또는 Xcache로 교체하세요.
  23. 제거한 후 워드프레스 mod_rewrite 규칙도 제거하면 퍼머링크가 손상될 수 있습니다. 설정-퍼머링크 페이지로 이동하여 해당 양식을 다시 저장하여 해당 규칙을 다시 생성하세요.
  24. 블로그가 로딩되지 않는다면 wp-config.php가 올바른지 확인하세요. 시작 또는 종료 PHP 태그가 누락되었나요?
  25. 전면 …

설치

다른 플러그인처럼 플러그인 페이지에서 직접 설치하되 사용자 정의 퍼머링크가 활성화되어 있는지 확인하세요. 설정의 플러그인 설정 페이지에서 WP 수퍼 캐시로 이동하여 캐싱을 활성화합니다.

WP 수퍼 캐시를 제거하는 방법

플러그인 페이지에서 플러그인을 비활성화하기만 하면 됩니다. 플러그인은 생성 및 수정한 대부분의 파일을 정리해야 하지만 아직 .htaccess 파일에서 mod_rewrite 규칙을 제거하지는 않습니다. 해당 파일에서 수퍼캐시 시작 및 ���료 태그로 표시된 섹션을 찾습니다. 일부 사용자는 해당 블록에 워드프레스 규칙도 추가하기 때문에 플러그인은 이를 제거하지 않습니다.

수동으로 제거합니다:

  1. 플러그인 설정 페이지에서 캐싱을 끄고 캐시를 지웁니다.
  2. 플러그인 페이지에서 플러그인을 비활성화합니다.
  3. Wp-config.php에서 WP_CACHE 정의를 제거합니다. define( 'WP_CACHE', true );와 같이 보입니다.
  4. .htaccess 파일에서 수퍼 캐시 mod_rewrite 규칙을 제거합니다.
  5. Wp-content/advanced-cache.php 및 wp-content/wp-cache-config.php 파일을 제거합니다.
  6. Wp-content/cache/ 디렉터리를 제거합니다.
  7. 플러그인 디렉터리에서 wp-super-cache 디렉터리를 제거합니다.

다른 모든 방법이 실패하고 사이트가 고장난 경우

  1. Wp-config.php에서 WP_CACHE 정의를 제거합니다. define( 'WP_CACHE', true );와 같이 보입니다.
  2. 플러그인이 루트 디렉터리의 .htaccess 파일에 쓴 규칙(위 참조)을 제거합니다.
  3. 플러그인 폴더에서 wp-super-cache 폴더를 삭제합니다.
  4. 선택적으로 고급-cache.php, wp-cache-config.php 및 wp-content/의 캐시 폴더를 삭제합니다.

FAQ

내 블로그가 캐시되고 있는지 어떻게 알 수 있나요?

설정 – WP 수퍼 캐시로 이동하여 쉬운 설정 페이지에서 “캐시 테스터” 양식을 찾습니다. “캐시 테스트”를 클릭하면 플러그인이 사이트의 첫 페이지를 두 번 요청하여 각각의 타임스탬프를 비교하여 일치하는지 확인합니다.

수동으로 수행하려면 플러그인 설정 페이지에서 디버깅을 활성화하고 새 브라우저 탭에서 로그 파일을 로드합니다. 그런 다음 로그인 및 로그아웃 상태에서 블로그를 확인합니다. 로그에 활동이 표시되어야 합니다. 사이트의 모든 페이지의 소스를 확인합니다. 페이지가 처음 생성되면 소스 코드 끝에 “XXXX초 후에 생성된 동적 페이지”라는 텍스트와 “YYYY-MM-DD HH:MM:SS에서 WP-Super-Cache에 의해 생성된 캐시된 페이지”라는 텍스트가 표시됩니다. 다시 로드하면 캐시된 페이지에 동일한 타임스탬프가 표시되므로 몇 초 정도 기다렸다가 확인하세요 ↵.
수퍼캐싱이 비활성화되어 있고 압축을 활성화한 경우 “압축 = gzip”이라는 텍스트가 추가됩니다. 압축이 비활성화되어 있고 페이지가 정적 HTML 파일로 제공되는 경우 “수퍼 캐시”라는 텍스트가 추가됩니다. 캐시된 파일이 PHP 스크립트에 의해 제공되는지 아니면 정적 캐시에서 제공되는지 확인하는 유일한 다른 방법은 HTTP 헤더를 보는 것입니다. PHP 캐시된 페이지에는 ‘WP-Super-Cache’라는 헤더가 있습니다: PHP에서 수퍼 캐시 파일 제공” 헤더가 있습니다. WPCache 캐시 파일에는 “WP-Super-Cache: WPCache 캐시 파일 제공”이라는 헤더가 있습니다. 또한 캐시 디렉터리 wp-content/cache/supercache/hostname/에서 정적 캐시 파일을 확인해야 합니다.↵
.htaccess 파일에서 플러그인 규칙이 누락된 경우 플러그인은 수퍼 캐시된 페이지가 발견되면 이를 제공하려고 시도합니다. 이 경우 헤더 “WP-Super-Cache: PHP에서 수퍼 캐시 파일 제공”이라는 헤더가 표시됩니다.
Apache용 pagespeed 모듈은 테스트할 때 문제를 일으킬 수 있습니다. 캐시 테스터를 실행할 때 문제가 발생하면 이 모듈을 비활성화하세요.

수퍼 캐시를 비활성화하려면 어떻게 해야 하나요?

WP-Cache 엔진만 사용하려면 wp-config.php를 편집하거나 상수 ‘DISABLE_SUPERCACHE’를 1로 설정하는 mu-플러그인을 만드세요.

WP-Cache 와 수퍼캐시 파일

모든 캐시 파일은 wp-content/cache/supercache/HOSTNAME/에 저장되며 여기서 호스트네는 도메인 네임입니다. 파일은 사이트의 퍼머링크 구조와 일치하는 디렉터리에 저장됩니다. 수퍼캐시 파일은 블로그를 방문�� 방문자 유형에 따라 index.html 또는 그 변형된 파일입니다. 다른 파일의 이름은 wp-cache-XXXXXXXXXXXXXXX.php입니다. 관련 메타 파일명은 “메타”로 시작합니다. 이러한 파일에는 캐시된 파일에 대한 정보가 포함되어 있습니다. 이러한 파일은 플러그인의 “WPCache 캐싱” 엔진에 의해 생성됩니다.

댓글 및 내 블로그의 다른 동적 부분이 즉시 업데이트되나요?

댓글은 블로그 소유자의 댓글 정책에 따라 검토되는 즉시 표시됩니다. 페이지의 다른 동적 요소는 자바스크립트, 플래시, 자바 또는 다른 클라이언트 측 브라우저 언어로 작성되지 않으면 업데이트되지 않을 수 있습니다. 플러그인은 실제로 정적 HTML 페이지를 생성합니다. 이러한 페이지가 제공될 때는 PHP가 실행되지 않습니다. “인기 콘테스트”는 작동하지 않는 플러그인 중 하나입니다.

수퍼 캐시 압축으로 인해 서버 속도가 느려지나요?

아니요, 그 반대입니다. 수퍼 캐시 파일은 이러한 방식으로 압축되어 저장되므로 무거운 압축이 한 번만 수행됩니다. 이러한 파일은 일반적으로 훨씬 더 작으며 압축되지 않은 HTML보다 훨씬 더 빠르게 방문자의 브라우저로 전송됩니다. 결과적으로 서버가 네트워크를 통해 통신하는 시간이 줄어들어 CPU 시간과 대역폭이 절약되고 다음 요청을 훨씬 더 빠르게 처리할 수 있습니다.

페이지의 특정 부분을 동적으로 유지하려면 어떻게 해야 하나요?

참고: 이 기능은 기본적으로 비활성화되어 있습니다. 고급 설정 페이지에서 이 기능을 활성화해야 합니다.

이를 수행하는 방법에는 두 가지가 있습니다. 자바스크립트를 사용하여 페이지에서 동적으로 유지하려는 부분을 그릴 수 있습니다. 이는 Google 애드센스 및 외부 사이트의 많은 위젯이 사용하는 방법이며 권장되는 방법입니다. 또는 WP 수퍼 캐시 필터를 사용하여 작업을 수행할 수 있지만 mod_rewrite 모드 캐싱은 사용할 수 없습니다. “단순” 전달 방법을 사용하거나 수퍼 캐싱을 비활성화해야 합니다.

WP 수퍼 캐시 1.4에는 wpsc_cachedata라는 캐시 액션 필터가 도입되었습니다. 표시될 캐시된 페이지는 이 필터를 통과하여 페이지를 수정할 수 있습니다. 페이지에 플레이스홀더 태그가 포함된 경우 필터를 사용하여 해당 태그를 동적으로 생성된 html.↵로 대체할 수 있습니다.
late_init 기능을 사용하지 않는 한 wpsc_cachedata 필터에 연결되는 함수는 WP 수퍼 캐시 플러그인 폴더에 있는 파일에 넣어야 합니다. 예제 플러그인이 포함되어 있습니다. 예제 코드를 보려면 dynamic-cache-test.php를 편집하세요.
여기에는 두 가지 예제 함수가 있습니다. 캐시된 페이지가 제공될 때 사용자가 정의한 문자열(또는 태그)을 대체하는 간단한 함수가 있습니다. 다른 예제 함수는 출력 버퍼를 사용하여 동적 콘텐츠를 생성합니다. PHP 작동 방식의 제한으로 인해 출력 버퍼 코드는 적어도 페이지가 캐시될 때 wpsc_cachedata 필터가 적용되기 전에 실행되어야 합니다. 캐시된 페이지를 제공할 때는 중요하지 않습니다. 보다 기술적이고 긴 설명은 이 글를 참조하세요.
워드프레스 기능을 실행하려면 고급 설정 페이지에서 ‘늦게 초기화’ 기능을 활성화해야 합니다.

“init” 작업이 실행될 때까지 캐시 제공을 지연하려면 어떻게 해야 하나요?

캐시된 파일은 거의 모든 워드프레스가 로드되기 전에 제공됩니다. 성능에는 좋지만 워드프레스의 핵심 부분을 사용하여 플러그인을 확장하려는 경우 불편할 수 있습니다. 고급 설정 페이지에서 ‘초기화 지연’ 모드를 활성화하면 ‘초기화’가 실행될 때 캐시된 파일이 제공됩니다. 이제 워드프레스와 플러그인이 로드됩니다.

왜 지금 내 블로그에서 WP 사용자 온라인, 인기 콘테스트, WP 포스트 레이팅 또는 플러그인 X가 작동하지 않거나 업데이트되지 않나요?

이 플러그인은 전체 페이지를 캐시하지만 일부 플러그인은 페이지가 로드될 때마다 PHP 코드를 실행할 수 있다고 생각합니다. 이 문제를 해결하려면 플러그인은 이전 답변에서 설명한 Javascript/AJAX 메서드 또는 wpsc_cachedata 필터를 사용하여 동적 정보를 업데이트하거나 표시해야 합니다.

플러그인을 업그레이드하면 WP 수퍼 캐시 플러그인이 사라지는 이유는 무엇인가요?

워드프레스는 플러그인을 업데이트하면 플러그인 폴더를 삭제합니다. 이는 WP 수퍼 캐시에서도 동일하게 적용되므로 wp-super-cache/plugins/에 있는 수정된 파일은 모두 삭제됩니다. 여러 가지 방법으로 사용자 정의 플러그인을 다른 디렉터리에 저장할 수 있습니다. wp-config.php 또는 wp-content/wp-cache-config.php에서 $wp_cache_plugins_dir 변수를 정의하여 wp-super-cache 폴더 외부의 디렉터리를 가리키도록 할 수 있습니다. 플러그인은 해당 디렉터리에서 해당 플러그인을 찾습니다. 또는 일찍 로드해야 하는 플러그인을 배포하는 경우 wpsc_add_plugin( $파일명 ) 함수를 사용하여 어디에 있든 새 플러그인을 추가할 수 있습니다. 플러그인 파일을 제거하려면 wpsc_delete_plugin( $filename )를 사용합니다. WP 수퍼 캐시 플러그인 작성에 대한 #574 또는 이 글를 참조하세요.

캐시 재구축 기능은 어떤 기능을 하나요?

방문자가 댓글을 남기면 해당 페이지의 캐시된 파일이 삭제되고 다음 방문자가 캐시된 페이지를 다시 만듭니다. 페이지를 로드하는 데 시간이 걸리므로 이 시간 동안 100명의 방문자가 방문하면 어떻게 되나요? 캐시된 페이지가 없으므로 워드프레스는 각 사용자에게 새로운 페이지를 제공하고 플러그인은 100명의 방문자 각각에 대해 캐시된 페이지를 생성하려고 시도하여 서버에 큰 부하를 일으킵니다. 이 기능을 사용하면 이런 일이 발생하지 않습니다. 댓글을 남기면 캐시된 페이지는 지워지지 않습니다. 대신 재구축을 위해 표시됩니다. 다음 10초 이내에 다음 방문자가 캐시된 페이지를 다시 생성하는 동안 다른 99명의 방문자에게는 이전 페이지가 제공됩니다. 결국 첫 번째 방문자에 의해 페이지가 로드되고 캐시된 페이지가 업데이트됩니다. 자세한 내용은 이 게시글를 참조하세요.

플러그인이 기본적으로 검색 엔진 봇의 요청을 캐시하지 않는 이유는 무엇인가요?

이러한 봇은 일반적으로 각 페이지를 한 번만 방문하며 페이지가 인기가 없는 경우 서버에 유휴 상태로 남아 있는 캐시 파일을 만들 필요가 없습니다. 하지만 고급 설정 페이지의 ‘거부된 사용자 에이전트’에서 봇 목록을 제거하여 이러한 방문이 캐시되도록 허용할 수 있습니다.

내 홈페이지 대신 카테고리 페이지가 표시됩니다.

소수의 웹사이트에서 다음과 같은 구성에 문제가 발생할 수 있습니다:

  1. 첫 페이지에 정적 페이지를 사용합니다.
  2. /%category%/%postname%/ 퍼머링크 구조를 사용합니다.

가끔 카테고리 페이지가 정적 페이지 대신 사이트의 홈페이지로 캐시되는 경우가 있습니다. 문제를 재현할 수는 없지만 간단한 해결책은 ‘단순’ 모드를 사용하는 것입니다. 고급 설정 페이지에서 ‘추가 홈페이지 검사’를 활성화할 수도 있습니다.

여기(http://ismyblogworking.com/) 에서 캐싱에 대한 경고가 표시되는 이유

“블로그가 클라이언트 캐싱을 지원하지 않습니다(If-modified-since에 대한 304 응답 없음).”↵
“피드가 캐싱을 지원하지 않습니다(If-modified-since에 대한 304 응답 없음).”

수퍼캐시는 전문가 모드에서는 304 헤더 검사를 지원하지 않지만 단순 모드에서는 이를 지원합니다. 이는 서버가 아닌 브라우저에서 수행하는 캐싱입니다. 브라우저가 서버에 현재 페이지의 업데이트된 버전을 사용할 수 있는지 확인하기 위해 수행하는 검사입니다. 그렇지 않은 경우 이전 버전을 다시 다운로드하지 않습니다. 해당 페이지는 여전히 방문자의 브라우저가 아닌 서버에 의해 캐시된 상태입니다.↵
자세한 분석은 http://www.ircache.net/cgi-bin/cacheability.py 또는 https://redbot.org/ 에서 캐시 가능성 엔진을 사용해 보세요.

이 플러그인과 함께 Google 애널리틱스에서 utm_source 추적 도구를 가장 잘 사용하려면 어떻게 해야 하나요?

이 추적은 트위터 및 피드 리더와 같은 다양한 소스에서 링크된 각 URL에 쿼리 문자열을 추가합니다. 안타깝게도 페이지가 수퍼캐싱되는 것을 막습니다. 수퍼캐싱할 수 있는 앵커 태그로 바꾸는 방법은 여기 Joost의 댓글를 참조하세요.

플러그인에서 wp-content는 쓰기 가능! htdocs는 쓰기 가능!

웹 서버가 이 디렉터리에 쓸 수 있는 것은 좋지 않지만 공유 호스팅 계정은 관리를 쉽게 하기 위해 이런 방식으로 설정하는 경우가 있습니다. chmod 755 디렉토리를 사용하여 권한을 수정하거나 ftp 클라이언트의 권한 섹션을 찾습니다. 이 구글 검색에서 이 주제에 대한 자세한 정보를 찾을 수 있으며 이 코덱스 페이지도 있습니다. 안타깝게도 일부 호스트는 해당 디렉터리를 쓰기 가능해야 합니다. 이 경우 이 경고를 무시하세요.

Wp-config.php에서 WP_CACHE 정의를 삭제하려면 어떻게 하나요?

데스크톱 FTP 클라이언트를 로드하고 사이트에 연결합니다. 사이트의 루트(또는 그 아래 디렉터리)로 이동하여 wp-config.php가 있는 디렉터리를 찾습니다. 해당 파일을 다운로드하고 텍스트 편집기에서 편집합니다. define( 'WP_CACHE', true ); 줄을 삭제하고 파일을 저장합니다. 이제 파일을 업로드하여 서버의 wp-config.php를 덮어씁니다.

.htaccess 파일에서 수퍼 캐시 규칙을 삭제하려면 어떻게 해야 하나요?

데스크톱 ftp 클라이언트를 로드하고 사이트에 연결합니다. ftp 클라이언트의 환경설정에서 ‘숨김 파일 표시’를 활성화해야 할 수도 있습니다. 사이트의 루트로 이동하여 .htaccess 파일을 찾습니다. 해당 파일을 다운로드하고 텍스트 편집기에서 편집합니다. “# BEGIN WPSuperCache”와 “# END WPSuperCache” 사이의 줄을 삭제하고 파일을 저장합니다. 이제 서버의 .htaccess 파일을 덮어쓰면서 업로드합니다.

파일 권한을 변경하려면 어떻게 해야 하나요?

워드프레스 코덱스의 이 페이지에서는 서버의 파일 권한과 이를 변경하는 다양한 방법에 대해 알아야 할 모든 것을 설명합니다.

새 글을 작성할 때 로드 스파이크가 발생하는 이유는 무엇인가요?

‘새 글이 작성될 때 캐시된 모든 파일 지우기’ 옵션을 설정했을 수 있습니다. 이러한 파일을 지우는 데 시간이 걸릴 수 있으며 방문자는 이제 캐시되지 않은 페이지를 방문하게 됩니다. URL에 utm_source가 포함된 Google 애널리틱스 캠페인 추적을 사용 중인가요? 해당 페이지는 캐시되지 않습니다. 올바른 사용 방법은 위의 “이 플러그인과 함께 Google 애널리틱스에서 utm_source 추적 도구를 가장 잘 사용하려면 어떻게 해야 하나요?”라는 질문을 참조하세요.↵
캐시된 페이지는 글을 작성할 때 새로 고쳐야 합니다. 서버가 트래픽 양을 감당할 수 없을 수도 있습니다. ‘캐시 재구축’ 기능을 활성화��면 도움이 될 수 있습니다.

얼마나 많은 페이지를 캐시할 수 있나요?

실제 유일한 제한은 서버에서 정의한 제한입니다. 예를 들어 EXT2 및 EXT3에서는 최대 31,999개의 하위 디렉터리를 허용하므로 /%POSTNAME%/와 같은 플랫 퍼머링크 구조와 32,000개 이상의 글이 있는 경우 문제가 발생할 수 있습니다. 마찬가지로 다중 사이트 네트워크를 운영하면서 사이트(블로그)가 31,999개 이상인 경우 모든 사이트를 캐시할 수 없습니다. 현실적으로 그렇게 많은 활성 사이트가 있다면 하나의 서버에서 운영할 수 없습니다.

내 사이트의 www 버전이 별도로 캐시되는 것을 볼 수 있습니다. 이를 중지하려면 어떻게 해야 하나요?

워드프레스는 사이트의 정식 URL로 리디렉션해야 하지만 그렇지 않은 경우 수퍼캐시 및 워드프레스 규칙 위에 .htaccess에 추가하세요. example.com을 고유한 호스트 네임으로 변경합니다.↵
RewriteCond %{HTTP_HOST} www.example.com$ [NC]↵
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

캐시된 모바일 페이지를 휴대폰이나 태블릿과 같은 작은 화면의 클라이언트에게 제공하려면 어떻게 해야 하나요?

테마가 반응형이라면 페이지를 표시하는 모든 기기에 맞게 페이지 크기가 조정됩니다. 반응형 테마가 아닌 경우 별도의 모바일 플러그인을 사용하여 해당 방문자에게 적합한 형식의 페이지를 렌더링해야 합니다. 다음 플러그인이 테스트되었지만 모바일 클라이언트에 따라 YMMV입니다. 고급 설정 페이지에서 모바일 브라우저 지원도 활성화해야 합니다.

후기

2024년 3월 27일
Updated 2024 After a lot of turbulances all these years, now it seems to be much better at last. Preload also works as expected :). It took several years for that 🙂 Jetpack should not be promoted in the WP Supercache plugin. Jetpack is Not good at all.
2024년 3월 17일 답글 1개
A simple and powerful extension that remarkably improves the speed of my site. I recommend it to wordpress site developers.
모든 1,333 평가 읽기

기여자 & 개발자

“WP 수퍼 캐시”(은)는 오픈 소스 소프트웨어입니다. 다음의 사람들이 이 플러그인에 기여하였습니다.

기여자

“WP 수퍼 캐시”(이)가 31 개 언어로 번역되었습니다. 기여해 주셔서 번역자님께 감사드립니다.

자국어로 “WP 수퍼 캐시”(을)를 번역하세요.

개발에 관심이 있으십니까?

코드 탐색하기는, SVN 저장소를 확인하시거나, 개발 기록RSS로 구독하세요.

변경이력

1.12.4 – 2024-07-17

Removed

  • General: update WordPress version requirements to WordPress 6.5.

Fixed

  • Fixed problem with is_utf8_charset missing in WP 6.6

이전 변경 로그는 여기에서 확인하세요