Make WordPress Core

Opened 3 years ago

Closed 15 months ago

#55595 closed enhancement (maybelater)

Consider only registering widgets on themes that supports widgets

Reported by: spacedmonkey's profile spacedmonkey Owned by: pereirinha's profile pereirinha
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 @spacedmonkey
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 @joyously
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.

#4 @pbearne
2 years ago

#57202 was marked as a duplicate.

#5 @flixos90
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

#8 @mukesh27
16 months ago

  • Owner set to pereirinha
  • Status changed from new to assigned

This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.


16 months ago

#10 @joemcgill
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.

This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.


15 months ago

This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.


15 months ago

#13 @mukesh27
15 months ago

  • Milestone 6.5 deleted
  • Resolution set to maybelater
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.