Consider only registering widgets on themes that supports widgets

[spacedmonkey]

The wp_widgets_init function is run all init and is run on every request. This is wasteful for a number of reasons. Register a widget can result in a get_option lookup. Also, if the theme does not support widgets, then this is wasteful. Consider adding a simple check at the start of wp_widgets_init to check if the current theme supports widgets, before registering.

This is specially good, considering that more and more themes are now block based and do not use widgets at all.

[joyously]

What about plugins using the_widget()?
​https://developer.wordpress.org/reference/functions/the_widget/

[spacedmonkey]

@joyously That feel super edge casey. But we could add a check in the_widget to force registery if not already registered.

[joyously]

There could also be actions triggered, that would no longer be triggered.
See ​https://wpdirectory.net/search/01G144AV0DYES8C17J92YSRS8Z
The SEO plugins have remove_all_actions( 'widgets_init' ); and all the plugins that register a widget do it on the 'widget_init' action which is in the wp_widgets_init() function.

I didn't look at all 18705 matches, but I do know there is a widget block, so you don't need the theme to declare support for widgets to be using all those legacy widgets, which won't work without the action at which the widget is registered.

[pbearne]

#57202 was marked as a duplicate.

[flixos90]

Prioritizing this to work on in the 6.5 milestone.

We will need to find a way for widgets to be "lazyily" registered, i.e. only once a widget is needed, to support the cases where even in a theme that doesn't support widgets, the_widget() is called (e.g. in a block). Potentially this can be accomplished by registering the default widgets and firing the widgets_init action only once a widget is requested for rendering.

[joemcgill]

I spent a little time reviewing the potential performance benefit of not registering widgets and am not seeing a huge performance impact for the actual registration of widgets. Looking back at ​the profiling data I collected when profiling WP 6.3, wp_widgets_init accounts for a very small inclusive wall time (IWT):

• Twenty Twenty-one (home) – 0.61% IWT
• Twenty Twenty-three (home) – 0.87% IWT

Similarly, ​a recent profile of Twenty Twenty-four on WP 6.4 shows this only takes 0.8% IWT.

In the ​WP 6.2 profiling analysis we noticed that rendering widgets (i.e., WP_Widget::display_callback had a significant performance cost, but is only relevant when a site has widgets to display, and is additionally dependent on which widgets are being rendered. For example, the core categories block used in the category list widget was responsible for 5–10% of the total IWT during the 6.2 performance analysis.

Unless there is an additional factor I'm missing, I'm thinking we could consider closing this and focusing effort on how widgets are rendered instead.

[mukesh27]

This ticket was discuss in today's performance scrub and we are agree to close this ticket as maybelater for now as per @joemcgill above comment.

Feel free to reopen if it is not case.