How to Disable a Module's CSS/JS Without Uninstalling It

The Problem: You Need the Module, But Not Its Assets on Every Page

There are many situations where you want to keep a PrestaShop module installed and active but prevent it from loading its CSS or JavaScript files on specific pages, or even on all pages. Perhaps you have a module whose functionality you need but whose styling conflicts with your theme. Perhaps a module loads a heavy JavaScript library that you have already included through your theme. Perhaps you want to replace a module's default styles with your own custom CSS without the original styles interfering. Or perhaps you have identified through a performance audit that a module loads assets on pages where it has no visible output, and you want to eliminate that waste.

Uninstalling the module is not an option because you need its core functionality: its hooks, its database tables, its configuration, its back office features. You just need to surgically remove specific CSS or JavaScript files from the front office output. PrestaShop provides several mechanisms to accomplish this, and this article covers all of them in detail, from the simplest to the most powerful.

Method 1: Using Theme.yml to Remove Module Assets

The simplest and most maintainable way to remove a module's CSS or JavaScript in PrestaShop 1.7 and later is through the theme's configuration file, theme.yml. This file, located in the root of your theme directory, controls which assets the theme loads and which module assets it removes.

Open your theme.yml file and look for the assets section. If it does not exist, you can create it. Within the assets section, you can specify CSS and JavaScript files to remove by their asset ID. Every asset registered through registerStylesheet or registerJavascript has an ID, which is typically the module name followed by a descriptive suffix.

To find the asset IDs used by a module, inspect your page source and look for the stylesheet link tags and the elements. PrestaShop adds an id attribute to these elements in debug mode, or you can find the IDs in the module's source code where it calls registerStylesheet or registerJavascript.

In your theme.yml file, add a section like this under assets, then css, then all. Add an entry with the asset ID and set it to false. For example, if a module registers a stylesheet with the ID modulename-style, you would add modulename-style with a value of false under the css all section. Do the same for JavaScript files under the js all section.

After modifying theme.yml, you need to clear your PrestaShop cache from Advanced Parameters, Performance. The theme.yml changes take effect after the cache is rebuilt. This approach persists across module updates because the removal is defined in your theme, not in the module itself. However, it removes the assets from all pages. If you need the assets on some pages but not others, you will need a more targeted approach.

Method 2: Media::unregisterStylesheet and Media::unregisterJavascript

PrestaShop 1.7 introduced the Media class methods unregisterStylesheet and unregisterJavascript, which allow you to programmatically remove specific assets that were registered by other modules. These methods are powerful because you can call them conditionally, removing assets only on specific pages while keeping them on others.

To use this approach, you need a custom module or a modification to an existing module. In your module's hookActionFrontControllerSetMedia method, call Media::unregisterStylesheet with the asset ID of the CSS file you want to remove. Similarly, call Media::unregisterJavascript with the asset ID of the JavaScript file. You can wrap these calls in conditional logic to only remove assets on specific page types.

For example, if you want to remove a slider module's assets from every page except the homepage, you would check whether the current controller is IndexController. If it is not the homepage, you call the unregister methods. If it is the homepage, you do nothing and let the assets load normally.

The key consideration with this approach is hook execution order. Your module's hookActionFrontControllerSetMedia must execute after the module whose assets you want to remove. PrestaShop executes hook callbacks in the order modules are registered on the hook, which you can control through the Design, Positions page in the back office. Move your custom module below the target module on the actionFrontControllerSetMedia hook to ensure your unregister calls happen after the target module registers its assets.

If the offending module uses the older addCSS and addJS methods instead of registerStylesheet and registerJavascript, the unregister methods may not work because the older methods do not use the same asset management system. In that case, you need a different approach.

Method 3: Custom Module to Block Specific Assets

When you need fine-grained control over which assets load on which pages, creating a dedicated asset manager module is the most flexible solution. This module acts as a central place where you define rules for blocking or allowing specific module assets.

Create a new module with a hookActionFrontControllerSetMedia method. Inside this method, define an array of asset rules. Each rule specifies a module name, the asset IDs to block, and the conditions under which to block them. The conditions can be based on controller name, page type, or any other criteria available in the PrestaShop context.

Your module iterates through the rules on every page load, checks the conditions, and calls Media::unregisterStylesheet or Media::unregisterJavascript for each asset that should be blocked on the current page. This centralized approach is much easier to maintain than scattering asset removal logic across multiple modules or theme files.

You can enhance this module with a back office configuration page that lets you manage the rules through the PrestaShop admin interface instead of editing code. A simple form with fields for module name, asset ID, and a multiselect for page types where the asset should be blocked gives you a user-friendly way to manage asset loading without touching any code after the initial setup.

This approach works with both the new registerStylesheet system and the older addCSS system, though you may need to use different techniques for each. For assets registered with the new system, use the Media::unregister methods. For assets added with the older system, you can manipulate the controller's css_files and js_files arrays directly in the hookActionFrontControllerSetMedia method.

Method 4: The Hook Unhooking Approach

A more aggressive but sometimes necessary approach is to completely unhook a module from the hooks where it registers its assets. Go to Design, then Positions in your back office. Find the module on the displayHeader or actionFrontControllerSetMedia hook. Click the delete or unhook button to remove the module from that hook entirely.

This prevents the module from loading any assets at all, on any page. The module's other hooks, such as displayProductAdditionalInfo or displayFooter, continue to work normally. However, the module's front office output may break if it depends on its CSS for styling or its JavaScript for interactive behavior.

This approach is most useful when you plan to replace the module's styling entirely with your own custom CSS. You unhook the module from displayHeader to prevent its CSS from loading, then write your own styles in your theme's custom CSS file that target the module's HTML elements. This gives you complete control over the module's appearance without any conflict between the original styles and your customizations.

For JavaScript, unhooking is riskier. If the module relies on its JavaScript for core functionality like AJAX calls, form validation, or dynamic content loading, removing the JavaScript will break those features. Only unhook JavaScript if you are certain the module's front office output does not depend on it, or if you are providing a replacement implementation through your theme.

One important caveat: if you update the module, the update process may re-register the module on the hooks you removed it from. After every module update, check Design, Positions to verify your unhooking is still in effect. Some modules explicitly register their hooks during the update process, which overrides your manual unhooking.

Method 5: Overriding Module Assets Through Your Theme

PrestaShop's theme system allows you to override module template files by placing them in your theme's modules directory. While this is primarily used for template overrides, you can also use it to control asset loading indirectly.

If a module loads its assets through its template files using Smarty functions like script or stylesheet tags directly in TPL files rather than through PHP hooks, you can override those templates in your theme and remove the asset references. Copy the module's template file to your theme's modules directory, maintaining the same directory structure, and edit the copy to remove the unwanted CSS or JavaScript references.

This approach is theme-specific, meaning it only affects the current theme. If you switch themes, the overrides do not carry over. It also requires maintenance: when the module updates its templates, you need to update your overrides to match any structural changes while keeping your asset removal modifications.

For modules that load assets through PHP hooks rather than templates, theme template overrides do not help with asset blocking. In that case, use one of the other methods described in this article.

PrestaShop 1.7 vs 8.x: Differences in Approach

PrestaShop 8.x refined the asset management system introduced in 1.7, but the fundamental approaches remain the same. The main differences are in the internal implementation and some additional features.

In PrestaShop 1.7, the asset management system uses registerStylesheet and registerJavascript with a priority system. The Media::unregisterStylesheet and Media::unregisterJavascript methods work reliably for assets registered through this system. However, modules that still use the legacy addCSS and addJS methods (which are deprecated but still functional) do not go through the new asset management system, making them harder to remove cleanly.

PrestaShop 8.x improved backward compatibility so that even assets added through the legacy methods are processed through the new asset pipeline. This means Media::unregister methods work more consistently across all modules, regardless of which registration method they use. If you are running PrestaShop 8.x, the unregister approach is the most reliable method for all modules.

PrestaShop 8.x also introduced better cache-busting for assets, which means that when you remove or modify assets, the changes take effect immediately after clearing the cache, without customers seeing stale cached versions. In PrestaShop 1.7, you sometimes needed to clear both the PrestaShop cache and the browser cache, or wait for the Combine, Compress, Cache (CCC) system to regenerate combined files.

Both versions support the theme.yml approach for asset removal, and the syntax is identical. If you are writing a custom module for asset management, the same code works on both 1.7 and 8.x with minimal differences.

Measuring Performance Gains After Disabling Assets

After disabling module assets, you should measure the performance improvement to confirm that your changes had the expected effect. Use a combination of tools for a comprehensive measurement.

Start with Chrome DevTools' Network tab. Compare the total number of requests and total transferred size before and after your changes. Filter by CSS and JS to see the specific reduction in stylesheet and JavaScript file counts and sizes. A meaningful optimization should show a clear reduction in both the number of requests and the total size.

Run a Lighthouse performance audit before and after. Focus on the metrics most affected by CSS and JavaScript loading: First Contentful Paint is affected by render-blocking CSS, Largest Contentful Paint is affected by overall resource loading, and Total Blocking Time is affected by JavaScript parsing and execution. Record these metrics from at least three runs and compare the averages.

Use the Coverage tab in Chrome DevTools to measure CSS and JavaScript usage. Open the Coverage tab from the three-dot menu under More Tools, then reload the page. The Coverage tab shows you how much of each CSS and JavaScript file is actually used on the current page. Files with high unused percentages (shown in red) are candidates for removal or conditional loading. After disabling module assets, the remaining files should show higher usage percentages, indicating that you have successfully removed waste.

Also consider real-world metrics from your analytics platform. If you use Google Analytics or a similar tool, compare page load times for a week before and after your optimization. Real-world data from actual visitors across different devices and network conditions gives you the most accurate picture of the performance improvement.

Risks and Compatibility Concerns

Disabling module assets carries risks that you need to understand and manage. The most common risk is visual breakage. When you remove a module's CSS, its HTML elements lose their styling and may display incorrectly. This can range from minor cosmetic issues like wrong colors or spacing to major layout problems like overlapping elements or invisible content.

JavaScript removal carries higher risk. Modern modules often depend on their JavaScript for core functionality. Removing JavaScript can cause features to stop working entirely: buttons that do not respond to clicks, forms that do not submit, popups that do not open, AJAX content that does not load. Always test every feature of a module after removing its JavaScript.

There is also a compatibility risk with module updates. When a module is updated, the developer may add new CSS or JavaScript files with different asset IDs. Your removal rules, whether in theme.yml or a custom module, may not catch the new assets because they target the old asset IDs. After every module update, verify that your asset blocking is still working correctly and update your rules if necessary.

Some modules perform feature detection in their JavaScript and behave differently when their CSS is not loaded. A module might check for the existence of specific CSS classes or computed styles before initializing its JavaScript functionality. Removing the CSS in this case does not just change the appearance but also breaks the JavaScript behavior that depends on those CSS-defined states.

Finally, be aware of dependencies between modules. Module A might load a JavaScript library like a lightbox plugin that Module B also uses but does not load itself because it assumes Module A provides it. Removing Module A's JavaScript files would break both modules in this scenario. Check for shared dependencies before removing any assets.

A Practical Workflow for Safe Asset Removal

Follow this workflow to safely disable module assets without breaking your store. First, document your current state. Take screenshots of every page type where the module displays content. Record Lighthouse scores and Network tab statistics. This gives you a baseline to compare against and a reference for how the module should look and function.

Second, identify the specific assets you want to remove. Use DevTools to find the exact file names and asset IDs. Determine which pages need the assets and which do not.

Third, implement the removal using the most appropriate method from this article. For simple global removal, use theme.yml. For conditional removal based on page type, create a custom module with Media::unregister calls. For complete asset replacement, unhook the module and provide your own styles.

Fourth, test thoroughly. Check every page type where the module should display content. Verify that the module's visual appearance is correct and all interactive features work. Check pages where you removed the assets to confirm they are no longer loading. Test on multiple browsers and devices.

Fifth, measure the performance improvement. Run Lighthouse audits and compare with your baseline. Check the Network tab for reduced request counts and sizes. If the improvement is significant, your optimization was successful. If the improvement is minimal, the assets you removed may not have been the main performance bottleneck, and you should investigate other optimization opportunities.

Sixth, document your changes. Record which assets you removed, which method you used, and which pages are affected. This documentation is essential for troubleshooting future issues, especially after module updates, and for knowledge transfer if someone else maintains the store.

By following this systematic approach, you can safely reduce your store's page weight and improve loading times without sacrificing the module functionality your store depends on. The key is always testing and measurement: never assume that removing an asset is safe, and always verify the results with concrete data.

For more details, read our guides: Custom CSS and JavaScript in PrestaShop Without Breaking Updates and Page Speed and SEO: How Slow Loading Kills Your Google Rankings.