{"id":509,"date":"2026-09-28T08:15:00","date_gmt":"2026-09-28T06:15:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?page_id=509"},"modified":"2026-09-25T10:49:21","modified_gmt":"2026-09-25T08:49:21","slug":"performance-optimization-via-functions-php-selective-dequeuing-of-wordpress","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/wordpress-plugins-tricks\/tutorials-en-wordpress-plugins-tricks\/performance-optimization-via-functions-php-selective-dequeuing-of-wordpress\/","title":{"rendered":"Performance Optimization via functions.php: Selective Dequeuing of WordPress Plugin Scripts"},"content":{"rendered":"
Architectural Overview: The WordPress Asset Pipeline<\/h2>\n
Modern WordPress installations often suffer from CSS and JavaScript bloat caused by third-party plugins. By default, many complex plugins\u2014such as e-commerce suites, form builders, or syntax highlighters\u2014register and enqueue their static assets globally across every frontend URL. This unconditional loading inflates the Document Object Model (DOM), increases HTTP request counts, and degrades critical Core Web Vitals metrics including Largest Contentful Paint (LCP) and Interaction to Next Paint (INP).<\/p>\n
In WordPress v7.0.2, the asset management lifecycle relies on the WP_Scripts<\/code> and WP_Styles<\/code> classes. Assets are queued during the wp_enqueue_scripts<\/code> action hook. To prevent unnecessary files from reaching the browser without disabling plugin functionality, selective dequeuing must be implemented via the active theme’s functions.php<\/code> or an architectural Must-Use (MU) plugin.<\/p>\n\nWordPress loads every plugin asset on every page unless something intervenes. The table shows which handle is genuinely needed where; everything else is dequeued conditionally.<\/figcaption><\/figure>\n
Step-by-Step Implementation Guide<\/h2>\n
Step 1: Inspecting and Auditing Registered Handles<\/h3>\n
Before an asset can be dequeued, its unique internal handle must be identified. WordPress assigns a specific identifier string to every stylesheet and script file upon registration via wp_register_script()<\/code> or wp_register_style()<\/code>.<\/p>\n
To audit currently enqueued handles on any specific frontend route, the following diagnostic snippet can be temporarily executed within functions.php<\/code> to log all active handles to the PHP server log:<\/p>\n
Step 2: Understanding Hook Priorities and Execution Context<\/h3>\n
Attempting to remove an asset before a plugin has enqueued it will fail silently. Most standard plugins attach their enqueue functions to wp_enqueue_scripts<\/code> using the default priority of 10<\/code>.<\/p>\n
Therefore, a dequeuing function must be hooked to wp_enqueue_scripts<\/code> with a significantly higher numerical priority (e.g., 100<\/code> or 999<\/code>) to ensure execution occurs strictly after all third-party registrations have completed.<\/p>\n
Step 3: Writing the Selective Dequeuing Logic<\/h3>\n
The core functions for removing assets from the execution queue are:<\/p>\n
\n
wp_dequeue_script( $handle )<\/code> \u2013 Removes a JavaScript file from the queue.<\/li>\n
wp_deregister_script( $handle )<\/code> \u2013 Unregisters the script handle completely.<\/li>\n
wp_dequeue_style( $handle )<\/code> \u2013 Removes a CSS stylesheet from the queue.<\/li>\n
wp_deregister_style( $handle )<\/code> \u2013 Unregisters the style handle completely.<\/li>\n<\/ul>\n
Combining dequeue and deregister operations guarantees that dependent scripts cannot accidentally re-trigger the loading of the parent asset; the dependent scripts themselves are then no longer output either.<\/p>\n
Step 4: Production Code Pattern for WooCommerce and Form Assets<\/h3>\n
The following production-ready architecture demonstrates how to prevent WooCommerce assets and form-builder scripts from loading on standard technical blog posts and informational pages:<\/p>\n
Step 5: Quality Assurance and Regression Testing<\/h3>\n
After deploying the snippet, validation must be conducted across different content types:<\/p>\n
\n
Network Tab Inspection:<\/strong> Open the browser developer tools (F12) on a standard blog post and verify that the target .js<\/code> and .css<\/code> files are entirely absent from the network waterfall.<\/li>\n
Functional Verification:<\/strong> Visit an isolated route where the assets are legitimately required (e.g., the checkout URL or contact page) to confirm that conditional tags evaluate correctly and scripts execute without errors.<\/li>\n
Console Error Monitoring:<\/strong> Ensure no secondary JavaScript routines break due to missing global dependencies (such as undefined jQuery.fn<\/code> extensions).<\/li>\n<\/ol>\n
Summary and Measurable Added Value<\/h2>\n
What is achieved:<\/strong> Unconditional global asset enqueuing is replaced by strict, route-aware conditional loading. Third-party stylesheets and scripts are systematically isolated to the specific URLs where their functional dependencies are required.<\/p>\n
Resulting added value:<\/strong><\/p>\n
\n
Drastic Payload Reduction:<\/strong> Total transfer size on content pages is reduced by up to 300\u2013800 KB depending on plugin stack complexity.<\/li>\n
Elimination of Unused Code:<\/strong> Audits in Google PageSpeed Insights immediately show resolved warnings for “Reduce unused JavaScript”<\/em> and “Reduce unused CSS”<\/em>.<\/li>\n
Optimized Core Web Vitals:<\/strong> Faster JavaScript main-thread idle times lead to significantly lower Total Blocking Time (TBT) and superior INP scores, elevating organic search ranking potential.<\/li>\n<\/ul>\n
\n
Questions and answers<\/h2>\n
Why can wp_deregister_script() remove more scripts than intended?<\/h3>\n
Because WordPress only outputs a script when every handle it depends on is registered. Deregistering a handle therefore also drops every script that lists it as a dependency, including those of other plugins, and in normal operation the page shows no error for it. The network tab inspection from step 5 makes it visible: a file missing after the change that was not on the list depended on the removed handle.<\/p>\n
What needs attention with the contact form condition on a multilingual site?<\/h3>\n
is_page() compares against the ID, slug or title of the requested page. On a multilingual site every translation is a page of its own, with its own ID and usually its own slug. The condition from step 4 therefore only recognizes the page with the slug contact; on \/de\/kontakt\/ or \/pl\/kontakt\/ the form script is removed, and the form there runs without the script it relies on.<\/p>\n
Two approaches fix this:<\/p>\n
\n
is_page() also accepts a list, such as is_page( array( 'contact', 'kontakt', 'support' ) )<\/code>. That is simple, but it has to be updated for every new language or form page.<\/li>\n
The condition asks instead whether the content contains the shortcode: is_singular() && has_shortcode( get_post()->post_content, 'contact-form-7' )<\/code>. That follows the form rather than the address, but it does not detect forms placed in a widget or in a theme template.<\/li>\n<\/ul>\n
Which approach fits is decided by the functional verification from step 5, carried out on every language version of the form pages, not just the first.<\/p>\n<\/div>\n
![\"Cross](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/hand-dequeue-en.png\")