Wp-calypso: Cards load as Default and then change to Gallery

Created on 17 Nov 2016  路  10Comments  路  Source: Automattic/wp-calypso

When loading a new set of cards, some cards first appear as a Default card and then change to a Gallery card.

Is there any way to reduce/remove this lag/flip?

Reader [Type] Question

Most helpful comment

reader default to gallery flash

All 10 comments

Have an example post?

reader default to gallery flash

I have a couple of ideas here:

  • combine both fastNormRules + slowNorm rules and break it up rule/rule with requestIdleCallback. Call the waitForImagesToLoad earlier on to initiate all of the requests and then wait for it to finish before calling classifyPost. This may mean that the placeholder will stay for a bit longer...but I'm not sure. It would improve overall app performance (unblocking ui thread more frequently) and would stop the jump
  • For posts that contain many images and so we are pretty sure they may be galleries we may be able to artificially make the images smaller using photon query params so they load faster (aka maxWidth=250px instead of 720)

@blowery what do you think? Even if we don't want muck with requestIdleCallback + smartly splitting up norm rules, we could still call waitForImagesToLoad in fastNormRules and then call the then in slowRules

They way things are right now, fastNormRules _have_ to by synchronous. So if we want to make them async, we'd have do rejigger how they're used a bit and how we consume posts in general. We don't want the post to appear in the flux store until it's at least passed through the safety and unescaping bits of the post normalizer.

Maybe we can try to pick up the sizes of the images earlier and then avoid loading images that we know the size of? Or just assume that a post with some number of images in it will be a gallery? Or automatically make posts with a wp gallery in them and enough photos a gallery card?

For posts that contain many images and so we are pretty sure they may be galleries we may be able to artificially make the images smaller using photon query params so they load faster (aka maxWidth=250px instead of 720)

I've been thinking about that one. The problem is that we also use that photon request to get the presumptive size of the images, which also tells us if an image is big enough to feature. So we'd want to ask for at least a featureable image size.

In addition, we may want to rewriting the image urls when we _are_ in gallery cards to resize them as small as possible. The issue there is that we already loaded the image once at a different size, so it's in the cache, and that's the size that will be fastest to load... Fun problem.

The other other way to solve this would be to record the image sizes during post ingestion into the feedbag. I think we can glean some info from wp metadata ( @gibrown ?) for wpcom and maybe jetpack media, but for feed media we probably need to fetch it and store it somewhere.

I think one other complication here is that wp's new responsive image stuff is stripping the width and height from img tags. We may need to try grab the info from the photon query string or from image meta or ... somewhere. Maybe the srcset, but I don't think that gives us height? Might be enough though.

I think we can glean some info from wp metadata ( @gibrown ?) for wpcom and maybe jetpack media, but for feed media we probably need to fetch it and store it somewhere.

Ya for wp.com and sometimes JP we can get the data the same way as we do for ES indexing.

This is way better now.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ehg picture ehg  路  3Comments

apeatling picture apeatling  路  3Comments

kellychoffman picture kellychoffman  路  3Comments

samouri picture samouri  路  3Comments

spen picture spen  路  3Comments