나는 get_theme_mod()여러 프로젝트에서 한동안 사용 해왔다 . 고객이 사용할 수있는 도구라고 생각하면서 WordPress v3.4에서 테마 사용자 정의 API를 사용하기로 결정했습니다.

얼마 후, 내 사이트가 평소보다 조금 느리게 느껴지고 있으며 맞춤 설정 도구는 특히로드하는 데 오랜 시간이 걸렸습니다. 내 조사 기간 동안 시행 착오의 많은 통해, 나는 밖으로 전환 시도하기로 결정 type내 설정 (즉 등록 할 때 $wp_customize->add_setting()부터) theme_mod에 option.

이 작업을 수행하고에 대한 모든 get_theme_mod()통화를 교환 한 후, 프런트 엔드의 전자, 특히 백엔드의 Customizer와는 반대로 후자의 설정을 사용하여 속도가 크게 향상되는 get_option()것을 알았습니다 . 나는 이것이 왜 그런지에 대한 답을 찾으려고 노력하면서 WordPress 핵심을 살펴 보았지만이 시나리오에서 특정 행업이 무엇인지 식별 ​​할 수는 없습니다.

커뮤니티가 인식 할 수있는 get_option()것보다 훨씬 빠르게 수행하는 것과 관련하여 통찰력 이 get_theme_mod()있을 수 있습니다.

예, theme_mod 함수는 느리지 만 크게 향상되지는 않으며 그 이점은 차이보다 중요합니다.

테마 모드는 옵션으로 저장됩니다. 본질적으로 theme_mod 함수는 옵션 함수를 감싸는 래퍼입니다.

먼저 theme_mod 설정은 특정 테마 이름을 기준으로 단일 옵션에 배열로 저장됩니다. 그래서 내가 이것을하면 :

set_theme_mod('aaa',123);
set_theme_mod('bbb',456);

그런 다음 실제로 데이터베이스에 얻는 것은 theme_mods_themename이라는 이름의 단일 옵션 행이며 여기에는 ( 'aaa'=> 123, 'bbb'=> 456)이있는 직렬 배열이 포함됩니다.

이제, get_theme_mod실제로이 만들고 있기 때문에 속도가 느려집니다 get_option전화를. 먼저 테마의 이름을 얻습니다. 그런 다음 theme_mods_themename옵션을 얻습니다 . 바로 50 %의 속도 손실입니다. 나머지 작업은 추가 필터 호출이 있다는 점에서 대부분 필터에 있습니다. 그러나 해당 필터에 무언가가 없으면 그다지 중요하지 않습니다.

옵션 시스템은 검색된 데이터를 객체 캐시에 저장하므로 여기에서 여러 데이터베이스 호출을 수행하지 않습니다. 처음 사용하는 경우에만 데이터베이스 적중이 발생합니다.

는 set_theme_mod그 다음 또 다른하게, 그 같은 두 GET 옵션 호출을하기 때문에 다소 느려집니다 get_option다시 테마 이름을 얻기 위해 전화를 한 다음이하는 update_option지금 변경 옵션의 전체 세트. 이로 인해 데이터베이스가 업데이트되고 더 많은 데이터를 전송한다는 사실은 실제로 눈에 띄게 느려지는 원인이 될 수 있습니다. 더 큰 행을 업데이트하는 것보다 몇 바이트를 업데이트하는 것이 더 빠릅니다. 그러나 보통 눈치 채지 못할 정도입니다. 많은 설정을 완전히하지 않는 한 ...

테마 모드 함수는 아마도 전체적으로 최적화해야 할 것입니다. 그럼에도 불구하고 자식 테마 때문에 get_option 대신에 사용해야합니다.

옵션 행을 직접 사용하는 문제는 옵션 행을 직접 사용하고 설정에 특정 키 이름을 사용한다는 것입니다.

"AAA"라는 테마가 있고 다른 사이트에서 사용하기 위해 "BBB"라는 하위 테마를 만드는 경우 "AAA"테마는 "example"이라는 옵션을 사용할 수 있습니다. 한 사이트를 업데이트하고 내 옵션을 업데이트하면 동일한 옵션이 이제 내 하위 테마에 적용됩니다. 내가 원하지 않으면 어떻게해야합니까? 하위 테마에서 다른 옵션 설정을 사용하도록하려면 어떻게해야합니까?

키의 일부로 실제 테마 이름 (하드 코딩 된 값이 아님)을 포함하여 테마 모드는 사이트의 각 "테마"가 고유 한 설정 세트를 사용하도록합니다. 앞뒤로 전환 할 수 있으며 설정이 전송되지 않고 설정 방식을 유지합니다. 더 단순하고 명확하며 직관적입니다.

그리고 미래의 핵심 변경 또는 플러그인이 theme_mods의 작동 방식을 수정하면 변경없이 자동으로 이점을 얻을 수 있습니다. 래퍼는 항상 느려질 것입니다. 그것은 피할 수 없으며 래퍼의 특성입니다. 그럼에도 불구하고 여전히 기계어가 아닌 PHP 코드를 작성하고 있습니다. 우리는 이와 같은 래퍼를 사용하여 사물을 단순화하고 기능을 분리합니다. 테마는 옵션이 데이터베이스에 저장되는 방식 또는 이름 지정 방식을 알거나 신경 쓸 필요가 없습니다. theme_mod 함수는보다 간단한 솔루션을 제공합니다.

get_theme_mod그냥 래퍼 get_option입니다. 이론상 그것은 또 다른 추상화 계층이기 때문에 느리게 작동하지만 실제로는 그 차이가 인간이 알아 차릴만큼 충분히 크지 않아야합니다.

theme_mod 후크에 느린 코드가 연결되어 있으면 실제 속도 차이가 발생할 수 있습니다.

맞춤 설정 도구에 문제가있을 수 있습니까? 여기 OP와 같은 것이 보입니다.

약 30 개의 옵션으로 내 맞춤 설정 도구로드 시간이 약 3 초에서 0.5 초로 줄어든 것을 확인할 get_option수 있습니다.get_theme_mod

메소드를 직접 호출하면 2ms 차이가 있습니다.

( https://gist.github.com/anonymous/d98a46d00d52d40e7dec )

API를 직접 비교할 때 눈에 띄지 않을 수 있지만 Customizer에서 API를 사용하는 방법에 문제가 있어야합니다.

이 코드를 사용하여 (100 회 반복) 시간 을 테스트 할 수 있습니다 get_option(입력 functions.php또는 어딘가에).

add_action('wp','My_Test');
function My_Test(){
    var_dump(microtime(true));
    for ($i=1; $i<100; $i++) { get_option('blogdescription'); }
    var_dump(microtime(true));
    for ($i=1; $i<100; $i++) { get_theme_mod('blogdescription'); }
    var_dump(microtime(true));
    exit;
}   

또 다른 생각

차이가 나는지 모르겠지만 (Wordpress 개발자가 더 잘 알고있을 수도 있지만) 웹 사이트에 트래픽이 많고 모든 페이지로드시 수백 가지 옵션이 필요하다고 생각합니다. 하나에 많은 옵션 get_option? 이처럼 :

update_option('my_extra_optss',  array(
      'myNAME' => 'George',
      'myAGE'  => 43 ));

그때 :

$x = get_option('my_extra_optss');
$x['myNAME'];
$x['myAGE'];
................

사이트가 조금 더 빨라 집니까?

TL; DR : 테마 개발자 인 경우 get_theme_mod 를 사용해야합니다 .

전체 답변 :

100 개의 get_option 호출이있는 경우 데이터베이스에 100 개의 쿼리가 필요합니다.

100 개의 get_theme_mod 호출이있는 경우 데이터베이스에 하나의 쿼리 만 걸립니다.

왜? 모든 테마 모드는 단일 데이터베이스 행에 저장되고 하나만 호출되기 때문에 각 옵션은 행이고 100 개의 get_option 호출은 100 개의 데이터베이스 쿼리를 생성하며 물론 사이트 속도가 느려집니다.

테마에 많은 옵션이있는 경우 get_theme_mod 를 사용 하면 데이터베이스에 대한 쿼리 수가 크게 줄어 듭니다.

Query Monitor Plugin으로 성능 및 쿼리 수를 확인할 수 있습니다