[wp-trac] [WordPress Trac] #36697: Combining the HTTP requests for obtaining the available nav menu items into a single request

WordPress Trac noreply at wordpress.org
Mon Sep 12 14:25:18 UTC 2016


#36697: Combining the HTTP requests for obtaining the available nav menu items into
a single request
--------------------------------------------------+------------------
 Reporter:  nguyencongtuan                        |       Owner:
     Type:  defect (bug)                          |      Status:  new
 Priority:  normal                                |   Milestone:  4.7
Component:  Customize                             |     Version:  4.3
 Severity:  normal                                |  Resolution:
 Keywords:  has-patch needs-testing dev-feedback  |     Focuses:
--------------------------------------------------+------------------
Changes (by celloexpressions):

 * version:  4.5 => 4.3


Comment:

 From the end user perspecitve, it's important that it seems like the
 content is already there when they open the panel. There can't/shouldn't
 be a delay between opening a section of available menu items and seeing at
 lest the initial items there to select from.

 It might partially be because we fire so many requests at once, but even
 with the current setup I often have to wait for sections to finish loading
 by the time I get to opening them. Merging these into one request is
 probably the best approach to improving the user experience here. The vast
 majority of users won't care about content loading that they might not
 need/see; a corollary is the fact that most customizer objects are loaded
 (at least their data) when the customizer is opened even if they won't be
 used. They'll care if they have to wait for something to load, and
 anything that has to do an Ajax call has the potential to be quite slow
 and even to fail, even in my everyday experience with sub-par (for the US)
 connections.

 In most cases the user will be opening the add-items panel when they go
 into menus, with the exceptions being changing locations, reordering, or
 deleting only, although those actions often also coincide with adding
 items. We're not talking about a lot of data here, so if we can start
 loading it in anticipation of the user needing it, the user is less likely
 to need to wait. The approach in [attachment:36697.2.diff] seems like the
 best improvement we can make here.

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


More information about the wp-trac mailing list