부모 테마는 다목적으로 만들어졌기 때문에, 우리가 쓰지 않는 기능의 자산까지 함께 싣는 경우가 있습니다. 라이트박스 · 슬라이더 · 애니메이션 라이브러리 같은 것들입니다. 이것을 내리는 일은 기술적으로 어렵지 않은데, 어려운 것은 내린 뒤의 책임입니다.
먼저 전제를 분명히 합니다. 이 작업은 재는 것이 먼저입니다. “요청이 적을수록 좋다” 는 일반론으로 시작하면, 실제로는 아무것도 개선하지 못하면서 깨질 수 있는 지점만 늘립니다. 그 자산이 이 사이트에서 하는 일이 없다는 것을 확인한 뒤에 시작합니다.
1단계 — 무엇이 실려 있는지 목록화
추측으로 이름을 적지 않습니다. 대표 화면 몇 개(홈 · 아카이브 · 단일 글 · 검색 · 404)에서 현재 큐에 들어 있는 핸들을 그대로 뽑습니다.
<?php
add_action( 'wp_print_footer_scripts', function () {
if ( ! current_user_can( 'manage_options' ) ) {
return;
}
error_log( '[js] ' . implode( ', ', wp_scripts()->queue ) );
error_log( '[css] ' . implode( ', ', wp_styles()->queue ) );
}, 1 );화면마다 목록이 다를 수 있으므로 여러 화면에서 뽑아 비교합니다. 어떤 화면에서만 나타나는 핸들은 그 화면의 기능이 쓰고 있다는 신호입니다.
2단계 — 한 번에 하나씩 내립니다
제거는 등록된 뒤에 실행되어야 합니다. 부모보다 늦은 우선순위로 붙이는 이유가 이것입니다 — 등록 전에 부르면 아무 일도 일어나지 않고, 코드는 멀쩡해 보입니다.
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( is_admin() ) {
return;
}
wp_dequeue_script( 'parent-slider' );
wp_deregister_script( 'parent-slider' );
}, 200 ); // 부모보다 뒤여기서 흔히 걸리는 함정이 하나 있습니다. 부모가 wp_footer 시점에 자산을 등록한다면, head 단계의 dequeue 로는 잡히지 않습니다. 이때는 자산이 아니라 등록하는 훅 자체를 내려야 합니다.
<?php
remove_action( 'wp_footer', 'parent_theme_enqueue_scripts' );또 하나. 라이브러리와 함께 출력되는 인라인 데이터 스텁이 남아 있어야 하는 경우가 있습니다. 템플릿이 그 전역 객체를 부르고 있다면, 라이브러리만 내리고 스텁을 지우면 콘솔에 참조 오류가 납니다. 반대로 스텁만 남기면 아무 라이브러리도 로드되지 않은 채 호출부만 안전해집니다 — 어느 쪽이 맞는지는 템플릿을 봐야 압니다.
3단계 — 무엇이 깨졌는지 확인
제거한 자산의 영향은 화면을 봐서는 알 수 없는 경우가 많습니다. 자바스크립트가 사라지면 오류가 콘솔에만 남고 레이아웃은 그대로이기 때문입니다. 그래서 확인은 눈이 아니라 목록으로 합니다.
한 번에 하나씩 내리는 이유가 여기 있습니다. 세 개를 함께 내리면 어느 것이 원인인지 알기 위해 되돌리기를 반복해야 합니다. 커밋도 하나씩 나누어 두면 문제가 생겼을 때 되돌릴 단위가 명확합니다.
넘어오는 책임
제거는 일회성 작업이 아닙니다. 부모 테마는 앞으로도 그 자산이 있다는 전제로 기능을 추가합니다. 업데이트로 새 기능이 들어오면, 우리가 내린 라이브러리에 기대는 코드가 함께 들어올 수 있습니다.
그래서 제거 코드는 한 파일에 모으고, 각 줄 옆에 무엇을 왜 내렸는지와 그 자산에 기대던 기능이 무엇이었는지를 적어 둡니다. 이 주석이 다음 회차에서 다룰 업데이트 대응 목록의 일부가 됩니다.
자산 크기와 렌더링의 관계는 성능 최적화 아카이브에 정리돼 있고, 실제 사이트에서 이 작업을 어떤 순서로 진행하는지는 작업 과정에서 볼 수 있습니다.
다음 회차
연재의 마지막 회차입니다. 지금까지 만든 자식 테마는 부모의 함수 · 템플릿 · 훅에 여러 곳에서 기대고 있습니다. 그 목록을 미리 만들어 두면 부모 업데이트가 발굴 작업이 아니라 점검표가 됩니다.