The Optimization tab controls additional frontend performance features that work alongside MinimalCSS-generated CSS.
While the Page Inventory and Archive Inventory focus on generating optimized CSS for specific URLs, the Optimization tab helps reduce unnecessary frontend weight from scripts, default WordPress assets, and other sitewide resources.
This tab should be reviewed carefully because script and WordPress asset settings can affect how your site behaves on the frontend.
What the Optimization Tab Is For
The Optimization tab is used to manage performance settings that apply more broadly across your site.
Depending on your site setup, this may include:
- Script optimization
- Script delay settings
- WordPress default asset cleanup
- Frontend performance helpers
- Compatibility-focused exclusions
- Optional sitewide optimizations beyond page-specific CSS generation
These settings can help reduce unnecessary requests, improve page loading behavior, and support better Core Web Vitals results.
Recommended Approach
Start with conservative settings first.
Before enabling multiple optimization features at once, test your most important pages and confirm that menus, forms, tracking scripts, sliders, popups, ecommerce features, and interactive elements still work correctly.
A safe workflow is:
- Enable one optimization setting at a time.
- Save your changes.
- Test key pages on desktop and mobile.
- Check important interactive features.
- Continue only after confirming the site still works as expected.
This makes it easier to identify which setting caused an issue if something changes on the frontend.
Scripts Section
The Scripts section helps control how JavaScript loads on your site.
JavaScript can have a major impact on performance because scripts may block rendering, delay interactivity, or compete with important page resources during load.
The Scripts section may include options to delay or adjust script loading so the most important page content can appear sooner.
This can be especially helpful for scripts that are not immediately needed when the page first loads.
Examples may include:
- Analytics scripts
- Tracking pixels
- Chat widgets
- Marketing scripts
- Social media embeds
- Review widgets
- Video embeds
- Heatmap tools
- Non-critical third-party scripts
However, scripts that are required for layout, navigation, forms, checkout, or core interactivity should be tested carefully before being delayed.
Script Delay
The Script Delay feature delays selected JavaScript until later in the page experience.
Instead of loading every script immediately, delayed scripts may wait until user interaction or another trigger occurs. This can reduce the amount of JavaScript competing for browser resources during the initial page load.
Script delay can help improve performance metrics such as:
- Initial page load speed
- Main-thread work
- Total Blocking Time
- Interaction readiness
- Core Web Vitals-related performance
Script delay is most useful for non-critical scripts that are not needed immediately when the page first appears.
When Script Delay Is Helpful
Script delay can be a good option for scripts that support tracking, marketing, or optional enhancements.
Good candidates may include:
- Google Analytics
- Meta Pixel
- LinkedIn Insight Tag
- TikTok Pixel
- Heatmap scripts
- Live chat widgets
- Social sharing widgets
- Embedded review widgets
- Newsletter popups
- Third-party marketing tools
These scripts often do not need to load before the visitor can see and use the main page content.
Scripts You Should Be Careful With
Some scripts should not be delayed unless you have tested them carefully.
Be cautious with scripts related to:
- Mobile menus
- Dropdown menus
- Sticky headers
- Sliders and carousels
- Contact forms
- Form validation
- WooCommerce cart and checkout
- Payment gateways
- Membership login areas
- Booking systems
- Search filters
- AJAX filtering
- Accessibility tools
- Cookie consent banners
- Security or anti-spam features
If these scripts are delayed too aggressively, parts of the page may not work until after user interaction, or they may not initialize correctly.
Testing Script Delay
After enabling script delay, test your site as a real visitor would.
Check your most important pages and actions, including:
- Opening and closing the mobile menu
- Submitting contact forms
- Using sliders, tabs, accordions, or popups
- Clicking calls to action
- Testing checkout and cart actions
- Using search, filters, or sorting tools
- Confirming analytics and tracking still fire as expected
- Checking cookie consent behavior
- Testing logged-in and logged-out views if your site has user accounts
Script delay should improve performance without breaking essential functionality.
Script Exclusions
If a delayed script causes issues, exclude that script from delay.
This allows you to keep script delay enabled for non-critical scripts while allowing important scripts to load normally.
Common reasons to exclude a script include:
- A form stops submitting correctly
- The mobile menu does not open
- A slider does not initialize
- Checkout behavior changes
- A popup or consent banner stops working
- Filters, tabs, or accordions stop responding
- A tracking script needs to fire earlier
When troubleshooting, exclude only the script that needs normal loading instead of disabling script delay completely.
WordPress Defaults Settings
The WordPress Defaults settings help remove or reduce frontend assets that WordPress may load automatically.
WordPress includes several default scripts, styles, and features that may not be needed on every site. Removing unused defaults can reduce requests and keep the frontend cleaner.
These settings are usually safe for many sites, but they should still be tested.
Common WordPress Defaults That May Be Optimized
Depending on the available options in MinimalCSS, the WordPress Defaults section may include settings related to:
- Emoji scripts and styles
- WordPress embeds
- Dashicons on the frontend
- Block editor styles
- Comment reply scripts
- REST API links in the document head
- WordPress version meta output
- Really Simple Discovery links
- Windows Live Writer links
- Shortlink output
Not every site needs all of these frontend assets.
For example, if your site does not use WordPress comments, the comment reply script may not be needed. If your site does not rely on emoji replacement, WordPress emoji assets may be unnecessary. If logged-out visitors do not need Dashicons, those assets may be removed from the public frontend.
Emoji Optimization
WordPress may load emoji-related assets to support emoji rendering.
Many modern browsers already display emoji without requiring extra WordPress scripts. If your site does not need WordPress emoji handling, disabling emoji assets can reduce frontend overhead.
After disabling emoji assets, review pages where emojis are used to confirm they still display acceptably.
Embeds Optimization
WordPress includes embed functionality that helps turn certain URLs into embedded content.
If your site does not rely on WordPress oEmbed behavior, disabling embed scripts may reduce unnecessary frontend JavaScript.
Be careful if your content uses embedded posts, videos, social content, or other media that depends on WordPress embed behavior.
Dashicons Optimization
Dashicons are the icon font used by WordPress admin.
Some themes or plugins may load Dashicons on the frontend, even for visitors who are not logged in. If your public-facing site does not need Dashicons, disabling them for logged-out visitors can reduce unnecessary font and CSS loading.
Before disabling Dashicons, check whether your theme, forms, ratings, account links, or plugin widgets use Dashicons on the frontend.
Disable Gutenberg Scripts
WordPress may load Gutenberg-related scripts and styles on the frontend to support block editor features.
On many modern WordPress sites, these assets are useful because page content, posts, buttons, columns, galleries, and reusable patterns may rely on block-based styling. However, some sites use classic editor content, page builders, or custom templates and may not need all Gutenberg frontend assets.
Disabling Gutenberg scripts can help reduce unnecessary frontend requests, especially on sites that do not use Gutenberg blocks heavily.
Be careful with this setting if your site uses:
- Gutenberg blocks
- Block patterns
- Core WordPress buttons, columns, galleries, or embeds
- Block-based themes
- Full Site Editing
- Reusable blocks
- WooCommerce blocks
- Plugin blocks inserted into pages or posts
After enabling this option, review pages and posts that use block-based layouts. Pay close attention to spacing, buttons, columns, galleries, and embedded content.
If Gutenberg-based content looks different after enabling this setting, turn the option off or exclude the affected pages from aggressive optimization.
Remove jQuery Migrate Script
The jQuery Migrate script helps older themes and plugins continue working with newer versions of jQuery.
Some WordPress themes and plugins still rely on older jQuery methods. jQuery Migrate acts as a compatibility layer so older scripts do not immediately break when WordPress uses a newer version of jQuery.
Removing jQuery Migrate can reduce one frontend script request and slightly clean up script loading, but it should be tested carefully.
This setting is usually safer on sites with modern themes and well-maintained plugins. Be more cautious on older sites, heavily customized sites, or sites using older page builders, sliders, galleries, forms, or theme scripts.
After removing jQuery Migrate, test interactive features such as:
- Mobile menus
- Dropdown menus
- Sliders and carousels
- Popups
- Accordions and tabs
- Forms and validation
- WooCommerce cart and checkout behavior
- Filtering and sorting tools
- Custom theme JavaScript
If you see JavaScript errors in the browser console or interactive features stop working, re-enable jQuery Migrate.
Best Practice Workflow
A safe Optimization tab workflow looks like this:
- Review the Scripts section first.
- Enable script delay only if you are prepared to test important frontend features.
- Test menus, forms, sliders, carts, checkout, popups, and tracking.
- Exclude any scripts that should not be delayed.
- Review the WordPress Defaults settings.
- Disable only the WordPress defaults your site does not need.
- Test important page templates again.
- Regenerate CSS if related frontend layout or asset changes affect page appearance.
- Keep notes on any exclusions or compatibility settings you apply.
This approach helps improve performance without creating unexpected frontend issues.
Troubleshooting
My mobile menu stopped working
A required menu script may have been delayed. Exclude the related theme, menu, or navigation script from script delay and test again.
My contact form does not submit correctly
Form scripts may need to load normally. Exclude the related form plugin scripts from script delay. Also test any anti-spam, CAPTCHA, or validation features.
WooCommerce cart or checkout behavior changed
Do not delay critical WooCommerce cart, checkout, payment, or session-related scripts. Exclude those scripts and test the full purchase flow again.
My cookie banner is not appearing soon enough
Cookie consent scripts often need to load early for compliance and tracking control. Exclude the cookie consent script from delay if needed.
A slider, popup, or accordion stopped working
The script that initializes the feature may be delayed. Exclude the related script and test the page again.
Icons disappeared from the frontend
If Dashicons or another icon font was disabled, your theme or plugin may still rely on it. Re-enable the related setting or exclude the affected asset from cleanup.
Embedded content stopped working
If WordPress embeds were disabled, some embedded content may no longer behave as expected. Re-enable embed support if your site relies on embedded posts, videos, or social content.
Recommended Settings for Most Sites
For many brochure, service, and content websites, a good starting point is:
- Use script delay carefully for non-critical third-party scripts.
- Avoid delaying scripts required for menus, forms, checkout, login, or filtering.
- Disable WordPress emoji assets if your site does not need them.
- Disable embeds only if your site does not rely on WordPress embed behavior.
- Disable Dashicons for logged-out visitors only if your frontend does not use them.
- Test every setting before applying it broadly.
The safest configuration is the one that improves performance while preserving the full visitor experience.