Gallery blocks are slow

[bradyvercher]

Issue Overview

The Gallery block as it's currently implemented has performance and scaling issues due to the number of requests it generates. I'm not familiar with best practices in React, but I'll try to explain what I'm seeing when working with galleries.

Steps to Reproduce (for bugs)

1. Insert a new Gallery block

2. Click the "Insert from Media Library" button to open the media modal
   
   This is standard behavior, but just to explain what happens: When the media modal is opened for the first time, it sends a query-attachments AJAX request to fetch the 40 most recent attachments and adds them to a global collection accessible at wp.media.model.Attachments.all.
   
   Scrolling through the library will lazy load 40 attachments at a time.

3. Select 10 images and click the "Create New Gallery" button

4. Click the "Insert Gallery" button
   
   When inserting the gallery, the Gallery block fires off a separate request to the REST API for each image in the gallery. In this case, that's 10 requests that have to respond before the gallery can be previewed.
   
   Besides slamming the server with requests, this also creates a suboptimal rendering delay.

5. Click the edit button in the toolbar to update the gallery
   
   The block sends a get-attachment AJAX request for each image in the gallery. This happens every time the media frame is opened.

6. Close the media frame

7. Save the post

8. Refresh
   
   When the editor loads, the images are fetched individually from the REST API.

Expected Behavior

I expected galleries to render more quickly. On my local machine, a gallery with 10 images could take anywhere from 4-10 seconds to render.

Possible Solution

Ideally, if a post has a gallery, the image data would be preloaded to prevent any extra requests during the initial load.

When opening the media frame, PR #2488 would help minimize requests .

When inserting a gallery from the media frame, all the data needed to render the gallery should be available in the wp.media.model.Attachments.all collection. It would be nice to use data that's already in memory instead of spawning a new request for each image. The other option would be to fetch data for all the images in a single request.

I did try disabling withAPIData for the GalleryImage component and everything seemed to continue working correctly, but I didn't test thoroughly. If that were removed, galleries would render almost instantly.

Related Issues and/or PRs

PR #2488 puts the media frame in the correct state when editing a gallery, but also prevents a separate AJAX request from being spawned for each image when opening the modal.

[aduth]

The original need for per-image requests was introduced in #2874 as part of gallery shortcode pasting (cc @iseulde). Seems for the majority of cases we don't have need for the API requests at all, so ideally they could be skipped. To support gallery shortcodes, I wonder if it would be better if the transform itself could return a promise to resolve to the block attributes, during which time it could transform the IDs to the expected attribute shape.

[designsimply]

I tested adding a gallery block with 10 images and then refreshing the editor page using WordPress 4.9.8 and Gutenberg 4.1.1 via an 72Mbps connection and found that refreshing the gallery page took ~6.2s (full test: 1m3s).

[antpb]

I believe with the recent changes in how we fetch images that this is now working as expected. I’ve verified on 4.3 that load time has improved from this reported issue and that the images are not loading in the way that we were seeing in the past. I am moving from the 5.0 RC milestone as this is not a blocker to RC.

The originally suggested PR was merged some time ago.