Opened 3 years ago
Closed 15 months ago
#55595 closed enhancement (maybelater)
Consider only registering widgets on themes that supports widgets
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Widgets | Keywords: | needs-patch close |
Focuses: | performance | Cc: |
Description
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.
Change History (13)
#2
@
3 years ago
@joyously That feel super edge casey. But we could add a check in the_widget to force registery if not already registered.
#3
@
3 years ago
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.
#5
@
17 months ago
- Milestone changed from Awaiting Review to 6.5
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.
This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.
17 months ago
This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.
16 months ago
This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.
16 months ago
#10
@
15 months ago
- Keywords close added
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.
What about plugins using
the_widget()
?https://developer.wordpress.org/reference/functions/the_widget/