[wp-trac] [WordPress Trac] #37006: Extremely poor customizer performance

[WordPress Trac]

#37006: Extremely poor customizer performance
--------------------------+------------------------------
 Reporter:  jessecurry    |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Customize     |     Version:  3.9
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by westonruter):

 * version:  4.5.2 => 3.9


Comment:

 @jessecurry thanks. This has been raised previously on the Layers GitHub
 issues. Please see https://github.com/Obox/layerswp/issues/246

 See my comment there:
 https://github.com/Obox/layerswp/issues/246#issuecomment-194461882

 > I don't think that storing widgets as posts will help with the specific
 performance problem here. In fact, it could make performance worse if
 there is not a persistent object cache. In any case, the
 [https://github.com/xwp/wp-customize-widgets-plus/blob/master/php/class-
 widget-posts.php Widget Posts] module of the [https://github.com/xwp/wp-
 customize-widgets-plus Customize Widgets Plus] plugin is an implementation
 of storing widgets in a `widget_instance` post type. (This plugin needs
 more documentation and it needs an update on WordPress.org.)
 >
 > I think the specific problem you are facing is the fact that widgets in
 Core are still very PHP-centric. PHP is currently required to render the
 widget control forms, handle processing and sanitization of widget
 instance data, in addition to rendering the form into the page. PHP should
 not be required for rendering the form and handling the sanitization in
 the UI. Server-side sanitization should be applied only when the instance
 data is sent to the preview.
 >
 > The core Trac ticket for this is #33507: Allow widget controls to be JS-
 driven. A big problem of running out of memory is that widgets in Core
 currently require the `WP_Widget::form()` method to be called for each and
 every widget that has a Customizer control. This can greatly balloon the
 HTML response size. If JS-driven widgets are used, then there would only
 be one HTML template for a given widget which could be re-used for each
 widget instance output.
 >
 > Another issue in Core is that all widgets get rendered up-front
 regardless of whether they are going to be used. #23909 (Widgets settings
 loaded and instances registered unnecessarily) is the Trac ticket focused
 on this, along with #28580 (Speed up customizer by lazy-loading controls
 and settings as needed).
 >
 > There are not firm timetables on implementing these Trac tickets, though
 it's all definitely something I'm interested in for 4.6 if time and
 resources allow.

 I will note that there is now a feature plugin or JS Widgets:
 https://github.com/xwp/wp-js-widgets/

 This should greatly improve performance for generating controls, since
 they would all be constructed from JS templates. The problem is that all
 widgets would need to be re-implemented as JS Widgets to see the
 performance benefit. Also, this plugin doesn't address the lazy-loading of
 settings.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37006#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform