Removing parent theme assets, and the responsibility you inherit

Parent themes are built to serve many sites, so they often load assets for features you will never use: lightboxes, sliders, animation libraries. Removing them is not technically difficult. What is difficult is the responsibility afterwards.

Start with a premise: measure first. Beginning from the general principle that “fewer requests is better” tends to produce no measurable improvement while adding places that can break. Confirm the asset does nothing for this site, then begin.

Step 1 — inventory what is actually loaded

Do not write handle names from memory. Pull the real queue on a handful of representative screens — home, archive, single, search, 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 );

The list varies by screen, so gather several and compare them. A handle that appears on only one screen is a signal that a feature on that screen uses it.

Step 2 — remove one at a time

Removal has to run after registration, which is why you attach at a later priority than the parent. Called too early it does nothing at all, and the code still looks perfectly reasonable.

<?php
add_action( 'wp_enqueue_scripts', function () {
    if ( is_admin() ) {
        return;
    }

    wp_dequeue_script( 'parent-slider' );
    wp_deregister_script( 'parent-slider' );
}, 200 );   // later than the parent

There is a trap worth naming. If the parent registers its assets during wp_footer rather than the enqueue hook, a dequeue running at head time never catches them. In that case you remove the registering action itself.

<?php
remove_action( 'wp_footer', 'parent_theme_enqueue_scripts' );

One more. An inline data stub is sometimes printed alongside the library and still needed. If templates call that global object, dropping the library while deleting the stub gives you reference errors in the console; keeping only the stub leaves the call sites safe with no library behind them. Which is correct depends on the templates, so read them.

Step 3 — find out what broke

The effect of a removal is often invisible on screen. When JavaScript disappears the error lands in the console while the layout stays exactly as it was. So verification is done with a list, not with your eyes.

This is why you remove one at a time. Drop three together and identifying the culprit means repeatedly reverting. Splitting the commits gives you an obvious unit to roll back when something surfaces.

The responsibility you inherit

A removal is not a one-off task. The parent theme will keep adding features on the assumption that those assets exist. An update can bring in new code that depends on the very library you dropped.

So keep removals in one file, and annotate each line with what you removed, why, and which feature relied on it. Those comments become part of the update checklist that the next part is about.

How asset weight relates to rendering is collected in the Performance archive, and the order we run this work on real sites is published on our process page.

Next part

One part remains. The child theme you have built now leans on the parent’s functions, templates and hooks in many places. Write that list down in advance and a parent update becomes a checklist rather than an excavation.