[wp-trac] [WordPress Trac] #6814: Async media crunching

[WordPress Trac]

#6814: Async media crunching
----------------------------------------------+----------------------------
 Reporter:  matt                              |       Owner:
                                              |  adamsilverstein
     Type:  enhancement                       |      Status:  assigned
 Priority:  normal                            |   Milestone:  Future
                                              |  Release
Component:  Upload                            |     Version:  2.5
 Severity:  normal                            |  Resolution:
 Keywords:  blessed dev-feedback needs-patch  |     Focuses:  performance
----------------------------------------------+----------------------------
Changes (by azaozz):

 * keywords:  blessed has-dev-note has-patch dev-feedback => blessed dev-
     feedback needs-patch


Comment:

 Replying to [comment:25 mukesh27]:
 > do we think we can add/fix it in the upcoming WordPress release?

 Would be great but there are a few "undecided problems" here.

 1. Certain image sub-sizes are typically needed immediately after
 uploading an image. Most common case is when a user adds an image to a
 post. The editor expects the proper/correct sub-size to be available as
 soon as the image has finished "crunching".

 2. The "how to trigger making of sub-sizes" is still undecided. The above
 patch makes them on the next request however that just moves the
 "bottleneck" of creating sub-sizes (can be in excess of 30 seconds) from
 the upload request to the next page load request. Not sure that's a good
 idea especially on bigger/busier sites where the next request is most
 likely to be on the front-end.

 3. Apart from creating image sub-sizes this patch would likely have to
 look at/handle converting uploaded images to WEBP format. Think there is
 another ticket specifically for this but likely the tickets should be
 merged as the solution would probably be the same.

 The negative effect from point 1 can probably be fixes to a large extend
 by creating just two sub-sizes on uploading an image, the `large` and
 `thumbnail` sizes. That will cover most use cases. In the rest of the
 cases WP will fall back on using one of these sub-sizes until the rest are
 created (that functionality already exists). As a side-note this won't
 work well for custom sub-sizes that crop the image.

 For point 2 there are several options. The above approach can be changed a
 bit so only one or two sup-sizes are created on each request. That may
 become a problem after uploading a lot of images (making a big gallery) on
 a site that sees a little traffic, but would be better than "locking down"
 the site for seconds.

 Another approach may be to try to implement the "selective sub-size
 creation method". Then only image sub-sizes that are requested will be
 created. Good part of it is that it will reduce disk use for sub-sizes,
 bad part is it would slow-down front-end image load times when the needed
 sub-size(s) do not exist yet. That slow-down may be quite significant when
 loading a gallery. Also thinking this may be affected by HTTP/2 and may
 result in PHP running out of memory or timing out when a lot of sub-sizes
 have to be created.

 As WEBP is supported by virtually all newer browsers thinking it may be
 worth it to convert all uploaded images to .webp on uploading. This would
 be handled in another ticket. If it's too early yet, seems WP will have to
 generate two formats of sub-sizes, original and WEBP. That can be handles
 in this ticket.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/6814#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform