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

Image Block: Improve performance by only requesting image metadata if selected. #17504

Merged
merged 1 commit into from Sep 24, 2019

Conversation

@epiqueras
Copy link
Contributor

epiqueras commented Sep 20, 2019

Fixes #17465

Description

This PR stops image blocks from preemptively requesting image metadata and delays it until the block is selected.

This fixes performance issues with posts that contain many images.

How to test?

Verify that the image block still works as expected and that the issue described in #17465 is no longer happening.

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
Copy link
Member

jorgefilipecosta left a comment

Hi @epiqueras, checking the code it seems that the image object is only needed to select an image size updateImage( sizeSlug ) {... and to select an image link destination getLinkDestinations() {... Can't we extract these small UI pieces into separate small components and request the image object user using useSelect?
This way if the sizes/link UI is not expanded the image is not request at all.

@epiqueras
Copy link
Contributor Author

epiqueras commented Sep 20, 2019

I don't think that's worth the extra complexity.

What if we need it in other places as well?

Making the request once selected is perfectly fine from a performance standpoint.

@gziolo
Copy link
Member

gziolo commented Sep 24, 2019

Doesn't what @jorgefilipecosta proposes aligns closely with the principles we shared when building components? I didn't look inside the code, but I think it makes a lot of sense to use data in components which consume it rather than pass it down from the edit. It's usually less code to use big edit implementation, but it doesn't mean that it's the most efficient one in terms of maintainability.

@epiqueras
Copy link
Contributor Author

epiqueras commented Sep 24, 2019

Doesn't what @jorgefilipecosta proposes aligns closely with the principles we shared when building components? I didn't look inside the code, but I think it makes a lot of sense to use data in components which consume it rather than pass it down from the edit. It's usually less code to use big edit implementation, but it doesn't mean that it's the most efficient one in terms of maintainability.

Yeah, but this component is already implemented and the fix is 2 lines. Breaking it into components is almost a complete refactor and shouldn't be tied to this fix.

Copy link
Member

jorgefilipecosta left a comment

I verified this fix works well, I guess breaking the big edit in components would be positive but I agree with @epiqueras it is something we can look after and not as part of this fix.

@epiqueras epiqueras merged commit aedd241 into master Sep 24, 2019
7 checks passed
7 checks passed
pull-request-automation
Details
Header rules - gutenberg-playground No header rules processed
Details
Pages changed - gutenberg-playground 3 new files uploaded
Details
Redirect rules - gutenberg-playground No redirect rules processed
Details
Mixed content - gutenberg-playground No mixed content detected
Details
Travis CI - Pull Request Build Passed
Details
netlify/gutenberg-playground/deploy-preview Deploy preview ready!
Details
@epiqueras epiqueras deleted the try/improving-image-loading-performance branch Sep 24, 2019
dd32 pushed a commit to dd32/gutenberg that referenced this pull request Sep 27, 2019
@youknowriad youknowriad modified the milestones: Future, Gutenberg 6.6 Sep 30, 2019
@karmatosed karmatosed added this to Inbox in Tightening Up Oct 21, 2019
@karmatosed karmatosed removed this from Inbox in Tightening Up Oct 21, 2019
@jorgefilipecosta jorgefilipecosta mentioned this pull request Dec 2, 2019
6 of 6 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.