Defer WordPress Scripts — Non-Critical JS Safely with PHP

Script handles are WordPress’s internal IDs — set by the first argument to wp_enqueue_script(). The global $wp_scripts object (a WP_Scripts instance) stores two key arrays: ->registered (all scripts known to WordPress, keyed by handle) and ->queue (the ordered list of handles that will actually print). The debug helper in Step 1 iterates ->queue and looks up each handle in ->registered to read ->src (the file URL), ->deps (dependency handles), and ->ver (version string). This is how you discover what your site loads — handles like contact-form-7, jquery-core, wp-block-library are set by plugins and WordPress core. Without this visibility, you’re guessing at handle names.

Dequeue priority order matters. wp_enqueue_scripts fires during the wp_head sequence with a default priority of 10. Most plugins hook at priority 10 — themes and custom code should use priority 99 or higher to ensure every script has been registered before you attempt to dequeue it. If you dequeued at priority 10, a plugin hooking at 20 would re-add the script after your dequeue. The wp_dequeue_script() function removes a handle from the queue but leaves the registration intact — calling wp_enqueue_script( 'contact-form-7' ) later will re-add it. For permanent removal, follow with wp_deregister_script(), though that prevents re-enqueuing which may break conditional logic.

Defer and async behave fundamentally differently. async downloads the script in parallel with HTML parsing and executes immediately once downloaded — regardless of whether HTML parsing is complete or other scripts have loaded. If script B depends on script A and both are async, B may execute before A. Use async only for independent scripts (analytics, ad tags). defer downloads in parallel but delays execution until the HTML document has been fully parsed (before DOMContentLoaded). Multiple deferred scripts execute in the order they appear in the document — safe for UI libraries that don’t depend on jQuery but do depend on each other. Both attributes only apply to external scripts (with src attribute); inline scripts ignore them.

jQuery creates a dependency chain that defer can break. When a plugin script calls wp_enqueue_script( 'my-slider', ..., [ 'jquery' ] ), WordPress generates a <script> tag for my-slider only after jquery has loaded. In normal (render-blocking) execution this works: jQuery loads, the DOM pauses, then the slider loads. With defer, execution order is preserved but jQuery’s DOM-ready callback won’t fire until after all deferred scripts. Worse — if you defer a jQuery-dependent script but keep jQuery render-blocking, the slider executes at DOMContentLoaded when jQuery’s document-ready may have already fired and the slider’s init code misses the event. The solution: either skip defer for jQuery-dependent scripts (Step 4), or move jQuery to the footer and defer it too.

Filter hooks make the system extensible without editing core code. apply_filters( 'tsd_defer_handles', [] ) passes an empty array as the default — themes and plugins add handles via a filter callback. For example, a WooCommerce add-on plugin that registers wc-variation-picker can add itself to the defer list: add_filter( 'tsd_defer_handles', function( $h ) { $h[] = 'wc-variation-picker'; return $h; } ). If the plugin is deactivated, the filter callback never runs, and the handle list stays clean. This is cleaner than hardcoding every possible handle in the production file. The filter runs early (init hook) so all callbacks are attached before wp_enqueue_scripts fires.

Test with browser DevTools Network tab. Open Chrome DevTools → Network tab → check “Disable cache” → reload the page. Before the change, note the waterfall: scripts (js files) are dark bars that block rendering. After deploying Step 5, the same scripts should show as lighter bars loading in parallel, with the green “Start Render” line appearing earlier. Filter by “JS” in the Network tab to see only script requests. Key metric: the time from the first request to DOMContentLoaded (blue vertical line) should drop. Typical improvement: 200–800ms on a shared host with 8–12 plugins.

Verify no JavaScript console errors. Deferring a jQuery-dependent script causes a Uncaught ReferenceError: $ is not defined or jQuery is not defined. After deploying, click every interactive element — sliders, lightboxes, accordions, contact forms — and watch the Console tab (preserve log enabled). If a slider doesn’t initialize, check: did you add its handle to tsd_defer_handles? If yes, did Step 4’s jQuery check skip it? If the slider works, its init code is either not jQuery-dependent or runs on DOMContentLoaded which fires after deferred scripts. No errors after 30 seconds of interaction means the config is safe.

Check PageSpeed / Lighthouse improvement. Run Lighthouse in Chrome DevTools → Lighthouse tab → check “Performance” → “Analyze page load.” Look at “Eliminate render-blocking resources” — this audit should show fewer red-flagged scripts. The “Reduce JavaScript execution time” audit should also improve because scripts load asynchronously and the main thread isn’t blocked during parsing. Compare scores before and after: a typical site with 5 render-blocking scripts gains 5–12 points on mobile Performance. The “Time to Interactive” metric drops by 300–1200ms because the browser doesn’t wait for non-critical JS before letting users click.

Per-post-type conditional loading. Extend Step 2’s conditional dequeue to check post type. A “Testimonials” plugin might only need its slider on the testimonials archive page, not every page. Use is_post_type_archive() and is_singular() to gate script loading:

add_action( 'wp_enqueue_scripts', function() {n    if ( ! is_post_type_archive( 'testimonial' ) && ! is_singular( 'testimonial' ) ) {n        wp_dequeue_script( 'testimonial-slider' );n    }n}, 99 );

For posts with specific templates, check get_page_template_slug(). For Gutenberg blocks, use has_block( 'namespace/block-name' ) which searches post content for the block delimiter comment. This is reliable because Gutenberg stores block names as HTML comments in post_content — has_block() does a simple string search, not a block parse.

Defer WooCommerce scripts on non-shop pages. Woo’s scripts — cart fragments, checkout validation, product gallery — load on every page even though they’re only needed on shop, cart, and product pages. Gate them:

add_action( 'wp_enqueue_scripts', function() {n    $woo_pages = [ 'product', 'cart', 'checkout' ];n    $is_woo   = is_woocommerce() || is_cart() || is_checkout();nn    if ( ! $is_woo ) {n        wp_dequeue_script( 'wc-add-to-cart' );n        wp_dequeue_script( 'wc-cart-fragments' );n        wp_dequeue_script( 'photoswipe-ui-default' );n        wp_dequeue_style( 'woocommerce-general' );n        wp_dequeue_style( 'woocommerce-layout' );n    }n}, 99 );

This strips 60–120 KB of CSS and JS from your blog posts, landing pages, and static content — pages where the user never sees a product or adds anything to a cart. For sites where the shop is a secondary section, this is the single biggest script-reduction win after defer.

Combine defer with script concatenation. After deferring individual scripts, bundle them into one file using a build tool (Webpack, Vite, or WP’s own concatenation via WP_SCRIPTS_FORCE_CONCAT) or a caching plugin. The workflow: identify defer-safe handles → concatenate into a single JS file → enqueue the concatenated file → add it to the defer list. The concatenated file loads in one HTTP request instead of 6–8. Configure in wp-config.php:

define( 'CONCATENATE_SCRIPTS', false );       // Disable core concatn// Use your build tool to produce:n// assets/js/deferred-bundle.jsnnadd_action( 'wp_enqueue_scripts', function() {n    wp_enqueue_script( 'theme-deferred',n        get_template_directory_uri() . '/assets/js/deferred-bundle.js',n        [], null, true ); // true = in footern} );

The true parameter loads the script in the footer, and the defer attribute on top of that is redundant (footer scripts already load after HTML). If you keep it in <head>, add defer via the filter.

Add a WP-CLI command to list script handles. Create a custom WP-CLI command that outputs every registered script handle, its source, and its dependencies — the same data as Step 1’s debug helper but accessible via terminal:

// Save as inc/wp-cli-scripts.php, require from functions.phpnif ( defined( 'WP_CLI' ) && WP_CLI ) {n    WP_CLI::add_command( 'theme scripts', function() {n        global $wp_scripts;n        // Force enqueue to populate the queue.n        do_action( 'wp_enqueue_scripts' );nn        $rows = [];n        foreach ( $wp_scripts->registered as $handle => $reg ) {n            $rows[] = [n                'handle' => $handle,n                'src'    => $reg->src ?? 'inline',n                'deps'   => implode( ', ', $reg->deps ),n                'ver'    => $reg->ver ?? '',n            ];n        }n        WP_CLIUtilsformat_items( 'table', $rows,n            [ 'handle', 'src', 'deps', 'ver' ] );n    } );n}

Run with wp theme scripts. The table output shows which scripts depend on jQuery (look for jquery in the deps column) — those should not go in the defer list. The src column reveals third-party domains (CDN scripts, tracking pixels) that you may not want to defer because they depend on external server response times.