[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