1001665 - Images blocking on something before loading

Status: RESOLVED WORKSFORME

(Marketplace Graveyard :: Code Quality, defect, P2)

Description

[Wil Clouser [:clouserw]]

Originally from bug 987895:

> > 6] starting at request 44 there is a run of images all requested together
> > that have obviously been waiting for something to complete.. I bet that wait
> > time can be moved up. how does include.js make its requests? i.e. does it
> > try and do some kind of smart scheduling or does it go ahead and make the
> > image requests as fast as it can? with spdy it should do the latter.

Comment 1

[Mathieu Pillard [:mat]]

At the time this was written there was no smart scheduling: basically, we start rendering the main template, it contains a {% defer %} tag that does the XHR to the endpoint containing the apps, and when that XHR is received it modifies the DOM to add the apps to the page, which loads the images via regular <img> tags.

Nowadays we've added deferred image loading, so this is no longer strictly true, ccing :ngoke so he can make the necessary additions to my comment.


TL;DR: those images were waiting for the XHR that contains... the path to the images, so I don't think there is much we can do here, but I'm hoping to be proven wrong :)

Comment 2

[Andy McKay]

Is this still true?

Comment 3

[Kevin Ngo [:ngoke]]

That's true, the base page needs to be loaded and then the image deferrer needs to kick off before the images are actually requested.

Comment 4

[Christopher Van Wiemeersch [:cvan]]

The answer is to send down only the critical JS (and CSS) so we get the XHRs back sooner, so we know the image URLs specified in the JSON responses, so we can request the images sooner.

A lot of that should be solving with bug 1001665.

Comment 5

[Mathieu Pillard [:mat]]

Is there anything left to do here ? We are loading images asynchronously on purpose, and only those visible or close to the viewport. We only know which images to load once they are present, which means we need the XHR and the template, so we have very little margin.

> A lot of that should be solving with bug 1001665.

You meant bug 1001666, right ? Or another one ? bug 1001665 is this very bug :-)

Comment 6

[Christopher Van Wiemeersch [:cvan]]

(In reply to Mathieu Pillard [:mat] from comment #5)
> Is there anything left to do here ? We are loading images asynchronously on
> purpose, and only those visible or close to the viewport. We only know which
> images to load once they are present, which means we need the XHR and the
> template, so we have very little margin.

Agreed, I don't think there's much to do here. Any type of preloading I think is necessary given that we are already deferring images until they're visible.

> > A lot of that should be solving with bug 1001665.
> 
> You meant bug 1001666, right ? Or another one ? bug 1001665 is this very bug
> :-)

Yep, that's the one heh.

Comment 7

[Mathieu Pillard [:mat]]

Closing as works for me since the deferring works as intended. Per comment 5 and 6, if we want to make the images (or really, all relevant resources for the current view, not just images) load earlier we'll do that in bug 1001666.