Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reader: Cut down image transfer significantly #11400

Merged
merged 3 commits into from
Feb 15, 2017

Conversation

blowery
Copy link
Contributor

@blowery blowery commented Feb 15, 2017

The primary thing here is teaching waitForImagesToLoad how to detect existing dimensions on images. This prevents the majority of preload requests for size for WordPress hosted sites. In addition, it now only tries to preload 5 images, max.

This PR also teaches the post card, gallery card, and recommended post card to load smaller images by default.

This cuts down on the number of images we need to transfer to load Reader pages and significantly speeds up how we choose what image to show.

To test, pull up the Following stream and scroll. Make sure the network tab is open. You should see significantly less network traffic, mostly for images.

Also, only try to preload 5 images max.

This cuts down on the number of images we need to transfer to load Reader pages and sigificantly speeds up how we choose what image to show.
@matticbot
Copy link
Contributor

@blowery blowery added [Feature] Reader The reader site on Calypso. [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Feb 15, 2017
@blowery blowery changed the title Reader: Teach the post preloader how to detect existing dimensions Reader: Cut down image transfer significantly Feb 15, 2017

const FeaturedImage = ( { imageUri, href, children, onClick } ) => {
if ( imageUri === undefined ) {
return null;
}

const featuredImageStyle = {
backgroundImage: 'url(' + cssSafeUrl( imageUri ) + ')',
backgroundImage: 'url(' + cssSafeUrl( resizeImageUrl( imageUri, { w: 250 } ) ) + ')',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth sticking the 250 into a const and explaining why we're using that value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


function FeaturedImage( { image, href } ) {
const uri = resizeImageUrl( safeImageUrl( image.uri ), { w: 385 } )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth sticking the 385 into a const and explaining why we're using that value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

return urlOrPromise;
}
return promiseForImage( imageForURL( urlOrPromise ) );
};

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth a comment block here explaining the general approach and how promises are used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, it got a little weird.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, and it's not needed anymore! I pulled this check down.

@bluefuton
Copy link
Contributor

Functionality looks good 👍

naturalWidth: knownDimensions.width,
naturalHeight: knownDimensions.height
};
}
imagesToCheck.push( image.src );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we still want to check images that we already know?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nevermind. you skip loading them later

@@ -43,7 +43,12 @@ function promiseForImage( image ) {
} );
}

const promiseForURL = flow( imageForURL, promiseForImage );
const promiseForURL = function( urlOrPromise ) {
if ( urlOrPromise instanceof Promise ) {
Copy link
Contributor

@samouri samouri Feb 15, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are we passing in a promise anywhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup, when we already know the size. I was trying to do the minimal thing to the image loading pipeline here, so I represented a "known" image as an already resolved promise, resolving it with a duck-typed image object. Not super clean, but it slips through the flow nicely.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually... this is done elsewhere now. Ripping it out.

@@ -14,7 +14,7 @@ import cssSafeUrl from 'lib/css-safe-url';
import { isFeaturedImageInContent } from 'lib/post-normalizer/utils';
import ReaderPostCardExcerpt from './excerpt';

const GALLERY_ITEM_THUMBNAIL_WIDTH = 420;
const READER_CONTENT_WIDTH = 800;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be 800 or 720?
I think it would be better if we reused (and/or updated) all of the constants from client/state/reader/posts/normalization-rules.js

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That one confused me too. We use 720, but cards can definitely be 800 with the redesign.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@samouri
Copy link
Contributor

samouri commented Feb 15, 2017

Wow. While on my personal Following stream the difference isn't so stark, when I measured any photo-heavy tag stream it was massive.

I'm talking about half the network traffic. To test I cleared cache and went to /tag/hawaii without scrolling:

  • 32.2MB Prod
  • 14.9MB This branch. 👍

@samouri samouri added [Status] Needs Author Reply and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Feb 15, 2017
@blowery blowery added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. and removed [Status] Needs Author Reply labels Feb 15, 2017
@samouri samouri added [Status] Ready to Merge and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Feb 15, 2017
@blowery blowery merged commit 90f9bcc into master Feb 15, 2017
@blowery blowery deleted the try/reader/limit-image-preloading branch February 15, 2017 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Reader The reader site on Calypso. [Type] Performance
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants